Jak skonfigurować DNS i routing dla Cloudflare Tunnel

Cloudflare Tunnel pozwala udostępnić usługę działającą na Raspberry Pi, domowym serwerze lub w sieci prywatnej bez przekierowywania portu przychodzącego na routerze. Łącznik cloudflared nawiązuje połączenie wychodzące z Cloudflare, a publiczna nazwa hosta określa, do której lokalnej usługi ma trafić żądanie.

Cała konfiguracja składa się z trzech elementów:

app.example.com
        ↓ DNS
sieć Cloudflare
        ↓ Cloudflare Tunnel
http://localhost:8080

Ten poradnik skupia się na zależności między publiczną nazwą hosta, jej rekordem DNS i adresem lokalnej usługi. Zakładam, że domena jest już aktywna w Cloudflare, a tunel istnieje i ma połączoną instancję cloudflared.

Do czego służy trasa opublikowanej aplikacji

Trasa opublikowanej aplikacji mapuje publiczną nazwę hosta, na przykład app.example.com, na usługę dostępną dla cloudflared, na przykład http://localhost:8080.

Po utworzeniu trasy w panelu Cloudflare powstaje również pośredniczony przez Cloudflare rekord CNAME. Wskazuje on na adres przypisany do konkretnego tunelu:

<UUID-TUNELU>.cfargotunnel.com

Serwer źródłowy nie potrzebuje publicznego adresu IP, a rekord DNS nie powinien wskazywać bezpośrednio na prywatny adres Raspberry Pi. Cloudflare odbiera publiczne żądanie i przekazuje je przez tunel.

Zanim skonfigurujesz DNS

Sprawdź lokalną usługę z maszyny lub kontenera, w którym działa cloudflared:

curl -I http://localhost:8080

Użyj rzeczywistego protokołu, hosta i portu usługi źródłowej. Poprawna odpowiedź potwierdza, że aplikacja działa lokalnie, zanim do ścieżki żądania dołączą DNS i tunel.

Ważny szczegół: localhost zawsze oznacza środowisko sieciowe, w którym działa cloudflared. Jeżeli cloudflared znajduje się w kontenerze, a aplikacja w innym kontenerze, localhost zwykle wskazuje na sam kontener cloudflared. W takiej sytuacji użyj nazwy lub adresu kontenera dostępnego we wspólnej sieci, na przykład:

http://web:8080

Dodanie publicznej nazwy hosta w panelu

W aktualnym panelu Cloudflare:

  1. Otwórz Networking → Tunnels.
  2. Wybierz tunel używany przez serwer.
  3. Otwórz kartę Routes.
  4. Wybierz Add route, a następnie Published application.
  5. Podaj publiczną nazwę hosta, na przykład app.example.com.
  6. Podaj adres lokalnej usługi, na przykład http://localhost:8080.
  7. Zapisz trasę.

Cloudflare powinien automatycznie utworzyć odpowiedni rekord DNS. Możesz to potwierdzić na liście rekordów domeny. Rekord powinien być pośredniczony przez Cloudflare, a jego cel powinien kończyć się na .cfargotunnel.com.

Dokumentacja Cloudflare opisuje tę konfigurację jako trasę opublikowanej aplikacji.

Dodanie trasy DNS za pomocą cloudflared

W przypadku tunelu zarządzanego lokalnie nazwę hosta można również powiązać z wiersza poleceń:

cloudflared tunnel route dns <NAZWA-LUB-UUID-TUNELU> app.example.com

Polecenie tworzy lub aktualizuje rekord DNS kierujący publiczną nazwę hosta do wybranego tunelu. Nie określa jednak, która lokalna aplikacja ma otrzymać żądanie. Konfiguracja tunelu musi nadal zawierać regułę ingress mapującą nazwę hosta na usługę źródłową. Prosta konfiguracja może wyglądać tak:

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

ingress:
  - hostname: app.example.com
    service: http://localhost:8080
  - service: http_status:404

Ostatnia reguła przechwytująca wszystkie pozostałe żądania jest ważna. Określa, co powinno się stać, gdy żądanie nie pasuje do żadnej skonfigurowanej nazwy hosta.

Po zmianie konfiguracji zarządzanej lokalnie sprawdź reguły ingress i uruchom ponownie lub przeładuj cloudflared zgodnie ze sposobem jego instalacji.

Domena główna i CNAME flattening

Subdomena taka jak app.example.com może korzystać ze zwykłego rekordu CNAME. Główna nazwa domeny, czyli example.com bez subdomeny, jest szczególnym przypadkiem. Tradycyjne zasady DNS nie pozwalają umieścić tam rekordu CNAME razem z innymi rekordami wymaganymi dla domeny.

Cloudflare rozwiązuje to za pomocą CNAME flattening. Mechanizm pozwala połączyć główną nazwę domeny z tunelem, ale klient DNS otrzymuje rozwiązane adresy IP zamiast celu CNAME. Cloudflare domyślnie włącza tę funkcję dla głównej nazwy domeny. Szczegóły opisuje dokumentacja CNAME flattening.

Dlatego zapytanie dig CNAME example.com może nie pokazać celu tunelu, nawet gdy konfiguracja działa prawidłowo.

Sprawdzenie DNS i tunelu

Najpierw sprawdź, czy publiczna nazwa hosta jest rozwiązywana:

dig +short app.example.com A
dig +short app.example.com AAAA

Dla rekordu pośredniczonego przez Cloudflare odpowiedź zwykle zawiera adresy Cloudflare. Nie ujawnia prywatnego adresu serwera źródłowego ani nie musi pokazywać bazowego rekordu CNAME.

Następnie sprawdź aplikację przez HTTPS:

curl -I https://app.example.com

Więcej informacji o połączeniu i odpowiedzi uzyskasz za pomocą:

curl -v https://app.example.com/ -o /dev/null

Sprawdź również sam tunel:

cloudflared tunnel info <NAZWA-LUB-UUID-TUNELU>

Każdy z tych testów odpowiada na inne pytanie:

  • dig sprawdza publiczne rozwiązywanie DNS,
  • cloudflared tunnel info sprawdza zarejestrowane połączenia tunelu,
  • lokalny curl sprawdza usługę źródłową,
  • publiczny curl sprawdza pełną trasę przez Cloudflare.

Typowe problemy

Nazwa hosta nie jest rozwiązywana

Sprawdź, czy rekord DNS istnieje we właściwej strefie Cloudflare. Samo dodanie trasy do lokalnego pliku ingress nie gwarantuje utworzenia publicznego rekordu DNS.

Dla tunelu zarządzanego lokalnie uruchom cloudflared tunnel route dns albo utwórz pośredniczony rekord CNAME wskazujący na <UUID-TUNELU>.cfargotunnel.com.

Cloudflare Tunnel Error 1033

Cloudflare nie może znaleźć sprawnego połączenia cloudflared dla tunelu. Sprawdź, czy proces lub usługa łącznika działa oraz czy cloudflared tunnel info pokazuje aktywne połączenie.

Cloudflare Tunnel 502 Bad Gateway

Publiczny DNS i tunel mogą działać prawidłowo, ale cloudflared nie może połączyć się ze skonfigurowaną usługą źródłową. Sprawdź:

  • czy aplikacja działa,
  • czy protokół jest prawidłowy (http lub https),
  • czy usługa nasłuchuje na skonfigurowanym porcie,
  • czy localhost wskazuje na właściwy kontener lub host,
  • czy lokalna zapora nie blokuje połączenia.

Sprawdź dokładny adres usługi źródłowej z tego samego środowiska sieciowego, w którym działa cloudflared.

Jeżeli cloudflared działa obok kontenerów, a usługa źródłowa nadal jest niedostępna, zobacz przykład konfiguracji firewalld dla kontenerów Docker na Raspberry Pi.

Otwiera się niewłaściwa aplikacja

Sprawdź nazwy hostów i kolejność reguł ingress. Bardziej szczegółowe reguły powinny znajdować się przed regułą przechwytującą wszystkie pozostałe żądania, która musi być ostatnia.

DNS działa, ale HTTPS nie jest jeszcze gotowy

Cloudflare wystawia certyfikat brzegowy dla publicznej nazwy hosta. Bezpośrednio po dodaniu nowej nazwy jego wystawienie może potrwać krótką chwilę. Zanim zaczniesz ponownie zmieniać konfigurację usługi źródłowej, upewnij się w panelu, że nazwa hosta jest aktywna.

Dostęp przez tunel nie zastępuje uwierzytelniania

Cloudflare Tunnel usuwa potrzebę bezpośredniego wystawiania portu przychodzącego, ale opublikowana nazwa hosta jest publiczna, dopóki nie dodasz innej kontroli dostępu. Panele administracyjne, pulpity i prywatne aplikacje nie powinny traktować samego tunelu jako warstwy uwierzytelniania.

Dla usług o ograniczonym dostępie użyj silnego uwierzytelniania oferowanego przez aplikację i rozważ politykę Cloudflare Access. Może ona wymagać zalogowania użytkownika, zanim uzyska on dostęp do opublikowanej aplikacji.

Podsumowanie

Najważniejsza zależność jest prosta:

  1. Publiczna nazwa hosta jest rozwiązywana przez DNS Cloudflare.
  2. Jej pośredniczony rekord CNAME jest powiązany z konkretnym tunelem.
  3. Trasa tunelu mapuje nazwę hosta na usługę dostępną dla cloudflared.
  4. Usługa źródłowa pozostaje prywatna i nie wymaga otwierania portu przychodzącego na routerze.

Podczas diagnostyki sprawdzaj osobno każdą warstwę: lokalną aplikację, połączenie tunelu, rozwiązywanie DNS, a na końcu publiczne żądanie HTTPS. Dzięki temu łatwiej odróżnić problem z DNS od niedostępnego tunelu lub błędnego adresu usługi źródłowej.

Jeśli potrzebujesz pomocy w diagnostyce Cloudflare Tunnel, sieci Dockera, DNS lub reverse proxy, zobacz usługę Docker, reverse proxy i wdrożenia aplikacji.