Symmetrisk NAT och VPN: mät mappningen, inte etiketten

En supporttråd slutar med domen ”symmetrisk NAT, VPN kommer inte att fungera här”, och därefter installeras klienten om tre gånger utan anledning. Etiketten gör skada eftersom den svarar på en fråga som ingen ställde. En klient som ansluter utåt till en fast server skapar en mappning i samma stund som den skickar det första paketet, och svaret släpps tillbaka enligt regler som nästan varje nätverk implementerar. Det som mappning beroende av ändpunkten verkligen komplicerar är två peers som försöker nå varandra samtidigt, och det är ett annat test.

Två frågor gömmer sig bakom en etikett

Den första frågan är om en värd bakom det här nätverket kan öppna en session mot en känd offentlig adress och port. För en tunnelklient är det det normala fallet, och svaret är nästan alltid ja. Routern registrerar den interna källan, tilldelar en extern port och släpper igenom svaret eftersom det hör till en session som startade inifrån.

Den andra frågan är om två värdar bakom olika nätverk kan hitta en gemensam väg och skicka till varandra utan en server i mitten. Det beror på hur varje nätverk tilldelar de externa portarna, och det är den enda platsen där mappningens beteende spelar roll.

Att blanda de två ger den klassiska feldiagnosen: en peer-till-peer-funktion misslyckas, någon kör ett NAT-typtest, ser den sämsta kategorin och drar slutsatsen att den vanliga tunneln inte heller kan fungera. Tunneln var aldrig det som misslyckades.

Mappning och filtrering är två skilda egenskaper

RFC-terminologin är mer exakt än de namn leverantörerna använder, och den är värd att ta med i biljetten eftersom den avgör diskussioner. Mappning är hur den externa porten tilldelas. Filtrering är vilka inkommande paket som släpps igenom. Ett nätverk kan vara strikt i det ena och liberalt i det andra, och den kombinationen är vad ett peer-till-peer-protokoll måste överleva.

Den tredje raden är vad de flesta konsumentroutrar och mobiloperatörer menar med symmetrisk. Notera att etiketten bara beskriver tilldelningen. Ett nätverk med den mappningen och liberal filtrering kan fortfarande ta emot inkommande paket till porten det just tilldelade, och därför lyckas hålslagning på vissa och misslyckas på andra.

Filtrering har sina egna tre fall och sitt eget namn för varje. Att skriva ”symmetrisk NAT” i en biljett när man menar ”adress- och portberoende filtrering” skickar nästa person till fel kapitel i handboken. De två beter sig olika i test, så felet är inte akademiskt.

Mät mappningen i stället för att namnge den

Du kan observera den tilldelade porten direkt från serversidan av vilken UDP-tjänst du än kontrollerar. Starta en fångst på den offentliga värden, skicka från klienten och läs den källport paketet kom med:

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

Ändpunktsraden är den mest användbara av de tre, eftersom WireGuard registrerar den senaste adressen och porten den tog emot från varje peer. Jämför den porten med den som klienten tror att den använder. De kommer att skilja sig varje gång någon översättning sker, och den viktiga frågan är om värdet förblir stabilt.

Upprepa observationen mot en andra destinationsport eller en andra server och jämför igen. Om den externa porten ändras per destination är mappningen adress- och portberoende. Om den förblir densamma ger nätverket dig en enda mappning och upptäckt har en chans.

STUN-baserade verktyg rapporterar samma klassificering i ett steg, och de går bra att använda när nätverket tillåter utgående UDP till en offentlig STUN-server. När det inte gör det fungerar fångstmetoden ovan fortfarande och kräver inget annat än en värd du redan kontrollerar.

Välj en åtgärd som passar felet

Om funktionen som misslyckas är peer-till-peer är de stödda svaren en relay, en mötestjänst som båda peers kan nå, eller en annan topologi. TURN finns just för detta, och en produkt som levererar sin egen relay talar om att den förväntar sig att vissa nätverk är fientliga.

Om funktionen som misslyckas är en vanlig tunnel är mappningens beteende inte ditt problem och inget av det ovan gäller. Kontrollera att klienten faktiskt skickar, att servern ser paketet och att svaret kommer tillbaka. Den sekvensen är tre observationer och den kräver ingen kunskap om routerns NAT-kategori.

Det som inte fungerar är att sprida lokala portändringar tills något ansluter. Att ändra klientens källport ändrar inte hur nätverket tilldelar mappningar. En tillfällig framgång på femte försöket är en falsk positiv, och den kommer att citeras som åtgärd i månader.

Registrera arkitekturen, inte domen

En användbar anteckning säger vilket protokoll, i vilken riktning sessionen börjar, om det finns en relay på vägen och vad som observerades på ledningen. ”symmetrisk NAT, fungerar inte” är oanvändbart, eftersom det samtidigt är fel om tunneln och intetsägande om peer-vägen.

Ta med den uppmätta portstabiliteten och filtreringsbeteendet om du testade dem. Dessa två fakta låter någon annan förutsäga om en ny funktion kommer att fungera i det nätverket utan att upprepa hela utredningen. De åldras också bättre än en leverantörskategori som betyder något lite olika på varje hjälpsida.

Till sist bör du ha RFC 4787-terminologin till hands när du skriver ner det. Att använda de exakta termerna kostar en mening och hindrar nästa läsare från att upprepa samma feldiagnos, och det är hela poängen med att skriva anteckningen.