Přesměrování portu versus přístup přes VPN: kam paket skutečně putuje

Přesměrování portu přepíše cíl a tím to končí; VPN paket nejprve zabalí. Podívejte se, kterou vrstvu mění každé z nich a co to znamená pro HTTPS.

Dva návrhy, jedna aplikace HTTPS a paket v každém z nich jde jinou cestou. Přesměrování portu mění, kam se paket doručí, a zbytek nechává být. VPN nejprve nese tento paket uvnitř jiného paketu, takže posluchač aplikace vidí jiný zdroj a menší maximální užitečné zatížení. Šifrování, o kterém se lidé přou, je přítomno v obou případech, protože aplikace je stále HTTPS; liší se to, kdo může otevřít spojení a co může sledovat síť mezi nimi. Tento rozdíl rozhoduje většinu praktických otázek.

Pravidlo DNAT přepíše cíl a tím to končí

Na Linuxové bráně znamená zveřejnění služby pravidlo v řetězci PREROUTING tabulky nat, nebo ekvivalent v nftables. Pravidlo odpovídá veřejné adrese a portu, poté přepíše cíl na privátní adresu aplikace. Zdrojová adresa, zdrojový port i užitečné zatížení zůstávají nedotčené a conntrack zaznamenává mapování, aby se odpovědi při odchodu přepsaly zpět. Chování je tradiční model překladu adres popsaný 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

Posluchač aplikace se nikdy nedozví, že spojení přišlo přes překlad. Vidí skutečnou zdrojovou adresu klienta, což je užitečné pro přístupové protokoly a omezení rychlosti, a odpovídá na privátní adresu, protože conntrack mapování obrací. Nic na této cestě nic nedešifruje ani znovu nešifruje: TLS stále běží mezi klientem a vlastním certifikátem aplikace.

Pravidlo také určuje režimy selhání, se kterými se později setkáte. Pokud brána předává, ale hostitel aplikace nemá cestu zpět ke klientovi, odpovědi odcházejí s nesprávným zdrojem a handshake se zasekne. Pokud se jako první trefí druhé pravidlo, rozhoduje pořadí, a iptables -t nat -L -n -v ukazuje čítače, které dokazují, které pravidlo paket zachytilo.

Tunel zabalí paket dřív, než ho posluchač uvidí

VPN aplikaci vůbec nezveřejňuje. Klient sestaví vnější paket adresovaný veřejné adrese brány, zašifruje v něm vnitřní paket a brána vnitřní paket dešifruje a směruje na privátní cíl. U WireGuardu je vnější přenos UDP, obvykle na vysokém portu; u OpenVPN přes TCP 443 vypadá vnější paket jako TLS pro cokoli, co cestu sleduje.

Uvnitř tunelu si vnitřní paket zachovává privátní adresy: adresu tunelu klienta, řekněme 10.8.0.6, a aplikaci na 10.20.30.40. Posluchač proto vidí zdroj z fondu tunelu a každý klient sdílí tuto bránu jako další skok. Přístupové protokoly za VPN často ukazují právě proto bránu místo uživatele, pokud brána nezachovává původní zdroj.

Zabalení stojí místo v hlavičce a to je jediný rozdíl na úrovni mechanismu s měřitelným důsledkem. Vnější IP hlavička plus UDP plus vlastní hlavička WireGuardu ukrajují z MTU cesty, takže velké pakety se musí fragmentovat nebo vnitřní TCP zásobník musí omezit své MSS. Přenos, který funguje po přesměrované cestě, se může na tunelu zaseknout, když mezilehlé zařízení zahodí ICMP, které by oznámilo menší 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

Expozice se rozhoduje u vstupu, ne šifrou

Oba návrhy končí na stejném TLS posluchači, takže oba dědí stejný certifikát, stejné verze protokolu a stejné přihlášení aplikace. Mění se to, kdo smí zahájit handshake. U veřejného přesměrování dostane každý hostitel, který dosáhne 203.0.113.10:443, TCP handshake a TLS ClientHello dřív, než se vůbec zkontroluje autorizace aplikace. U přístupu pouze tunelem je posluchač dostupný jen z adres, které brána směruje do tunelu, a SYN cizího hosta umírá na politice brány.

Tento rozdíl je o dosažitelnosti, ne o důvěrnosti. Přesměrovaná služba HTTPS není prostý text a VPN neodstraňuje potřebu autentizace aplikace: vpuštění do tunelu odpovídá na to, zda zařízení smí posílat pakety do této sítě, zatímco souborová aplikace odpovídá na to, zda uživatel smí číst dokument. Záměna těchto dvou věcí je způsob, jakým týmy skončí s VPN, která dává celou LAN, a aplikací s jedním sdíleným heslem.

Prohlédněte posluchač a politiku odděleně, protože kterékoli z nich může být širší, než předpokládá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

Pokud ss ukazuje, že posluchač je vázán na 0.0.0.0, je aplikace dostupná odkudkoli, kam směrování a politika firewallu dovolí, a přesměrování je jen jedním ze způsobů, jak dovnitř. Vázání na privátní adresu nebo omezení rozsahu zdrojů ve firewallu je samostatné rozhodnutí od volby VPN a právě to skutečně zužuje expozici.

Měřte cestu, ne označení

Když někdo tvrdí, že přesměrování je rychlejší, poctivé srovnání drží vše ostatní konstantní: stejný klient, stejná přístupová síť, stejný soubor, stejná konfigurace TLS, stejný hostitel aplikace. Spusťte přenos dvakrát pro každou cestu a zaznamenejte celkový čas, počet selhání a odezvu, ne výstup nesouvisejícího testu rychlosti.

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

Tato čísla oddělují navázání spojení od doby přenosu, což je důležité, protože obě cesty se obvykle liší v latenci zpáteční cesty a MTU, nikoli v ceně šifry. Práce TLS probíhá na koncových bodech v obou návrzích a tunel přidává zapouzdření, jinou trasu a možná zatíženější bránu. Pokud je cesta tunelem delší nebo je jeho brána zatížená, rozdíl patří cestě, ne slovu šifrování.

Zvolte vstupní politiku, kterou služba skutečně potřebuje, a pak rozhodněte, zda naměřený rozdíl ospravedlňuje její změnu. Veřejné přesměrování se hodí pro službu určenou otevřenému internetu, s omezeními zdrojů, aktualizovaným TLS a monitorováním před ní. Přístup pouze tunelem se hodí pro interní nástroj, jehož uživatelé jsou už zapsaní, pokud jsou směrování brány i oprávnění aplikace užší než celá LAN.

Než návrh prohlásíte za hotový, potvrďte čtyři věci: na kterou adresu je posluchač vázán, které pravidlo nebo trasa paket vpustí, zda funguje zpáteční cesta ze skutečné adresy klienta a zda velká užitečná zatížení přežijí MTU. Každé z toho má výše příkaz a na žádné neodpovídá slovo bezpečné ani graf šířky pásma.

Související články