Symmetrische NAT en VPN’s: meet de mapping, niet het label

Een supportthread eindigt met het oordeel „symmetrische NAT, de VPN zal hier niet werken”, en daarna wordt de client drie keer zonder reden opnieuw geïnstalleerd. Het label richt schade aan omdat het een vraag beantwoordt die niemand stelde. Een client die naar buiten verbindt met een vaste server, maakt een mapping aan op het moment dat hij het eerste pakket verstuurt, en het antwoord mag terug onder regels die bijna elk netwerk implementeert. Wat mapping die van het eindpunt afhangt echt ingewikkeld maakt, zijn twee peers die tegelijk elkaar proberen te bereiken, en dat is een andere test.

Twee vragen verschuilen zich achter één label

De eerste vraag is of een host achter dit netwerk een sessie kan openen naar een bekend openbaar adres en een poort. Voor een tunnelclient is dat het normale geval, en het antwoord is bijna altijd ja. De router registreert de interne bron, wijst een externe poort toe en laat het antwoord door omdat het bij een sessie hoort die van binnenuit begon.

De tweede vraag is of twee hosts achter verschillende netwerken een gedeeld pad kunnen vinden en naar elkaar kunnen sturen zonder een server ertussen. Dat hangt af van hoe elk netwerk die externe poorten toewijst, en alleen daar is het gedrag van de mapping van belang.

De twee verwarren levert de klassieke verkeerde diagnose op: een peer-to-peerfunctie faalt, iemand draait een NAT-typetest, ziet de slechtste categorie en concludeert dat de gewone tunnel ook niet kan werken. De tunnel was nooit wat faalde.

Mapping en filtering zijn aparte eigenschappen

De RFC-terminologie is preciezer dan de namen die leveranciers gebruiken, en het loont die in de ticket te zetten omdat ze discussies beslecht. Mapping is hoe de externe poort wordt toegewezen. Filtering is welke inkomende pakketten worden doorgelaten. Een netwerk kan streng zijn in het ene en ruim in het andere, en die combinatie is wat een peer-to-peerprotocol moet overleven.

De derde rij is wat de meeste consumentenrouters en mobiele operators met symmetrisch bedoelen. Merk op dat het label alleen de toewijzing beschrijft. Een netwerk met die mapping en ruime filtering kan nog steeds inkomende pakketten naar de poort aannemen die het net heeft toegewezen, en daarom lukt hole punching bij sommige wel en bij andere niet.

Filtering heeft zijn eigen drie gevallen en zijn eigen naam voor elk. „symmetrische NAT” in een ticket schrijven terwijl je „adres- en poortafhankelijke filtering” bedoelt, stuurt de volgende persoon naar het verkeerde hoofdstuk van de handleiding. De twee gedragen zich anders in de test, dus de fout is niet academisch.

Meet de mapping in plaats van haar te benoemen

Je kunt de toegewezen poort rechtstreeks vanaf de serverkant van elke UDP-dienst die je beheert observeren. Start een opname op de openbare host, stuur vanaf de client en lees de bronpoort waarmee het pakket aankwam:

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

De eindpuntregel is de nuttigste van de drie, omdat WireGuard het laatste adres en de laatste poort vastlegt die het van elke peer ontving. Vergelijk die poort met degene waarvan de client denkt dat hij hem gebruikt. Ze zullen verschillen telkens wanneer er enige vertaling plaatsvindt, en de belangrijke vraag is of de waarde stabiel blijft.

Herhaal de observatie tegen een tweede bestemmingspoort of een tweede server en vergelijk opnieuw. Als de externe poort per bestemming verandert, is de mapping adres- en poortafhankelijk. Als hij gelijk blijft, geeft het netwerk je één mapping en maakt ontdekking kans.

STUN-gebaseerde tools rapporteren dezelfde classificatie in één stap, en ze zijn prima te gebruiken wanneer het netwerk uitgaand UDP naar een openbare STUN-server toestaat. Wanneer dat niet zo is, werkt de opnamemethode hierboven nog steeds en vereist niets anders dan een host die je al beheert.

Kies een oplossing die bij het falen past

Als de falende functie peer-to-peer is, zijn de ondersteunde antwoorden een relay, een ontmoetingsdienst die beide peers kunnen bereiken, of een andere topologie. TURN bestaat precies hiervoor, en een product dat zijn eigen relay meelevert, vertelt je dat het verwacht dat sommige netwerken vijandig zijn.

Als de falende functie een gewone tunnel is, is het gedrag van de mapping niet jouw probleem en geldt niets van het bovenstaande. Controleer of de client echt verstuurt, of de server het pakket ziet en of het antwoord terugkomt. Die volgorde is drie observaties en vereist geen kennis van de NAT-categorie van de router.

Wat niet werkt, is lokale poortwijzigingen strooien tot er iets verbindt. De bronpoort van de client wijzigen verandert niet hoe het netwerk mappings toewijst. Een toevallig succes bij de vijfde poging is een fout-positief, en het zal maandenlang als oplossing worden geciteerd.

Leg de architectuur vast, niet het oordeel

Een bruikbare notitie zegt welk protocol, in welke richting de sessie begint, of er een relay in het pad zit en wat er op de lijn is waargenomen. „symmetrische NAT, werkt niet” is onbruikbaar, omdat het tegelijk onjuist is over de tunnel en niets zegt over het pad van de peer.

Neem de gemeten poortstabiliteit en het filtergedrag op als je die hebt getest. Die twee feiten laten iemand anders voorspellen of een nieuwe functie op dat netwerk werkt zonder het hele onderzoek te herhalen. Ze verouderen ook beter dan een leverancierscategorie die op elke hulppagina iets net anders betekent.

Houd ten slotte de RFC 4787-terminologie bij de hand wanneer je dit opschrijft. De precieze termen gebruiken kost één zin en voorkomt dat de volgende lezer dezelfde verkeerde diagnose herhaalt, en dat is het hele punt van het schrijven van de notitie.