VPN za NAT, který nemůžete nastavit: co přesto funguje

Každý koncový bod tunelu potřebuje adresu a port, na které se druhá strana dostane, a router, který nespravujete, je obvyklým důvodem, proč tento požadavek selže. Zajímavé není to, že triky existují, ale že každý závisí na vlastnosti mapovací tabulky, kterou z klienta nevidíte. Dvě z těchto vlastností rozhodují téměř o všem: jak mapování vzniká a zda přijímá pakety z adresy, se kterou vnitřek nikdy nekomunikoval. Setřiďte prostředí podle těchto vlastností a obejití přestanou být folklórem.

Mapovací tabulka rozhoduje o všem

Překlad síťových adres vede tabulku, ve které je vnitřní adresa a port zapsána proti veřejné adrese a portu. Odpovědi odpovídající záznamu se překládají zpět a paket, který přichází zvenčí bez odpovídajícího záznamu, nemá vůbec žádné cílové místo. To jediné chování vysvětluje, proč je naslouchač za routerem z internetu nedosažitelný. Vysvětluje také, proč první paket v každém směru musí vzniknout uvnitř.

Podívejte se na tabulku ze strany routeru a obejití jsou zřejmá: buď něco vytvoří trvalý záznam, nebo vytvoří dočasný a udržuje ho čerstvý, nebo provoz touto cestou vůbec nejde. Zbytek článku jsou tyto tři případy v pořadí. Nic zde nezávisí na funkci výrobce nad rámec toho, co tabulka zaznamenává.

Co rendezvous služba umí a co ne

Probušení děr UDP používá odchozí záznam jako dočasné otevření, místo aby porazilo filtr. Oba partneři kontaktují rendezvous službu, která zjistí každý veřejný koncový bod a druhé straně vrátí její bod. Pak oba posílají proti sobě a každý odchozí paket vytváří nebo obnovuje záznam, který pustí odpověď dovnitř. Pořadí je to, co to dělá funkčním, a pořadí je také to, co to dělá křehkým: partner, který odešle dřív, než druhá strana vytvořila svůj záznam, se prostě zahodí, zatímco opakování o chvíli později uspěje. Služba sama nenese žádný provoz VPN, takže jejím jediným vlivem je časování, které koordinuje.

Chování mapování rozhoduje o zbytku a RFC 4787 pojmenovává tři tvary: nezávislé na koncovém bodu, závislé na adrese a závislé na adrese i portu. U posledního se port, na který musí partner cílit, mění s každým cílem, takže předpověď přestává být spolehlivá. Tady technika naráží na slepou uličku, protože operátorský NAT a přísný podnikový firewall společně odstraňují předvídatelnost, kterou schéma potřebuje, a žádné opakování ji nevrátí.

Keepalive, restarty a koncový bod, který se posouvá

Probušená cesta je tok, nikoli naslouchač, takže vše, co nad ní běží, musí přežít změnu. Musí udržovat mapování živé periodickým provozem, všimnout si, když se veřejný koncový bod posune, a znovu se ustavit po restartu routeru nebo přiřazení nové adresy. Mesh VPN produkty tuto logiku dávají do svého řídicího plánu, zatímco obyčejný server ji nechává na vás. Keepalive pomáhají jen dokud stejné mapování přežívá, a na mobilním klientovi žerou baterii, proto agresivní interval není zdarma.

Notebook, který hodinu spí, se obvykle vrátí na jiném veřejném koncovém bodu. Vše, co cestu obnovuje, musí znovu běžet zevnitř, což klade stejný požadavek zpět na klienta.

Tři způsoby, jak obejít chybějící přesměrování

První způsob žádá router, aby záznam vytvořil sám, přes UPnP IGD, NAT-PMP nebo PCP, když funkce existuje a je zapnutá. Druhý předává provoz relayi s veřejnou adresou, což vždy funguje a vždy stojí šířku pásma plus jinou hranici důvěry. Třetí obrací směr: vnitřní hostitel otevře odchozí tunel k veřejnému serveru a všechno ostatní jede uvnitř něj.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Koncový bod relaye činí tuto výměnu viditelnou v konfiguraci klienta, kde je koncovým bodem relay, a ne vlastní adresa partnera. Trvalý keepalive udržuje mapování teplé a povolené prefixy rozhodují, co přes něj klient smí posílat. Reverzní tunel z vnitřního hostitele je stejný nápad s jiným vlastníkem a nepotřebuje žádnou změnu NAT. Každý ze tří odstraňuje požadavek na příchozí spojení, aniž by porazil firewall, který nevyžádaný provoz záměrně blokuje, protože provoz stále začíná uvnitř.

Přizpůsobte obejití tomu, kdo vlastní router

Pokud router spravujete, statické přesměrování UDP se audituje snáz než jakékoli schéma prolamování a selhává způsoby, které vidíte. Pokud ne, zjistěte, zda výrobce nabízí relay nebo hostovaný řídicí plán a zda by politika jejich použití dovolila. Pokud není k dispozici ani jedno, zbývá reverzní tunel nebo přijetí toho, že koncový bod není zvenčí dosažitelný. Zaznamenat, kterou možnost jste použili, je důležitější, než to zní, protože možnosti se liší v tom, kdo může provoz pozorovat a co se stane, když třetí strana něco změní.

Všimněte si, zda cesta, ke které jste dospěli, byla přímá, nebo přes relay, protože tento jediný fakt předpovídá jak latenci, tak chování při selhání. RFC 4787 zůstává referencí pro chování mapování pod tím vším a čtení jeho sekce o mapování je rychlejší než postupné testování tří obejití. Tabulce je jedno, kterou možnost jste zvolili; zaznamenává jen, co smí příští paket udělat.