Presmerovanie portu verzus prístup cez VPN: kam paket naozaj putuje

Presmerovanie portu prepíše cieľ a tým sa skončí; VPN najprv paket zabalí. Pozrite sa, ktorú vrstvu mení každé z nich a čo to znamená pre HTTPS.

Dva návrhy, jedna aplikácia HTTPS a paket v každom z nich ide inou cestou. Presmerovanie portu mení, kam sa paket doručí, a zvyšok necháva tak. VPN najprv nesie tento paket v inom pakete, takže poslucháč aplikácie vidí iný zdroj a menšiu maximálnu užitočnú záťaž. Šifrovanie, o ktorom sa ľudia hádajú, je prítomné v oboch prípadoch, pretože aplikácia je stále HTTPS; líši sa to, kto môže otvoriť spojenie a čo môže sledovať sieť medzi nimi. Tento rozdiel rozhoduje väčšinu praktických otázok.

Pravidlo DNAT prepíše cieľ a tým sa skončí

Na Linuxovej bráne znamená zverejnenie služby pravidlo v reťazci PREROUTING tabuľky nat, alebo ekvivalent v nftables. Pravidlo zodpovedá verejnej adrese a portu, potom prepíše cieľ na privátnu adresu aplikácie. Zdrojová adresa, zdrojový port aj užitočná záťaž zostávajú nedotknuté a conntrack zaznamenáva mapovanie, aby sa odpovede pri odchode prepísali späť. Správanie je tradičný model prekladu adries opísaný v 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

Poslucháč aplikácie sa nikdy nedozvie, že spojenie prišlo cez preklad. Vidí skutočnú zdrojovú adresu klienta, čo je užitočné pre prístupové záznamy a limity rýchlosti, a odpovedá na privátnu adresu, pretože conntrack mapovanie obracia. Nič na tejto ceste nič nešifruje ani neodšifruje znova: TLS stále beží medzi klientom a vlastným certifikátom aplikácie.

Pravidlo určuje aj režimy zlyhania, s ktorými sa neskôr stretnete. Ak brána preposiela, ale hostiteľ aplikácie nemá žiadnu cestu späť ku klientovi, odpovede odchádzajú s nesprávnym zdrojom a podanie ruky sa zasekne. Ak sa ako prvé zhoduje druhé pravidlo, rozhoduje poradie, a iptables -t nat -L -n -v ukazuje počítadlá, ktoré dokazujú, ktoré pravidlo paket zachytilo.

Tunel zabalí paket skôr, než ho poslucháč uvidí

VPN aplikáciu vôbec nezverejňuje. Klient zostaví vonkajší paket adresovaný verejnej adrese brány, zašifruje v ňom vnútorný paket a brána vnútorný paket dešifruje a smeruje na privátny cieľ. Pri WireGuarde je vonkajšia doprava UDP, zvyčajne na vysokom porte; pri OpenVPN cez TCP 443 vyzerá vonkajší paket ako TLS pre všetko, čo cestu sleduje.

Vo vnútri tunela si vnútorný paket zachováva privátne adresy: adresu tunela klienta, povedzme 10.8.0.6, a aplikáciu na 10.20.30.40. Poslucháč preto vidí zdroj z fondu tunela a každý klient zdieľa túto bránu ako ďalší skok. Prístupové záznamy za VPN často ukazujú práve preto bránu namiesto používateľa, ak brána nezachováva pôvodný zdroj.

Zabalenie stojí miesto v hlavičke a to je jediný rozdiel na úrovni mechanizmu s merateľným dôsledkom. Vonkajšia IP hlavička plus UDP plus vlastná hlavička WireGuardu ukrajujú z MTU cesty, takže veľké pakety sa musia fragmentovať alebo vnútorný TCP zásobník musí obmedziť svoje MSS. Prenos, ktorý funguje na presmerovanej ceste, sa môže na tuneli zaseknúť, keď medziľahlé zariadenie zahodí ICMP, ktoré by oznámilo menšie 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

Expozícia sa rozhoduje na vstupe, nie šifrou

Oba návrhy končia na rovnakom TLS poslucháčovi, takže oba dedia rovnaký certifikát, rovnaké verzie protokolu a rovnaké prihlásenie aplikácie. Mení sa to, kto smie začať podanie ruky. Pri verejnom presmerovaní dostane každý hostiteľ, ktorý dosiahne 203.0.113.10:443, TCP podanie ruky a TLS ClientHello skôr, než sa vôbec skontroluje autorizácia vašej aplikácie. Pri prístupe len cez tunel je poslucháč dostupný iba z adries, ktoré brána smeruje do tunela, a SYN cudzinca zomiera na politike brány.

Tento rozdiel je o dostupnosti, nie o dôvernosti. Presmerovaná služba HTTPS nie je otvorený text a VPN neodstraňuje potrebu autentifikácie aplikácie: prijatie do tunela odpovedá, či zariadenie smie posielať pakety do tejto siete, kým súborová aplikácia odpovedá, či používateľ smie čítať dokument. Miešanie týchto dvoch vecí vedie k tomu, že tímy skončia s VPN, ktorá dáva celú LAN, a s aplikáciou s jedným spoločným heslom.

Prezrite poslucháča a politiku oddelene, pretože ktorékoľvek z nich môže byť širšie, než predpokladáte:

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

Ak ss ukazuje, že poslucháč je naviazaný na 0.0.0.0, aplikácia je dostupná odvadiaľ, kde to dovoľuje smerovanie a politika firewallu, a presmerovanie je len jedna z ciest dnu. Naviazanie na privátnu adresu alebo obmedzenie rozsahu zdrojov vo firewalle je samostatné rozhodnutie od voľby VPN a práve ono skutočne zužuje expozíciu.

Merajte cestu, nie označenie

Keď niekto tvrdí, že presmerovanie je rýchlejšie, čestné porovnanie drží všetko ostatné konštantné: rovnaký klient, rovnaká prístupová sieť, rovnaký súbor, rovnaká konfigurácia TLS, rovnaký hostiteľ aplikácie. Spustite prenos dvakrát pre každú cestu a zaznamenajte celkový čas, počet zlyhaní a odozvu, nie výstup nesúvisiaceho testu rýchlosti.

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

Tieto čísla oddeľujú nadviazanie spojenia od času prenosu, čo je dôležité, pretože obe cesty sa zvyčajne líšia latenciou spiatočnej cesty a MTU, nie cenou šifry. Práca TLS prebieha na koncoch v oboch návrhoch a tunel pridáva zapuzdrenie, inú trasu a možno vyťaženejšiu bránu. Ak je trasa tunela dlhšia alebo je jeho brána zaťažená, rozdiel patrí trase a nie slovu šifrovanie.

Vyberte vstupnú politiku, ktorú služba skutočne potrebuje, a potom rozhodnite, či nameraný rozdiel ospravedlňuje jej zmenu. Verejné presmerovanie sa hodí pre službu určenú otvorenému internetu, s obmedzeniami zdrojov, aktualizovaným TLS a monitorovaním pred ňou. Prístup len cez tunel sa hodí pre interný nástroj, ktorého používatelia sú už zapísaní, ak sú smerovanie brány aj oprávnenia aplikácie užšie než celá LAN.

Skôr než návrh vyhlásite za hotový, potvrďte štyri veci: na ktorú adresu je poslucháč naviazaný, ktoré pravidlo alebo trasa paket vpustí, či funguje spiatočná cesta zo skutočnej adresy klienta a či veľké užitočné záťaže prežijú MTU. Každá z nich má vyššie príkaz a na žiadnu neodpovedá slovo bezpečné ani graf šírky pásma.

Súvisiace články