Cloudflare Tunnel som alternativ til portåbning

Cloudflare Tunnel forklaret uden portåbning

Ved klassisk portåbning opretter en ekstern klient direkte forbindelse til routerens eller serverens offentlige IP-adresse. Routeren videresender derefter den indgående trafik til en tjeneste i det interne netværk. En Cloudflare Tunnel vender denne forbindelsesoprettelse på hovedet: Connectoren cloudflared kører på det tilgængelige interne netværk og opretter selv udgående forbindelser til Cloudflare.

Hvis en bruger f.eks. åbner en administratorportal, modtager Cloudflare anmodningen om brugerens værtsnavn og videresender den via en allerede eksisterende tunnelforbindelse til connectoren. Denne når frem til den konfigurerede måltjeneste, f.eks. http://localhost:8080. Origin kræver derfor hverken en IP-adresse, der kan nås direkte fra internettet, eller en indgående firewall-tilladelse for denne tjeneste.

Det betyder ikke, at netværksreglerne bortfalder. Værten med cloudflared Cloudflare skal kunne oprette forbindelse til omverdenen. Cloudflare angiver i denne forbindelse port 7844 via TCP eller UDP; her anvendes henholdsvis HTTP/2 og QUIC. Udgående trafik skal være tilladt i den lokale firewall, på routeren og eventuelt via en virksomhedsproxy. Dette er den praktiske begrænsning bag udsagnet „uden portåbning“.

En DNS-post alene skaber ikke denne beskyttede forbindelsesvej. DNS tildeler blot et navn til en måladresse; den opretter ikke en forbindelse fra det private netværk og formidler ikke en lokal tjeneste. Den udgående stik er er den afgørende komponent: Han kender den interne måltjeneste og holder vejen dertil åben indefra og ud. Hvilke brugere der må benytte denne vej, skal konfigureres separat.

En tunnel er ikke en adgangsbeskyttelse

En tunnel reducerer oprindelsesserverens direkte synlighed på netværket, men træffer ikke selvstændigt beslutninger om adgangsrettigheder. Hvis et webadministrationspanel dirigeres via et offentligt værtsnavn, kan det i princippet tilgås af enhver internetbruger, hvis der ikke er en Access-applikation foran. Cloudflare anbefaler derfor, at Access konfigureres før den produktive tunnelforbindelse. Tunnelen er transportvejen, ikke adgangskontrollen.

For et privilegeret admin-panel bør der være en Adgangspolitik kun tillade klart definerede personer eller grupper. Ud over »Include«-, »Require«- og »Exclude«-kriterier er der handlinger som »Allow«, »Block«, »Bypass« og »Service Auth« til rådighed. MFA kan påkræves via en tilknyttet identitetsudbyder eller som en ekstra faktor. En generel regel for alle konti i et e-mail-domæne er som regel for vidtgående for grænseflader med høje privilegier.

Adgangslaget supplerer, men erstatter ikke en sikker konfiguration af applikationen. Administrationspanelet kræver fortsat sikker login, rettidige opdateringer, passende sessionsregler og en tilbageholden tildeling af rettigheder. Også lokale brugerkonti, roller og administratorrettigheder forbliver afgørende: Hvis en bruger efter login via Access får adgang til applikationen, må denne person ikke automatisk få yderligere administratorrettigheder der.

Derudover skal det kontrolleres, om applikationen validerer adgangstokener eller benytter den dertil beregnede tunnel-indstilling til token-validering. Dette knytter applikationen til den forudgående identitetskontrol og mindsker risici ved en utilsigtet alternativ adgangsvej til origin-serveren. Det er fornuftigt at anvende et lagdelt design: restriktiv offentliggørelse, identitetskontrol med MFA, minimale applikationsrettigheder og en internt tilgængelig, ikke-offentligt eksponeret måltjeneste.

Klassificering af HTTP, SSH, RDP og TCP

HTTP(S)-applikationer og administrationsprotokoller har forskellige adgangsmodeller. En intern webgrænseflade kan offentliggøres via et værtsnavn og sikres med Access foran Origin. SSH, RDP og visse TCP-tjenester kan ligeledes nås via tunneler, men kræver afhængigt af metoden yderligere software eller browserbaseret adgang på klientsiden. En web-login giver ikke automatisk adgang til et vilkårligt indbygget netværk.

Ved brug af SSH med den sædvanlige lokale terminal kan klient-side cloudflared Opret forbindelsen sammen med Access. Cloudflare dokumenterer desuden browserbaseret SSH som en separat adgangsvej. De to varianter adskiller sig med hensyn til klient-workflow, lokal SSH-konfiguration og betjening; de er derfor ikke generelt indbyrdes udskiftelige. Udsagn om mere omfattende infrastruktur- eller certifikatmodeller hører kun hjemme i en planlægning, hvis den aktuelle, relevante dokumentation herom er blevet gennemgået separat.

En SSH-terminal, der vises i en browser, kan være praktisk til support eller i en tidskritisk nødsituation, hvor der ikke er en lokal SSH-klient klar. Inden anvendelsen skal man dog vurdere revisionskrav, driftsprocedurer, lokale nøgleprocedurer og filoverførsler. RDP og andre TCP-tjenester bør ligeledes vurderes på baggrund af den enkelte anvendelse i stedet for at behandle dem generelt som en webgrænseflade.

Tunnel er ikke en fuldgyldig erstatning for alle former for netværksforbindelser. Serverinitierede protokoller som VoIP eller SIP understøttes ikke; også langvarige, afbrydelsesfølsomme TCP-sessioner kræver en egnethedsvurdering. Desuden ser Origin ved SSH, RDP og TCP ikke den oprindelige klient-IP, men derimod connectoren. Ved HTTP kan en applikation CF-Connecting-IP analysere. IP-baserede tilladelseslister og forensiske logfiler skal tage højde for denne grænse.

Sikker tildeling af flere tjenester

En lokal Ingress-fil knytter hvert offentliggjort værtsnavn til præcis én intern destination. For et admin-panel og SSH er det en god idé at bruge separate navne: På den måde holdes rettigheder, logfiler og senere ændringer klart adskilt fra hinanden. Cloudflared vurderer reglerne fra top til bund; den første regel, der passer, bestemmer målet.

Det følgende eksempel er en konfigurationsskabelon til en lokalt administreret tunnel. Den bruger bevidst example.invalid og indeholder hverken loginoplysninger eller et rigtigt domæne. Webtjenesten forbliver på localhost:8080 tilgængelig; SSH videresendes til den lokale SSH-tjeneste.

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

Den sidste regel er den Catch-all-reglen. Den er kræves til lokale Ingress-filer og sørger her for http_status:404 for at sikre, at et ukendt værtsnavn ikke ved en fejltagelse ender hos den første eller en anden intern tjeneste. En bred standardomdirigering ville udgøre en unødvendig risiko, især når det gælder administrative mål.

Filen definerer udelukkende stien fra tunnelen til Origin. Den opretter hverken DNS-poster eller beskytter navnene via Cloudflare Access. Inden en rute kan tages i brug, skal værtsnavnet og adgangsreglerne derfor konfigureres separat. Også lokalt bør målportene kun være tilgængelige der, hvor Cloudflare faktisk har brug for dem.

Før opstart kan rækkefølgen kontrolleres uden at ændre indstillingerne. Den første kommando validerer Ingress-konfigurationen; den anden viser, hvilken regel der ville gælde for den angivne adresse.

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

Målrettet udvælgelse af SSH-adgange

SSH via en tunnel er ikke en standardiseret adgangsmetode. Den rette variant afhænger af, om administratorer fortsat bruger deres lokale terminal, eller om de i tilfælde af en fejl skal arbejde uden en forudkonfigureret klient. De tilgængelige modeller adskiller sig med hensyn til klient, identitet og betjeningsforløb; den konkrete SSHD-konfiguration og den lokale rettighedsadministration forbliver adskilt herfra.

For et lille team, der regelmæssigt arbejder med velkendte lokale værktøjer, er client-side Cloudflare ofte en passende løsning: SSH-porten forbliver intern, mens Access indfører et ekstra identitetslag, inden forbindelsen oprettes. Det er dog ikke det samme som en central administration af alle SSH-rettigheder.

Adgang via browseren skal betragtes som en separat proces. Den kan være nyttig i forbindelse med support eller uplanlagt adgang, da den ikke forudsætter, at der er konfigureret en SSH-klient. Den er dog ikke en generelt bedre administrationsmetode: filoverførsler, velkendte lokale nøgleprocedurer og revisionskrav kan gøre en terminal-klient eller en privat adgang mere velegnet.

Uanset hvilken vej man vælger, forbliver de lokale beskyttelseslag intakte. Linux-konti, sudo-regler, SSHD-konfigurationen og rettighederne på målsystemet bestemmer fortsat, hvad en bruger, der er logget ind, må gøre. Tunnelen erstatter hverken disse regler eller en begrænset tildeling af rettigheder.

For offentliggjorte ikke-HTTP-tjenester kan det være nødvendigt at anvende cloudflared på klientsiden; SSH tilbyder desuden adgang via browseren. RDP og andre TCP-tjenester bør derfor ikke planlægges forhastet efter SSH-modellen, men i stedet ud fra deres respektive klient- og driftskrav.

Tunnel, VPN, bastion eller portåbning

Valget handler ikke kun om, hvorvidt en port er åben, men også om det ønskede omfang af adgangen. Cloudflare Tunnel er især velegnet til få, klart definerede tjenester. Hvis man derimod skal have adgang til mange interne systemer og netværkssegmenter, har man som regel brug for en model til privat netværksadgang i stedet for en samling af individuelle portåbninger.

En klassisk portåbning er ikke i sig selv forkert. Den kan være velegnet til en bevidst offentlig tjeneste, hvor der tages målrettet ansvar for applikationsbeskyttelse, firewall-drift og offentlig tilgængelighed. I modsætning hertil opretter connectoren i tunnelen forbindelsen udefra det interne net; origin-serveren behøver ikke at blive kontaktet direkte fra internettet.

Til et enkelt admin-panel eller et lille antal vedligeholdelsesmål er en tjenestebaseret offentliggørelse med identitetsbaseret adgang er som regel lettere at afgrænse end en omfattende netværkstunnel. Det fritager dog ikke for at undersøge protokollen: Serverinitierede protokoller understøttes ikke, og lange, afbrydelsesfølsomme TCP-sessioner kan kræve andre forbindelsesmodeller.

Et VPN er stadig en god løsning, hvis medarbejderne har brug for flere private applikationer, adresseområder eller interne afhængigheder. En bastion-host samler derimod SSH-adgange til ét indgangssted, som selv skal være omhyggeligt sikret og administreret. En reverse proxy er på sin side et lag til TLS-terminering og applikationslevering; den besvarer ikke alene spørgsmålet om, hvordan den private origin kan nås. Rollerne som proxy, applikationsserver og procesmanager kan også i Sammenligning af NGINX Unit og PHP-FPM forstå.

Den praktiske beslutning starter derfor med en afgrænsning: Hvilke personer har brug for adgang til hvilken tjeneste og med hvilken klient? Jo mere begrænset svaret er, desto lettere er det at drive en tunnel med præcise værtsnavne og regler. Omfattende netværksbehov, specielle protokoller eller høje krav til sessionsstabilitet taler derimod for en særskilt vurdering.

Sikring af tunneler under drift

En aktiv tunnel består ikke af en enkelt, lejlighedsvis forbindelse. Cloudflare dokumenterer for hver cloudflared-tunnel fire langvarige udgående forbindelser til mindst to af sine egne datacentre. Hvis en enkelt forbindelsesvej svigter, kan forespørgsler derfor dirigeres via en anden eksisterende vej. Dette reducerer afhængighederne på strækningen mellem Connector og Cloudflare, men gør ikke selve den interne tjeneste højtilgængelig.

Til kritiske applikationer kan flere cloudflared-instanser benytte den samme tunnel som replikaer. Dette skaber yderligere ruter fra Cloudflare-netværket til det private netværk, men erstatter hverken en redundant applikation eller en database- eller hoststrategi. Hvis for eksempel den eneste server med adminpanelet ikke er tilgængelig, hjælper yderligere connectorer på denne eller andre værter kun, hvis de rent faktisk kan nå den fungerende måltjeneste. Forbindelsesvej og tjenestetilgængelighed skal derfor planlægges hver for sig.

Hvis flere origins skal kontrolleres målrettet, omgås i tilfælde af fejl eller fordeles efter bestemte regler, er der behov for yderligere belastningsfordeling med sundhedstjek og trafikstyring. En tunnel alene træffer ikke disse beslutninger i dybden. Arkitekturen bør desuden fastlægge, hvordan måltjenesten genoprettes efter et nedbrud, og om der fortsat er behov for administrativ adgang under forstyrrelsen.

Tilgængeligheden begrænser sig ikke til selve softwaren. Hvis connectoren og målsystemet er placeret i et separat teknikrum, skal strømforsyning, køling, luftkvalitet og regelmæssige kontroller ligeledes indgå i driftskonceptet. Hvilke yderligere miljømæssige risici der kan opstå i denne sammenhæng, fremgår af gennemgangen af Ventilation af et serverrum i kælderen. Sådanne foranstaltninger kan ikke erstatte replikater, men de forhindrer, at alle de planlagte forbindelsesveje bryder sammen på grund af den samme lokale infrastrukturafhængighed.

Opdateringer af cloudflared skal udføres inden for et planlagt vedligeholdelsesvindue: De medfører en genstart og kan derfor påvirke den trafik, der netop behandles. Cloudflare nævner load balancing eller flere cloudflared-instanser som muligheder for opgraderinger uden afbrydelse. Hvilken opdateringsmetode der er den rigtige, afhænger af installationstypen og driftsmiljøet og bør dokumenteres inden vedligeholdelsesvinduet.

Dokumenter for hver opdatering den installerede version, den ansvarlige host, en alternativ løsning og en tilgængelighedstest for måltjenesten. Efter genstart skal du ikke kun kontrollere tunnelstatus, men også om den definerede Ingress-regel når frem til den forventede tjeneste, og om det planlagte adgangslag fortsat fungerer. På den måde forbliver connector, måltjeneste og autorisationsvej overskuelige som separate driftsopgaver.

Tidlig opdagelse af typiske konfigurationsfejl

Inden idriftsættelsen påbegyndes fejlfinding på connectoren: Værten skal kunne nå Cloudflare udgående via port 7844 via TCP eller UDP. Det er forventeligt, at der mangler en indgående portåbning, men derimod ikke, at der er en generel blokerende udgående firewall. Først når cloudflared kan oprette de udgående forbindelser, er det værd at undersøge DNS, værtsnavne og adgangsregler på applikationsniveau.

1. Kontroller lokal tilgængelighed: Den tjeneste, der er angivet i Ingress-reglen, skal være tilgængelig fra cloudflared-værten via det angivne lokale eller interne endepunkt.
2. Sammenlign DNS og Ingress: Det offentlige værtsnavn skal stemme overens med den tilsigtede tunnelrute; reglerne skal være rækkefølgemæssigt placeret således, at den specifikke tjeneste behandles før de mere generelle regler.
3. Test af catch-all: En afsluttende regel med http_status:404 forhindrer, at uforudsete værtsnavne videresendes til en standardtjeneste.
4. Konfigurer Access inden den produktive lancering: Først derefter kan den eksterne sti kontrolleres ved hjælp af en konto med og en konto uden adgangsrettigheder.

En hyppig sikkerhedsfejl er en for bred adgangsrute: I stedet for kun at give adgang til et admin-panel eller en bestemt SSH-tjeneste, gøres et større netværksområde tilgængeligt. Lige så risikabelt er generelle e-mail-domæneregler for privilegerede grænseflader. For administratoradgang bør små, kontrollerbare grupper, passende »Require«-kriterier og MFA afspejle den faktiske kreds af personer. Minimal godkendelse betyder også, at man ikke unødigt skal sammenfatte separate værtsnavne og måltjenester.

Tunnel- og adgangsrettighedskonfiguration løser forskellige opgaver. Ingress-reglen bestemmer, hvorhen en allerede etableret forbindelse skal føre hen; Access afgør, hvem der skal autentificeres og autoriseres inden da. Uden en passende Access-applikation kan et offentliggjort HTTP-værtsnavn være tilgængeligt fra internettet. Derfor er lokale konti, sudo-regler, SSHD-indstillinger og applikationens sikkerhedshærdning fortsat selvstændige kontrolpunkter.

For logfiler og revisioner er grænsen for kilde-IP vigtig: Ved SSH, RDP og andre TCP-adgange ser oprindelsesserveren ikke den oprindelige klient-IP, men derimod connector-konteksten. IP-baserede tilladelseslister på målsystemet udgør derfor ikke en pålidelig brugertilknytning. HTTP-applikationer kan udnytte CF-Connecting-IP-headeren, forudsat at deres logning og tillidskæde bevidst tager højde for dette.

Vælg den rigtige adgangsløsning

Cloudflare Tunnel er velegnet til et enkelt webadministrationspanel, hvis tjenesten skal være tilgængelig via et entydigt værtsnavn uden at afsløre en offentlig oprindelses-IP-adresse eller give adgang til indgående trafik. Den mest fornuftige opsætning er en snæver destination, forud for hvilken der er en adgangsapplikation med en lille identitetsgruppe og MFA. Metoden beskytter netværksstien, men erstatter hverken sikker sessionshåndtering eller rettighedskontrol i adminpanelet.

Et lille administratorteam, der er vant til at arbejde i terminalen, kan bruge SSH via cloudflared og Access på klientsiden. Browserbaseret SSH egner sig især som en forberedt nød- eller supportadgang. Begge metoder stiller forskellige krav til klienter og brugere; filoverførsel, arbejdsgange og revisionskrav skal passe til den valgte metode. Beslutninger om mere avancerede modeller for centraliserede SSH-rettigheder bør kun træffes på baggrund af den aktuelle, specifikke dokumentation for den pågældende model.

Hvis man har brug for mange interne tjenester, hele segmenter eller omfattende øst-vest-kommunikation, bør man overveje en privat netværksadgang såsom VPN eller en forbindelsesmodel, der er beregnet til dette formål. En enkelt offentliggjort tunnel er ikke automatisk en erstatning for alle VPN-arbejdsbelastninger. Tunnel er ikke egnet til serverinitierede protokoller som VoIP eller SIP; også langvarige, afbrydelsesfølsomme TCP-sessioner kræver en vurdering af den konkrete protokol og mulige konsekvenser af genopkobling.

En klassisk portåbning kan være forsvarlig, hvis en tjeneste bevidst tilbydes direkte til offentligheden, og firewall, origin-beskyttelse samt applikationsautentificering administreres i overensstemmelse hermed. En bastion-host samler SSH-adgange, men er selv et indgangssted, der skal sikres særligt omhyggeligt. En reverse proxy er derimod et lag til TLS-terminering og applikationslevering; den besvarer ikke alene spørgsmålet om, hvordan den private origin kan nås.

Den produktive minimumsstandard er: det mindst nødvendige målomfang, identitetsbaserede regler, MFA for privilegerede roller, testet Ingress- og Catch-all-konfiguration, planlagt opdateringsproces samt dokumenteret gendannelse. Genopretningsplan omfatter som minimum ansvarsfordeling, alternative ruter og kontrol af, om måltjenesten og connectoren igen er tilgængelige efter vedligeholdelse. Tunneler reducerer netværkets eksponerede overflade, men de erstatter ikke applikationssikkerhed, lokale adgangsrettigheder eller løbende driftsovervågning.