Portforwarding kontra VPN-adgang: hvor pakken egentlig havner

Portforwarding omskriver destinationen og stopper der; en VPN pakker pakken ind først. Se hvilket lag hver især ændrer, og hvad det betyder for HTTPS.

To designs, én HTTPS-applikation, og pakken tager en forskellig rute i hver. Portforwarding ændrer, hvor pakken leveres, og lader resten være. En VPN bærer pakken inde i en anden pakke først, så applikationens lytter ser en anden kilde og en mindre maksimal nyttelast. Krypteringen, som folk diskuterer, er til stede i begge tilfælde, fordi applikationen stadig er HTTPS; det, der er forskelligt, er hvem der kan åbne en forbindelse, og hvad netværket imellem kan observere. Den forskel afgør de fleste praktiske spørgsmål.

DNAT-reglen omskriver destinationen og stopper der

På en Linux-gateway betyder offentliggørelse af en tjeneste en regel i nat-tabellens PREROUTING-kæde eller det tilsvarende i nftables. Reglen matcher den offentlige adresse og port og omskriver derefter destinationen til applikationens private adresse. Kildeadresse, kildeport og nyttelast er urørte, og conntrack registrerer mappingen, så svar omskrives tilbage på vej ud. Adfærden er den traditionelle adresseoversættelsesmodel, der er beskrevet i RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Applikationens lytter opdager aldrig, at forbindelsen ankom gennem en oversættelse. Den ser klientens rigtige kildeadresse, hvilket er nyttigt til adgangslogfiler og hastighedsgrænser, og den svarer til den private adresse, fordi conntrack vender mappingen om. Intet på den vej dekrypterer eller genkrypterer noget: TLS kører stadig mellem klienten og applikationens eget certifikat.

Reglen fastlægger også de fejltilstande, du senere vil møde. Hvis gatewayen videresender, men applikationens vært ikke har nogen rute tilbage til klienten, forlader svar med den forkerte kilde, og håndtrykket går i stå. Hvis en anden regel matcher først, afgør rækkefølgen resultatet, og iptables -t nat -L -n -v viser de tællere, der beviser, hvilken regel der tog pakken.

Tunnelen pakker pakken ind, før lytteren ser den

En VPN offentliggør slet ikke applikationen. Klienten bygger en ydre pakke adresseret til gatewayens offentlige adresse, krypterer den indre pakke indeni, og gatewayen dekrypterer og ruter den indre pakke til den private destination. Med WireGuard er den ydre transport UDP, normalt på en høj port; med OpenVPN over TCP 443 ligner den ydre pakke TLS for alt, der overvåger ruten.

Inde i tunnelen beholder den indre pakke private adresser: klientens tunneladresse, for eksempel 10.8.0.6, og applikationen på 10.20.30.40. Lytteren ser derfor en kilde fra tunnelpuljen, og hver klient deler den gateway som sit næste hop. Adgangslogfiler bag en VPN viser ofte gatewayen i stedet for brugeren netop af denne grund, medmindre gatewayen bevarer den oprindelige kilde.

Indpakningen koster headerplads, og det er den eneste forskel på mekanismeniveau med en målbar konsekvens. En ydre IP-header plus UDP plus WireGuards egen header spiser af rutenes MTU, så store pakker skal fragmenteres, eller den indre TCP-stak skal begrænse sin MSS. En overførsel, der virker over den videresendte rute, kan gå i stå over tunnelen, når en mellemstation dropper den ICMP, der ville have signaleret den mindre MTU.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Eksponering afgøres ved indgangen, ikke af chifferen

Begge designs ender ved den samme TLS-lytter, så begge arver det samme certifikat, de samme protokolversioner og det samme applikationslogin. Det, der ændres, er, hvem der må starte et håndtryk. Med en offentlig forwarding får enhver vært, der kan nå 203.0.113.10:443, et TCP-håndtryk og en TLS ClientHello, før din applikationsautorisation overhovedet konsulteres. Med adgang kun via tunnel kan lytteren kun nås fra adresser, som gatewayen ruter ind i tunnelen, og en fremmeds SYN dør ved gatewaypolitikken.

Den forskel handler om tilgængelighed, ikke om fortrolighed. En videresendt HTTPS-tjeneste er ikke klartekst, og en VPN fjerner ikke behovet for applikationsgodkendelse: tunneloptagelse svarer på, om en enhed må sende pakker ind i dette netværk, mens filapplikationen svarer på, om en bruger må læse et dokument. At blande de to er, hvordan teams ender med en VPN, der giver hele LAN'et, og en applikation med én delt adgangskode.

Undersøg lytteren og politikken hver for sig, fordi hver af dem kan være bredere, end du antager:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Hvis ss viser, at lytteren er bundet til 0.0.0.0, er applikationen tilgængelig fra hvor som helst, routing og firewallpolitik tillader det, og forwardingen er kun én af vejene ind. At binde til den private adresse eller begrænse kildeområdet i firewallen er en beslutning adskilt fra valget af VPN, og det er den beslutning, der faktisk indsnævrer eksponeringen.

Mål ruten, ikke etiketten

Når nogen påstår, at forwardingen er hurtigere, holder den ærlige sammenligning alt andet konstant: samme klient, samme adgangsnetværk, samme fil, samme TLS-konfiguration, samme applikationsvært. Kør overførslen to gange for hver rute, og noter samlet tid, antal fejl og responsivitet, ikke outputtet af en urelateret hastighedstest.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

De tal adskiller forbindelsesopsætning fra overførselstid, hvilket betyder noget, fordi de to ruter normalt adskiller sig i rundtur-latens og MTU snarere end i chifferomkostninger. TLS-arbejdet sker ved endepunkterne i begge designs, og en tunnel tilføjer indkapsling, en anden rute og muligvis en travlere gateway. Hvis tunnelruten er længere, eller dens gateway er belastet, hører forskellen til ruten og ikke til ordet kryptering.

Vælg den indgangspolitik, tjenesten faktisk har brug for, og afgør derefter, om en målt forskel retfærdiggør at ændre den. En offentlig forwarding passer til en tjeneste tiltænkt det åbne internet, med kildebegrænsninger, opdateret TLS og overvågning foran. Adgang kun via tunnel passer til et internt værktøj, hvis brugere allerede er tilmeldt, forudsat at gatewayens routing og applikationens tilladelser begge er snævrere end hele LAN'et.

Før du kalder designet færdigt, bekræft fire ting: hvilken adresse lytteren er bundet til, hvilken regel eller rute der lukker pakken ind, om returvejen virker fra klientens rigtige adresse, og om store nyttelaster overlever MTU'en. Hver af dem har en kommando ovenfor, og ingen af dem besvares med ordet sikker eller et båndbreddediagram.

Relaterede artikler