Simmetriese NAT en VPN’s: toets die kartering, nie die etiket nie

’n Ondersteuningsdraad eindig met die uitspraak “simmetriese NAT, die VPN sal hier nie werk nie”, en dan word die kliënt drie keer verniet herinstalleer. Die etiket rig skade aan omdat dit ’n vraag beantwoord wat niemand gevra het nie. ’n Kliënt wat uitwaarts na ’n vaste bediener verbind, skep ’n kartering die oomblik wanneer dit die eerste pakket stuur, en die antwoord word toegelaat om terug te kom onder reëls wat byna elke netwerk implementeer. Wat kartering wat van die eindpunt afhang werklik bemoeilik, is twee eweknieë wat mekaar op dieselfde tyd probeer bereik, en dit is ’n ander toets.

Twee vrae skuil agter een etiket

Die eerste vraag is of ’n gasheer agter hierdie netwerk ’n sessie na ’n bekende publieke adres en poort kan oopmaak. Vir ’n tonnelkliënt is dit die normale geval, en die antwoord is byna altyd ja. Die router teken die interne bron aan, ken ’n eksterne poort toe, en laat die antwoord deur omdat dit aan ’n sessie behoort wat van binne af begin het.

Die tweede vraag is of twee gashere agter verskillende netwerke ’n gedeelde pad kan ontdek en na mekaar kan stuur sonder ’n bediener in die middel. Dit hang daarvan af hoe elke netwerk daardie eksterne poorte toeken, en dit is die enigste plek waar die karteringsgedrag saak maak.

Om die twee te verwar lewer die klassieke misdiagnose: ’n eweknie-funksie faal, iemand hardloop ’n NAT-tipe toets, sien die slegste kategorie, en kom tot die gevolgtrekking dat die gewone tonnel ook nie kan werk nie. Die tonnel was nooit die ding wat gefaal het nie.

Kartering en filtering is aparte eienskappe

Die RFC-terminologie is presieser as die name wat verskaffers gebruik, en dit is die moeite werd om dit in ’n kaartjie te dra omdat dit argumente besleg. Kartering is hoe die eksterne poort toegeken word. Filtering is watter inkomende pakkette toegelaat word om deur te gaan. ’n Netwerk kan streng wees in die een en vrygewig in die ander, en die kombinasie is wat ’n eweknie-protokol moet oorleef.

Die derde ry is wat die meeste verbruikers-routers en mobiele operateurs met simmetries bedoel. Let daarop dat die etiket slegs die toekenning beskryf. ’n Netwerk met daardie kartering en vrygewige filtering kan steeds inkomende pakkette na die poort aanvaar wat dit pas toegeken het, en daarom slaag gaatjiesprik op sommige daarvan en faal dit op ander.

Filtering het sy eie drie gevalle en sy eie naam vir elkeen. Om “simmetriese NAT” in ’n kaartjie te skryf wanneer jy “adres-en-poort-afhanklike filtering” bedoel, stuur die volgende persoon na die verkeerde hoofstuk van die handleiding. Die twee gedra hulle anders onder toets, so die fout is nie akademies nie.

Meet die kartering in plaas daarvan om dit te benoem

Jy kan die toegekende poort direk vanaf die bedienerkant van enige UDP-diens wat jy beheer, waarneem. Begin ’n opname op die publieke gasheer, stuur vanaf die kliënt, en lees die bronpoort waarmee die pakket aangekom het:

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

Die eindpunt-lyn is die nuttigste van die drie, want WireGuard teken die laaste adres en poort aan wat dit van elke eweknie ontvang het. Vergelyk daardie poort met die een wat die kliënt dink hy gebruik. Hulle sal verskil wanneer enige vertaling plaasvind, en die belangrike vraag is of die waarde stabiel bly.

Herhaal die waarneming teen ’n tweede bestemmingspoort of ’n tweede bediener en vergelyk weer. As die eksterne poort per bestemming verander, is die kartering adres-en-poort-afhanklik. As dit dieselfde bly, gee die netwerk jou een kartering en het ontdekking ’n kans.

STUN-gebaseerde gereedskap rapporteer dieselfde klassifikasie in een stap, en dit is goed om te gebruik wanneer die netwerk uitgaande UDP na ’n publieke STUN-bediener toelaat. Wanneer dit nie doen nie, werk die opnamemetode hierbo steeds en vereis niks anders as ’n gasheer wat jy reeds beheer nie.

Kies ’n oplossing wat by die fout pas

As die funksie wat faal eweknie-tot-eweknie is, is die ondersteunde antwoorde ’n aflos, ’n ontmoetingsdiens wat beide eweknieë kan bereik, of ’n ander topologie. TURN bestaan juis hiervoor, en ’n produk wat sy eie aflos lewer, sê vir jou dat hy verwag dat sommige netwerke vyandig is.

As die funksie wat faal ’n gewone tonnel is, is karteringsgedrag nie jou probleem nie en geld niks van die bostaande nie. Kontroleer dat die kliënt werklik stuur, dat die bediener die pakket sien, en dat die antwoord terugkom. Daardie volgorde is drie waarnemings en dit vereis niks omtrent die router se NAT-kategorie te weet nie.

Wat nie werk nie, is om plaaslike poortveranderings rond te strooi tot iets verbind. Om die kliënt se bronpoort te verander, verander nie hoe die netwerk karterings toeken nie. ’n Toevallige sukses op ’n vyfde poging is ’n vals positief, en dit sal maande lank as ’n oplossing aangehaal word.

Teken die argitektuur aan, nie die uitspraak nie

’n Nuttige nota sê watter protokol, in watter rigting die sessie begin, of ’n aflos in die pad is, en wat op die draad waargeneem is. “Simmetriese NAT, werk nie” is onbruikbaar, want dit is gelyktydig verkeerd oor die tonnel en oninformatief oor die eweknie-pad.

Sluit die gemete poortstabiliteit en die filtergedrag in as jy hulle getoets het. Daardie twee feite laat iemand anders voorspel of ’n nuwe funksie op daardie netwerk sal werk sonder om die hele ondersoek te herhaal. Hulle verouder ook beter as ’n verskafferkategorie wat op elke hulpsbladsy iets effens anders beteken.

Laastens, hou die RFC 4787-terminologie byderhand wanneer jy dit opskryf. Om die presiese terme te gebruik kos een sin en verhoed dat die volgende leser dieselfde misdiagnose herhaal, wat die hele punt van die nota skryf is.