Dvojitý NAT a vaše VPN: klient funguje, server ne

Váš router stojí za dalším routerem, WAN adresa je privátní a VPN klient se přesto připojí. Tahle kombinace překvapuje lidi, kteří čekají, že dvojitý NAT tunely rozbije, ale právě odchozí spojení překlad zvládá nejlépe. Hostování VPN serveru za stejnými dvěma vrstvami je případ, který obvykle selhává. Než cokoli změníte, nakreslete si směr spojení.

Nejprve si nakreslete směr spojení

Otevřete stavovou stránku vnitřního routeru a zapište jeho WAN adresu, pak ji porovnejte s adresou, kterou vám hlásí nějaká veřejná služba. Pokud se obě liší, mezi vaším routerem a internetem stojí alespoň jeden překladač. Pokud WAN adresa spadá do 100.64.0.0/10, vnější překladač pravděpodobně patří vašemu poskytovateli a vy ho neovládáte. Tyto dva údaje rozhodují, který z dalších kroků vůbec může fungovat.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

Dvojitý NAT není dvojitá VPN. Překlad přepisuje adresy a porty; nepřidává druhý šifrovaný tunel a nic nešifruje. Držet obě představy oddělené je důležité, protože řešení jsou úplně jiná a jedno z nich znamená rozhovor s poskytovatelem, ne stránku nastavení.

Odchozí směr: klient se ptá, překladače mapují

Odchozí tunel začíná paketem z vašeho počítače, takže každý překladač může vytvořit mapování a pustit odpověď zpět. Protokol, port a časovače nečinnosti rozhodují, zda to mapování přežije dost dlouho, aby bylo užitečné. Většina spotřebitelských routerů to zvládá bez jakékoli konfigurace.

Poruchy, které se opravdu objevují, se obvykle týkají časových limitů a podpory protokolů, ne počtu routerů. Tunel, který po několika minutách ticha spadne, je mapování, které vyprší, a keepalive je standardní odpověď. IPsec má standardní rozšíření NAT-traversal, takže tvrzení, že přes překlad neprojde, je prostě chybné. Pokud se tunel vůbec neustaví, podívejte se na koncový bod a přihlašovací údaje, než obviníte topologii.

wg show
ping -c3 10.8.0.1

Přestaňte, pokud odchozí tunel funguje z jedné sítě a z jiné ne. To srovnání je o sítích, ne o počtu routerů.

Příchozí směr: přesměrování pokrývá jen zařízení, které vlastníte

Hostování serveru je opačný směr: nové spojení přichází z internetu a musí se dostat k vašemu počítači přes každou vrstvu. Pravidlo přesměrování portu na vnitřním routeru pomůže jen tehdy, když vnější překladač ten provoz doručí i vám. Opakování místního pravidla vám kontrolu nad zařízením poskytovatele nedá.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Porovnejte WAN adresu vnitřního routeru s veřejnou adresou, kterou jste pozorovali, a poznamenejte si, odkud každá hodnota pochází. Pokud je WAN adresa privátní nebo ve sdíleném rozsahu, vnější vrstva dělá překlad, který nemůžete nastavit. Než strávíte celý večer pravidly, která nemohou nabýt účinnosti, zeptejte se poskytovatele, jakou příchozí dostupnost podporuje. Odebrat router nebo plošně vypnout firewall není diagnóza a je to špatná výměna za jeden otevřený port.

Přestaňte, pokud vnější vrstva patří poskytovateli a nepřesměrovává. Pak jsou podporované odpovědi jiný způsob přístupu nebo relay, ne další pravidlo na vaší straně.

Testujte jednu proměnnou po druhé

Měňte při každém testu jednu věc a výsledek si zapisujte, protože cesta s dvojitým NAT má víc proměnných než cesta s jedním routerem. Držte profil a zařízení pevně a pak porovnejte jinou přístupovou síť. Zaznamenejte, zda selhává vyjednávání, zda relace po nečinnosti spadne nebo zda selhávají jen privátní cíle. Tato tři pozorování ukazují na tři různé vrstvy.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Překrývající se privátní podsítě jsou samostatná past, kterou žádné množství překladu nespraví. Pokud vaše domácí síť a vzdálená síť používají stejný rozsah, konflikt tras se objeví bez ohledu na to, kolik překladačů je mezi nimi. Přečíslování jedné strany je jediná trvalá odpověď.

Vzdálená brána si zaslouží stejnou pozornost, protože její pravidla přesměrování a zpětné trasy mohou být chybějícím dílkem. Tunel, který projde autentizací, stále může nemít použitelnou cestu pro aplikace a tato porucha vypadá z klientské strany stejně. Procházka končí, když dokážete říct, který směr selhává a která vrstva za něj odpovídá.