Portvideresending kontra VPN-tilgang: kvar pakken faktisk hamnar

Portvideresending skriv om destinasjonen og stoppar der; ein VPN pakkar pakken inn først. Sjå kva lag kvar av dei endrar, og kva det betyr for HTTPS.

To design, éin HTTPS-applikasjon, og pakken tek ei ulik rute i kvar. Portvideresending endrar kvar pakken vert levert, og lèt resten vere. Ein VPN ber pakken inne i ein annan pakke først, slik at lyttaren til applikasjonen ser ei anna kjelde og ei mindre maksimal nyttelast. Krypteringa folk diskuterer, er til stades i begge tilfelle, fordi applikasjonen framleis er HTTPS; det som skil, er kven som kan opne ei tilkopling, og kva nettet imellom kan observere. Den skilnaden avgjer dei fleste praktiske spørsmåla.

DNAT-regelen skriv om destinasjonen og stoppar der

På ein Linux-gateway tyder publisering av ei teneste ein regel i PREROUTING-kjeda til nat-tabellen, eller det tilsvarande i nftables. Regelen matchar den offentlege adressa og porten, og skriv deretter om destinasjonen til den private adressa til applikasjonen. Kjeldeadresse, kjeldeport og nyttelast er urørte, og conntrack registrerer mappinga slik at svar vert skrivne tilbake på veg ut. Åtferda er den tradisjonelle adresseomsetjingsmodellen som er skildra 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

Lyttaren til applikasjonen får aldri vite at tilkoplinga kom gjennom ei omsetjing. Han ser den verkelege kjeldeadressa til klienten, noko som er nyttig for tilgangsloggar og hastigheitsgrenser, og han svarar til den private adressa fordi conntrack snur mappinga. Ingenting på den vegen dekrypterer eller krypterer på nytt: TLS går framleis mellom klienten og det eigne sertifikatet til applikasjonen.

Regelen fastset òg feilmodusane du vil møte seinare. Viss gatewayen videresender, men verten til applikasjonen ikkje har noka rute tilbake til klienten, går svar ut med feil kjelde, og handtrykket stoppar. Viss ein annan regel matchar først, avgjer rekkjefølgja resultatet, og iptables -t nat -L -n -v viser teljarane som beviser kva regel som tok pakken.

Tunnelen pakkar inn pakken før lyttaren ser han

Ein VPN publiserer ikkje applikasjonen i det heile. Klienten byggjer ein ytre pakke adressert til den offentlege adressa til gatewayen, krypterer den indre pakken inni, og gatewayen dekrypterer og rutar den indre pakken til den private destinasjonen. Med WireGuard er den ytre transporten UDP, vanlegvis på ein høg port; med OpenVPN over TCP 443 ser den ytre pakken ut som TLS for alt som overvaker ruta.

Inne i tunnelen held den indre pakken på private adresser: tunneladressa til klienten, til dømes 10.8.0.6, og applikasjonen på 10.20.30.40. Lyttaren ser difor ei kjelde frå tunnelbassenget, og kvar klient deler den gatewayen som neste hopp. Tilgangsloggar bak ein VPN viser ofte gatewayen i staden for brukaren nettopp av denne grunnen, med mindre gatewayen tek vare på den opphavlege kjelda.

Innpakkinga kostar headerplass, og det er den einaste skilnaden på mekanismenivå med ei målbar følgje. Ein ytre IP-header pluss UDP pluss WireGuards eigen header et av MTU-en til ruta, så store pakkar må fragmenterast, eller den indre TCP-stakken må avgrense MSS-en sin. Ei overføring som fungerer over den videresende ruta, kan stoppe over tunnelen når ein mellomstasjon droppar 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 vert avgjord ved inngangen, ikkje av chiffret

Begge designa endar på same TLS-lyttar, så begge arvar same sertifikat, same protokollversjonar og same applikasjonsinnlogging. Det som endrar seg, er kven som får starte eit handtrykk. Med ei offentleg videresending får kvar vert som når 203.0.113.10:443, eit TCP-handtrykk og ein TLS ClientHello før applikasjonsautorisasjonen din i det heile vert vurdert. Med tilgang berre via tunnel kan lyttaren berre nåast frå adresser som gatewayen rutar inn i tunnelen, og SYN-en til ein framand døyr ved gatewaypolitikken.

Den skilnaden handlar om tilgjenge, ikkje om konfidensialitet. Ei videresend HTTPS-teneste er ikkje klartekst, og ein VPN fjernar ikkje behovet for applikasjonsautentisering: tunnelopptak svarar på om ei eining kan sende pakkar inn i dette nettet, medan filapplikasjonen svarar på om ein brukar kan lese eit dokument. Å blande dei to er korleis team endar med ein VPN som gir heile LAN-et, og ein applikasjon med eitt delt passord.

Undersøk lyttaren og politikken kvar for seg, fordi kvar av dei kan vere breiare enn du reknar med:

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

Viss ss viser at lyttaren er bunden til 0.0.0.0, er applikasjonen tilgjengeleg frå kvar som helst rutar og brannmurpolitikk tillèt det, og videresendinga er berre éin av vegane inn. Å binde til den private adressa, eller avgrense kjeldeområdet i brannmuren, er eit vedtak skilt frå valet av VPN, og det er vedtaket som faktisk avgrensar eksponeringa.

Mål ruta, ikkje etiketten

Når nokon hevdar at videresendinga er snøggare, held den ærlege samanlikninga alt anna konstant: same klient, same tilgangsnett, same fil, same TLS-konfigurasjon, same applikasjonsvert. Køyr overføringa to gonger per rute, og noter total tid, tal på feil og responsivitet, ikkje utdataa frå ein urelatert hastigheitstest.

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

Desse tala skil tilkoplingsopsett frå overføringstid, noko som betyr noko fordi dei to rutene vanlegvis skil seg i rundtur-forsinkelse og MTU snarare enn i chifferkostnad. TLS-arbeid skjer ved endepunkta i begge designa, og ein tunnel legg til innkapsling, ei anna rute og moglegvis ein travlare gateway. Viss tunnelruta er lengre eller gatewayen er lasta, høyrer skilnaden til ruta og ikkje til ordet kryptering.

Vel inngangspolitikken tenesta faktisk treng, og avgjer deretter om ein målt skilnad rettferdiggjer å endre han. Ei offentleg videresending passar for ei teneste meint for det opne internettet, med kjeldeavgrensingar, oppdatert TLS og overvaking framfor. Tilgang berre via tunnel passar for eit internt verktøy der brukarane alt er registrerte, føresett at rutinga til gatewayen og løyva til applikasjonen begge er smalare enn heile LAN-et.

Før du kallar designet ferdig, stadfest fire ting: kva adresse lyttaren er bunden til, kva regel eller rute som slepp pakken inn, om returvegen fungerer frå den verkelege adressa til klienten, og om store nyttelaster overlever MTU-en. Kvar av dei har ein kommando ovanfor, og ingen av dei vert svara med ordet trygg eller eit bandbreddediagram.

Relaterte artiklar