Cloudflare Tunnel als alternatief voor het openstellen van poorten

Cloudflare Tunnel uitgelegd zonder poorttoegang

Bij klassieke poortdoorsturing maakt een externe client rechtstreeks verbinding met het openbare IP-adres van de router of server. De router stuurt het inkomende verkeer vervolgens door naar een dienst in het interne netwerk. Een Cloudflare Tunnel keert dit verbindingsproces om: de connector cloudflared draait op het toegankelijke interne netwerk en brengt zelf uitgaande verbindingen tot stand met Cloudflare.

Als een gebruiker bijvoorbeeld een beheerdersportaal opent, ontvangt Cloudflare het verzoek voor de hostnaam en stuurt dit via een reeds bestaande tunnelverbinding door naar de connector. Deze bereikt de geconfigureerde doelservice, bijvoorbeeld http://localhost:8080. Voor de Origin is daarom noch een rechtstreeks via internet bereikbaar IP-adres, noch een inkomende firewalltoegang voor deze dienst nodig.

Dat betekent niet dat er geen netwerkregels meer gelden. De host met cloudflared Cloudflare moet verbinding kunnen maken met de buitenwereld. Cloudflare specificeert hiervoor poort 7844 via TCP of UDP; daarbij wordt gebruikgemaakt van respectievelijk HTTP/2 en QUIC. Uitgaand verkeer moet worden toegestaan in de lokale firewall, op de router en, indien van toepassing, via een bedrijfsproxy. Dit is de praktische beperking achter de uitspraak „zonder poortopeningen“.

Een DNS-vermelding alleen is niet voldoende om dit beveiligde verbindingspad tot stand te brengen. DNS koppelt alleen een naam aan een doeladres; het brengt geen verbinding tot stand vanuit het privénetwerk en biedt geen lokale dienst aan. De uitgaande connector is het cruciale onderdeel: het kent de interne doelservice en houdt de route daarheen van binnen naar buiten open. Welke gebruikers deze route mogen gebruiken, moet afzonderlijk worden geconfigureerd.

Een tunnel is geen toegangsbeveiliging

Een tunnel vermindert de directe zichtbaarheid van de origin op het netwerk, maar beslist niet zelfstandig over toegangsrechten. Als een webbeheerpaneel via een openbare hostnaam wordt gerouteerd, kan het in principe door elke internetgebruiker worden geopend zonder dat er een Access-toepassing aan voorafgaat. Cloudflare raadt daarom aan om Access vóór de productieve tunnelroute in te stellen. De tunnel is het transportpad, niet de toegangscontrole.

Voor een beveiligd beheerderspaneel zou een Toegangsbeleid alleen duidelijk gedefinieerde personen of groepen toelaten. Naast Include-, Require- en Exclude-criteria zijn er acties beschikbaar zoals Allow, Block, Bypass en Service Auth. MFA kan worden afgedwongen via een gekoppelde identiteitsprovider of als extra factor. Een algemene regel voor alle accounts van een e-maildomein gaat meestal te ver voor interfaces met hoge bevoegdheden.

De toegangslaag vormt een aanvulling op, maar vervangt niet de beveiliging van de applicatie. Het beheerderspaneel vereist nog steeds een veilige aanmelding, tijdige updates, passende sessieregels en een terughoudende toekenning van rechten. Ook lokale gebruikersaccounts, rollen en beheerdersrechten blijven van cruciaal belang: als een gebruiker na aanmelding via Access toegang krijgt tot de applicatie, mag deze persoon daar niet automatisch verdergaande beheerdersrechten krijgen.

Daarnaast moet worden gecontroleerd of de applicatie access-tokens valideert of gebruikmaakt van de daarvoor bestemde tunneloptie voor tokenverificatie. Dit koppelt de applicatie aan de voorafgaande identiteitscontrole en vermindert risico's door een onbedoelde alternatieve toegangsweg naar de origin. Een gelaagde aanpak is zinvol: restrictieve publicatie, identiteitscontrole met MFA, minimale applicatierechten en een intern bereikbare, niet algemeen blootgestelde doelservice.

HTTP, SSH, RDP en TCP indelen

HTTP(S)-toepassingen en beheerprotocollen hebben verschillende toegangsmodellen. Een interne webinterface kan via een hostnaam worden gepubliceerd en met Access worden beveiligd vóór de origin. SSH, RDP en bepaalde TCP-diensten kunnen eveneens via tunnels bereikbaar zijn, maar vereisen aan de clientzijde, afhankelijk van de methode, aanvullende software of toegang via een browser. Een webaanmelding leidt hierdoor niet automatisch tot willekeurige native netwerktoegang.

Voor SSH via de gebruikelijke lokale terminal kan aan de clientzijde cloudflared de verbinding samen met Access tot stand brengen. Cloudflare beschrijft daarnaast door de browser weergegeven SSH als een afzonderlijke toegangsmethode. Beide varianten verschillen wat betreft de client-workflow, de lokale SSH-configuratie en de bediening; ze zijn daarom niet zonder meer onderling uitwisselbaar. Uitspraken over verdergaande infrastructuur- of certificaatmodellen horen alleen thuis in een planning als de actuele, relevante documentatie daarvan afzonderlijk is gecontroleerd.

Een via de browser weergegeven SSH-terminal kan handig zijn voor ondersteuning of voor tijdkritische noodtoegang, wanneer er geen lokale SSH-client beschikbaar is. Vóór het gebruik moeten echter auditvoorschriften, bedieningsprocedures, lokale sleutelprocedures en bestandsoverdrachten worden beoordeeld. RDP en andere TCP-diensten moeten eveneens per toepassing worden gecontroleerd, in plaats van ze over één kam te scheren met een webinterface.

Tunnel is geen volwaardige vervanging voor elke netwerkverbinding. Door de server geïnitieerde protocollen zoals VoIP of SIP worden niet ondersteund; ook langdurige, onderbrekingsgevoelige TCP-sessies vereisen een geschiktheidscontrole. Bovendien ziet de Origin bij SSH, RDP en TCP niet het oorspronkelijke IP-adres van de client, maar dat van de connector. Bij HTTP kan een toepassing CF-Connecting-IP analyseren. IP-gebaseerde allow-lists en forensische logbestanden moeten rekening houden met deze limiet.

Meerdere diensten veilig toewijzen

Een lokaal Ingress-bestand koppelt elke gepubliceerde hostnaam aan precies één interne bestemming. Voor een admin-paneel en SSH is het zinvol om aparte namen te gebruiken: zo blijven machtigingen, logbestanden en latere wijzigingen duidelijk van elkaar gescheiden. Cloudflared evalueert de regels van boven naar beneden; de eerste regel die van toepassing is, bepaalt de bestemming.

Het volgende voorbeeld is een configuratiesjabloon voor een lokaal beheerde tunnel. Hierin wordt bewust gebruikgemaakt van example.invalid en bevat noch inloggegevens, noch een echt domein. De webservice blijft beperkt tot localhost:8080 bereikbaar; SSH wordt doorgestuurd naar de lokale SSH-dienst.

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

De laatste regel is de Catch-all-regel. Dit is nodig voor lokale Ingress-bestanden en zorgt hier met http_status:404 om te voorkomen dat een onbekende hostnaam per ongeluk bij de eerste of een andere interne dienst terechtkomt. Een brede standaarddoorsturing zou vooral bij administratieve doelen een onnodig risico vormen.

Het bestand definieert uitsluitend de route van de tunnel naar Origin. Het stelt geen DNS-vermeldingen in en beschermt de namen ook niet via Cloudflare Access. Voordat een route in productie kan worden genomen, moeten de hostnaam en het toegangsbeleid daarom afzonderlijk worden geconfigureerd. Ook lokaal mogen de doelpoorten alleen bereikbaar zijn op de plaatsen waar Cloudflare ze daadwerkelijk nodig heeft.

Voor het opstarten kan de volgorde worden gecontroleerd zonder de instellingen te wijzigen. Het eerste commando valideert de Ingress-configuratie; het tweede laat zien welke regel voor het opgegeven adres van toepassing zou zijn.

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

SSH-toegangen doelgericht selecteren

SSH via een tunnel is geen uniforme toegangsmethode. Welke variant het meest geschikt is, hangt af van de vraag of beheerders hun lokale terminal blijven gebruiken of in geval van een storing zonder vooraf ingestelde client moeten werken. De beschikbare modellen verschillen wat betreft client, identiteit en bedieningsprocedure; de concrete SSHD-configuratie en het lokale rechtenbeheer blijven hiervan gescheiden.

Voor een klein team dat regelmatig met bekende lokale tools werkt, is client-side Cloudflare vaak een geschikte oplossing: de SSH-poort blijft intern, terwijl Access vóór het tot stand brengen van de verbinding een extra identiteitslaag toevoegt. Dit is echter niet hetzelfde als een centraal beheer van alle SSH-toegangsrechten.

Toegang via de browser moet als een afzonderlijk proces worden beschouwd. Dit kan handig zijn bij ondersteuning of bij onvoorziene toegang, omdat er geen geconfigureerde SSH-client nodig is. Het is echter geen algemeen betere beheermethode: bestandsoverdrachten, vertrouwde lokale sleutelprocedures en auditvoorschriften kunnen een terminalclient of een privétoegang geschikter maken.

Ongeacht de manier waarop dit gebeurt, blijven lokale beveiligingslagen bestaan. Linux-accounts, sudo-regels, De SSHD-configuratie en de rechten op het doelsysteem blijven bepalend voor wat een gebruiker die zich succesvol heeft aangemeld, mag doen. De tunnel vervangt noch deze regels, noch een beperkte toekenning van rechten.

Voor gepubliceerde niet-HTTP-diensten kan cloudflared aan de clientzijde nodig zijn; SSH biedt daarnaast toegang via de browser. RDP en andere TCP-diensten moeten daarom niet overhaast volgens het SSH-model worden gepland, maar op basis van hun specifieke client- en systeemvereisten.

Tunnel, VPN, bastion of poortdoorsturing

De keuze heeft niet alleen betrekking op de vraag of een poort openstaat, maar ook op de gewenste omvang van de toegang. Cloudflare Tunnel is vooral geschikt voor een klein aantal duidelijk omschreven diensten. Wie daarentegen toegang moet hebben tot veel interne systemen en netwerksegmenten, heeft meestal een model voor toegang tot het privé-netwerk nodig in plaats van een verzameling afzonderlijke publicaties.

Een klassieke poortopenstelling is niet per definitie verkeerd. Het kan geschikt zijn voor een bewust openbare dienst, waarbij de beveiliging van de applicaties, de werking van de firewall en de openbare bereikbaarheid doelgericht worden beheerd. In tegenstelling hiermee brengt de connector bij een tunnel de verbinding tot stand vanuit het interne netwerk; de bron hoeft niet rechtstreeks via het internet te worden benaderd.

Voor één enkel beheerderspaneel of een klein aantal onderhoudsdoelen is een dienstgerichte publicatie met toegang op basis van identiteit meestal gemakkelijker af te bakenen dan een uitgebreide netwerktunnel. Dit betekent echter niet dat het protocol niet hoeft te worden gecontroleerd: door de server geïnitieerde protocollen worden niet ondersteund, en lange, onderbrekingsgevoelige TCP-sessies kunnen andere connectiviteitsmodellen vereisen.

Een VPN blijft zinvol wanneer medewerkers meerdere privétoepassingen, adresruimten of interne afhankelijkheden nodig hebben. Een bastionhost concentreert daarentegen SSH-toegangen op één toegangspunt, dat zelf zorgvuldig moet worden beveiligd en beheerd. Een reverse proxy is op zijn beurt een laag voor TLS-terminatie en applicatie-uitrol; deze biedt niet alleen een antwoord op de vraag hoe de privé-origin bereikbaar is. De rollen van proxy, applicatieserver en procesmanager kunnen ook in de Vergelijking tussen NGINX Unit en PHP-FPM begrijpen.

De praktische beslissing begint daarom met een afbakening: welke personen hebben toegang nodig tot welke dienst en met welke client? Hoe beperkter dit antwoord is, des te beter kan een tunnel met precieze hostnamen en regels worden beheerd. Uitgebreide netwerkbehoeften, speciale protocollen of hoge eisen aan de stabiliteit van de sessie pleiten daarentegen voor een afzonderlijke beoordeling.

Tunnels tijdens het gebruik beveiligen

Een actieve tunnel bestaat niet uit één enkele, incidentele verbinding. Cloudflare documenteert voor elke cloudflared-tunnel vier langdurige uitgaande verbindingen met ten minste twee eigen datacenters. Als één verbindingspad uitvalt, kunnen verzoeken daarom via een ander bestaand pad worden verwerkt. Dit vermindert de afhankelijkheden op het traject tussen de connector en Cloudflare, maar maakt de interne dienst zelf niet hoogbeschikbaar.

Voor kritieke toepassingen kunnen meerdere cloudflared-instanties dezelfde tunnel als replicaten gebruiken. Dit creëert extra routes van het Cloudflare-netwerk naar het privé-netwerk, maar vervangt noch een redundante toepassing, noch een database- of hoststrategie. Als bijvoorbeeld de enige server met het admin-paneel niet bereikbaar is, helpen extra connectoren op deze of andere hosts alleen als ze de werkende doelservice daadwerkelijk kunnen bereiken. verbindingspad en de beschikbaarheid van diensten moeten daarom afzonderlijk worden gepland.

Als meerdere origins gericht moeten worden gecontroleerd, bij storingen moeten worden omzeild of volgens regels moeten worden verdeeld, is aanvullende load balancing met health checks en traffic steering vereist. Een tunnel alleen neemt deze beslissingen niet grondig. De architectuur moet bovendien vastleggen hoe de doelservice na een storing wordt hersteld en of administratieve toegang tijdens de storing nog steeds nodig is.

De beschikbaarheid beperkt zich niet tot de software. Als de connector en het doelsysteem in een aparte technische ruimte staan, moeten ook de stroomvoorziening, de koeling, de luchtkwaliteit en regelmatige controles in het exploitatieconcept worden meegenomen. Welke aanvullende omgevingsrisico’s hierbij kunnen optreden, blijkt uit de beschouwing over de Ventilatie van een serverruimte in de kelder. Dergelijke maatregelen zijn geen vervanging voor replicaties, maar voorkomen wel dat alle beoogde verbindingspaden stranden op dezelfde lokale infrastructuurafhankelijkheid.

Updates van cloudflared moeten binnen een gepland onderhoudsvenster plaatsvinden: ze leiden tot een herstart en kunnen daardoor het verkeer dat op dat moment wordt verwerkt, beïnvloeden. Cloudflare noemt load balancing of meerdere cloudflared-instanties als opties voor upgrades zonder onderbreking. Welke updatemethode geschikt is, hangt af van het type installatie en de bedrijfsomgeving en moet vóór het onderhoudsvenster worden gedocumenteerd.

Documenteer voor elke update de geïnstalleerde versie, de verantwoordelijke host, een uitwijkroute en een bereikbaarheidstest voor de doelservice. Controleer na het herstarten niet alleen de tunnelstatus, maar ook of de gedefinieerde Ingress-regel de verwachte dienst bereikt en of de beoogde toegangslaag nog steeds van kracht is. Zo blijven de connector, de doelservice en het autorisatiepad als afzonderlijke operationele taken traceerbaar.

Typische configuratiefouten vroegtijdig opsporen

Vóór de livegang begint het opsporen van fouten bij de connector: de host moet Cloudflare vanuit zijn eigen systeem via poort 7844 via TCP of UDP kunnen bereiken. Het is te verwachten dat er geen inkomende poort is vrijgegeven, maar een firewall die alle uitgaande verbindingen blokkeert, is dat niet. Pas wanneer cloudflared de uitgaande verbindingen tot stand kan brengen, is het de moeite waard om DNS, hostnamen en toegangsregels op applicatieniveau te onderzoeken.

1. Controleer de lokale bereikbaarheid: de in de Ingress-regel genoemde dienst moet vanaf de cloudflared-host bereikbaar zijn via het opgegeven lokale of interne eindpunt.
2. DNS en Ingress op elkaar afstemmen: de openbare hostnaam moet overeenkomen met de beoogde tunnelroute; de volgorde van de regels moet ervoor zorgen dat de specifieke dienst voorrang krijgt boven algemenere regels.
3. Catch-all testen: een afsluitende regel met http_status:404 voorkomt dat onvoorziene hostnamen worden doorgestuurd naar een standaarddienst.
4. Access instellen vóór de productieve release: pas daarna kan het externe pad op een gecontroleerde manier worden getest met zowel een geautoriseerd als een niet-geautoriseerd account.

Een veelvoorkomende beveiligingsfout is een te brede route: in plaats van slechts één beheerpaneel of een specifieke SSH-dienst vrij te geven, wordt een groter netwerkgebied toegankelijk gemaakt. Even riskant zijn algemene e-maildomeinregels voor bevoorrechte interfaces. Voor beheerderstoegang moeten kleine, controleerbare groepen, passende ‘Require’-criteria en MFA de daadwerkelijke groep personen weerspiegelen. Minimale goedkeuring betekent ook dat afzonderlijke hostnamen en doelservices niet onnodig moeten worden samengevoegd.

Tunnel- en autorisatieconfiguratie dienen verschillende doelen. De ingress-regel bepaalt waar een reeds tot stand gebrachte verbinding naartoe gaat; Access bepaalt wie daarvoor wordt geauthenticeerd en geautoriseerd. Zonder de juiste Access-toepassing kan een gepubliceerde HTTP-hostnaam bereikbaar zijn vanaf het internet. Ook lokale accounts, sudo-regels, SSHD-instellingen en het beveiligen van de applicatie blijven daarom afzonderlijke controlepunten.

Voor logbestanden en audits is de bron-IP-limiet van belang: bij SSH, RDP en andere TCP-toegangen ziet de bron niet het oorspronkelijke IP-adres van de client, maar de connectorcontext. Op IP gebaseerde allow-lists op het doelsysteem bieden hiervoor geen betrouwbare toewijzing aan gebruikers. HTTP-toepassingen kunnen de header CF-Connecting-IP evalueren, mits hun logboekregistratie en hun vertrouwensketen hier bewust rekening mee houden.

De juiste toegangsoplossing kiezen

Cloudflare Tunnel is geschikt voor een enkel webbeheerpaneel als de dienst via een duidelijke hostnaam bereikbaar moet zijn, zonder dat er een openbaar origin-IP-adres of inkomende toegang nodig is. De aanbevolen opzet is een strikt afgebakende bestemming, voorafgegaan door een toegangsapplicatie met een kleine identiteitsgroep en MFA. Deze werkwijze beveiligt het netwerkpad, maar vervangt noch veilig sessiebeheer, noch rechtencontrole in het beheerpaneel.

Een klein beheerteam dat gewend is aan het werken met een terminal, kan SSH gebruiken via cloudflared en Access aan de clientzijde. SSH via de browser is vooral geschikt als vooraf ingestelde nood- of ondersteuningstoegang. Beide methoden stellen verschillende eisen aan de client en de bediening; bestandsoverdracht, werkprocessen en auditvoorschriften moeten aansluiten bij de gekozen methode. Over meer geavanceerde modellen voor gecentraliseerde SSH-toegangsrechten mag alleen worden beslist op basis van de actuele, specifieke documentatie daarvan.

Wie veel interne diensten, hele segmenten of uitgebreide oost-west-communicatie nodig heeft, zou een privé-netwerktoegang zoals een VPN of een daarvoor bestemd connectiviteitsmodel moeten overwegen. Een enkele gepubliceerde tunnel is niet automatisch een vervanging voor alle VPN-workloads. Voor door servers geïnitieerde protocollen zoals VoIP of SIP is een tunnel niet geschikt; ook langdurige, onderbrekingsgevoelige TCP-sessies vereisen een beoordeling van het specifieke protocol en de mogelijke gevolgen van het opnieuw verbinden.

Het openstellen van poorten op de klassieke manier kan aanvaardbaar zijn wanneer een dienst bewust rechtstreeks openbaar wordt aangeboden en de firewall, de bescherming van de oorspronkelijke server en de authenticatie van de applicatie dienovereenkomstig worden beheerd. Een bastionhost bundelt SSH-toegangen, maar blijft zelf een toegangspunt dat bijzonder zorgvuldig moet worden beveiligd. Een reverse proxy is op zijn beurt een laag voor TLS-terminatie en applicatie-levering; deze beantwoordt niet alleen de vraag hoe de privé-origin bereikbaar is.

De minimale productienorm luidt: zo klein mogelijke doelomvang, op identiteit gebaseerde regels, MFA voor bevoorrechte rollen, geteste Ingress- en catch-all-configuratie, gepland updateproces en gedocumenteerd herstel. Herstelplan omvat ten minste verantwoordelijkheden, alternatieve routes en de controle of de doeldienst en de connector na onderhoud weer bereikbaar zijn. Tunnels verkleinen het blootgestelde netwerkoppervlak, maar vormen geen vervanging voor het beveiligen van applicaties, lokale machtigingen of voortdurende operationele monitoring.