Eksponer en intern tjeneste trygt med Cloudflare Tunnel

Du har en tjeneste kjørende hjemme, kanskje i et LXC, og du vil nå den utenfra. Den klassiske oppskriften er portforwarding pluss dynamisk DNS. Prisen er en åpen port mot internett og en hjemme-IP som ligger synlig for alle. Åpne porter skannes døgnet rundt, mer eller mindre automatisk. Det er ikke et spørsmål om du blir funnet, bare når.

Snu retningen

Cloudflare Tunnel snur hele problemet på hodet: i stedet for at internett kobler inn til deg, kobler du ut til Cloudflare. En liten agent som heter cloudflared kjører på innsiden og holder en utgående forbindelse åpen. All trafikk til tjenesten kommer inn samme vei. Sluttresultatet er greit å oppsummere: ingen innkommende porter, ingen synlig IP, ingenting å skanne.

Cloudflare terminerer HTTPS for deg på kjøpet. Du slipper å styre egne sertifikater eller mase med Let’s Encrypt-fornying på innsiden. Tjenesten din snakker helt vanlig HTTP lokalt, og Cloudflare tar seg av TLS ut mot verden.

Oppsett

Start med å installere cloudflared på serveren som faktisk når den interne tjenesten. Deretter autentiserer du mot kontoen din og oppretter en tunnel.

cloudflared tunnel login
cloudflared tunnel create min-tjeneste

Så ruter du et vertsnavn videre til den interne HTTP-tjenesten. Her lar vi et subdomene peke mot noe som kjører lokalt.

# config.yml
tunnel: min-tjeneste
credentials-file: /etc/cloudflared/<tunnel-id>.json

ingress:
  - hostname: tjeneste.eksempel.no
    service: http://192.168.x.x:8080
  - service: http_status:404

Deretter oppretter du DNS-oppføringen. Det blir en CNAME som peker mot selve tunnelen, ikke mot IP-en din.

cloudflared tunnel route dns min-tjeneste tjeneste.eksempel.no

Til slutt kjører du tunnelen som en tjeneste, så den kommer opp igjen av seg selv etter en omstart.

cloudflared service install
systemctl enable --now cloudflared

En tunnel er ikke sikkerhet

Her kommer det viktigste poenget, og det er verdt å dvele ved. En tunnel gjør tjenesten tilgjengelig. Den beskytter den ikke. Uten noe foran ligger tjenesten nå åpen for hele internett, bare bak et pent domenenavn i stedet for en rå IP. Har den en svak pålogging, eller et kjent hull i en gammel versjon, er du akkurat like eksponert som du var med portforwarding.

Løsningen er en Access-policy foran tunnelen. Cloudflare Access sjekker hver eneste forespørsel før den i det hele tatt når tjenesten din. Du kan kreve innlogging, et bestemt e-postdomene, eller et service-token for maskiner som skal snakke sammen uten et menneske i loopen.

# Access-policy (eksempel)
Application: tjeneste.eksempel.no
Policy: Allow
  Include: emails ending in @dittfirma.no

Nå må en bruker godkjennes av Cloudflare før forespørselen slipper videre. De som ikke er autorisert, ser aldri så mye som forsiden av applikasjonen din.

Oppsummert

Portforwarding gir deg en åpen angrepsflate som skannes kontinuerlig, enten du følger med eller ikke. En tunnel fjerner hele den flaten: ingen porter, ingen IP, ingen sertifikathåndtering å holde liv i. Legg en Access-policy foran, så sitter du igjen med en intern tjeneste som er nåbar utenfra og likevel lukket for alle andre enn dem du selv slipper inn.