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

En støttetråd ender med dommen «symmetrisk NAT, VPN vil ikke virke her», og deretter reinstallasjon klienten tre ganger uten grunn. Etiketten gjør skade fordi den svarer på et spørsmål ingen stilte. En klient som kobler utover til en fast server, oppretter en mapping i det øyeblikket den sender den første pakken, og svaret slippes tilbake etter regler som nesten hvert nettverk implementerer. Det endepunktsavhengig mapping virkelig kompliserer, er to peers som prøver å nå hverandre samtidig, og det er en annen test.

To spørsmål gjemmer seg bak én etikett

Det første spørsmålet er om en vert bak dette nettverket kan åpne en sesjon til en kjent offentlig adresse og port. For en tunnelklient er det det normale tilfellet, og svaret er nesten alltid ja. Ruteren registrerer den interne kilden, tildeler en ekstern port og slipper svaret gjennom fordi det hører til en sesjon som startet innenfra.

Det andre spørsmålet er om to verter bak forskjellige nettverk kan finne en felles vei og sende til hverandre uten en server i midten. Det avhenger av hvordan hvert nettverk tildeler de eksterne portene, og det er det eneste stedet der mappingens oppførsel betyr noe.

Å blande de to gir den klassiske feildiagnosen: en peer-til-peer-funksjon feiler, noen kjører en NAT-type-test, ser den dårligste kategorien og konkluderer med at den vanlige tunnelen heller ikke kan virke. Tunnelen var aldri det som feilet.

Mapping og filtrering er to forskjellige egenskaper

RFC-terminologien er mer presis enn navnene leverandørene bruker, og den er verdt å ta med i billetten fordi den avgjør diskusjoner. Mapping er hvordan den eksterne porten tildeles. Filtrering er hvilke innkommende pakker som slippes gjennom. Et nettverk kan være strengt i det ene og liberalt i det andre, og den kombinasjonen er det en peer-til-peer-protokoll må overleve.

Den tredje raden er det de fleste forbrukerrutere og mobiloperatører mener med symmetrisk. Legg merke til at etiketten bare beskriver tildelingen. Et nettverk med den mappingen og liberal filtrering kan fortsatt ta imot innkommende pakker til porten det nettopp tildelte, og derfor lykkes hulltaking på noen av dem og feiler på andre.

Filtrering har sine egne tre tilfeller og sitt eget navn for hvert av dem. Å skrive «symmetrisk NAT» i en billett når man mener «adresse- og portavhengig filtrering», sender neste person til feil kapittel i håndboken. De to oppfører seg forskjellig under test, så feilen er ikke akademisk.

Mål mappingen i stedet for å navngi den

Du kan observere den tildelte porten direkte fra serversiden av enhver UDP-tjeneste du kontrollerer. Start en opptak på den offentlige verten, send fra klienten og les kildeporten pakken kom med:

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

Endepunktlinjen er den mest nyttige av de tre, fordi WireGuard registrerer den siste adressen og porten den mottok fra hver peer. Sammenlign den porten med den klienten tror den bruker. De vil avvike hver gang en oversettelse skjer, og det viktige spørsmålet er om verdien holder seg stabil.

Gjenta observasjonen mot en annen destinasjonsport eller en annen server og sammenlign igjen. Hvis den eksterne porten endrer seg per destinasjon, er mappingen adresse- og portavhengig. Hvis den forblir den samme, gir nettverket deg én mapping, og oppdagelse har en sjanse.

STUN-baserte verktøy rapporterer samme klassifisering i ett trinn, og de kan brukes når nettverket tillater utgående UDP til en offentlig STUN-server. Når det ikke gjør det, fungerer opptaksmetoden over fortsatt og krever ingenting annet enn en vert du allerede kontrollerer.

Velg en retting som passer til feilen

Hvis funksjonen som feiler er peer-til-peer, er de støttede svarene et relay, en møtetjeneste som begge peers kan nå, eller en annen topologi. TURN finnes nettopp for dette, og et produkt som leverer sitt eget relay forteller deg at det forventer at noen nettverk er fiendtlige.

Hvis funksjonen som feiler er en vanlig tunnel, er mappingens oppførsel ikke ditt problem, og ingenting av det ovenstående gjelder. Kontroller at klienten faktisk sender, at serveren ser pakken, og at svaret kommer tilbake. Den sekvensen er tre observasjoner, og den krever ikke å vite noe om ruterens NAT-kategori.

Det som ikke virker, er å spre lokale portendringer til noe kobler seg til. Å endre klientens kildeport endrer ikke hvordan nettverket tildeler mappinger. En tilfeldig suksess på femte forsøk er en falsk positiv, og den vil bli sitert som en retting i månedsvis.

Registrer arkitekturen, ikke dommen

Et nyttig notat sier hvilken protokoll, i hvilken retning sesjonen starter, om det er et relay på veien, og hva som ble observert på ledningen. «symmetrisk NAT, virker ikke» er ubrukelig, fordi det samtidig er feil om tunnelen og intetsigende om peer-veien.

Ta med den målte portstabiliteten og filtreringsoppførselen hvis du testet dem. Disse to fakta lar noen andre forutsi om en ny funksjon vil virke på det nettverket uten å gjenta hele undersøkelsen. De eldes også bedre enn en leverandørkategori som betyr noe litt forskjellig på hver hjelpeside.

Til slutt bør du ha RFC 4787-terminologien for hånden når du skriver det ned. Å bruke de presise termene koster én setning og hindrer neste leser i å gjenta samme feildiagnose, og det er hele poenget med å skrive notatet.