Szimmetrikus NAT és VPN: a leképezést mérje, ne a címkét

Egy támogatási szál azzal a verdikttel zárul, hogy „szimmetrikus NAT, itt a VPN nem fog működni”, majd a klienst ok nélkül háromszor újratelepítik. A címke kárt okoz, mert olyan kérdésre válaszol, amelyet senki sem tett fel. Az a kliens, amely kifelé csatlakozik egy rögzített kiszolgálóhoz, az első csomag elküldésének pillanatában leképezést hoz létre, és a válasz visszaengedése olyan szabályok szerint történik, amelyeket szinte minden hálózat megvalósít. Amit a végpontfüggő leképezés valóban megnehezít, az két partner egyidejű kapcsolatteremtése, és az egy másik vizsgálat.

Két kérdés bújik meg egyetlen címke mögött

Az első kérdés az, hogy a hálózat mögötti gazdagép tud-e munkamenetet nyitni egy ismert nyilvános cím és port felé. Egy alagút-kliensnél ez a szokásos eset, és a válasz szinte mindig igen. Az útválasztó rögzíti a belső forrást, kioszt egy külső portot, és átengedi a választ, mert az egy belülről indult munkamenethez tartozik.

A második kérdés az, hogy két különböző hálózat mögötti gazdagép képes-e közös útvonalat felfedezni és köztes kiszolgáló nélkül egymásnak küldeni. Ez attól függ, hogyan osztja ki az egyes hálózat ezeket a külső portokat, és a leképezés viselkedésének csak itt van jelentősége.

A kettő összekeverése adja a klasszikus téves diagnózist: egy partner–partner funkció elakad, valaki lefuttat egy NAT-típus vizsgálatot, meglátja a legrosszabb kategóriát, és arra jut, hogy a hétköznapi alagút sem működhet. Az alagút soha nem az volt, ami elakadt.

A leképezés és a szűrés két külön tulajdonság

Az RFC terminológiája pontosabb, mint a szállítók által használt nevek, és érdemes beírni a jegybe, mert eldönti a vitákat. A leképezés az, ahogyan a külső portot kiosztják. A szűrés az, hogy mely bejövő csomagok mehetnek át. Egy hálózat lehet szigorú az egyikben és engedékeny a másikban, és éppen ez a kombináció az, amit egy partner–partner protokollnak túl kell élnie.

A harmadik sor az, amit a legtöbb fogyasztói útválasztó és mobilszolgáltató szimmetrikus alatt ért. Figyelje meg, hogy a címke csak a kiosztást írja le. Egy ilyen leképezésű és engedékeny szűrésű hálózat továbbra is fogadhat bejövő csomagokat arra a portra, amelyet épp kiosztott, ezért a lyukfúrás egyeseken sikerül, másokon nem.

A szűrésnek megvan a maga három esete és mindegyiknek a saját neve. Ha a jegybe „szimmetrikus NAT” kerül, miközben „cím- és portfüggő szűrésről” van szó, a következő embert a kézikönyv rossz fejezetéhez küldi. A kettő másképp viselkedik vizsgálat közben, tehát a hiba nem elméleti.

Mérje meg a leképezést ahelyett, hogy elnevezné

A kiosztott portot közvetlenül megfigyelheti bármely Ön által irányított UDP-szolgáltatás kiszolgálói oldalán. Indítson rögzítést a nyilvános gazdagépen, küldjön a kliensről, és olvassa le, milyen forrásporttal érkezett a csomag:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

A végpont sor a leghasznosabb a három közül, mert a WireGuard minden partnernél az utolsóként kapott címet és portot rögzíti. Hasonlítsa össze ezt a portot azzal, amelyet a kliens használ. Eltérni fognak, valahányszor bármilyen átírás történik, és a fontos kérdés az, hogy az érték stabil marad-e.

Ismételje meg a megfigyelést egy második célport vagy egy második kiszolgáló felé, és hasonlítson össze újra. Ha a külső port célonként változik, a leképezés cím- és portfüggő. Ha ugyanaz marad, a hálózat egy leképezést ad, és a felderítésnek van esélye.

A STUN-alapú eszközök egy lépésben ugyanezt az osztályozást jelentik, és nyugodtan használhatók, ha a hálózat engedi a kimenő UDP-t egy nyilvános STUN-kiszolgáló felé. Ha nem engedi, a fenti rögzítéses módszer továbbra is működik, és semmi mást nem igényel, csak egy gazdagépet, amely már az Ön irányítása alatt áll.

A hibához illő megoldást válasszon

Ha az elakadó funkció partner–partner, a támogatott válaszok a továbbító, egy találkozási szolgáltatás, amelyet mindkét partner elér, vagy egy másik topológia. A TURN éppen erre való, és az a termék, amely saját továbbítót szállít, elárulja, hogy számít néhány ellenséges hálózatra.

Ha az elakadó funkció hétköznapi alagút, akkor a leképezés viselkedése nem az Ön gondja, és a fentiek egyike sem érvényes. Ellenőrizze, hogy a kliens valóban küld, hogy a kiszolgáló látja a csomagot, és hogy a válasz visszaér. Ez a sorrend három megfigyelés, és nem igényel semmilyen tudást az útválasztó NAT-kategóriájáról.

Ami nem működik, az a helyi port cserélgetése addig, amíg valami csatlakozik. A kliens forrásportjának megváltoztatása nem változtat azon, hogyan osztja ki a hálózat a leképezéseket. Az ötödik próbálkozásra véletlenül bejövő siker hamis pozitív, és hónapokig megoldásként fogják idézni.

Az architektúrát rögzítse, ne a verdiktet

Egy hasznos feljegyzés megmondja, melyik protokoll, melyik irányban indul a munkamenet, van-e továbbító az útvonalon, és mit figyeltek meg a vonalon. A „szimmetrikus NAT, nem működik” használhatatlan, mert egyszerre téves az alagútról és semmitmondó a partner útvonaláról.

Vegye bele a mért portstabilitást és a szűrés viselkedését, ha tesztelte őket. Ez a két tény másnak lehetővé teszi annak előrejelzését, hogy egy új funkció működni fog-e azon a hálózaton, anélkül hogy megismételné a teljes vizsgálatot. Jobban is öregszenek, mint egy szállítói kategória, amely minden súgóoldalon kicsit mást jelent.

Végül tartsa kéznél az RFC 4787 terminológiáját, amikor leírja. A pontos kifejezések használata egy mondatba kerül, és megakadályozza, hogy a következő olvasó ugyanazt a téves diagnózist ismételje meg, márpedig a feljegyzés megírásának egész értelme ez.