Dodanie Tunelu Cloudflare do routera z OpenWrt (alternatywa dla VPN)
Jeżeli śledzisz moją stronę i wpisy związane z OpenWrt to zapewne napotkałeś się na mój wpis odnośnie instalacji serwera VPN na routerze z OpenWrt z użyciem WireGuard.
WireGuard jest jednym z najszybszych dostępnych protokołów służących stworzeniu połączenia VPN. Dzięki niemu, z poziomu Internetu, możemy bez problemu połączyć się z naszą siecią i używać jej, albo do celów lokalnych (dostęp do drukarki lub dysku sieciowego) lub w celu ograniczeń restrykcji regionalnych. Będąc poza krajem, mogę w każdej chwili połączyć się z moim routerem i moje urządzenie wyglądać będzie w Internecie tak, jakby znajdowało się tam, gdzie jest router, czyli w Wielkiej Brytanii.
To super szybkie rozwiązanie wiąże się jednak z koniecznością konfiguracji, która czasami może być złożona i powodować przeróżne błędy (choć z reguły jest dużo łatwiejsza a niżeli inne VPN-y).
WireGuard ma również pewne ograniczenie. Aby połączyć się z naszym routerem, musimy dysponować zewnętrznym (statycznym lub dynamicznym, bez znaczenia) adresem IP.
W przypadku zmiennego (dynamicznego) adresu IP możemy ustawić domenę zgodnie ze wpisem Ustawienie domeny dla zmiennego adresu IP (OpenWrt i DDNS)
W przypadku gdy nasze połączenie internetowe nie posiada zewnętrznego adresu IP, tak jak w przypadku opisanym w moim wpisie Dodanie drugiego połączenia internetowego do routera z OpenWrt, wówczas mamy problem.
Większość połączeń mobilnych (4G/5G) nie dysponuje zewnętrznym adresem IP, a dodatkowo każdy użytkownik umieszczony jest za tak zwanym CG-NATem.
Osobiście opisałbym CG-NAT jako sieć użytkowników wewnątrz innej sieci przynależącej do współdzielonego zewnętrznego adresu IP. Nasz router (nasza sieć) umieszczona jest w innej sieci, w której znajduje się router, który posiada zewnętrzny adres IP, nad którym nie mamy kontroli.
W pracy posiadam skonfigurowany router z OpenWrt w taki sposób, gdy połączenie główne wysiądzie, to połączenie mobilne zostaje aktywowane. Użytkownicy w sieci lokalnej mogą nadal pracować, jednakże ci, którzy łączą się za pośrednictwem WireGuard, mają problem.
Postanowiłem spróbować użyć metody na stworzenie tunelu, który niezależnie od tego, czy posiadamy zewnętrzny adres IP, czy jesteśmy za CG-NAT, czy też nie chcemy się bawić w konfigurację WireGuard lub przekierowywania portów na routerze, pozwoli nam na dostęp do zasobów sieci lokalnej z Internetu.
Tutaj napotkałem na rozwiązanie Hectora Moliny z wykorzystaniem Cloudflare Tunnel i Zero Trust Network Access.
Autor oryginalnego wpisu podkreślił brak pakietu cloudflared w repozytoriach OpenWrt, który w prosty sposób pozwoliłby na instalację i konfigurację tunelu.
Tutaj poniekąd sytuacja się ostatnio zmieniła, gdyż pakiet jest dostępny z poziomu komendy opkg, jeżeli chodzi o oprogramowanie OpenWrt 22.03. Jednakże, jak się przekonałem, pakiet ten nie jest na bieżąco aktualizowany oraz w pełni nie działa. Nie bez powodu pakietu tego brakuje w repozytoriach najnowszej wersji OpenWrt 23.05.
W związku z tym opisze tutaj jak utworzyć tunel Cloudflare z wykorzystanie pakietu dla naszego routera dostarczonego bezpośrednio przez ekipę z Cloudflare. Dodatkowo nie musimy się przejmować o jego aktualizacje, gdyż będzie się on aktualizował automatycznie, jak tylko nowa wersja zostanie opublikowana.
Oprócz całego tunelu CouldFlare ma swoją aplikację 1.1.1.1 (Cloudflare WARP), która pozwala na skonfigurowanie jej w celu połączenia się z naszym tunelem. Dzięki temu nie musimy się bawić w konfigurację profili dla każdego użytkownika.
Dla systemu macOS dostępna jest aplikacja Cloudflare WARP oraz Cloudflare ONE. Cloudflare One pozwala na skonfigurowanie naszego tunelu niezależnie od aplikacji WARP, dzięki czemu mamy możliwość użytkowania zarówno WARP, jak i skonfigurowanego tunelu bez konieczności przelogowywania się za każdym razem.
Mimo tego, że WireGuard jest moim domyślnym podejściem, jeżeli chodzi o połączenie zdalne z siecią domową, to warto mieć alternatywę do dyspozycji, która w ramach zmieniających się warunków, może rozwiązać takie bolączki, jakim jest CG-NAT.
Dodatkowo tunel nie wymaga od nas otwierania żadnych portów na naszym routerze w celu połączenia, tak jak to jest w przypadku Wireguard. Pozwala on również ominąć wszelkie ograniczenia sieciowe.
Można to opisać, porównując tunel, do sposobu połączenia się za pomocą aplikacji TeamViewer. Bez znaczenia czy mamy zewnętrzny adres IP, jesteśmy za CG-NAT lub nie, o ile połączenie internetowe działa, o tyle jest możliwość stworzenia tunelu w celu otrzymania dostępu do naszej sieci.
Instalujemy oficjalny pakiet cloudflared
W oprogramowaniu OpenWrt w wersji 22.03 jest możliwość zainstalowania pakietu cloudflared przy pomocy komendy opkg, jednakże nie polecam tego, gdyż pakiet ten jest wadliwy, a dokładniej plik inicjujący nasz tunel nie działa.
Po aktualizacji do najnowszej wersji OpenWrt 23.05 nie ujrzymy pakietu cloudflared w repozytorium co po części ułatwi sprawę, gdyż pozbędziemy się związanych z tym problemów.
Wcześniej niniejszy wpis opierał się na pakiecie z repozytorium, jednak zmodyfikowałem go, aby te samo rozwiązanie użyć niezależnie czy używamy OpenWrt 22.03, czy też 23.05.
Nim zaczniemy drobna uwaga. Pakiet cloudflared wymaga prawie 32 MB wolnego miejsca na naszym urządzeniu. Upewnij się, że twój router, a dokładniej partycja
/overlay, posiada co najmniej dwu krotność miejsca potrzebnego na ten pakiet.
Cloudflare dostarcza pakiet dla kilku platform. W przypadku routerów z OpenWrt potrzebujemy pakiet dla platformy ARM dla systemu Linux.
W tym celu wykonujemy poniższą komendę:
wget --no-check-certificate -O /usr/bin/cloudflared https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-arm
Nadajemy prawa do wykonywania (uruchamiania):
chmod +x /usr/bin/cloudflared
I uruchamiamy, sprawdzając, czy nasz plik działa:
root@OpenWrt:~# cloudflared version
Powinniśmy zobaczy coś takiego:
cloudflared version 2023.10.0 (built 2023-10-31-1235 UTC)
Na tym etapie przechodzimy na stronę Cloudflare Zero Trust gdzie wybieramy użytkownika, po czym ustalamy nazwę naszej “drużyny” przypisanej w domenie cloudflareaccess.com
Zapamiętaj nazwę “drużyny” (team), gdyż będziesz ją potrzebować w celu skonfigurowania użytkowników na ich urządzeniach. Jeżeli zapomnisz, możesz ją znaleźć (i zmienić) w Settings > Custom pages.
Następnie musimy wybrać plan taryfowy. Oczywiście, na początku wybieramy plan darmowy (Free).
W ramach darmowego planu możemy mieć do 50 użytkowników usługi, co jest bardzo hojne.
Takim sposobem rozpoczęliśmy zabawę.
Na tym etapie musimy utworzyć nasz tunel. Tę zabawę robimy po stronie naszego routera.
cloudflared tunnel login
Wykonując tę komendę, otrzymamy link, który musimy wkleić w naszą przeglądarkę internetową, aby zalogować się do Cloudflare.
Na dalszym etapie wybierzemy domenę, dla której autoryzujemy nasz tunel.
Jeżeli wszystko poszło prawidłowo, otrzymamy informacje, że Cloudflare utworzył certyfikat umożliwiający utworzenie tunelu.
Nasz terminal wyświetli:
root@OpenWrt:~# cloudflared tunnel login
Please open the following URL and log in with your Cloudflare account:
https://dash.cloudflare.com/argotunnel?...
Leave cloudflared running to download the cert automatically.
You have successfully logged in.
If you wish to copy your credentials to a server, they have been saved to:
/root/.cloudflared/cert.pem
Plik cert.pem musimy skopiować (przenieść) do folderu /etc/cloudflared/
mkdir /etc/cloudflared
mv /root/.cloudflared/cert.pem /etc/cloudflared/
Następnie utworzymy nasz tunel:
cloudflared tunnel create Nazwa-Tunelu
Nasz terminal wyświetli informację, gdzie zapisane zostały uwierzytelnienia oraz ID naszego tunelu.
Tunnel credentials written to /etc/cloudflared/b26bb351-46ca-4fc1-a157-0ecdc1560658.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel Nazwa-Tunelu with id b26bb351-46ca-4fc1-a157-0ecdc1560658
Moje ID w tym przykładzie to
b26bb351-46ca-4fc1-a157-0ecdc1560658, twój będzie inny.
Te informacje musimy wypełnić w naszym pliku konfiguracyjnym vim /etc/cloudflared/config.yml
tunnel: b26bb351-46ca-4fc1-a157-0ecdc1560658
credentials-file: /etc/cloudflared/b26bb351-46ca-4fc1-a157-0ecdc1560658.json
warp-routing:
enabled: true
Pozostaje nam uruchomienie naszego tunelu i sprawdzenie, czy wszystko działa.
Kilka zabiegów korygujących (wymagane)
Nim to jednak zrobimy, jest jeszcze dodatkowy krok, który myśmy wykonać po stronie naszego routera w celu poprawienia kilku błędów, które wyświetlają się podczas uruchomienia tunelu.
- Tworzymy plik
touch /etc/sysctl.d/99-fix-buffer-and-ping.conf - Dodajemy do pliku poprzez
vim /etc/sysctl.d/99-fix-buffer-and-ping.confnastępujące linijki
net.core.rmem_max=2500000
net.ipv4.ping_group_range=0 2147483647
- Uruchamiamy następującą komendę
sysctl -p /etc/sysctl.d/99-fix-buffer-and-ping.conf.
Zapobiega to problemowi podczas uruchamiania:
WRN The user running cloudflared process has a GID (group ID) that is not within ping_group_range. You might need to add that user to a group within that range, or instead update the range to encompass a group the user is already in by modifying /proc/sys/net/ipv4/ping_group_range. Otherwise cloudflared will not be able to ping this network error="Group ID 0 is not between ping group 1 to 0"
WRN ICMP proxy feature is disabled error="cannot create ICMPv4 proxy: Group ID 0 is not between ping group 1 to 0 nor ICMPv6 proxy: socket: permission denied"
Teraz możemy uruchomić nasz tunel.
cloudflared tunnel run Nazwa-Tunelu
Po przejściu do panelu Cloudflare Zero Trust > Network > Tunnels (było Access > Tunnels) zobaczymy czy nasz tunel działa.
Tym sposobem wiemy, że tunel działa. Możemy powyższą komendę zakończyć (Ctrl+C dla Windows, lub Cmd+C dla macOS).
Migracja tunelu
Uruchamiamy jeszcze raz, ręcznie, nasz tunel i przechodzimy do naszego tunelu na stronie Cloudflare Zero Trust i wybieramy opcję configure (lub po prostu klikamy na nazwę tunelu) w sekcji Network > Tunnels (było Access > Tunnels ).
Tutaj otrzymamy opcję migracji tunelu, którą musiały wykonać.
Klikamy przycisk Start migration, potwierdzamy przy każdym pytaniu (nie wprowadzając żadnych danych) przyciskiem Confirm kończąc Migrate tunnel.
Dodanie adresów naszej sieci lokalnej
Klikamy ponownie nasz tunel i przycisk Configure.
W zakładce Private Network dodajemy nasze lokalne adresy, które używamy w naszej sieci.
Jako że do Wireguard używam pulę 10.0.0.(1-254) a w sieci 192.168.0.(1-254) dodałem je następująco.
10.0.0.0/24
192.168.1.0/24
Dostęp do sieci lokalnej - Split Tunnel
Dodatkowo musimy podzielić tunel (Split Tunnel), aby można było za uzyskać dostęp do sieci lokalnej.
W tym celu przechodzimy do Settings > WARP Client i klikamy w sekcji Device settings na nasz domyślny profil (Default).
Przechodzimy do sekcji Split Tunnels, który domyślnie ustawiony jest na Exclude IPs and domains i klikamy przycisk Manage.
Tam na liście wykluczeń odszukujemy adresy sieci, które odpowiadają naszej sieci lokalnej, w tym przypadku 10.0.0.0/8, 192.168.0.0/16, 192.0.0.0/24 i usuwamy je.
Na tym etapie możemy zakończyć nasz tunel.
Dodanie obsługi pakietów UTP i ICMP (ping)
Oprócz tego przechodząc do Settings > Network, w sekcji Firewall włączamy Proxy i zaznaczamy, oprócz domyślnie włączonych pakietów TCP, również UTP oraz ICMP.
Dzięki temu rozszerzymy funkcjonalność naszego tunelu a dodatkowo zyskamy możliwość wykonywania polecenia ping do naszych urządzeń w sieci lokalnej, co jest bardzo przydatne w celu analizowania czy nasz tunel działa, czy nie.
Włączamy również usługę WARP to WARP.
Uruchomienie tunelu
Podczas instalowania pakietu cloudflared z repozytorium OpenWrt 22.03, wraz z nim dostarczany jest plik startowy instalowany w /etc/init.d/cloudflared. Plik ten jest jednak wadliwy i nie działa, dlatego go nie używamy.
W przypadku oficjalnego pakietu nie dysponujemy domyślnie tego rodzaju plikiem, co po części uprości nam całą procedurę.
Aby go utworzyć, wykonujemy następującą komendę:
cloudflared service install
Dzięki temu otrzymamy plik w zapisany w
/etc/init.d/cloudflared, który niestety nie do końca działa, ale jest na to rozwiązanie opisane poniżej.
Plik startowy nie jest przystosowany do pracy z OpenWrt. Pakiety dostępne na routerze, takie jak ps nie są takie same (nie posiadają tych samych opcji) co w innym Linuxowym systemie.
Nasz tunel wystartuje komendą /etc/init.d/cloudflared start bez problemu, ale zatrzymanie komendą stop nie działa i mimo tego, że status pokazuje, że tunel nie działa, to nadal widzimy go, gdy wykonamy komendę ps | grep cloudflared.
Plik startowy generowany przez cloudflared przeznaczony jest dla systemu Linux Redhat (jak można zobaczyć, wykonując komendę head -2 /etc/init.d/cloudflared).
Naprawa nowego pliku startowego /etc/init.d/cloudflared
W pliku dla systemu RedHat prawie na samym początku, mamy następującą komendę:
is_running() {
[ -f "$pid_file" ] && ps $(get_pid) > /dev/null 2>&1
}
Komenda ps w OpenWrt nie posiada za dużo opcji, więc nie można po prostu wyświetlić procesu, podając jego PID (ps 14535 nie zadziała).
W tym celu następującą część:
ps $(get_pid)
zmieniamy na:
ps | grep $(get_pid) | grep -v grep
Komenda
grep -v grepna na celu wykluczenie pakietu grep z odpowiedzi, jaką otrzymamy.
Takim sposobem wszystkie komendy pakietu cloudflared działają i jesteśmy gotowi do dalszej konfiguracji.
Usage: /etc/init.d/cloudflared {start|stop|restart|status}
Logowanie się do tunelu za pomocą aplikacji 1.1.1.1 (Cloudflare WARP)
Podczas gdy nasz tunel działa, musimy rozpocząć konfigurację naszych użytkowników.
Nim to nastąpi, musimy określić, kto może logować się do naszego tunelu.
Metoda logowania
W panelu Cloudflare Zero Trust przechodzimy do Settings po czym Authentication gdzie możemy dodać sposoby logowania w Login methods.
Skupię się tutaj na tym, co jest włączone domyślnie, a mianowicie One-time PIN i to wykorzystamy na początku.
Jak zauważysz, dostępne są tam opcje, dzięki którym możemy określić na przykład, że użytkownik będzie musiał zalogować się za pomocą konta Google, aby potwierdzić tożsamość i wraz z ustaloną (na dalszym etapie) regułą logowania połączyć się z tunelem.
Osoba logująca się w naszym tunelu będzie musiała podać nazwę “drużyny” (team), którą sprecyzowaliśmy na początku w domenie cloudflareaccess.com.
Przypomnę, że możemy ją zobaczyć w Settings > Custom pages.
Nim to jednak zrobimy, musimy określić, kto może się logować, ustalając regułę logowania.
Reguła logowania
W tym celu w Settings przechodzimy do WARP Client > Device enrollment permissions. Klikając przycisk Manage utworzymy nową regułę w sekcji Policies za pomocą przycisku Add a rule.
- Nazwę reguły (Rule name) ustaliłem Allowed emails.
- Regułę akcji (Rule action) pozostawiłem na Allow
- W sekcji Include wybrałem (Selector) Emails a w polu wartości (Value) wpisałem mój adres email.
Możemy tutaj również określić, że wszyscy użytkownicy w domenie mogą się logować do tunelu (Emails ending in). Jeżeli dysponujemy własną domeną oraz adresami email w niej skonfigurowanej, ograniczy to konieczność dodawania każdego adresu email/użytkownika z osobna.
Podczas logowania się w aplikacji 1.1.1.1/Cloudflare WARP będę musiał podać mój email, na który dostanę hasło jednorazowe do wpisania w aplikacji, dzięki któremu zostanę uwierzytelniony i zalogowany.
<script async delay="https://dariusz.wieckiewicz.org/g/serve.js?client=ca-pub-5380116874441486"
crossorigin="anonymous"></script>
<ins class="adsbygoogle"
style="display:block; text-align:center;"
data-ad-layout="in-article"
data-ad-format="fluid"
data-ad-client="ca-pub-5380116874441486"
data-ad-slot="9220966978"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
Aplikacja
Zacznijmy od aplikacji na nasze urządzenie mobilne.
Dla systemu iOS, dostępna jest ona w App Store. Wszelkie inne (odnośniki do nich) wyświetlone są, gdy przejdziemy na stronę 1.1.1.1 w naszej przeglądarce internetowej.
Po wstępnym uruchomieniu i skonfigurowaniu profilu VPN do standardowej usługi WARP przechodzimy do ustawień (trzy poziome kreski) > Account > Login to Cloudflare Zero Trust
Na tym etapie poproszeni zostaniemy o nazwę naszej “drużyny” (team) i przekierowani zostaniemy do strony logowania. Wprowadzamy tam zatwierdzony adres email, po czym otwieramy nasz email i odczytujemy otrzymany kod, który wprowadzamy w aplikacji.
Po zalogowaniu moja aplikacja Cloudflare WARP (1.1.1.1) zmieni nieco wygląd, a opcje ograniczą się do pojedynczego przycisku włączenia/wyłączenia tunelu Zero Trust.
W analogiczny sposób (Preferences > Account > Login to Cloudflare Zero Trust) dokonamy tego w aplikacji na naszym komputerze.
Podtrzymanie tunelu w przypadku zmiany adresu IP (opcjonalne)
Jedynym problemem, jaki mi pozostał to upewnienie się, że tunel będzie nadal działa, gdy adres IP interfejsu internetowego ulegnie zmianie lub też internet będzie przekierowany przez inny interfejs.
W moim przypadku gdy główne połączenie internetowe ze statycznym adresem IP przestanie działać, a awaryjne (za CG-NAT) zostanie aktywowane.
Jak sprawdziłem, aktywny tunel nie wykrywa faktu, że adres IP, lub interfejs dostępowy, uległ zmianie. Mimo że tunel jest włączony, to będzie on nieaktywny.
Z pakietem mwan3
Odniesienie do wpisu Dodanie drugiego połączenia internetowego do routera z OpenWrt
W moim przypadku, w momencie przełączenia internetu na awaryjne połączenie, pakiet mwan3 zadba o to, aby w sieci lokalnej nadal było połączenie internetowe.
Pakiet mwan3 ma możliwość wykonania komendy w momencie, gdy jedno z połączeń przestanie działać. Mogę to teoretycznie wykorzystać do zatrzymania tunelu Cloudflare i uruchomienia na nowym połączeniu.
W panelu LuCI przechodzimy do Network > MultiWAN Manager i zakładki Notify.
Tutaj możemy wykonać następujący skrypt.
if [ "${ACTION}" = "ifdown" ] || [ "${ACTION}" = "ifup" ] && [ "${INTERFACE}" = "wan" ] ; then
(/bin/sleep 30; /etc/init.d/cloudflared restart >/dev/null) &
fi
W przypadku gdy nasz interfejs WAN przestanie działać (lub ponownie się uruchomi), skrypt odczeka 30 sekund, po czym zrestartuje nasz tunel Cloudflare.
Inny przykład:
if [ "${ACTION}" = "ifdown" ] || [ "${ACTION}" = "ifup" ] ; then
if [ "${INTERFACE}" != "loopback" ] && [ "${INTERFACE}" != "self" ] ; then
(/bin/sleep 30; /etc/init.d/cloudflared restart >/dev/null) &
fi
fi
Gdy którykolwiek z interfejsów przestanie działać lub wznowi działanie (ignorując interfejs loopback), poczekaj 30 sekund i uruchom ponownie tunel Cloudflare.
Chciałbym jednak przeanalizować inne opcje, gdy tylko nasz adres IP, z którego nawiązane jest połączenie, ulegnie zmianie.
Poprzez analizę adresu IP
Tak jak opisałem w moim wpisie Ustawienie domeny dla zmiennego adresu IP (OpenWrt i DDNS) i sekcji Obsługa wielu połączeń internetowych z DDNS (gdy powyższe rozwiązanie nie działa), za pomocą curl możemy odczytać zewnętrzny adres IP z danego interfejsu.
Jeżeli nasz zapasowy interfejs ma IP na routerze 192.168.8.2, wykonujemy następującą komendę, aby odczytać IP.
curl -s --interface 192.168.8.2 'http://icanhazip.com'
Pozwoli to nam odczytać aktualny adres IP.
Osobiście, w domu, posiadając jeden interfejs, zapiszę mój adres IP do pliku, wykonując komendę porównywania, gdy adres IP się zmieni, uruchomię ponownie tunel.
Komenda do odczytania adresu IP i zapisanie w pliku tymczasowym jest następująca.
curl -s 'http://icanhazip.com' > /tmp/ip_read
Odczytanie adresu IP dodam do harmonogramu cron aby wykonywało się raz na dobę, minutę po północy.
01 0 * * * curl -s 'http://icanhazip.com' > /tmp/ip_read
Do harmonogramu dodam również mój skrypt, który będzie odczytywał adres IP i porównywał z odczytanym wcześniej. W momencie, gdy adres IP ulegnie zmianie, tunel zostanie uruchomiony ponownie. Skrypt będzie uruchamiany co 5 minut.
*/5 * * * * /bin/sh /root/ip_check_script
Zawartość pliku ip_check_script
FILE1="/tmp/ip_read"
curl -s 'http://icanhazip.com' > /tmp/ip_check
FILE2="/tmp/ip_check"
if cmp -s -- "$FILE1" "$FILE2"; then
# IP not changed, don't do anything
:
else
# ip address differ, run the following
/etc/init.d/cloudflared restart > /dev/null
# update ip_read
cp /tmp/ip_check /tmp/ip_read
fi
Dodajemy prawa do uruchimienia
chmod +x ip_check_script
Dodamy również do harmonogramu cron sprawdzenie adresu IP po ponownym uruchomieniu routera.
@reboot sleep 15 && curl -s 'http://icanhazip.com' > /tmp/ip_read
Aby komenda resetowania tunelu nie była wykonywana co 5 minut (mimo że adres IP nie uległ zmianie), w momencie, gdy adres IP odczytany na bieżąco ulegnie zmianie, wówczas plik ip_read zostanie zaktualizowany.
Automatyczne uruchomienie tunelu przy starcie routera
Domyślnie dostarczony z pakietem cloudflared, z repozytorium OpenWrt 22.03, /etc/init.d/cloudflared, który nie działał, a który zastąpiliśmy i naprawiliśmy, posiadał opcję uruchomienia usługi podczas startu routera (enabled).
Nowy, oficjalny, plik ma tylko cztery opcje (start, stop, restart i status).
Aby sprawićm by nasz tunel startował po uruchomieniu, wykorzystamy do tego harmonogram cron.
Dodajemy następującą linijkę.
@reboot sleep 15 && /etc/init.d/cloudflared start
Do powyższej linijki dodałem odczekanie 15 sekund. W niektórych przypadkach należy odczekać nieco dłużej, szczególnie gdy zajmuje routerowi trochę nawiązanie połączenia z internetem.
Failsafe — Sprawdzenie okresowe czy tunel działa
Jeżeli zrobiliśmy wszystko poprawnie, to nasz tunel bez problemów powinien działać, jednakże zdarzają się sytuacje, gdy nasz tunel (proces) przestanie działać.
W związku z tym warto wprowadzić swojego rodzaju sprawdzenie. W momencie wykrycia, że tunel nie działa, wykonać komendę, aby go wskrzeszać.
Do tego celu możemy wykorzystać 2 rodzaje komend. Wybierz jedną, którą uważasz za słuszną. Osobiście preferuję pierwsze rozwiązanie.
Wybraną komendę dodamy do harmonogramu cron wykonywanego co 5 minut. W momencie, gdy nasza komenda wykryje, że nasz tunel nie działa, spróbuje go ponownie uruchomić.
*/5 * * * * /bin/sh /root/cloudflared_check
Sprawdzenie za pomocą opcji /etc/init.d/cloudflared status
if [[ $(/bin/sh /etc/init.d/cloudflared status) == "Running" ]];
then
:
else
/bin/sh /etc/init.d/cloudflared restart
fi
Powyższą komendę zapisujemy w plik /root/cloudflared_check i nadajemy mu prawa do wykonywania chmod +x /root/cloudflared_check.
Sprawdzenie przy pomocy pakietu pgrep
if pgrep cloudflared >/dev/null
then
:
else
/bin/sh /etc/init.d/cloudflared restart
fi
Powyższą komendę zapisujemy w plik /root/cloudflared_check i nadajemy mu prawa do wykonywania chmod +x /root/cloudflared_check.
Zarządzanie użytkownikami
Podczas gdy wszystko działa, a użytkownicy mogą korzystać z nowej usługi, aby zobaczyć jakie urządzenia oraz jacy użytkownicy są dostępni, możemy to zrobić z sekcji My Team i odpowiednio Devices (Urządzenia) oraz Users (Użytkownicy).
Również tam możemy wycofać prawa logowania danemu użytkownikowi za pomocą opcji Revoke.
Dołączenie plików konfiguracyjnych do kopii zapasowej OpenWrt
Jeżeli wykonujesz kopię zapasową OpenWrt z menu System > Backup / Flash Firmware, w zakładce Configuration dodaj następujące foldery, aby włączone były one w plik kopii zapasowej.
/etc/cloudflared/
Osobiście, jako że posiadam również inne pakiety, w tym WireGuard, moje foldery wyglądają następująco:
/etc/ssl/
/etc/wireguard/
/etc/cloudflared/
/etc/config/
/etc/init.d/
/root/
Bonus
Nie wiem, czy wiesz, że jako bonus całej tej zabawy, będąc połączony do własnego tunelu, zyskujesz dostęp do sieci za pomocą IPv6 (od strony użytkowników, nie routera).
Źródła:
