Cloudflare Tunnel jako alternatywa dla otwierania portów

Cloudflare Tunnel bez udostępniania portów – wyjaśnienie

W przypadku klasycznego otwarcia portu klient zewnętrzny łączy się bezpośrednio z publicznym adresem IP routera lub serwera. Router przekierowuje następnie ruch przychodzący do usługi w sieci wewnętrznej. Jeden Cloudflare Tunnel odwraca ten proces nawiązywania połączenia: łącznik cloudflared działa w dostępnej sieci wewnętrznej i samodzielnie nawiązuje połączenia wychodzące z Cloudflare.

Jeśli użytkownik wywoła na przykład portal administracyjny, Cloudflare odbiera żądanie dotyczące jego nazwy hosta i przekazuje je do łącznika za pośrednictwem istniejącego już połączenia tunelowego. Łącznik ten dociera do skonfigurowanej usługi docelowej, na przykład http://localhost:8080. W związku z tym urządzenie Origin nie wymaga ani adresu IP dostępnego bezpośrednio z Internetu, ani zezwolenia na przychodzący ruch w zaporze sieciowej dla tej usługi.

Nie oznacza to jednak, że zasady sieciowe przestają obowiązywać. Host z cloudflared Cloudflare musi mieć możliwość połączenia się z siecią zewnętrzną. Cloudflare dokumentuje w tym celu port 7844 przez protokół TCP lub UDP; wykorzystywane są przy tym protokoły HTTP/2 lub QUIC. Ruch wychodzący musi być dozwolony w lokalnej zaporze sieciowej, na routerze oraz, w razie potrzeby, przez firmowy serwer proxy. To właśnie jest praktyczne ograniczenie kryjące się za stwierdzeniem „bez otwierania portów“.

Sam wpis DNS nie zapewnia takiej zabezpieczonej ścieżki połączenia. DNS jedynie przypisuje nazwę do adresu docelowego; nie nawiązuje połączenia z sieci prywatnej ani nie udostępnia lokalnej usługi. złącze wyjściowe jest kluczowym elementem: zna on wewnętrzną usługę docelową i zapewnia swobodny dostęp do niej od wewnątrz na zewnątrz. To, którzy użytkownicy mogą korzystać z tej ścieżki, należy skonfigurować oddzielnie.

Tunel nie stanowi zabezpieczenia dostępu

Tunel ogranicza bezpośrednią widoczność serwera źródłowego w sieci, ale sam w sobie nie decyduje o uprawnieniach. Jeśli panel administracyjny serwisu jest kierowany przez publiczną nazwę hosta, to bez zastosowania aplikacji Access jako warstwy pośredniej może być zasadniczo wywołany przez dowolnego użytkownika Internetu. Dlatego Cloudflare zaleca skonfigurowanie Access przed produkcyjną trasą tunelu. Tunel jest ścieżką transportową, a nie mechanizmem kontroli dostępu.

W przypadku uprzywilejowanego panelu administracyjnego należy Polityka dostępu zezwalać wyłącznie na dostęp ściśle określonych osób lub grup. Oprócz kryteriów „Include”, „Require” i „Exclude” dostępne są takie działania, jak „Allow”, „Block”, „Bypass” oraz „Service Auth”. Uwierzytelnianie wieloskładnikowe (MFA) można wymusić za pośrednictwem podłączonego dostawcy tożsamości lub jako dodatkowy czynnik. Zastosowanie jednej reguły dla wszystkich kont w domenie poczty elektronicznej jest zazwyczaj zbyt szerokie w przypadku interfejsów o wysokich uprawnieniach.

Warstwa dostępu stanowi uzupełnienie zabezpieczeń aplikacji, ale ich nie zastępuje. Panel administracyjny nadal wymaga bezpiecznego logowania, terminowych aktualizacji, odpowiednich zasad dotyczących sesji oraz oszczędnego przyznawania uprawnień. Istotne znaczenie mają również lokalne konta użytkowników, role i uprawnienia administracyjne: jeśli użytkownik uzyska dostęp do aplikacji po zalogowaniu się za pomocą Access, nie może automatycznie otrzymać w niej dalszych uprawnień administracyjnych.

Ponadto należy sprawdzić, czy aplikacja weryfikuje tokeny dostępu lub czy korzysta z przeznaczonej do tego celu opcji tunelowania w celu weryfikacji tokenów. Wiąże to aplikację z poprzedzającą ją weryfikacją tożsamości i ogranicza ryzyko wynikające z niezamierzonej alternatywnej ścieżki dostępu do serwisu źródłowego. Sensowne jest zastosowanie warstwowego podejścia: restrykcyjne udostępnianie, weryfikacja tożsamości za pomocą uwierzytelniania wieloskładnikowego (MFA), minimalne uprawnienia aplikacji oraz wewnętrznie dostępna, nieeksponowana publicznie usługa docelowa.

Klasyfikacja protokołów HTTP, SSH, RDP i TCP

Aplikacje HTTP(S) i protokoły administracyjne mają różne modele dostępu. Wewnętrzny interfejs internetowy można udostępnić za pomocą nazwy hosta i zabezpieczyć przed pochodzeniem za pomocą Access. SSH, RDP i niektóre usługi TCP mogą być również dostępne za pośrednictwem tuneli, jednak po stronie klienta wymagają one, w zależności od metody, dodatkowego oprogramowania lub dostępu opartego na przeglądarce. Logowanie przez Internet nie przekłada się automatycznie na dowolny natywny dostęp do sieci.

W przypadku SSH przy użyciu zwykłego terminala lokalnego można po stronie klienta cloudflared nawiązać połączenie za pomocą programu Access. Cloudflare opisuje ponadto SSH renderowane przez przeglądarkę jako odrębną ścieżkę dostępu. Oba warianty różnią się pod względem przebiegu pracy klienta, lokalnej konfiguracji SSH oraz obsługi; dlatego nie można ich traktować jako zamienników w każdym przypadku. Uwagi dotyczące bardziej zaawansowanych modeli infrastruktury lub certyfikatów powinny znaleźć się w planie tylko wtedy, gdy ich aktualna, odpowiednia dokumentacja została oddzielnie sprawdzona.

Terminal SSH renderowany w przeglądarce może okazać się przydatny w przypadku wsparcia technicznego lub pilnego dostępu awaryjnego, gdy nie ma przygotowanego lokalnego klienta SSH. Przed wdrożeniem należy jednak ocenić wytyczne dotyczące audytu, procedury obsługi, lokalne metody kluczowe oraz transfer plików. Usługi RDP i inne usługi TCP powinny być również sprawdzane indywidualnie dla każdej aplikacji, zamiast traktować je ogólnie tak samo jak interfejs internetowy.

Tunnel nie stanowi pełnoprawnego zamiennika każdego połączenia sieciowego. Protokoły inicjowane przez serwer, takie jak VoIP czy SIP, nie są obsługiwane; również długotrwałe sesje TCP, wrażliwe na przerwy, wymagają sprawdzenia zgodności. Ponadto w przypadku protokołów SSH, RDP i TCP serwer Origin nie widzi pierwotnego adresu IP klienta, lecz adres łącznika. W przypadku protokołu HTTP aplikacja może CF-Connecting-IP analizować. Listy dozwolone oparte na adresach IP oraz logi kryminalistyczne muszą uwzględniać to ograniczenie.

Bezpieczne przypisywanie wielu usług

Lokalny plik Ingress przypisuje każdą opublikowaną nazwę hosta dokładnie do jednego wewnętrznego celu. W przypadku panelu administracyjnego i SSH warto używać oddzielnych nazw: dzięki temu uprawnienia, logi i późniejsze zmiany pozostają wyraźnie oddzielone od siebie. Cloudflared analizuje reguły od góry do dołu; cel określa pierwsza pasująca reguła.

Poniższy przykład przedstawia szablon konfiguracji tunelu zarządzanego lokalnie. Celowo wykorzystuje on example.invalid i nie zawiera ani danych dostępowych, ani prawdziwej domeny. Serwis internetowy pozostaje na localhost:8080 dostępne; połączenie SSH jest przekierowywane do lokalnej usługi SSH.

tunnel: <TUNNEL-UUID>
credentials-file: /etc/cloudflared/<TUNNEL-UUID>.json

ingress:
  - hostname: admin.example.invalid
    service: http://localhost:8080
  - hostname: ssh.example.invalid
    service: ssh://localhost:22
  - service: http_status:404

Ostatnia zasada brzmi: Zasada „catch-all”. Jest ona niezbędna do obsługi lokalnych plików Ingress i zapewnia tutaj dzięki http_status:404 aby nieznana nazwa hosta nie trafiła przypadkowo do pierwszej lub innej usługi wewnętrznej. Szerokie standardowe przekierowanie stanowiłoby niepotrzebne ryzyko, zwłaszcza w przypadku celów administracyjnych.

Plik ten określa wyłącznie ścieżkę z tunelu do serwera Origin. Nie konfiguruje on wpisów DNS ani nie zabezpiecza nazw za pomocą usługi Cloudflare Access. Przed uruchomieniem trasy produkcyjnej należy zatem oddzielnie skonfigurować nazwę hosta i zasady dostępu. Również lokalnie porty docelowe powinny być dostępne tylko tam, gdzie są one faktycznie potrzebne w ramach usługi Cloudflare Access.

Przed uruchomieniem można sprawdzić kolejność bez zmiany ustawień. Pierwsze polecenie weryfikuje konfigurację Ingress; drugie pokazuje, która reguła miałaby zastosowanie dla podanego adresu.

cloudflared tunnel ingress validate
cloudflared tunnel ingress rule https://admin.example.invalid

Selektywny wybór dostępów SSH

SSH przez tunel nie jest jednolitą metodą dostępu. Wybór odpowiedniej opcji zależy od tego, czy administratorzy będą nadal korzystać ze swojego lokalnego terminala, czy też w razie awarii będą musieli pracować bez wcześniej przygotowanego klienta. Dostępne modele różnią się pod względem klienta, tożsamości i przebiegu obsługi; konkretna konfiguracja SSHD oraz lokalne zarządzanie uprawnieniami pozostają od tego niezależne.

W przypadku niewielkiego zespołu, który regularnie korzysta ze znanych lokalnych narzędzi, często sprawdza się rozwiązanie „cloudflared” po stronie klienta: port SSH pozostaje wewnętrzny, a Access przed nawiązaniem połączenia wprowadza dodatkową warstwę uwierzytelniania. Nie jest to jednak to samo, co scentralizowane zarządzanie wszystkimi uprawnieniami SSH.

Dostęp przez przeglądarkę należy traktować jako odrębny proces. Może on okazać się przydatny w przypadku wsparcia technicznego lub nieplanowanego dostępu, ponieważ nie wymaga skonfigurowanego klienta SSH. Nie jest to jednak ogólnie lepsza metoda administrowania: transfer plików, znane lokalne procedury związane z kluczami oraz wytyczne audytowe mogą sprawić, że klient terminalowy lub dostęp prywatny będą bardziej odpowiednie.

Niezależnie od wybranej ścieżki lokalne warstwy ochronne pozostają nienaruszone. Konta w systemie Linux, Zasady dotyczące sudo, Konfiguracja dysku SSHD oraz uprawnienia w systemie docelowym nadal decydują o tym, co może robić osoba, która pomyślnie się zalogowała. Tunel nie zastępuje ani tych zasad, ani ograniczonego przyznawania uprawnień.

W przypadku opublikowanych usług innych niż HTTP może być wymagane zastosowanie cloudflared po stronie klienta; SSH zapewnia ponadto dostęp renderowany przez przeglądarkę. Usługi RDP i inne usługi TCP nie powinny zatem być pochopnie planowane na wzór SSH, lecz z uwzględnieniem ich odpowiednich wymagań dotyczących klientów i systemu operacyjnego.

Tunel, VPN, bastion lub otwarcie portu

Wybór ten dotyczy nie tylko tego, czy port jest otwarty, ale także pożądanego zakresu dostępu. Cloudflare Tunnel nadaje się przede wszystkim do niewielkiej liczby jasno określonych usług. Natomiast użytkownicy, którzy muszą uzyskać dostęp do wielu systemów wewnętrznych i segmentów sieci, zazwyczaj potrzebują modelu zapewniającego prywatny dostęp do sieci zamiast zbioru pojedynczych publikacji.

Klasyczne otwarcie portów nie jest z zasady złe. Może się sprawdzić w przypadku świadomie publicznej usługi, za której ochronę aplikacji, działanie zapory sieciowej i publiczną dostępność ponosi się konkretną odpowiedzialność. W odróżnieniu od tego, w przypadku tunelu łącznik nawiązuje połączenie z sieci wewnętrznej; nie ma potrzeby bezpośredniego nawiązywania połączenia z serwerem źródłowym z Internetu.

W przypadku pojedynczego panelu administracyjnego lub niewielkiego zestawu celów konserwacyjnych zaleca się publikację opartą na usługach z dostęp oparty na tożsamości zazwyczaj łatwiejsze do ograniczenia niż kompleksowy tunel sieciowy. Nie zwalnia to jednak z konieczności sprawdzenia protokołu: protokoły inicjowane przez serwer nie są obsługiwane, a długie sesje TCP wrażliwe na przerwy mogą wymagać innych modeli łączności.

Sieć VPN nadal ma sens, gdy pracownicy potrzebują dostępu do wielu prywatnych aplikacji, zakresów adresów lub wewnętrznych zależności. Natomiast serwer bastionowy skupia dostępy SSH w jednym punkcie wejścia, który sam w sobie musi być starannie zabezpieczony i odpowiednio zarządzany. Z kolei serwer proxy odwrotny stanowi warstwę służącą do terminacji TLS i udostępniania aplikacji; nie odpowiada on sam w sobie na pytanie, w jaki sposób uzyskać dostęp do prywatnego serwera źródłowego. Role serwera proxy, serwera aplikacji i menedżera procesów można również zrealizować w Porównanie NGINX Unit i PHP-FPM zrozumieć.

W związku z tym praktyczna decyzja zaczyna się od określenia granic: które osoby potrzebują dostępu do jakiej usługi i za pomocą jakiego klienta? Im węższa jest ta odpowiedź, tym łatwiej jest obsługiwać tunel z precyzyjnymi nazwami hostów i regułami. Rozległe potrzeby sieciowe, specjalistyczne protokoły lub wysokie wymagania dotyczące stabilności sesji przemawiają natomiast za przeprowadzeniem odrębnej oceny.

Zabezpieczenie tunelu podczas eksploatacji

Aktywny tunel nie składa się z pojedynczego, sporadycznego połączenia. Cloudflare dokumentuje dla każdego tunelu typu „cloudflared” cztery długotrwałe połączenia wychodzące z co najmniej dwoma własnymi centrami danych. W przypadku awarii jednej ścieżki połączenia żądania mogą zatem być kierowane przez inną istniejącą ścieżkę. Zmniejsza to zależności na trasie między łącznikiem a Cloudflare, nie zapewnia jednak samej usłudze wewnętrznej wysokiej dostępności.

W przypadku aplikacji o krytycznym znaczeniu kilka instancji cloudflared może obsługiwać ten sam tunel jako repliki. Tworzy to dodatkowe ścieżki połączeń między siecią Cloudflare a siecią prywatną, ale nie zastępuje ani redundancji aplikacji, ani strategii dotyczącej baz danych lub hostów. Jeśli na przykład jedyny serwer z panelem administracyjnym jest niedostępny, dodatkowe łączniki na tym lub innych hostach pomogą tylko wtedy, gdy faktycznie będą w stanie połączyć się z działającą usługą docelową. ścieżka połączenia Dlatego też należy oddzielnie planować dostępność usług.

Jeśli konieczne jest celowe sprawdzanie wielu serwerów źródłowych, omijanie ich w razie awarii lub rozdzielanie ruchu zgodnie z regułami, wymagane jest dodatkowe równoważenie obciążenia z wykorzystaniem kontroli stanu (health checks) i kierowania ruchem (traffic steering). Sam tunel nie podejmuje tak szczegółowych decyzji. Architektura powinna ponadto określać, w jaki sposób usługa docelowa zostanie przywrócona po awarii oraz czy podczas zakłócenia nadal wymagany jest dostęp administracyjny.

Dostępność nie ogranicza się wyłącznie do oprogramowania. Jeśli moduł łączący i system docelowy znajdują się w oddzielnej serwerowni, koncepcja eksploatacji powinna uwzględniać również zasilanie, chłodzenie, jakość powietrza oraz regularne kontrole. Jakie dodatkowe zagrożenia środowiskowe mogą się w tym kontekście pojawić, pokazuje analiza dotycząca Wentylacja serwerowni w piwnicy. Takie środki nie zastępują replik, ale zapobiegają sytuacji, w której wszystkie przewidziane ścieżki połączeń zawiodłyby z powodu tej samej lokalnej zależności infrastrukturalnej.

Aktualizacje programu cloudflared należy przeprowadzać w zaplanowanym oknie serwisowym: powodują one ponowne uruchomienie i mogą w związku z tym wpłynąć na aktualnie obsługiwany ruch. Cloudflare wskazuje równoważenie obciążenia lub korzystanie z wielu instancji cloudflared jako opcje umożliwiające aktualizację bez przerw w działaniu. Wybór odpowiedniej metody aktualizacji zależy od rodzaju instalacji i środowiska operacyjnego i powinien zostać udokumentowany przed rozpoczęciem okna serwisowego.

Dla każdej aktualizacji należy udokumentować zainstalowaną wersję, odpowiedzialny serwer, ścieżkę awaryjną oraz test dostępności usługi docelowej. Po ponownym uruchomieniu sprawdź nie tylko stan tunelu, ale także, czy zdefiniowana reguła Ingress dociera do oczekiwanej usługi i czy przewidziana warstwa dostępu nadal działa. W ten sposób łącznik, usługa docelowa i ścieżka uprawnień pozostają przejrzyste jako odrębne zadania operacyjne.

Wczesne wykrywanie typowych błędów konfiguracji

Przed uruchomieniem należy rozpocząć diagnostykę łącznika: host musi mieć możliwość połączenia się z Cloudflare przez port 7844 za pomocą protokołu TCP lub UDP. Można się spodziewać braku otwarcia portu przychodzącego, ale nie należy zakładać, że zapora wychodząca blokuje ruch w sposób ogólny. Dopiero gdy usługa cloudflared będzie w stanie nawiązać połączenia wychodzące, warto sprawdzić DNS, nazwy hostów i reguły dostępu na poziomie aplikacji.

1. Sprawdź dostępność lokalną: usługa wymieniona w regule Ingress musi być dostępna z hosta cloudflared poprzez podany lokalny lub wewnętrzny punkt końcowy.
2. Zsynchronizowanie DNS i Ingress: publiczna nazwa hosta musi odpowiadać zamierzonej trasie tunelu; kolejność reguł musi sprawiać, że reguła dotycząca konkretnej usługi będzie stosowana przed regułami o bardziej ogólnym charakterze.
3. Testowanie reguły typu „catch-all”: Reguła końcowa z http_status:404 zapobiega przekazywaniu nieprzewidzianych nazw hostów do domyślnej usługi.
4. Konfiguracja programu Access przed uruchomieniem w środowisku produkcyjnym: Dopiero wtedy można w kontrolowany sposób sprawdzić ścieżkę zewnętrzną przy użyciu konta z uprawnieniami oraz konta bez uprawnień.

Częstym błędem w zakresie bezpieczeństwa jest zbyt szeroki zakres dostępu: zamiast udostępniać jedynie panel administracyjny lub określoną usługę SSH, udostępnia się większy obszar sieci. Równie ryzykowne są ogólne reguły dotyczące domen e-mailowych dla interfejsów z uprawnieniami. W przypadku dostępów administracyjnych małe, możliwe do weryfikacji grupy, odpowiednie kryteria Require oraz uwierzytelnianie wieloskładnikowe (MFA) powinny odzwierciedlać rzeczywisty krąg osób. Minimalne uprawnienia oznacza to również, że nie należy niepotrzebnie łączyć oddzielnych nazw hostów i usług docelowych.

Konfiguracja tuneli i uprawnień służy do realizacji różnych zadań. Reguła Ingress określa, dokąd kierowane jest już nawiązane połączenie; reguła Access decyduje, kto zostanie wcześniej uwierzytelniony i autoryzowany. Bez odpowiedniej reguły Access opublikowana nazwa hosta HTTP może być dostępna z Internetu. Dlatego też konta lokalne, reguły sudo, ustawienia SSHD oraz wzmocnienie bezpieczeństwa aplikacji pozostają odrębnymi punktami kontroli.

W przypadku logów i audytów istotne znaczenie ma ograniczenie dotyczące źródłowego adresu IP: w przypadku SSH, RDP i innych połączeń TCP serwer docelowy nie widzi pierwotnego adresu IP klienta, lecz kontekst łącznika. Listy dozwolonych adresów IP oparte na adresach IP w systemie docelowym nie stanowią w tym przypadku wiarygodnego sposobu przypisania użytkowników. Aplikacje HTTP mogą analizować nagłówek CF-Connecting-IP, o ile ich system logowania i łańcuch zaufania celowo uwzględniają tę informację.

Wybór odpowiedniego rozwiązania w zakresie dostępu

W przypadku pojedynczego panelu administracyjnego Cloudflare Tunnel sprawdza się, gdy usługa ma być dostępna pod jasną nazwą hosta bez udostępniania publicznego adresu IP serwera źródłowego ani zezwolenia na ruch przychodzący. Rozsądnym rozwiązaniem jest wąska konfiguracja docelowa, przed którą znajduje się aplikacja dostępowa z niewielką grupą tożsamości i uwierzytelnianiem wieloskładnikowym (MFA). Metoda ta zabezpiecza ścieżkę sieciową, ale nie zastępuje ani bezpiecznego zarządzania sesjami, ani weryfikacji uprawnień w panelu administracyjnym.

Niewielki zespół administratorów, przyzwyczajony do pracy w terminalu, może korzystać z SSH za pośrednictwem rozwiązań po stronie klienta, takich jak Cloudflare i Access. SSH renderowane w przeglądarce nadaje się przede wszystkim jako przygotowany dostęp awaryjny lub w celu wsparcia technicznego. Oba rozwiązania mają różne wymagania dotyczące klientów i obsługi; transfer plików, procesy robocze oraz wytyczne audytowe muszą być dostosowane do wybranej metody. Decyzje dotyczące bardziej zaawansowanych modeli scentralizowanych uprawnień SSH powinny być podejmowane wyłącznie na podstawie aktualnej, szczegółowej dokumentacji danego rozwiązania.

Kto potrzebuje wielu usług wewnętrznych, całych segmentów lub szerokiej komunikacji w kierunku wschód-zachód, powinien rozważyć prywatny dostęp do sieci, taki jak VPN, lub model łączności przeznaczony do tego celu. Pojedynczy opublikowany tunel nie zastępuje automatycznie wszystkich obciążeń sieci VPN. Tunel nie nadaje się do protokołów inicjowanych przez serwer, takich jak VoIP czy SIP; również długotrwałe sesje TCP, wrażliwe na przerwy w połączeniu, wymagają analizy konkretnego protokołu i ewentualnych konsekwencji ponownego nawiązania połączenia.

Klasyczne otwarcie portów może być uzasadnione, jeśli usługa jest świadomie udostępniana bezpośrednio publicznie, a zapora sieciowa, ochrona serwera źródłowego oraz uwierzytelnianie aplikacji są odpowiednio skonfigurowane. Host bastionowy skupia dostępy SSH, ale sam pozostaje punktem wejścia, który należy zabezpieczyć ze szczególną starannością. Z kolei serwer proxy odwrotny stanowi warstwę służącą do terminacji TLS i udostępniania aplikacji; nie odpowiada on wyłącznie na pytanie, w jaki sposób można uzyskać dostęp do prywatnego serwera źródłowego.

Minimalny standard produktywności obejmuje: najmniejszy niezbędny zakres celów, reguły oparte na tożsamości, uwierzytelnianie wieloskładnikowe (MFA) dla ról uprzywilejowanych, przetestowaną konfigurację Ingress i Catch-all, zaplanowany proces aktualizacji oraz udokumentowaną procedurę przywracania. Plan przywrócenia obejmuje co najmniej zakres odpowiedzialności, trasy awaryjne oraz sprawdzenie, czy usługa docelowa i łącznik są ponownie dostępne po zakończeniu konserwacji. Tunele zmniejszają powierzchnię narażoną sieci, ale nie zastępują zabezpieczeń aplikacji, lokalnych uprawnień ani bieżącego monitorowania działania.