Portvideresending kontra VPN-tilgang: hvor pakken faktisk havner

Portvideresending skriver om destinasjonen og stopper der; en VPN pakker pakken inn først. Se hvilket lag hver av dem endrer, og hva det betyr for HTTPS.

To design, én HTTPS-applikasjon, og pakken tar en forskjellig rute i hver. Portvideresending endrer hvor pakken leveres, og lar resten være. En VPN bærer pakken inne i en annen pakke først, slik at applikasjonens lytter ser en annen kilde og en mindre maksimal nyttelast. Krypteringen folk diskuterer, er til stede i begge tilfeller, fordi applikasjonen fortsatt er HTTPS; det som er forskjellig, er hvem som kan åpne en forbindelse, og hva nettet imellom kan observere. Den forskjellen avgjør de fleste praktiske spørsmålene.

DNAT-regelen skriver om destinasjonen og stopper der

På en Linux-gateway betyr publisering av en tjeneste en regel i nat-tabellens PREROUTING-kjede, eller det tilsvarende i nftables. Regelen matcher den offentlige adressen og porten, og skriver deretter om destinasjonen til applikasjonens private adresse. Kildeadresse, kildeport og nyttelast er urørt, og conntrack registrerer mappingen slik at svar skrives tilbake på vei ut. Oppførselen er den tradisjonelle adresseoversettelsesmodellen som 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

Applikasjonens lytter får aldri vite at forbindelsen kom gjennom en oversettelse. Den ser klientens virkelige kildeadresse, noe som er nyttig for tilgangslogger og hastighetsgrenser, og den svarer til den private adressen fordi conntrack snur mappingen. Ingenting på den veien dekrypterer eller krypterer på nytt: TLS går fortsatt mellom klienten og applikasjonens eget sertifikat.

Regelen fastsetter også feilmodiene du vil møte senere. Hvis gatewayen videresender, men applikasjonens vert ikke har noen rute tilbake til klienten, går svar ut med feil kilde, og håndtrykket stopper. Hvis en annen regel matcher først, avgjør rekkefølgen resultatet, og iptables -t nat -L -n -v viser tellerne som beviser hvilken regel som tok pakken.

Tunnelen pakker inn pakken før lytteren ser den

En VPN publiserer ikke applikasjonen i det hele tatt. Klienten bygger en ytre pakke adressert til gatewayens offentlige adresse, krypterer den indre pakken inni, og gatewayen dekrypterer og ruter den indre pakken til den private destinasjonen. Med WireGuard er den ytre transporten UDP, vanligvis på en høy port; med OpenVPN over TCP 443 ser den ytre pakken ut som TLS for alt som overvåker ruten.

Inne i tunnelen beholder den indre pakken private adresser: klientens tunneladresse, for eksempel 10.8.0.6, og applikasjonen på 10.20.30.40. Lytteren ser derfor en kilde fra tunnelpoolen, og hver klient deler den gatewayen som neste hopp. Tilgangslogger bak en VPN viser ofte gatewayen i stedet for brukeren nettopp av denne grunnen, med mindre gatewayen bevarer den opprinnelige kilden.

Innpakningen koster headerplass, og det er den eneste forskjellen på mekanismenivå med en målbar konsekvens. En ytre IP-header pluss UDP pluss WireGuards egen header spiser av rutenes MTU, så store pakker må fragmenteres, eller den indre TCP-stakken må begrense MSS-en sin. En overføring som fungerer over den videresendte ruten, kan stoppe over tunnelen når en mellomstasjon dropper den ICMP-en som ville ha signalisert den mindre MTU-en.

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 avgjøres ved inngangen, ikke av chifferen

Begge designene ender på samme TLS-lytter, så begge arver samme sertifikat, samme protokollversjoner og samme applikasjonsinnlogging. Det som endres, er hvem som får starte et håndtrykk. Med en offentlig videresending får enhver vert som når 203.0.113.10:443, et TCP-håndtrykk og en TLS ClientHello før applikasjonsautorisasjonen din i det hele tatt vurderes. Med tilgang bare via tunnel kan lytteren bare nås fra adresser som gatewayen ruter inn i tunnelen, og en fremmeds SYN dør ved gatewaypolitikken.

Den forskjellen handler om tilgjengelighet, ikke om konfidensialitet. En videresendt HTTPS-tjeneste er ikke klartekst, og en VPN fjerner ikke behovet for applikasjonsautentisering: tunnelopptak svarer på om en enhet kan sende pakker inn i dette nettet, mens filapplikasjonen svarer på om en bruker kan lese et dokument. Å blande de to er hvordan team ender med en VPN som gir hele LAN-et, og en applikasjon med ett delt passord.

Undersøk lytteren og politikken hver for seg, fordi hver av dem kan være bredere enn du antar:

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 applikasjonen tilgjengelig fra hvor som helst ruting og brannmurpolitikk tillater det, og videresendingen er bare én av veiene inn. Å binde til den private adressen, eller begrense kildeområdet i brannmuren, er en beslutning adskilt fra valget av VPN, og det er beslutningen som faktisk begrenser eksponeringen.

Mål ruten, ikke etiketten

Når noen hevder at videresendingen er raskere, holder den ærlige sammenligningen alt annet konstant: samme klient, samme tilgangsnett, samme fil, samme TLS-konfigurasjon, samme applikasjonsvert. Kjør overføringen to ganger per rute, og noter total tid, antall feil og responsivitet, ikke utdataene fra en urelatert hastighetstest.

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

Disse tallene skiller forbindelsesoppsett fra overføringstid, noe som betyr noe fordi de to rutene vanligvis skiller seg i rundtur-forsinkelse og MTU snarere enn i chifferkostnad. TLS-arbeid skjer ved endepunktene i begge designene, og en tunnel legger til innkapsling, en annen rute og muligens en travlere gateway. Hvis tunnelruten er lengre eller gatewayen er belastet, hører forskjellen til ruten og ikke til ordet kryptering.

Velg inngangspolitikken tjenesten faktisk trenger, og avgjør deretter om en målt forskjell rettferdiggjør å endre den. En offentlig videresending passer for en tjeneste ment for det åpne internettet, med kildebegrensninger, oppdatert TLS og overvåking foran. Tilgang bare via tunnel passer for et internt verktøy der brukerne allerede er registrert, forutsatt at gatewayens ruting og applikasjonens tillatelser begge er smalere enn hele LAN-et.

Før du kaller designet ferdig, bekreft fire ting: hvilken adresse lytteren er bundet til, hvilken regel eller rute som slipper pakken inn, om returveien fungerer fra klientens virkelige adresse, og om store nyttelaster overlever MTU-en. Hver av dem har en kommando ovenfor, og ingen av dem besvares med ordet sikker eller et båndbreddediagram.

Relaterte artikler