Symmetrisk NAT og VPN: mål mappingen, ikke etiketten

En supporttråd ender med dommen „symmetrisk NAT, VPN vil ikke virke her“, og derefter geninstalleres klienten tre gange uden grund. Etiketten gør skade, fordi den besvarer et spørgsmål, ingen stillede. En klient, der forbinder udad til en fast server, opretter en mapping i det øjeblik, den sender den første pakke, og svaret lukkes tilbage efter regler, som næsten alle netværk implementerer. Det, endepunktsafhængig mapping virkelig gør kompliceret, er to peers, der forsøger at nå hinanden samtidig, og det er en anden test.

To spørgsmål gemmer sig bag én etiket

Det første spørgsmål er, om en vært bag dette netværk kan åbne en session til en kendt offentlig adresse og port. For en tunnelklient er det det normale tilfælde, og svaret er næsten altid ja. Routeren registrerer den interne kilde, tildeler en ekstern port og lukker svaret igennem, fordi det hører til en session, der startede indefra.

Det andet spørgsmål er, om to værter bag forskellige netværk kan finde en fælles vej og sende til hinanden uden en server i midten. Det afhænger af, hvordan hvert netværk tildeler de eksterne porte, og det er det eneste sted, hvor mappingens adfærd betyder noget.

At blande de to giver den klassiske fejldiagnose: en peer-to-peer-funktion fejler, nogen kører en test af NAT-typen, ser den værste kategori og konkluderer, at den almindelige tunnel heller ikke kan virke. Tunnelen var aldrig det, der fejlede.

Mapping og filtrering er to forskellige egenskaber

RFC-terminologien er mere præcis end de navne, leverandørerne bruger, og den er værd at tage med i billetten, fordi den afgør diskussioner. Mapping er, hvordan den eksterne port tildeles. Filtrering er, hvilke indgående pakker der lukkes igennem. Et netværk kan være stramt i det ene og liberalt i det andet, og kombinationen er det, en peer-to-peer-protokol skal overleve.

Den tredje række er det, de fleste forbrugerroutere og mobiloperatører mener med symmetrisk. Bemærk, at etiketten kun beskriver tildelingen. Et netværk med den mapping og liberal filtrering kan stadig acceptere indgående pakker til den port, den netop har tildelt, og derfor lykkes hulboring på nogle af dem og fejler på andre.

Filtrering har sine egne tre tilfælde og sit eget navn for hvert af dem. At skrive „symmetrisk NAT“ i en billet, når man mener „adresse- og portafhængig filtrering“, sender den næste person til det forkerte kapitel i manualen. De to opfører sig forskelligt under test, så fejlen er ikke akademisk.

Mål mappingen i stedet for at navngive den

Du kan observere den tildelte port direkte fra serversiden af enhver UDP-tjeneste, du kontrollerer. Start en optagelse på den offentlige vært, send fra klienten, og læs den kildeport, pakken ankom med:

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

Endepunktslinjen er den mest nyttige af de tre, fordi WireGuard registrerer den sidste adresse og port, den har modtaget fra hver peer. Sammenlign den port med den, klienten tror, den bruger. De vil afvige, hver gang der sker en oversættelse, og det vigtige spørgsmål er, om værdien forbliver stabil.

Gentag observationen mod en anden destinationsport eller en anden server, og sammenlign igen. Hvis den eksterne port ændrer sig for hver destination, er mappingen adresse- og portafhængig. Hvis den forbliver den samme, giver netværket dig én mapping, og opdagelse har en chance.

STUN-baserede værktøjer rapporterer den samme klassifikation i ét trin, og de er fine at bruge, når netværket tillader udgående UDP til en offentlig STUN-server. Når det ikke gør, virker optagelsesmetoden ovenfor stadig og kræver intet andet end en vært, du allerede kontrollerer.

Vælg en rettelse, der passer til fejlen

Hvis den fejlende funktion er peer-to-peer, er de understøttede svar et relay, en mødetjeneste, som begge peers kan nå, eller en anden topologi. TURN findes netop til dette, og et produkt, der leverer sit eget relay, fortæller dig, at det forventer, at nogle netværk er fjendtlige.

Hvis den fejlende funktion er en almindelig tunnel, er mappingens adfærd ikke dit problem, og intet af det ovenstående gælder. Kontrollér, at klienten faktisk sender, at serveren ser pakken, og at svaret kommer tilbage. Den sekvens er tre observationer, og den kræver ikke at vide noget om routerens NAT-kategori.

Det, der ikke virker, er at sprede lokale portændringer, indtil noget forbinder. At ændre klientens kildeport ændrer ikke, hvordan netværket tildeler mappings. En tilfældig succes på femte forsøg er en falsk positiv, og den vil blive citeret som en rettelse i månedsvis.

Registrér arkitekturen, ikke dommen

Et brugbart notat siger, hvilken protokol, i hvilken retning sessionen starter, om der er et relay på vejen, og hvad der blev observeret på ledningen. „symmetrisk NAT, virker ikke“ er ubrugeligt, fordi det samtidig er forkert om tunnelen og intetsigende om peer-vejen.

Tag den målte portstabilitet og filtreringsadfærden med, hvis du testede dem. De to fakta lader en anden forudsige, om en ny funktion vil virke på det netværk uden at gentage hele undersøgelsen. De ældes også bedre end en leverandørkategori, der betyder noget lidt forskelligt på hver hjælpeside.

Endelig bør du have RFC 4787-terminologien ved hånden, når du skriver det ned. At bruge de præcise termer koster én sætning og forhindrer den næste læser i at gentage den samme fejldiagnose, og det er hele pointen med at skrive notatet.