Z racji tego, że od dawna korzystam z internetu mobilnego, jako podstawowego dostępu, to jedną z konsekwencji tego, jest brak publicznego (i najlepiej stałego) adresu IP. Niby da się, bo tak miałem w Otvarta, ale nasze drogi rozeszły się i raczej nie planuję, by to miało się zmienić. W każdym razie w Orange Flex, gdzie obecnie „siedzę”, mam tylko prywatny adres IP, czyli jestem za NATem. Tak więc by uzyskać dostęp do lokalnych zasobów z zewnątrz (np. połączenie po SSH do różnych urządzeń, zdalny dostęp do Home Assistant, czy paneli zarządzania alarmem i kamerami), muszę korzystać z alternatywnych do publicznego adresu IP rozwiązań. I jednym z takich rozwiązań jest usługa Zero Trust od Cloudflare.

Zero Trust od Cloudflare, czyli dostęp do lokalnych zasobów z internetu

Nie jest to jedyne rozwiązanie „tego typu”, z którego korzystam (o „tym drugim” mam nadzieję, że napisze niebawem), ale Zero Trust od Cloudflare jest dla mnie o tyle naturalnym wyborem, że i tak korzystam z usług Cloudflare, gdzie mam „zaparkowane” prawie wszystkie swoje domeny, pod którymi „coś jest”. A skoro chcę mieć dostęp zdalny, do tego najlepiej „po domenie”, to wybór był oczywisty. Zwłaszcza że – przynajmniej w większości przypadków – korzystanie z usługi Zero Trust nie wiążę się z żadnymi opłatami.

Domena i sprzęt, czyli niezbędne minimum

I tu od razu na wstępie zaznaczę, że do skorzystania z usługi Zero Trust – przynajmniej w kontekście tego artykułu – będzie potrzebne nie tylko konto w Cloudflare, ale również „zaparkowana” tam jakaś domena. Nie ma znaczenia jaka, ale jakaś musi być, bo jej subdomeny będziemy wykorzystywali do zdalnego dostępu (z internetu) do lokalnych (tych „w domu”) zasobów.

Samo konto w Cloudflare jest bezpłatne, a co do domeny… Można skorzystać z bezpłatnych domen, ale chyba lepszym rozwiązaniem jest po prostu zakup jakiejś domeny. Zwłaszcza że w przypadku „tańszych końcówek”, koszt to jakieś 10-15 zł rocznie.

Niezbędne też będzie jakieś urządzenie działające w ramach sieci lokalnej (LAN), na którym będzie można zainstalować agenta Cloudflare. Czy to bezpośrednio, czy np. w ramach Dockera (konkretnie Docker Compose). W moim przypadku zazwyczaj są to różne wersje Raspberry Pi, na których działa Raspberry Pi OS (Debian). W jednej lokalizacji jest to nawet już dość archaiczny układ, bo Raspberry Pi B+, czyli lekko podrasowana pierwsza Malina. Zresztą to też jest powód, dlaczego poza Zero Trust od Cloudflare korzystam dodatkowo z „tego drugiego” rozwiązania, o którym pewnie niebawem… ;-)

Cloudflared, czyli tunel w ramach usługi Zero Trust od Cloudflare

Skoro konto w Cloudflare jest, domena dodana i skonfigurowana, to można stworzyć pierwszy tunel (swego rodzaju proxy między internetem a siecią LAN). Tunel, czyli pewnego rodzaju proxy, które połączy serwery Cloudflare w internecie, z którymi będziemy się łączyć, z urządzeniem znajdującym się w naszej sieci lokalnej, na którym działa agent (Cloudflared), który jest pewnego rodzaju „tunelowym routerem”. Dzięki temu możemy mieć dostęp nie tylko do zasobów na tym urządzeniu, ale też na innych urządzeniach, na których już nie trzeba instalować oprogramowania do usługi Zero Trust od Cloudflare, czyli Cloudflared.

Po zalogowaniu się do usługi Zero Trust (kontem Cloudflare, na którym mamy domenę, z której będziemy korzystać) przechodzimy do sekcji „networks”, a następnie „tunnels”. I klikamy „create a tunnel”.

W tym momencie uruchomi się „kreator nowego tunelu”. Jako typ wybieramy „cloudflared” i w następnym kroku nadajemy jakąś nazwę naszemu (nowemu) tunelowi:

Kolejny krok to instalacja agenta, czyli Cloudflared na urządzeniu w sieci lokalnej. Do wyboru są (prze)różne systemy – Windows, Mac, Linux, Docker. Zarówno w wersji x86 i x64, jak i  arm32 i arm64:

Ja korzystam z Linuksa na Raspberry Pi, ale to nie ma większego znaczenia, bo niezależnie od tego, co wybierzemy, pojawi się odpowiednia instrukcja instalacji agenta. Dlatego też nie będę tego szczegółowo tutaj opisywał, bo wystarczy wykonać kroki przedstawione w tym kroku. Dodam tylko, że w przypadku Dockera można też skorzystać z Docker Compose, o czym wspominałem przy okazji artykułu o trochę „kontrowersyjnym tytule”, czyli że Home Assistant porzuca HAOS… ;-)

Po całej operacji na liście tuneli będzie nowo dodany tunel, wraz z informacją o jego statusie:

Na specjalnie przygotowanym na potrzeby artykułu koncie mam 2 tunele (RPi01 i RPi02), które działają, o czym świadczy napis „healthy” na zielonym tle.

Dodawanie (i edycja) hosta

Gdy tunel aktywny, można przystąpić to głównego punktu programy, czyli do konfiguracji hostów, a więc usług działających w sieci lokalnej, które chcemy, by były dostępne „z internetu”.

Tak więc klikamy na nazwie tunelu i w oknie, które się otworzy wybieramy „edit” (można też kliknąć trzy pionowe kroki na liście tuneli i wybrać „configure”):

W tym momencie pojawi się ekran konfiguracji tunelu. Z racji tego, że nas interesują „hosty”, to od razu przechodzimy do zakładki „public hostname”, gdzie znajdziemy listę wszystkich usług dostępnych za pomocą danego tunelu:

W przypadku jednego z testowych tuneli przygotowałem już kilka usług – jest to panel Home Assistant (dostęp potrzebny zwłaszcza dla mobilnej aplikacji Home Assistant), kilka kamer YI z oprogramowaniem YI-Hack, oraz 2 instancje ESPhome.

By dodać nowego hosta, czyli lokalną usługę (sieć LAN), która będzie dostępna z internetu, klikamy „add a public hostname”.

Wpisujemy jakąś subdomenę, np. „home” dla Home Assistant i wybieramy domenę z listy (są tu widoczne wszystkie domeny dodane do konta Cloudflare). Jest to adres, pod którym będzie dostępna usługa i składa się on z subdomeny (np. home) i domeny (np. webinsider.pl), co daje adres home.webinsider.pl, i właśnie pod takim adresem będzie dostępna usługa.

Niżej wybieramy typ usługi. Zapewne najczęściej będzie to:

• HTTP, gdy usługa lokalnie działa bez szyfrowania
• HTTPS, gdy usługa lokalnie działa z szyfrowaniem

I tu od razu mała uwaga: połączenie przez tunel Cloudflare, czyli między nami, Cloudflare i urządzeniem w sieci LAN z aplikacją Cloudflared, są zawsze szyfrowane (HTTPS), niezależnie od tego, czy lokalnie, wewnątrz sieci LAN, dana usługa działa po HTTP czy HTTPS.

Czasem przydaje się jeszcze SSH (dostęp do SSH), RDP (pulpit zdalny), czy SMB (Samba).

Z racji tego, że u mnie, w testowej sieci lokalnej (LAN) np. Home Assistant działa bez SSLa, to jako typ wybieram „HTTP” i podaję adres IP i (opcjonalnie) port, pod jakim jest dostępny, czyli:

http://10.0.0.1:8123

Oczywiście ten element należy dostosować do własnych potrzeb. Nie tylko, jeśli chodzi o tym, ale również URL i port.

Zabezpieczanie dostępu

I choć są lokalne usługi, które chcemy lub musimy wystawić w świat bez dodatkowych mechanizmów kontrolujących dostęp, to w przypadku niektórych usług taka dodatkowa autoryzacja będzie nie tylko wskazana, ale czasem wręcz niezbędna.

Np. panel do Home Assistant mam wystawiony bez dodatkowej autoryzacji po stronie Zero Trust, a więc każdy, kto zna adres, może się z nim połączyć, to jest to działanie celowe. Zwłaszcza że na początek przywita każdego ekran logowania, wraz z dwuskładnikową autoryzacją. Ale mam też „wystawione w świat” usługi, które chcę bronić dodatkowo, lub muszę, bo nie mają w standardzie odpowiednich mechanizmów uwierzytelnienia (np. panel ESPHome).

I tu z pomocą przychodzi kolejna opcja dostępna w ramach usługi Zero Trust od Cloudflare, czyli możliwość ustawienia dodatkowych mechanizmów pilnujących dostępu do udostępnionych w ramach usługi zasobów.

Przechodzimy do sekcji „access” i następnie „applications”. Na początku jest tu pusto, więc od razu klikamy „add an application”, co spowoduje uruchomienie odpowiedniego kreatora:

W większośći przypadków, przynajmniej opisywanych w tym artykule, „typ” to będzie „self-hosted”. W następnym kroku przechodzimy do konfiguracji tego, co ma być chronione:

Jako „application name” wpisujemy, co chcemy. W „session duration” wybieramy, przez jaki czas po autoryzacji ma być dostęp, bez potrzeby ponownej autoryzacji.

W sekcji „application domain” ustawiamy adresy, które chcemy chronić. I o ile domenę ponownie wybieramy z listy, to subdomenę musimy podać „z pamięci”. A oczywiście podajemy taką, by pokrywała się (wraz z domeną) z utworzonym wcześniej hostem, dla którego teraz ustawiamy ochronę. Możemy od razu dodać więcej niż jeden adres – wystarczy kliknąć „add domain”.

Kolejny krok, to ustawienie sposobu autoryzacji:

Zaczynamy ponownie od nazwy oraz ustawienia „allow” w „action” i przechodzimy do następnej sekcji, czyli „configure rules”:

Tutaj możliwości jest wiele, ale niewątpliwie jedną z najprostszych do wdrożenia, będzie „email”, czyli by uzyskać dostęp, trzeba podać jeden ze zdefiniowanych w tym kroku adresów e-mail, oraz jednorazowy kod, który przyjdzie właśnie na ten adres.

Po zapisaniu zmian, nowo utworzona „aplikacja” (ochronna) pojawi się na liście:

Jeśli w przyszłości pojawi się potrzeba, można przez edycję „aplikacji” dodać nowe adresy – zarowno hosty, jak i adresy e-mail, czy też ogólnie zmienić sposób autoryzacji. Oczywiście można mieć różne rekordy, dla różnych hostów (adresów). Kwestia potrzeb…

Dostęp z autoryzacją za pomocą konta e-mail

Gdy ustawimy zabezpieczenie, to przy próbie wyjścia na chroniony adres pojawi się okno z miejscem na wpisanie adres e-mail:

Gdy zostanie podany prawidłowy adres e-mail, to zostanie właśnie na ten konkretny adres wysłana wiadomość e-mail z jednorazowym kodem, który należy podać w kolejnym kroku:

Jak widać – nic skomplikowanego. I właśnie dlatego jako przykład wybrałem tego typu ochronę, bo zakładam, że każdy konto e-mail ma. Zwłaszcza jak korzysta z Cloudflare. Zresztą jakby co, to w Cloudflare można stworzyć sobie odpowiedni alias…

Zero Trust i Home Assistant

Choć nie jest to artykuł o Home Assistant, a występuje on tu tylko jako przykład, to jednak jest mowa o Home Assistant i Cloudflare, więc zapewne trafią tu jakieś osoby, szukające sposobu, by bezpłatnie uzyskać zdalny dostęp do Home Assistant. I zasadniczo artykuł zawiera już wszystko, czego potrzeba, poza jedną małą zmianą w konfiguracji Home Assistant, którą trzeba wprowadzić, by było możliwe połączenie przez usługę Zero Trust (a właściwie to dowolną inna tego typu też).

W pliku configuration.yaml w sekcji „http” należy dodać kilka linijek:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 10.0.0.1
    - 127.0.0.1
  ip_ban_enabled: true
  login_attempts_threshold: 5

U mnie agent Cloudflared działa na tej samej maszynie, co Home Assistant, stąd jest tam adres „127.0.0.1”, czyli „localhost”. Jest też adres „10.8.0.1”, bo taki lokalny adres IP ma to urządzenie. Oczywiście należy ten wpis dostosować do własnych potrzeb. Na koniec jeszcze restart Home Assistant…

Tak, bez publicznego IP i otwierania portów

I być może kogoś to zaskoczy, ale to już wszystko. W przypadku korzystania z usługi Zero Trust nie potrzeba publicznego adresu IP. Nie trzeba też na routerze otwierać żadnych portów. Wszystko odbywa się za pośrednictwem usługi Cloudflare i odpowiedniego „agenta” (Cloudflared) zainstalowanego na jakimś urządzeniu znajdującym się w sieci LAN.

WARP, czyli coś jak VPN

W tym miejscu być może powinienem przejść do opisu kolejnego rozwiązania do Cloudflare, czyli usługi WARP, dzięki której można stworzyć bezpośrednie połączenie między dowolnym urządzeniem, a urządzeniem z działającym programem Cloudflared. Czyli w pewnym uproszczeniu mamy w takiej sytuacji coś w stylu normalnego VPNa, ale nadal nie musimy mieć publicznego adresu IP i nie musimy otwierać żądnych portów.

Co więcej, WARP może się przydać np. do połączenia dwóch różnych lokalizacji, tak by móc korzystać z nich, ta jakby znajdowały się w jednej sieci LAN. Sam z korzystam z tego typu rozwiązania m.in. do połączenia urządzeń z ESPHome działających w innych lokalizacjach do „domowego” serwera Home Assistant.

Natomiast kluczem jest tutaj „korzystam z tego typu rozwiązania”. I nie jest to zwrot przypadkowy, bo choć wydawałoby się naturalne, że skoro i tak korzystam z Zero Trust od Cloudflare, to dołożyć do tego WARPa. Problem tylko w tym, że o ile Cloudflared działa na Raspberry Pi B+, to już klient WARP (czy też WARP Connector) do działania wymaga 64-bitowego systemu, a Raspberry Pi OS x64 obsługuje Maliny chyba od wersji 3. Więc by spiąć wszystkie lokalizacje, i tak musiałbym sięgnąć po inne rozwiązanie. Więc zdecydowałem kiedyś, że w tym celu skorzystam z innego niż WARP rozwiązania. Ale o tym niebawem. Natomiast jak w swoich lokalizacjach masz tylko maszyny z 64-bitowym systemem operacyjnym i korzystasz z Zero Trust, to wydaje się sensowne skorzystanie z WARPa, gdy potrzebujesz dodać do tego jeszcze VPNa.