VPN za NAT, ktorý neviete nakonfigurovať: čo stále funguje

Každý koncový bod tunela potrebuje adresu a port, na ktoré sa druhá strana dostane, a router, ktorý nespravujete, je zvyčajným dôvodom, prečo táto požiadavka zlyhá. Zaujímavé nie je to, že existujú triky, ale že každý z nich závisí od vlastnosti mapovacej tabuľky, ktorú z klienta nevidíte. Dve z týchto vlastností rozhodujú takmer o všetkom: ako mapovanie vzniká a či prijíma pakety z adresy, s ktorou vnútro nikdy nekomunikovalo. Zoraďte prostredie podľa týchto vlastností a obchádzky prestanú byť folklórom.

Mapovacia tabuľka rozhoduje o všetkom

Preklad sieťových adries vedie tabuľku, v ktorej je vnútorná adresa a port zapísaná proti verejnej adrese a portu. Odpovede zodpovedajúce záznamu sa prekladajú späť a paket, ktorý prichádza zvonku bez zodpovedajúceho záznamu, nemá vôbec žiadny cieľ. To jediné správanie vysvetľuje, prečo je poslucháč za routerom nedostupný z internetu. Vysvetľuje aj to, prečo prvý paket v každom smere musí vzniknúť vnútri.

Pozrite sa na tabuľku zo strany routera a obchádzky sú zrejmé: buď niečo vytvorí trvalý záznam, alebo vytvorí dočasný a udržiava ho čerstvý, alebo prevádzka touto cestou vôbec nejde. Zvyšok článku sú tieto tri prípady v poradí. Nič tu nezávisí od funkcie výrobcu nad rámec toho, čo tabuľka zaznamenáva.

Čo rendezvous služba dokáže a čo nie

UDP hole punching používa odchádzajúci záznam ako dočasné otvorenie namiesto porazenia filtra. Obaja partneri kontaktujú rendezvous službu, ktorá zistí každý verejný koncový bod a druhej strane vráti jej bod. Potom obaja posielajú proti sebe a každý odchádzajúci paket vytvára alebo obnovuje záznam, ktorý pustí odpoveď dnu. Poradie je to, čo to robí funkčným, a poradie je aj to, čo to robí krehkým: partner, ktorý odošle skôr, než druhá strana vytvorila svoj záznam, sa jednoducho zahodí, zatiaľ čo opakovanie o chvíľu neskôr uspeje. Služba sama nenesie žiadnu VPN prevádzku, takže jej jedinou pákou je časovanie, ktoré koordinuje.

Správanie mapovania rozhoduje o zvyšku a RFC 4787 pomenúva tri tvary: nezávislý od koncového bodu, závislý od adresy a závislý od adresy aj portu. Pri poslednom sa port, na ktorý musí partner cieliť, mení s každým cieľom, takže predpoveď prestáva byť spoľahlivá. Tam technika naráža na slepú uličku, pretože operátorský NAT a prísny podnikový firewall oba odstraňujú predvídateľnosť, ktorú schéma potrebuje, a žiadne opakovanie ju nevráti.

Keepalive, reštarty a koncový bod, ktorý sa posúva

Prebitá cesta je tok, nie poslucháč, takže všetko, čo na nej beží, musí prežiť zmenu. Musí udržiavať mapovanie živé periodickou prevádzkou, všimnúť si, keď sa verejný koncový bod posunie, a znovu sa ustáliť po reštarte routera alebo po opätovnom pridelení adresy. Mesh VPN produkty dávajú túto logiku do svojej riadiacej roviny, zatiaľ čo obyčajný server ju necháva na vás. Keepalive pomáhajú len dovtedy, kým prežíva to isté mapovanie, a na mobilnom klientovi žerú batériu, preto agresívny interval nie je zadarmo.

Notebook, ktorý hodinu spí, sa zvyčajne vráti na inom verejnom koncovom bode. Všetko, čo cestu obnovuje, musí znova bežať zvnútra, čo kladie tú istú požiadavku späť na klienta.

Tri spôsoby, ako obísť chýbajúce presmerovanie

Prvý spôsob žiada router, aby záznam vytvoril sám, cez UPnP IGD, NAT-PMP alebo PCP, keď funkcia existuje a je zapnutá. Druhý odovzdáva prevádzku relayu s verejnou adresou, čo vždy funguje a vždy stojí šírku pásma plus inú hranicu dôvery. Tretí obracia smer: vnútorný hostiteľ otvorí odchádzajúci tunel k verejnému serveru a všetko ostatné ide v ňom.

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

Koncový bod relayu robí túto výmenu viditeľnou v konfigurácii klienta, kde je koncovým bodom relay a nie vlastná adresa partnera. Trvalý keepalive udržiava mapovanie teplé a povolené prefixy rozhodujú, čo cez neho klient smie posielať. Reverzný tunel z vnútorného hostiteľa je ten istý nápad s iným vlastníkom a nepotrebuje žiadnu zmenu NAT. Každý z troch odstraňuje požiadavku na príchod bez porazenia firewallu, ktorý nevyžiadanú prevádzku blokuje už z návrhu, pretože prevádzka stále začína vnútri.

Prispôsobte obchádzku tomu, kto vlastní router

Ak router spravujete, statické presmerovanie UDP sa audituje ľahšie než akákoľvek schéma prebíjania a zlyháva spôsobmi, ktoré vidíte. Ak nie, zistite, či výrobca ponúka relay alebo hostovanú riadiacu rovinu a či by politika ich použitie dovolila. Ak nie je k dispozícii ani jedno, zostáva reverzný tunel alebo prijatie toho, že koncový bod nie je zvonku dostupný. Zaznamenať, ktorú možnosť ste použili, je dôležitejšie, než to znie, pretože možnosti sa líšia v tom, kto môže prevádzku pozorovať a čo sa stane, keď tretia strana niečo zmení.

Všimnite si, či cesta, ku ktorej ste dospeli, bola priama alebo cez relay, pretože tento jediný fakt predpovedá latenciu aj správanie pri zlyhaní. RFC 4787 zostáva referenciou pre správanie mapovania pod tým všetkým a čítanie jeho časti o mapovaní je rýchlejšie než postupné testovanie troch obchádzok. Tabuľke je jedno, ktorú možnosť ste zvolili; zaznamenáva len to, čo smie urobiť nasledujúci paket.