Port forwarding versus VPN-toegang: waar het pakket echt heen gaat

Twee ontwerpen, één HTTPS-applicatie, en het pakket neemt in elk een andere route. Een port forward verandert waar het pakket wordt afgeleverd en laat de rest met rust. Een VPN draagt dat pakket eerst in een ander pakket, zodat de listener van de applicatie een andere bron en een kleinere maximale payload ziet. De encryptie waar mensen over discussiëren is in beide gevallen aanwezig, omdat de applicatie nog steeds HTTPS is; wat verschilt, is wie een verbinding mag openen en wat het netwerk ertussen kan observeren. Dat onderscheid beslecht de meeste praktische vragen.

De DNAT-regel herschrijft de bestemming en stopt daar

Op een Linux-gateway betekent het publiceren van een dienst een regel in de PREROUTING-keten van de nat-tabel, of het equivalent in nftables. De regel matcht het openbare adres en de poort en herschrijft daarna de bestemming naar het privéadres van de applicatie. Bronadres, bronpoort en payload blijven onaangetast, en conntrack legt de mapping vast zodat antwoorden bij het uitgaan terug worden geschreven. Het gedrag is het traditionele adresvertaalmodel dat in RFC 3022 wordt beschreven.

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

De listener van de applicatie leert nooit dat de verbinding via een vertaling binnenkwam. Hij ziet het echte bronadres van de client, wat nuttig is voor toegangslogboeken en snelheidslimieten, en hij antwoordt op het privéadres omdat conntrack de mapping omkeert. Niets op dat pad ontsleutelt of herversleutelt: TLS loopt nog steeds tussen de client en het eigen certificaat van de applicatie.

De regel legt ook de faalmodi vast die je later tegenkomt. Als de gateway doorstuurt maar de host van de applicatie heeft geen route terug naar de client, verlaten antwoorden met de verkeerde bron en de handshake blijft hangen. Als een tweede regel eerst matcht, beslist de volgorde het resultaat, en iptables -t nat -L -n -v toont de tellers die bewijzen welke regel het pakket nam.

De tunnel verpakt het pakket voordat de listener het ziet

Een VPN publiceert de applicatie helemaal niet. De client bouwt een buitenste pakket gericht aan het openbare adres van de gateway, versleutelt het binnenste pakket erin, en de gateway ontsleutelt en routeert het binnenste pakket naar de privébestemming. Bij WireGuard is het buitenste transport UDP, meestal op een hoge poort; bij OpenVPN over TCP 443 lijkt het buitenste pakket op TLS voor alles wat het pad in de gaten houdt.

Binnen de tunnel behoudt het binnenste pakket privéadressen: het tunneladres van de client, zeg 10.8.0.6, en de applicatie op 10.20.30.40. De listener ziet dus een bron uit de tunnelpool, en elke client deelt die gateway als volgende hop. Toegangslogboeken achter een VPN tonen vaak de gateway in plaats van de gebruiker precies om deze reden, tenzij de gateway de oorspronkelijke bron bewaart.

Het inpakken kost kopruimte, en dat is het enige verschil op mechanismeniveau met een meetbaar gevolg. Een buitenste IP-kop plus UDP plus de eigen kop van WireGuard vreten aan de MTU van het pad, dus grote pakketten moeten worden gefragmenteerd of de binnenste TCP-stack moet zijn MSS beperken. Een overdracht die op het doorgestuurde pad werkt, kan op de tunnel vastlopen wanneer een tussenliggend apparaat de ICMP laat vallen die de kleinere MTU zou hebben gemeld.

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

Blootstelling wordt bij de ingang bepaald, niet door het cijfer

Beide ontwerpen eindigen bij dezelfde TLS-listener, dus beide erven hetzelfde certificaat, dezelfde protocolversies en dezelfde applicatie-login. Wat verandert, is wie een handshake mag beginnen. Met een openbare forward krijgt elke host die 203.0.113.10:443 bereikt een TCP-handshake en een TLS ClientHello voordat je applicatieautorisatie überhaupt wordt bekeken. Met toegang alleen via de tunnel is de listener alleen bereikbaar vanaf adressen die de gateway de tunnel in routeert, en de SYN van een vreemde sterft op het gatewaybeleid.

Dat verschil gaat over bereikbaarheid, niet over vertrouwelijkheid. Een doorgestuurde HTTPS-dienst is geen platte tekst, en een VPN haalt de noodzaak van applicatieauthenticatie niet weg: toelating tot de tunnel beantwoordt of een apparaat pakketten in dit netwerk mag sturen, terwijl de bestandstoepassing beantwoordt of een gebruiker een document mag lezen. De twee verwarren is hoe teams eindigen met een VPN die het hele LAN geeft en een applicatie met één gedeeld wachtwoord.

Onderzoek de listener en het beleid apart, want elk van beide kan breder zijn dan je denkt:

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

Als ss toont dat de listener aan 0.0.0.0 is gebonden, is de applicatie bereikbaar vanwaar routing en firewallbeleid het toestaan, en de forward is maar één van de ingangen. Binden aan het privéadres, of het bronbereik in de firewall beperken, is een aparte beslissing van het kiezen van een VPN, en het is de beslissing die de blootstelling echt verkleint.

Meet het pad, niet het label

Wanneer iemand beweert dat de forward sneller is, houdt de eerlijke vergelijking al het andere constant: dezelfde client, hetzelfde toegangsnetwerk, hetzelfde bestand, dezelfde TLS-configuratie, dezelfde applicatiehost. Draai de overdracht twee keer per pad en noteer totale tijd, aantal fouten en responsiviteit, niet de uitvoer van een ongerelateerde snelheidstest.

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

Die getallen scheiden verbindingsopbouw van overdrachtstijd, wat ertoe doet omdat de twee paden meestal verschillen in round-trip-latentie en MTU, niet in cijferkosten. TLS-werk gebeurt aan de uiteinden in beide ontwerpen, en een tunnel voegt inkapseling, een andere route en mogelijk een drukkere gateway toe. Als het tunnelpad langer is of zijn gateway belast, hoort het verschil bij het pad en niet bij het woord encryptie.

Kies het ingangsbeleid dat de dienst echt nodig heeft, en beslis dan of een gemeten verschil rechtvaardigt om het te veranderen. Een openbare forward past bij een dienst voor het open internet, met bronbeperkingen, bijgewerkte TLS en monitoring ervoor. Toegang alleen via de tunnel past bij een intern hulpmiddel waarvan de gebruikers al zijn ingeschreven, mits de routing van de gateway en de rechten van de applicatie beide smaller zijn dan het hele LAN.

Voordat je het ontwerp klaar noemt, bevestig vier dingen: aan welk adres de listener is gebonden, welke regel of route het pakket binnenlaat, of het terugpad vanaf het echte adres van de client werkt, en of grote payloads de MTU overleven. Elk daarvan heeft hierboven een commando, en geen ervan wordt beantwoord door het woord veilig of door een bandbreedtediagram.