Symetryczny NAT i VPN: mierz mapowanie, nie etykietę

Wątek pomocy kończy się werdyktem „symetryczny NAT, VPN tu nie zadziała”, a potem klient jest trzy razy bez powodu przeinstalowywany. Etykieta wyrządza szkodę, bo odpowiada na pytanie, którego nikt nie zadał. Klient łączący się na zewnątrz z ustalonym serwerem tworzy mapowanie w chwili wysłania pierwszego pakietu, a odpowiedź jest wpuszczana z powrotem według reguł, które wdraża niemal każda sieć. To, co mapowanie zależne od punktu końcowego naprawdę komplikuje, to dwaj równorzędni próbujący dotrzeć do siebie jednocześnie, i to jest inny test.

Dwa pytania ukrywają się za jedną etykietą

Pierwsze pytanie brzmi, czy host za tą siecią może otworzyć sesję do znanego publicznego adresu i portu. Dla klienta tunelu to zwykły przypadek, a odpowiedź brzmi prawie zawsze tak. Router zapisuje wewnętrzne źródło, przydziela port zewnętrzny i przepuszcza odpowiedź, bo należy ona do sesji rozpoczętej od wewnątrz.

Drugie pytanie brzmi, czy dwa hosty za różnymi sieciami mogą znaleźć wspólną ścieżkę i wysyłać do siebie bez serwera pośrodku. To zależy od tego, jak każda sieć przydziela te porty zewnętrzne, i tylko tam zachowanie mapowania ma znaczenie.

Mieszanie obu daje klasyczną błędną diagnozę: funkcja między równorzędnymi zawodzi, ktoś uruchamia test typu NAT, widzi najgorszą kategorię i wnioskuje, że zwykły tunel też nie może działać. Tunel nigdy nie był tym, co zawiodło.

Mapowanie i filtrowanie to dwie odrębne właściwości

Terminologia RFC jest precyzyjniejsza niż nazwy używane przez dostawców, i warto przenieść ją do zgłoszenia, bo rozstrzyga spory. Mapowanie to sposób przydzielania portu zewnętrznego. Filtrowanie to to, które pakiety przychodzące są przepuszczane. Sieć może być surowa w jednym i liberalna w drugim, i właśnie ta kombinacja jest tym, co protokół między równorzędnymi musi przetrwać.

Trzeci wiersz to to, co większość routerów konsumenckich i operatorów komórkowych rozumie przez symetryczny. Zwróć uwagę, że etykieta opisuje tylko przydział. Sieć z takim mapowaniem i liberalnym filtrowaniem wciąż może przyjmować pakiety przychodzące na port, który właśnie przydzieliła, dlatego przebijanie dziur udaje się na niektórych, a na innych nie.

Filtrowanie ma swoje trzy przypadki i swoją nazwę dla każdego. Zapisanie „symetryczny NAT” w zgłoszeniu, gdy ma się na myśli „filtrowanie zależne od adresu i portu”, wysyła następną osobę do niewłaściwego rozdziału podręcznika. Oba zachowują się inaczej w teście, więc błąd nie jest akademicki.

Mierz mapowanie, zamiast je nazywać

Przydzielony port możesz obserwować bezpośrednio od strony serwera dowolnej usługi UDP, którą kontrolujesz. Rozpocznij przechwytywanie na publicznym hoście, wyślij z klienta i odczytaj port źródłowy, z którym przyszedł pakiet:

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

Wiersz punktu końcowego jest najbardziej użyteczny z trzech, bo WireGuard zapisuje ostatni adres i port otrzymane od każdego równorzędnego. Porównaj ten port z tym, który klient uważa za używany. Będą się różnić zawsze, gdy zachodzi jakiekolwiek tłumaczenie, a ważne pytanie brzmi, czy wartość pozostaje stabilna.

Powtórz obserwację wobec drugiego portu docelowego lub drugiego serwera i porównaj ponownie. Jeśli port zewnętrzny zmienia się zależnie od celu, mapowanie zależy od adresu i portu. Jeśli pozostaje taki sam, sieć daje jedno mapowanie i odnajdywanie ma szansę.

Narzędzia oparte na STUN raportują tę samą klasyfikację w jednym kroku i można ich użyć, gdy sieć pozwala na wychodzący UDP do publicznego serwera STUN. Gdy nie pozwala, opisana wyżej metoda przechwytywania nadal działa i nie wymaga niczego poza hostem, który już kontrolujesz.

Wybierz poprawkę pasującą do usterki

Jeśli zawodzącą funkcją jest połączenie między równorzędnymi, obsługiwane odpowiedzi to przekaźnik, usługa spotkania, do której dotrą obaj równorzędni, lub inna topologia. TURN istnieje właśnie po to, a produkt dostarczający własny przekaźnik mówi ci, że spodziewa się wrogości niektórych sieci.

Jeśli zawodzącą funkcją jest zwykły tunel, zachowanie mapowania nie jest twoim problemem i nic z powyższego nie ma zastosowania. Sprawdź, czy klient naprawdę wysyła, czy serwer widzi pakiet i czy odpowiedź wraca. Ta sekwencja to trzy obserwacje i nie wymaga wiedzy o kategorii NAT routera.

To, co nie działa, to rozrzucanie zmian portu lokalnego, aż coś się połączy. Zmiana portu źródłowego klienta nie zmienia tego, jak sieć przydziela mapowania. Przypadkowy sukces przy piątej próbie to wynik fałszywie dodatni, i przez miesiące będzie cytowany jako poprawka.

Zapisuj architekturę, nie werdykt

Użyteczna notatka mówi, który protokół, w którym kierunku zaczyna się sesja, czy na ścieżce jest przekaźnik i co zaobserwowano na przewodzie. „symetryczny NAT, nie działa” jest bezużyteczne, bo jednocześnie jest błędne co do tunelu i nieinformacyjne co do ścieżki równorzędnego.

Uwzględnij zmierzoną stabilność portu i zachowanie filtrowania, jeśli je testowałeś. Te dwa fakty pozwalają komuś innemu przewidzieć, czy nowa funkcja zadziała w tej sieci, bez powtarzania całego dochodzenia. Starzeją się też lepiej niż kategoria dostawcy, która na każdej stronie pomocy znaczy coś nieco innego.

Na koniec miej pod ręką terminologię RFC 4787, gdy to zapisujesz. Używanie precyzyjnych terminów kosztuje jedno zdanie i powstrzymuje następnego czytelnika przed powtórzeniem tej samej błędnej diagnozy, a w tym jest cały sens pisania notatki.