Cloudflare Tunnel som alternativ till portöppningar

Cloudflare Tunnel förklarat utan portöppning

Vid klassisk portöppning ansluter en extern klient direkt till routerns eller serverns offentliga IP-adress. Routern vidarebefordrar sedan den inkommande trafiken till en tjänst i det interna nätverket. En Cloudflare Tunnel vänder på denna anslutningsprocess: Connector cloudflared körs i det tillgängliga interna nätverket och upprättar själv utgående anslutningar till Cloudflare.

Om en användare till exempel öppnar en administratörsportal tar Cloudflare emot förfrågan om användarens värdnamn och vidarebefordrar den via en redan befintlig tunnelanslutning till anslutningsmodulen. Denna når den konfigurerade måltjänsten, till exempel http://localhost:8080. För Origin krävs därför varken en IP-adress som är direkt tillgänglig via internet eller en inkommande brandväggsöppning för denna tjänst.

Det betyder inte att nätverksreglerna upphävs. Värddatorn med cloudflared måste Cloudflare kunna nå utåt. Cloudflare anger för detta ändamål port 7844 via TCP eller UDP; här används HTTP/2 respektive QUIC. Utgående trafik måste tillåtas i den lokala brandväggen, på routern och, i förekommande fall, via en företagsproxy. Detta är den praktiska begränsningen bakom uttrycket „utan portöppning“.

En DNS-post i sig räcker inte för att skapa denna skyddade anslutningsväg. DNS kopplar endast ett namn till en måladress; det initierar ingen anslutning från det privata nätverket och förmedlar ingen lokal tjänst. Den utgående kontakt är den avgörande komponenten: Den känner till den interna måltjänsten och håller vägen dit öppen inifrån och ut. Vilka användare som får använda denna väg ska konfigureras separat.

En tunnel är inget åtkomstskydd

En tunnel minskar ursprungsserverns direkta synlighet i nätverket, men fattar inte självständiga beslut om behörigheter. Om en webbadministrationspanel dirigeras via ett offentligt värdnamn kan den i princip nås av vilken internetanvändare som helst utan en Access-applikation i förväg. Cloudflare rekommenderar därför att Access konfigureras före den produktiva tunneln. Tunneln är transportvägen, inte åtkomstkontrollen.

För en privilegierad administratörspanel bör en Åtkomstpolicy Endast tydligt definierade personer eller grupper ska tillåtas. Förutom kriterierna Include, Require och Exclude finns åtgärder som Allow, Block, Bypass och Service Auth tillgängliga. MFA kan krävas via en ansluten identitetsleverantör eller som en ytterligare faktor. En generell regel för alla konton inom en e-postdomän är oftast för omfattande för gränssnitt med höga behörigheter.

Åtkomstlagret kompletterar, men ersätter inte, säkerhetsåtgärderna i applikationen. Administratörspanelen kräver fortfarande säker inloggning, snabba uppdateringar, lämpliga sessionsregler och en återhållsam tilldelning av behörigheter. Även lokala användarkonton, roller och administratörsbehörigheter förblir avgörande: Om en användare efter inloggning via Access får åtkomst till applikationen, får denna person inte automatiskt tilldelas ytterligare administratörsbehörigheter där.

Dessutom bör man kontrollera om applikationen validerar åtkomsttoken eller använder den avsedda tunnelalternativet för tokenkontroll. Detta kopplar applikationen till den uppströms liggande identitetskontrollen och minskar riskerna med en oavsiktlig alternativ åtkomstväg till origin-servern. Det är lämpligt att använda en skiktad arkitektur: restriktiv publicering, identitetskontroll med MFA, minimala applikationsrättigheter och en internt tillgänglig måltjänst som inte är allmänt exponerad.

Klassificera HTTP, SSH, RDP och TCP

HTTP(S)-applikationer och administrationsprotokoll har olika åtkomstmodeller. Ett internt webbgränssnitt kan publiceras via ett värdnamn och skyddas med Access framför ursprungsservern. SSH, RDP och vissa TCP-tjänster kan också nås via tunnlar, men kräver beroende på metod ytterligare programvara eller webbläsarbaserad åtkomst på klientsidan. En inloggning via webben innebär inte automatiskt att man får obegränsad nativ nätverksåtkomst.

För SSH med den vanliga lokala terminalen kan klientbaserad cloudflared upprätta anslutningen tillsammans med Access. Cloudflare dokumenterar dessutom webbläsarbaserad SSH som en separat åtkomstväg. De båda varianterna skiljer sig åt vad gäller klientarbetsflöde, lokal SSH-konfiguration och hantering; de är därför inte generellt utbytbara. Uttalanden om mer omfattande infrastruktur- eller certifikatmodeller bör endast ingå i en planering om den aktuella, relevanta dokumentationen har granskats separat.

En SSH-terminal som renderas i webbläsaren kan vara praktisk för support eller tidspressad nödåtkomst om ingen lokal SSH-klient finns tillgänglig. Innan den tas i bruk måste dock revisionskrav, driftsrutiner, lokala nyckelprocedurer och filöverföringar utvärderas. RDP och andra TCP-tjänster bör också granskas per applikation, istället för att behandlas generellt som ett webbgränssnitt.

Tunnel är inte en fullvärdig ersättning för alla typer av nätverksanslutningar. Serverinitierade protokoll som VoIP eller SIP stöds inte; även långvariga, avbrottskänsliga TCP-sessioner kräver en lämplighetsprövning. Dessutom ser Origin inte den ursprungliga klient-IP-adressen vid SSH, RDP och TCP, utan istället connectoren. Vid HTTP kan en applikation CF-Connecting-IP utvärdera. IP-baserade tillåtelselistor och forensiska loggar måste ta hänsyn till denna gräns.

Tilldela flera tjänster på ett säkert sätt

En lokal Ingress-fil kopplar varje publicerat värdnamn till exakt ett internt mål. För en administratörspanel och SSH är det lämpligt att använda separata namn: på så sätt hålls behörigheter, loggar och senare ändringar tydligt åtskilda från varandra. Cloudflared utvärderar reglerna uppifrån och ner; den första regel som stämmer avgör målet.

Följande exempel är en konfigurationsmall för en lokalt hanterad tunnel. Den använder medvetet example.invalid och innehåller varken inloggningsuppgifter eller en verklig domän. Webbtjänsten förblir på localhost:8080 tillgänglig; SSH vidarebefordras till den lokala SSH-tjänsten.

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 sista regeln är den Allomfattande regel. Den krävs för lokala Ingress-filer och ser här till att http_status:404 för att ett okänt värdnamn inte av misstag ska hamna hos den första eller någon annan intern tjänst. En bred standardvidarebefordran skulle utgöra en onödig risk, särskilt när det gäller administrativa mål.

Filen definierar endast vägen från tunneln till Origin. Den konfigurerar varken DNS-poster eller skyddar namnen med Cloudflare Access. Innan en produktiv rutt kan tas i bruk måste därför värdnamn och åtkomstpolicy konfigureras separat. Även lokalt bör målportarna endast vara tillgängliga där cloudflared faktiskt behöver dem.

Innan man startar kan man kontrollera ordningen utan att ändra inställningarna. Det första kommandot validerar Ingress-konfigurationen; det andra visar vilken regel som skulle gälla för den angivna adressen.

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

Välj SSH-åtkomster på ett målinriktat sätt

SSH via en tunnel är inte en enhetlig åtkomstväg. Vilken variant som är lämplig beror på om administratörerna fortsätter att använda sin lokala terminal eller om de vid ett fel måste arbeta utan en förberedd klient. De tillgängliga modellerna skiljer sig åt vad gäller klient, identitet och användningsflöde; den konkreta SSHD-konfigurationen och den lokala behörighetshanteringen förblir separata från detta.

För ett litet team som regelbundet arbetar med välkända lokala verktyg passar ofta client-sidan av Cloudflare: SSH-porten förblir intern, medan Access lägger till ett extra identitetsskikt innan anslutningen upprättas. Detta är dock inte detsamma som en central hantering av alla SSH-behörigheter.

Åtkomst via webbläsaren ska betraktas som en separat process. Den kan vara användbar vid support eller vid oplanerad åtkomst, eftersom den inte kräver någon konfigurerad SSH-klient. Den är dock inte en generellt sett bättre administrationsmetod: filöverföringar, välbekanta lokala nyckelrutiner och revisionskrav kan göra en terminal-klient eller en privat åtkomst mer lämplig.

Oavsett vilken väg man väljer kvarstår de lokala skyddslagren. Linux-konton, sudo-regler, SSHD-konfigurationen och behörigheterna på målsystemet avgör fortfarande vad en användare som har loggat in får göra. Tunneln ersätter varken dessa regler eller en begränsad behörighetstilldelning.

För publicerade icke-HTTP-tjänster kan det krävas cloudflared på klientsidan; SSH erbjuder dessutom åtkomst via webbläsaren. RDP och andra TCP-tjänster bör därför inte planeras förhastat enligt SSH-modellen, utan utifrån sina respektive klient- och driftskrav.

Tunnel, VPN, bastion eller portöppning

Valet handlar inte bara om huruvida en port är öppen, utan också om vilken omfattning åtkomsten ska ha. Cloudflare Tunnel lämpar sig framför allt för ett fåtal tydligt definierade tjänster. Den som däremot behöver nå många interna system och nätverkssegment behöver oftast en modell för privat nätverksåtkomst istället för en samling enskilda publiceringar.

En klassisk portöppning är inte i sig fel. Den kan vara lämplig för en medvetet offentlig tjänst där man på ett målinriktat sätt ansvarar för applikationsskydd, brandväggsdrift och offentlig tillgänglighet. Till skillnad från detta upprättar anslutningsmodulen i tunneln förbindelsen utifrån det interna nätverket; källan behöver inte nås direkt från internet.

För en enskild administratörspanel eller en liten uppsättning underhållsmål är en tjänstbaserad publicering med identitetsbaserad åtkomst oftast lättare att avgränsa än en omfattande nätverkstunnel. Detta innebär dock inte att man kan bortse från granskningen av protokollet: serverinitierade protokoll stöds inte, och långa TCP-sessioner som är känsliga för avbrott kan kräva andra anslutningsmodeller.

Ett VPN är fortfarande lämpligt om medarbetarna behöver flera privata applikationer, adressutrymmen eller interna beroenden. En bastionvärd samlar däremot SSH-åtkomster till en enda ingångspunkt, som i sin tur måste säkras noggrant och skötas på rätt sätt. En omvänd proxy är i sin tur en nivå för TLS-avslutning och applikationsleverans; den besvarar inte i sig frågan om hur den privata ursprungsservern nås. Rollerna som proxy, applikationsserver och processhanterare kan även hanteras i Jämförelse mellan NGINX Unit och PHP-FPM förstå.

Det praktiska beslutet börjar därför med en avgränsning: Vilka personer behöver åtkomst till vilken tjänst och med vilken klient? Ju mer begränsad svaret är, desto lättare blir det att driva en tunnel med exakta värdnamn och regler. Omfattande nätverksbehov, specialprotokoll eller höga krav på sessionsstabilitet talar däremot för en separat utvärdering.

Säkra tunnlar under drift

En aktiv tunnel består inte av en enda, tillfällig anslutning. Cloudflare dokumenterar för varje cloudflared-tunnel fyra långvariga utgående anslutningar till minst två av sina egna datacenter. Om en enskild anslutningsväg slutar fungera kan förfrågningar därför ledas via en annan befintlig väg. Detta minskar beroendet på sträckan mellan Connector och Cloudflare, men gör inte den interna tjänsten i sig högtillgänglig.

För kritiska tillämpningar kan flera cloudflared-instanser använda samma tunnel som repliker. Detta skapar ytterligare vägar från Cloudflare-nätverket till det privata nätverket, men ersätter varken en redundant applikation eller en databas- eller värdstrategi. Om till exempel den enda servern med adminpanelen inte är tillgänglig, hjälper ytterligare anslutningar på denna eller andra värdar endast i den mån de faktiskt kan nå den fungerande måltjänsten. anslutningsväg Därför måste drift och tillgänglighet planeras separat.

Om flera ursprungsservrar ska kontrolleras selektivt, kringgås vid störningar eller fördelas enligt vissa regler krävs ytterligare lastbalansering med hälsokontroller och trafikstyrning. En tunnel i sig kan inte fatta dessa beslut på ett djupgående sätt. Arkitekturen bör dessutom fastställa hur måltjänsten återställs efter ett avbrott och om administrativ åtkomst fortfarande behövs under störningen.

Tillgängligheten gäller inte bara programvaran. Om anslutningsenheten och målsystemet är placerade i ett eget teknikrum måste även strömförsörjning, kylning, luftkvalitet och regelbundna kontroller ingå i driftskonceptet. Vilka ytterligare miljörelaterade risker som kan uppstå i detta sammanhang framgår av analysen av Ventilation av ett serverrum i källaren. Sådana åtgärder ersätter inte repliker, men förhindrar att alla planerade anslutningsvägar misslyckas på grund av samma lokala infrastrukturberoende.

Uppdateringar av cloudflared bör genomföras under ett planerat underhållsfönster: de medför en omstart och kan därmed påverka den trafik som just då hanteras. Cloudflare anger lastbalansering eller flera cloudflared-instanser som alternativ för uppgraderingar utan avbrott. Vilken uppdateringsmetod som är lämplig beror på installationssätt och driftsmiljö och bör dokumenteras före underhållsfönstret.

Dokumentera för varje uppdatering den installerade versionen, den ansvariga värden, en reservlösning och ett tillgänglighetstest för måltjänsten. Kontrollera efter omstarten inte bara tunnelstatusen, utan även om den definierade Ingress-regeln når den förväntade tjänsten och om den avsedda åtkomstnivån fortfarande gäller. På så sätt förblir Connector, måltjänsten och behörighetsvägen spårbara som separata driftsuppgifter.

Upptäcka typiska felkonfigurationer i ett tidigt skede

Innan driftsättningen inleds felsökningen på Connector: Värddatorn måste kunna nå Cloudflare utgående via port 7844 via TCP eller UDP. Det är normalt att ingående portar inte är öppna, men det är inte normalt att en utgående brandvägg blockerar allt. Först när cloudflared kan upprätta de utgående anslutningarna är det värt att undersöka DNS, värdnamn och åtkomstregler på applikationsnivå.

1. Kontrollera lokal tillgänglighet: Den tjänst som anges i Ingress-regeln måste vara tillgänglig från cloudflared-värden via den angivna lokala eller interna slutpunkten.
2. Synkronisera DNS och Ingress: Det offentliga värdnamnet måste stämma överens med den avsedda tunneln; reglernas ordning måste vara sådan att den specifika tjänsten prioriteras framför mer allmänna regler.
3. Testa catch-all: En avslutande regel med http_status:404 förhindrar att oväntade värdnamn vidarebefordras till en standardtjänst.
4. Konfigurera Access innan den tas i drift: Först därefter kan den externa sökvägen kontrolleras noggrant med ett behörigt och ett obehörigt konto.

Ett vanligt säkerhetsfel är en alltför bred åtkomstväg: istället för att endast ge åtkomst till en administratörspanel eller en definierad SSH-tjänst görs ett större nätverksområde tillgängligt. Lika riskabelt är generella regler för e-postdomäner för privilegierade gränssnitt. För administratörsåtkomst bör små, kontrollerbara grupper, lämpliga Require-kriterier och MFA återspegla den faktiska personkretsen. Minimal godkännande innebär också att man inte i onödan slår samman separata värdnamn och måltjänster.

Tunnel- och behörighetskonfigurationen fyller olika syften. Ingress-regeln avgör vart en redan upprättad anslutning ska vidarebefordras; Access avgör vem som ska autentiseras och auktoriseras innan dess. Utan en lämplig Access-applikation kan ett publicerat HTTP-värdnamn vara tillgängligt från internet. Därför förblir även lokala konton, sudo-regler, SSHD-inställningar och säkerhetshärdningen av applikationen separata kontrollpunkter.

Gränsen för käll-IP-adressen är viktig för loggar och revisioner: Vid SSH, RDP och andra TCP-anslutningar ser källan inte klientens ursprungliga IP-adress, utan anslutningskontexten. IP-baserade tillåtelselistor på målsystemet utgör därför ingen tillförlitlig användartoddelning. HTTP-applikationer kan utvärdera rubriken CF-Connecting-IP, förutsatt att deras loggning och förtroendekedja medvetet tar hänsyn till detta.

Välj rätt åtkomstlösning

Cloudflare Tunnel är lämpligt för en enskild webbadministrationspanel om tjänsten ska kunna nås via ett tydligt värdnamn utan att en offentlig ursprungs-IP-adress eller inkommande åtkomst behövs. En lämplig konfiguration är en snäv måladress, med en åtkomstapplikation med en liten identitetsgrupp och MFA framför. Metoden skyddar nätverksvägen, men ersätter varken säker sessionshantering eller behörighetskontroll i administratörspanelen.

Ett litet administratörsteam som är van vid att arbeta i terminalen kan använda SSH via clientbaserade Cloudflared och Access. Webbläsarbaserad SSH lämpar sig framför allt som en förberedd nöd- eller supportåtkomst. De båda metoderna ställer olika krav på klienter och användare; filöverföring, arbetsflöden och revisionskrav måste passa den valda metoden. Beslut om mer avancerade modeller för centraliserade SSH-behörigheter bör endast fattas på grundval av deras aktuella, specifika dokumentation.

Den som behöver många interna tjänster, hela segment eller omfattande öst-väst-kommunikation bör överväga en privat nätverksanslutning, såsom VPN, eller en anslutningsmodell avsedd för detta ändamål. En enskild publicerad tunnel ersätter inte automatiskt alla VPN-arbetsbelastningar. Tunneln är inte lämplig för serverinitierade protokoll som VoIP eller SIP; även långvariga, avbrottskänsliga TCP-sessioner kräver en granskning av det specifika protokollet och eventuella konsekvenser av återanslutning.

En klassisk portöppning kan vara acceptabel om en tjänst medvetet erbjuds direkt till allmänheten och brandvägg, ursprungsskydd samt applikationsautentisering hanteras på rätt sätt. En bastionvärd samlar SSH-åtkomster, men förblir själv en ingångspunkt som måste säkras särskilt noggrant. En omvänd proxy är å sin sida en nivå för TLS-avslutning och applikationsleverans; den besvarar inte enbart frågan om hur den privata ursprungskällan kan nås.

Den produktiva minimistandarden är: minsta nödvändiga målomfång, identitetsbaserade regler, MFA för privilegierade roller, testad Ingress- och Catch-all-konfiguration, planerad uppdateringsprocess samt dokumenterad återställning. Återhämtningsplan omfattar åtminstone ansvarsområden, alternativa vägar samt kontroll av att måltjänsten och anslutningen åter är tillgängliga efter underhåll. Tunnlar minskar nätverkets utsatta yta, men ersätter inte applikationshårdning, lokala behörigheter eller löpande driftsövervakning.