Symmetrisk NAT og VPN: mål mappinga, ikkje etiketten

Ein støttetråd endar med dommen «symmetrisk NAT, VPN vil ikkje verke her», og deretter blir klienten reinstalla tre gonger utan grunn. Etiketten gjer skade fordi han svarar på eit spørsmål ingen stilte. Ein klient som koplar utover til ein fast tenar, opprettar ei mapping i det augneblinken han sender den første pakken, og svaret blir sleppt tilbake etter reglar som nesten kvart nettverk implementerer. Det endepunktsavhengig mapping verkeleg kompliserer, er to peers som prøver å nå kvarandre samstundes, og det er ein annan test.

To spørsmål gøymer seg bak éin etikett

Det første spørsmålet er om ein vert bak dette nettverket kan opne ein sesjon til ein kjend offentleg adresse og port. For ein tunnelklient er det det normale tilfellet, og svaret er nesten alltid ja. Ruteren registrerer den interne kjelda, tildeler ein ekstern port og slepp svaret gjennom fordi det høyrer til ein sesjon som starta innanfrå.

Det andre spørsmålet er om to vertar bak ulike nettverk kan finne ein felles veg og sende til kvarandre utan ein tenar i midten. Det kjem an på korleis kvart nettverk tildeler dei eksterne portane, og det er den einaste staden der åtferda til mappinga har noko å seie.

Å blande dei to gir den klassiske feildiagnosen: ein peer-til-peer-funksjon feilar, nokon køyrer ein NAT-type-test, ser den dårlegaste kategorien og konkluderer med at den vanlege tunnelen heller ikkje kan verke. Tunnelen var aldri det som feila.

Mapping og filtrering er to ulike eigenskapar

RFC-terminologien er meir presis enn namna leverandørane brukar, og han er verdt å ta med i billetten fordi han avgjer diskusjonar. Mapping er korleis den eksterne porten blir tildelt. Filtrering er kva innkomande pakkar som blir sleppte gjennom. Eit nettverk kan vere strengt i det eine og liberalt i det andre, og den kombinasjonen er det ein peer-til-peer-protokoll må overleve.

Den tredje rada er det dei fleste forbrukarrutarar og mobiloperatørar meiner med symmetrisk. Legg merke til at etiketten berre skildrar tildelinga. Eit nettverk med den mappinga og liberal filtrering kan framleis ta imot innkomande pakkar til porten det nettopp tildelte, og difor lukkast holtaking på nokre av dei og feilar på andre.

Filtrering har sine eigne tre tilfelle og sitt eige namn for kvart av dei. Å skrive «symmetrisk NAT» i ein billett når ein meiner «adresse- og portavhengig filtrering», sender neste person til feil kapittel i handboka. Dei to oppfører seg ulikt under test, så feilen er ikkje akademisk.

Mål mappinga i staden for å namngje ho

Du kan observere den tildelte porten direkte frå tenarsida av kvar UDP-teneste du kontrollerer. Start eit opptak på den offentlege verten, send frå klienten og les kjeldeporten pakken kom med:

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

Endepunktlinja er den mest nyttige av dei tre, fordi WireGuard registrerer den siste adressa og porten han tok imot frå kvar peer. Samanlikn den porten med den klienten trur han brukar. Dei vil avvike kvar gong ei oversetjing skjer, og det viktige spørsmålet er om verdien held seg stabil.

Gjenta observasjonen mot ein annan destinasjonsport eller ein annan tenar og samanlikn igjen. Om den eksterne porten endrar seg per destinasjon, er mappinga adresse- og portavhengig. Om han blir den same, gir nettverket deg éi mapping, og oppdaging har ein sjanse.

STUN-baserte verktøy rapporterer same klassifisering i eitt trinn, og dei kan brukast når nettverket tillèt utgåande UDP til ein offentleg STUN-tenar. Når det ikkje gjer det, fungerer opptaksmetoden over framleis og krev ingenting anna enn ein vert du allereie kontrollerer.

Vel ei retting som passar til feilen

Om funksjonen som feilar er peer-til-peer, er dei støtta svara eit relay, ei møteteneeste som begge peers kan nå, eller ein annan topologi. TURN finst nettopp for dette, og eit produkt som leverer sitt eige relay fortel deg at det ventar at nokre nettverk er fiendtlege.

Om funksjonen som feilar er ein vanleg tunnel, er åtferda til mappinga ikkje problemet ditt, og ingenting av det over gjeld. Kontroller at klienten faktisk sender, at tenaren ser pakken, og at svaret kjem tilbake. Den sekvensen er tre observasjonar, og han krev ikkje å vite noko om NAT-kategorien til ruteren.

Det som ikkje verkar, er å spreie lokale portendringar til noko koplar seg til. Å endre kjeldeporten til klienten endrar ikkje korleis nettverket tildeler mappingar. Ein tilfeldig suksess på femte forsøk er ein falsk positiv, og han vil bli sitert som ei retting i månadsvis.

Registrer arkitekturen, ikkje dommen

Eit nyttig notat seier kva protokoll, i kva retning sesjonen startar, om det er eit relay på vegen, og kva som vart observert på leidningen. «symmetrisk NAT, verkar ikkje» er ubrukeleg, fordi det samstundes er feil om tunnelen og seier ingenting om vegen til peer-en.

Ta med den målte portstabiliteten og filtreringsåtferda om du testa dei. Desse to fakta lèt nokon andre føreseie om ein ny funksjon vil verke på det nettverket utan å gjenta heile undersøkinga. Dei eldast også betre enn ein leverandørkategori som tyder noko litt ulikt på kvar hjelpeside.

Til slutt bør du ha RFC 4787-terminologien for handa når du skriv det ned. Å bruke dei presise termane kostar éi setning og hindrar neste lesar i å gjenta same feildiagnose, og det er heile poenget med å skrive notatet.