Cloudflare Tunnel — bezpieczny dostęp do serwera bez otwierania portów
Opublikowano: 10 kwietnia 2026 · Kategoria: Bezpieczeństwo
Tradycyjny reverse proxy wymaga publicznego IP i otwartych portów — Twój serwer jest widoczny z całego Internetu, narażony na skanery, brute-force i DDoS. Cloudflare Tunnel odwraca ten model: Twój serwer sam inicjuje szyfrowane połączenie do infrastruktury Cloudflare, porty 80 i 443 mogą być całkowicie zamknięte. Efekt: zero bezpośrednich połączeń do Twojego IP, ukryte IP serwera, wbudowane DDoS protection i CDN. Działa nawet bez publicznego IP — za NAT-em, w sieci biurowej, na Raspberry Pi w szafie. Usługa jest bezpłatna.
Instalacja cloudflared
cloudflared to agent który uruchamiasz na swoim serwerze. Łączy się do sieci Cloudflare
i przekazuje ruch do lokalnych serwisów. Musisz mieć domenę dodaną do Cloudflare i konto Cloudflare
(bezpłatne wystarczy).
# Ubuntu / Debian curl -L --output cloudflared.deb \ https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb sudo dpkg -i cloudflared.deb cloudflared --version # Lub przez repo Cloudflare curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | \ sudo gpg --dearmor -o /usr/share/keyrings/cloudflare-main.gpg echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] \ https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | \ sudo tee /etc/apt/sources.list.d/cloudflared.list sudo apt update && sudo apt install cloudflared
Tworzenie tunelu i autentykacja
# Zaloguj sie do Cloudflare (otworzy przegladarke) cloudflared tunnel login # Plik autoryzacji zapisany w ~/.cloudflared/cert.pem # Utwórz tunel o nazwie "myapp" cloudflared tunnel create myapp # Tunnel ID zapisany w ~/.cloudflared/UUID.json # Sprawdz liste tuneli cloudflared tunnel list # Przykladowy output: # ID NAME CREATED CONNECTIONS # a1b2c3d4-e5f6-7890-abcd-ef1234567890 myapp 2026-04-10T07:00:00Z 0
Konfiguracja ingress rules — wiele serwisów na jednym tunelu
Jeden tunel może obsługiwać wiele domen i serwisów jednocześnie. Konfigurujesz reguły routingu (ingress) w pliku YAML — każdy hostname kieruje do innego lokalnego portu lub serwisu.
# ~/.cloudflared/config.yml
tunnel: a1b2c3d4-e5f6-7890-abcd-ef1234567890
credentials-file: /root/.cloudflared/a1b2c3d4-e5f6-7890-abcd-ef1234567890.json
ingress:
# Aplikacja webowa (Nginx/Node.js/Python)
- hostname: app.twoja-domena.pl
service: http://localhost:3000
# Panel admina
- hostname: admin.twoja-domena.pl
service: http://localhost:8080
originRequest:
noTLSVerify: true
# Portainer (HTTPS na 9443)
- hostname: portainer.twoja-domena.pl
service: https://localhost:9443
originRequest:
noTLSVerify: true # self-signed cert Portainera
# SSH przez tunel (nie wymaga otwartego portu 22)
- hostname: ssh.twoja-domena.pl
service: ssh://localhost:22
# Regula domyslna - wymagana na koncu
- service: http_status:404 Konfiguracja DNS i uruchomienie tunelu
# Dodaj rekordy CNAME DNS w Cloudflare automatycznie cloudflared tunnel route dns myapp app.twoja-domena.pl cloudflared tunnel route dns myapp admin.twoja-domena.pl cloudflared tunnel route dns myapp portainer.twoja-domena.pl # CNAME: app.twoja-domena.pl → UUID.cfargotunnel.com # Uruchom tunel recznie (test) cloudflared tunnel run myapp # Zainstaluj jako systemd service (automatyczny start) sudo cloudflared service install # Status service sudo systemctl status cloudflared sudo systemctl enable cloudflared sudo journalctl -u cloudflared -f
Zero Trust Access Policies — uwierzytelnianie przed aplikacjami
Cloudflare Zero Trust (cloudflare.com/products/zero-trust) pozwala chronić aplikacje za Tunnelem przez wymaganie logowania — bez VPN. Użytkownik musi się zalogować przez dostawcę tożsamości (Google, GitHub, SAML) zanim dotrze do Twojej aplikacji. Konfiguracja odbywa się w panelu Cloudflare Zero Trust.
| Metoda | Jak działa | Wymagania | Koszt |
|---|---|---|---|
| Otwarty port + UFW | Ogranicz IP w firewallu | Stały IP klienta | Darmowe |
| HTTP Basic Auth | Hasło w nagłówku HTTP | Plik .htpasswd | Darmowe |
| VPN (WireGuard) | Klient VPN łączy się z siecią | Klient WireGuard | Darmowe (self-hosted) |
| CF Tunnel + Zero Trust | SSO (Google/GitHub) przed aplikacją | Konto Cloudflare | Darmowe (do 50 users) |
| CF Tunnel + WARP | Klient WARP jako "VPN" do sieci CF | App WARP na urządzeniu | Darmowe (do 50 users) |
Cloudflare Tunnel vs tradycyjny reverse proxy — porównanie
- Publiczne IP: Nginx/Caddy wymagają publicznego IP i otwartych portów. Tunnel działa za NAT-em bez publicznego IP.
- DDoS protection: Nginx wymaga dodatkowych narzędzi (fail2ban, rate limiting). Tunnel automatycznie korzysta z sieci Cloudflare Anycast + DDoS mitigation.
- SSL: Nginx wymaga certbot i automatycznego odnawiania. Tunnel zarządza SSL przez Cloudflare automatycznie — zero konfiguracji certyfikatów.
- Latency: Nginx direct to najniższe opóźnienia. Tunnel dodaje latency przez routing przez sieć CF (zwykle 5-20ms w Europie).
- Zależność zewnętrzna: Tunnel wymaga dostępności Cloudflare. Nginx na własnym VPS jest niezależny.
- Ukrycie IP serwera: Nginx ujawnia IP (chyba że przez Cloudflare proxy). Tunnel całkowicie ukrywa IP serwera.