Portaanstuur teenoor VPN-toegang: waar die pakkie werklik heen gaan

Twee ontwerpe, een HTTPS-toepassing, en die pakkie neem in elkeen ’n ander roete. ’n Portaanstuur verander waar die pakkie afgelewer word en laat die res daarvan ongemoeid. ’n VPN dra die pakkie eers binne ’n ander pakkie, sodat die toepassing se luisteraar ’n ander bron en ’n kleiner maksimum bruikbare vrag sien. Die enkripsie waaroor mense stry, is in albei gevalle teenwoordig, want die toepassing is steeds HTTPS; wat verskil, is wie ’n verbinding kan oopmaak en wat die netwerk tussenin kan waarneem. Daardie onderskeid besleg die meeste praktiese vrae.

Die DNAT-reël herskryf die bestemming en stop daar

Op ’n Linux-poort beteken die publikasie van ’n diens ’n reël in die nat-tabel se PREROUTING-ketting, of die ekwivalent in nftables. Die reël pas die openbare adres en poort, en herskryf dan die bestemming na die toepassing se private adres. Bronadres, bronpoort en vrag bly onaangeraak, en conntrack teken die kartering aan sodat antwoorde op die pad uit teruggeskryf word. Die gedrag is die tradisionele adresvertalingsmodel wat in RFC 3022 beskryf word.

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

Die toepassing se luisteraar leer nooit dat die verbinding deur ’n vertaling aangekom het nie. Dit sien die kliënt se werklike bronadres, wat nuttig is vir toegangslogboeke en tempobeperkings, en dit antwoord na die private adres omdat conntrack die kartering omkeer. Niks op daardie pad ontsyfer of hersyfer iets nie: TLS loop steeds tussen die kliënt en die toepassing se eie sertifikaat.

Die reël bepaal ook die foutmodusse wat jy later sal teëkom. As die poort aanstuur maar die toepassing se gasheer het geen roete terug na die kliënt nie, vertrek antwoorde met die verkeerde bron en die handdruk staan vas. As ’n tweede reël eerste pas, bepaal die orde die uitkoms, en iptables -t nat -L -n -v wys die tellers wat bewys watter reël die pakkie geneem het.

Die tonnel draai die pakkie in voordat die luisteraar dit sien

’n VPN publiseer die toepassing glad nie. Die kliënt bou ’n buitenste pakkie gerig aan die poort se openbare adres, enkripteer die binneste pakkie daarin, en die poort ontsyfer en stuur die binneste pakkie na die private bestemming. Met WireGuard is die buitenste vervoer UDP, gewoonlik op ’n hoë poort; met OpenVPN oor TCP 443 lyk die buitenste pakkie soos TLS vir enigiemand wat die pad dophou.

Binne die tonnel hou die binneste pakkie private adresse: die kliënt se tonneladres, sê 10.8.0.6, en die toepassing by 10.20.30.40. Die luisteraar sien dus ’n bron uit die tonnelpoel, en elke kliënt deel daardie poort as sy volgende sprong. Toegangslogboeke agter ’n VPN wys dikwels die poort eerder as die gebruiker juis om hierdie rede, tensy die poort die oorspronklike bron bewaar.

Die omhulsel kos kopruimte, en dit is die enigste verskil op meganismevlak met ’n gevolg wat jy kan meet. ’n Buitenste IP-kop plus UDP plus WireGuard se eie kop vreet aan die pad se MTU, so groot pakkies moet gefragmenteer word of die binneste TCP-stapel moet sy MSS beperk. ’n Oordrag wat oor die aangestuurde pad werk, kan oor die tonnel vasval wanneer ’n middelboks die ICMP laat val wat die kleiner MTU sou aangedui het.

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 word by die ingang bepaal, nie deur die syfer nie

Albei ontwerpe eindig by dieselfde TLS-luisteraar, so albei erf dieselfde sertifikaat, dieselfde protokolweergawes en dieselfde toepassing-aanmelding. Wat verander, is wie toegelaat word om ’n handdruk te begin. Met ’n openbare aanstuur kry enige gasheer wat 203.0.113.10:443 kan bereik ’n TCP-handdruk en ’n TLS ClientHello voordat jou toepassing-magtiging hoegenaamd geraadpleeg word. Met slegs-tonnel-toegang is die luisteraar net bereikbaar vanaf adresse wat die poort in die tonnel stuur, en ’n vreemdeling se SYN sterf by die poortbeleid.

Daardie verskil gaan oor bereikbaarheid, nie oor vertroulikheid nie. ’n Aangestuurde HTTPS-diens is nie gewone teks nie, en ’n VPN verwyder nie die behoefte aan toepassing-verifikasie nie: tonneltoelating antwoord of ’n toestel pakkies in hierdie netwerk mag stuur, terwyl die lêertoepassing antwoord of ’n gebruiker ’n dokument mag lees. Om die twee te verwar, is hoe spanne eindig met ’n VPN wat die hele LAN gee en ’n toepassing met een gedeelde wagwoord.

Ondersoek die luisteraar en die beleid afsonderlik, want enigeen kan wyer wees as wat jy aanneem:

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

As ss wys die luisteraar is aan 0.0.0.0 gebind, is die toepassing bereikbaar van waar roetering en firewallbeleid dit toelaat, en die aanstuur is net een van die maniere in. Om aan die private adres te bind, of om die bronreeks in die firewall te beperk, is ’n aparte besluit van die keuse van ’n VPN, en dit is die besluit wat blootstelling werklik vernou.

Meet die pad, nie die etiket nie

Wanneer iemand beweer die aanstuur is vinniger, hou die eerlike vergelyking alles anders konstant: dieselfde kliënt, dieselfde toegangsnetwerk, dieselfde lêer, dieselfde TLS-opstelling, dieselfde toepassing-gasheer. Hardloop die oordrag twee keer per pad en teken totale tyd, aantal mislukkings en reaksievermoë aan, nie die uitset van ’n onverwante spoedtoets nie.

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

Daardie syfers skei verbindingopstelling van oordragtyd, wat saak maak omdat die twee paaie gewoonlik verskil in rondrytyd en MTU eerder as in syferkoste. TLS-werk gebeur by die eindpunte in albei ontwerpe, en ’n tonnel voeg inkapseling, ’n ander roete en moontlik ’n besiger poort by. As die tonnelpad langer is of sy poort belaai is, hoort die verskil by die pad en nie by die woord enkripsie nie.

Kies die ingangsbeleid wat die diens werklik nodig het, en besluit dan of ’n gemete verskil regverdig om dit te verander. ’n Openbare aanstuur pas by ’n diens bedoel vir die oop internet, met bronbeperkings, opgedateerde TLS en monitering daar voor. Slegs-tonnel-toegang pas by ’n interne hulpmiddel wie se gebruikers al ingeskryf is, mits die poort se roetering en die toepassing se regte albei smaller as die hele LAN is.

Voordat jy die ontwerp as klaar beskou, bevestig vier dinge: watter adres die luisteraar aan gebind is, watter reël of roete die pakkie toelaat, of die terugpad vanaf die kliënt se werklike adres werk, en of groot vragte die MTU oorleef. Elkeen daarvan het ’n opdrag hierbo, en nie een word deur die woord veilig of deur ’n bandbreedtegrafiek beantwoord nie.