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.
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.
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 pakiet cloudflared z repozytorium
Zacznijmy od pakietu dostępnego w repozytorium.
opkg update
opkg install cloudflared
Co ciekawego, przy moim pierwszym podejściu instalacja nie powiodła się, gdyż nie miałem wystarczającego miejsca na dysku a dokładniej w folderze /overlay.
* verify_pkg_installable: Only have 4268kb available on filesystem /overlay, pkg cloudflared needs 8792
* opkg_install_cmd: Cannot install package cloudflared.
Pakiet cloudflared wymaga niecałe 9 MB wolnego miejsca na naszym urządzeniu. Na moim routerze w pracy miałem nagle tylko nieco ponad 4 MB z 55 MB dostępnego na pakiety więc musiałem zrobić nieco porządków.
W systemie, na którym zacząłem moje przygody, posiadałem zainstalowany pakietów monitoringu w ramach monitoringu i ograniczenia transferu w sieci lokalnej na routerze z OpenWrt oraz pakiet monitoringu zasilacza awaryjnego UPS na routerze z OpenWrt.
Jako że zgodnie z moim wpisem prosty sposób na poprawę stabilności routera z OpenWrt nie musiałem zlecić routerowi, aby uruchomiał się ponownie co pewien czas, podczas mojego Uptime 146d 8h 53m 42s, baza danych któregoś z tych narzędzi przerosła się zajmując moje cenne miejsce na aplikacje.
Najprostszą metodą na rozwiązanie problemu okazało się ponowne uruchomienie routera.
Uruchomiłem ponownie router i nagle moje pakiety zajmowały niecałe 12 MB, a 43 MB było dostępne, a więc mogłem ponowić instalację.
Instalujemy pakiet cloudflared z repozytorium, drugie podejście
Jeszcze raz.
opkg update
opkg install cloudflared
Pora na przygotowanie pliku konfiguracyjnego zlokalizowanego w /etc/cloudflared/config.yml
Nim to zrobimy, zatrzymajmy pakiet cloudflared w naszym systemie, gdyż jest on domyślnie uruchomiony.
/etc/init.d/cloudflared stop
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:
2023-06-29T14:18:39Z INF Waiting for login...
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/
mv 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 /root/.cloudflared/<Tunnel-UUID>.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 <Tunnel-UUID>
Plik json musimy również skopiować (przenieść) w odpowiednią lokalizację.
mv /root/.cloudflared/<Tunnel-UUID>.json /etc/cloudflared/
Te informacje musimy wypełnić w naszym pliku konfiguracyjnym vim /etc/cloudflared/config.yml
#url: http://localhost:8000
tunnel: <Tunnel-UUID>
credentials-file: /etc/cloudflared/<Tunnel-UUID>.json
warp-routing:
enabled: true
Wstaw symbol
#na początkuurl:(nie jest ten parametr potrzebny) Oraz dodajwarp-routing: enabled: trueaby utworzyć tunel dla całej sieci.
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 > Access > Tunnels zobaczymy czy nasz tunel działa.
Tym sposobem wiemy, że tunel działa. Możemy powyższą komendę zakończyć.
Uruchomienie tunelu przy starcie
Aby nasz tunel uruchamiał się automatycznie przy starcie systemu, w postaci usługi działającej w tle, wykonujemy komendę:
/etc/init.d/cloudflared enable
Analogicznie, aby wystartować tunel, wykonujemy komendę:
/etc/init.d/cloudflared start
Uwaga spoiler: nie, nasz tunel nie startuje tą metodą (czytaj dalej).
Tunel nie staruje z pliku /etc/init.d/cloudflared
Niestety, plik startowy zlokalizowany w /etc/init.d/cloudflared dostarczony z pakietem w wersji 2023.6.1-1 nie startuje tunelu. Nie ma też żadnej informacji, dlaczego i co to powoduje.
Zgłosiłem ten problem na forum OpenWrt do autora wpisy na oficjalnej stronie OpenWrt.
W związku z tym, nim zajmiemy się naprawą tego stanu rzeczy, wystartujmy nasz tunel za pomocą komendy cloudflared aby skonfigurować pozostałe rzeczy. W późniejszym etapie zobaczymy jak temu zaradzić.
cloudflared tunnel run
Migracja tunelu
Gdy nasz tunel działa, przechodzimy do naszego tunelu na stronie Cloudflare Zero Trust i wybieramy opcję configure (lub po prostu klikamy na nazwę tunelu) w sekcji 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.0.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.
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.
Na tym etapie możemy zakończyć nasz tunel, który uruchomiliśmy komendą cloudflared tunnel run.
Problem z uruchomieniem tunelu przez /etc/init.d/cloudflared
/etc/init.d/cloudflared stop
/etc/init.d/cloudflared start
Mimo że wszystko zrobiłem prawidłowo, nadal moja usługa cloudflared zwracała:
/etc/init.d/cloudflared status
active with no instances
Podczas gdy mogę uruchomić tunel komendą bez problemu.
cloudflared tunnel run
Postanowiłem to sprawdzić, nim przejdę dalej.
Po chwili grzebania doszedłem do wniosku, że coś jest nie tak z plikiem /etc/init.d/cloudflared/ i miałem racje.
Postanowiłem zmienić jego nazwę (lub usunąć, jak kto woli) i utworzyć nową usługę do działania w tle przy użyciu komendy cloudflared w następujący sposób.
/etc/init.d/cloudflared stop
mv /etc/init.d/cloudflared /etc/init.d/cloudflared.old
cloudflared service install
/etc/init.d/cloudflared start
Takim sposobem nasz tunel, korzystając z nowego pliku, włączył się komendą /etc/init.d/cloudflared start i działa w tle. Jest postęp!
Problem z nowym plikiem startowym /etc/init.d/cloudflared
Jedyny problem jest to, że bez opcji kill -9 <Numer-PID> nie ma możliwości jego zatrzymania, gdyż nowy plik /etc/init.d/cloudflared z komendą stop nie działa.
/etc/init.d/cloudflared stop
To, że nasza usługa działa w tle, zobaczymy, wykonując komendę ps | grep cloudflared.
Plik startowy generowany przez cloudflared nie jest w pełni kompatybilny z oprogramowaniem OpenWrt, dlatego autor pakietu dla OpenWrt dostarczył własny plik, aby ten problem rozwiązać.
Postanowiłem więc przeanalizować różnice w plikach i zobaczyć, czy lepiej naprawić oryginalny (dostarczony z pakietem) plik startowy, czy ten, wygenerowany przez pakiet, który, jak można zauważyć, analizując jego zawartość, przygotowany jest do system Red Hat. Po krótkiej analizie postanowiłem naprawić (dostosować) nowy plik.
Naprawa nowego pliku startowego /etc/init.d/cloudflared
W pliku dla systemu Red Hat 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 ps $(get_pid) zmieniłem na ps | grep $(get_pid) (ale to nie koniec).
Przy tym prostym zabiegu nasza komenda /etc/init.d/cloudflared stop zaczęła działać.
Oprócz start i stop jest jeszcze restart oraz status.
Uruchamiając /etc/init.d/cloudflared status nawet gdy usługa nie jest uruchomiona, wyświetli tekst Running gdyż wychwytuje ona komendę grep.
W związku z tym zmodyfikowałem dalej ps | grep $(get_pid) na ps | grep $(get_pid) | grep -v grep aby wykluczyć grep z listy. To jest jedyna modyfikacja niezbędna do poprawienia tego pliku.
Takim sposobem wszystkie komendy pakietu cloudflared działają.
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.
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 pakiet /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 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:
