Jak průchod NAT zabaluje ESP do UDP

Dva klienti za stejným routerem mluví s jedinou branou IPsec a jeden stále vypadává, zatímco druhý zůstává připojený. Nativní ESP je IP protokol 50 bez portů, takže překladač nemá k mapování co uchytit, když několik klientů sdílí jednu adresu. Průchod NAT tuto mezeru uzavírá zabalením ESP do UDP na 4500 a tato hlavička vysvětluje většinu následujících příznaků. Ukazuje také na zařízení, které je třeba změnit.

Proč se datová rovina přesouvá na port 4500

Během nastavení IKEv2 porovnává adresy a porty, o nichž každá strana věří, že je používá, výměnou hashů ve svých oznámeních o detekci NAT. Když se hashe neshodují, někde na cestě sedí překladač a oba protějšky přepnou chráněný provoz na zapouzdření UDP. Proto relace, která se setkala s překladačem, vypadá jinak než ta, která ne.

Obal je obálka, ne změna protokolu: ESP si zachovává svou hlavičku, kontrolu integrity a šifrování a UDP dodává jen porty, které překladač potřebuje. Port 500 nese výměnu IKE; 4500 nese zapouzdřená data po detekci a často i pozdější zprávy IKE. Žádný z portů nedělá z toku TCP spojení, což je předpoklad, který mate většinu lidí čtoucích zachytávku.

Zkontrolujte obě fáze v pořadí

Nejprve prokažte řídicí výměnu, poté datovou cestu, a obojí držte v poznámkách oddělené. Zachytávka, která ukazuje provoz na 500 a nikdy na 4500, obvykle znamená, že datová cesta je filtrovaná, takže oprava patří do pravidla firewallu, nikoli do klienta.

Sledujte oba porty pomocí tcpdump -ni any 'udp port 500 or udp port 4500' a čtěte překladovou tabulku na routeru, dokud je relace živá. Tabulka ukazuje zdrojový port, který brána skutečně uvidí, a zachytávka na notebooku se záměrně rozchází: notebook věří, že jde o 500, zatímco brána vidí 4500 s přeloženým zdrojovým portem, a oba mají pravdu. Stejný tok před překladem a po něm:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

Příznaky, které obal vysvětluje, a dva, které ne

Router, který povolí řídicí výměnu a zablokuje zapouzdřená data vytvoří hlášení „tunel stojí, ale nic neprochází“. Mapovací tabulky vypršují, takže nečinná relace potřebuje provoz keepalive, který protějšky posílají záměrně, a tyto pakety nejsou zdravotní kontroly. Když několik klientů za jednou branou selže společně, prozkoumejte překlad této brány a jakoukoli starší funkci průchodu. Obal nevysvětluje aplikaci, která selže u každého klienta po postavení tunelu, ani varování o certifikátu na blokovací stránce; obojí je nad touto vrstvou.

Čtěte mapovací tabulku pro dva klienty najednou: pokud oba ukazují stejný přeložený port, zařízení je neodděluje tak, jak brána vyžaduje. Režim průchodu, který předá nativní ESP jen jednomu hostiteli, není rovnocenný obsluze několika přeložených klientů, i když dodavatelé obojí popisují jako přátelské k IPsec. Dvojitý NAT přidává mapovací vrstvu a další bod vypršení, ale automaticky nepřerušuje odchozí spojení.

Provoz keepalive si zaslouží vlastní řádek v provozní příručce, protože právě on drží cestu pro odpověď otevřenou během období nečinnosti. Zapněte jej tam, kde jej dodavatel dokumentuje, a zkontrolujte jej jako první, když relace zemře po minutách ticha, a ne při prvním použití.

Změňte vlastníka mapování a pak znovu otestujte

Řiďte se podporovaným nastavením průchodu NAT na obou protějšcích, místo abyste hádali port. Úprava místního zdrojového portu u jednoho klienta nemůže změnit službu, která naslouchá na druhém konci, a obvykle rozbije už vytvořené mapování. Pokud klient sedí za zařízením, které neovládáte, změna patří jeho vlastníkovi.

Po každé změně zopakujte obě kontroly fází a potvrďte, že datový paket projde, ne jen že stavová obrazovka zezelenala. Držte n-tice, výstup mapovací tabulky a změnu pravidla v jedné poznámce, aby další člověk nezačínal znovu od řídicí výměny. Poznámky strongSwan k průchodu NAT pokrývají nastavení zapouzdření a keepalive za oběma fázemi.