Symetrický NAT a VPN: měřte mapování, ne nálepku
Mapování závislé na koncovém bodu ovlivňuje zjišťování protějšků, ne běžný tunel od klienta k serveru. Změřte port a pak, pokud přímá cesta selže, použijte relay.
Vlákno podpory končí verdiktem „symetrický NAT, VPN tu fungovat nebude“ a klient se pak třikrát zbytečně přeinstaluje. Nálepka škodí, protože odpovídá na otázku, kterou nikdo nepoložil. Klient, který se připojuje ven k pevnému serveru, vytvoří mapování v okamžiku, kdy odešle první paket, a odpověď se nechá projít zpět podle pravidel, která zavádí téměř každá síť. Co mapování závislé na koncovém bodu skutečně komplikuje, jsou dva protějšky, které se snaží dostat k sobě současně, a to je jiný test.
Za jednou nálepkou se skrývají dvě otázky
První otázka je, zda hostitel za touto sítí může otevřít relaci ke známé veřejné adrese a portu. Pro klienta tunelu je to běžný případ a odpověď je téměř vždy ano. Router zaznamená vnitřní zdroj, přidělí vnější port a pustí odpověď, protože patří relaci, která začala zevnitř.
Druhá otázka je, zda dva hostitelé za různými sítěmi dokážou najít společnou cestu a posílat si navzájem bez serveru uprostřed. To závisí na tom, jak každá síť přiděluje ty vnější porty, a to je jediné místo, kde na chování mapování záleží.
Záměna obojího dává klasickou chybnou diagnózu: funkce mezi protějšky selže, někdo spustí test typu NAT, uvidí nejhorší kategorii a usoudí, že ani běžný tunel nemůže fungovat. Tunel nikdy nebyl to, co selhalo.
Mapování a filtrování jsou dvě oddělené vlastnosti
Terminologie RFC je přesnější než názvy, které používají výrobci, a vyplatí se ji přenést do tiketu, protože ukončuje hádky. Mapování je způsob, jakým se přiděluje vnější port. Filtrování je to, které příchozí pakety se pustí. Síť může být přísná v jednom a benevolentní v druhém, a právě tahle kombinace je to, co musí protokol mezi protějšky přežít.
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
Třetí řádek je to, co většina domácích routerů a mobilních operátorů myslí slovem symetrický. Všimněte si, že nálepka popisuje jen přidělování. Síť s takovým mapováním a benevolentním filtrováním může stále přijímat příchozí pakety na port, který právě přidělila, a proto děrování děr na některých uspěje a na jiných ne.
Filtrování má své tři případy a svůj název pro každý z nich. Napsat do tiketu „symetrický NAT“, když máte na mysli „filtrování závislé na adrese a portu“, pošle dalšího člověka do špatné kapitoly příručky. Oba se při testu chovají jinak, takže chyba není akademická.
Mapování měřte, místo abyste ho pojmenovávali
Přidělený port můžete pozorovat přímo ze strany serveru jakékoli UDP služby, kterou ovládáte. Spusťte zachytávání na veřejném hostiteli, odešlete z klienta a přečtěte zdrojový port, se kterým paket dorazil:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820Řádek koncového bodu je nejužitečnější ze tří, protože WireGuard zaznamenává poslední adresu a port, které od každého protějšku přijal. Porovnejte tento port s tím, který klient považuje za svůj. Budou se lišit vždy, když probíhá jakýkoli překlad, a důležitá otázka je, zda hodnota zůstává stabilní.
Zopakujte pozorování vůči druhému cílovému portu nebo druhému serveru a znovu porovnejte. Pokud se vnější port mění podle cíle, mapování závisí na adrese a portu. Pokud zůstává stejný, síť vám dává jediné mapování a zjišťování má šanci.
Nástroje založené na STUN hlásí stejnou klasifikaci v jednom kroku a lze je použít, když síť povoluje odchozí UDP k veřejnému STUN serveru. Když to nepovoluje, výše uvedená metoda zachytávání stále funguje a nevyžaduje nic než hostitele, kterého už ovládáte.
Zvolte opravu, která odpovídá poruše
Pokud selhávající funkcí je spojení mezi protějšky, podporované odpovědi jsou relay, služba setkání, ke které se dostanou oba protějšky, nebo jiná topologie. TURN existuje právě proto a produkt, který dodává vlastní relay, vám říká, že očekává některé sítě nepřátelské.
Pokud selhávající funkcí je běžný tunel, chování mapování není váš problém a nic z výše uvedeného neplatí. Zkontrolujte, že klient skutečně odesílá, že server paket vidí a že se odpověď vrací. Tahle posloupnost jsou tři pozorování a nevyžaduje vědět nic o kategorii NAT routeru.
Co nefunguje, je rozhazování změn místního portu, dokud se něco nepřipojí. Změna zdrojového portu klienta nemění to, jak síť přiděluje mapování. Náhodný úspěch na pátý pokus je falešně pozitivní a měsíce se bude citovat jako oprava.
Zaznamenejte architekturu, ne verdikt
Užitečná poznámka říká, který protokol, kterým směrem relace začíná, zda je na cestě relay a co bylo pozorováno na drátě. „symetrický NAT, nefunguje“ je nepoužitelné, protože je zároveň chybné ohledně tunelu a neinformativní ohledně cesty mezi protějšky.
Pokud jste je testovali, uveďte naměřenou stabilitu portu a chování filtrování. Tyto dva údaje umožní někomu jinému předpovědět, zda nová funkce bude v té síti fungovat, aniž by opakoval celé vyšetřování. Také stárnou lépe než kategorie výrobce, která na každé stránce nápovědy znamená něco trochu jiného.
Nakonec mějte při psaní po ruce terminologii RFC 4787. Použití přesných termínů stojí jednu větu a zabrání dalšímu čtenáři zopakovat stejnou chybnou diagnózu, a to je celý smysl psaní poznámky.