VPN achter een NAT die u niet kunt configureren: wat nog werkt

Elk tunnel-eindpunt heeft een adres en een poort nodig die de andere kant kan bereiken, en de router die u niet beheert is de gebruikelijke reden dat die eis mislukt. Het interessante is niet dat er trucs bestaan, maar dat elk ervan afhangt van een eigenschap van een mappingtabel die u vanaf de client niet ziet. Twee van die eigenschappen beslissen bijna alles: hoe een mapping ontstaat, en of die pakketten accepteert van een adres waarmee de binnenkant nooit contact heeft gehad. Sorteer de omgeving op die eigenschappen en de omwegen zijn geen folklore meer.

De mappingtabel beslist alles

Network Address Translation houdt een tabel bij waarin een intern adres en een poort tegenover een openbaar adres en een poort staan. Antwoorden die bij een record passen worden terugvertaald, en een pakket dat van buiten komt zonder passend record heeft helemaal geen bestemming. Dat ene gedrag verklaart waarom een luisteraar achter de router niet vanaf internet bereikbaar is. Het verklaart ook waarom het eerste pakket in elke richting van binnenuit moet komen.

Kijk vanuit de router naar de tabel en de omwegen worden duidelijk: ofwel iets maakt een permanente vermelding, ofwel iets maakt een tijdelijke en houdt die vers, ofwel het verkeer neemt die weg nooit. De rest van dit artikel zijn die drie gevallen op volgorde. Niets hier hangt af van een leveranciersfunctie die verder gaat dan wat de tabel vastlegt.

Wat de rendezvousdienst wel en niet kan

UDP hole punching gebruikt het uitgaande record als een tijdelijke opening in plaats van het filter te verslaan. Beide peers contacteren een rendezvousdienst, die elk openbaar eindpunt leert kennen en het eindpunt van de andere kant terugmeldt. Daarna sturen beide naar elkaar toe, en elk uitgaand pakket maakt of ververst het record dat het antwoord binnenlaat. De volgorde is wat het laat werken, en de volgorde is ook wat het kwetsbaar maakt: een peer die stuurt voordat de andere kant zijn record heeft gemaakt, wordt gewoon weggegooid, terwijl een nieuwe poging even later slaagt. De dienst zelf draagt geen VPN-verkeer, dus zijn enige hefboom is de timing die hij coördineert.

Het mappinggedrag beslist de rest, en RFC 4787 noemt de drie vormen: eindpunt-onafhankelijk, adresafhankelijk en adres-en-poortafhankelijk. Bij de laatste verandert de poort die een peer moet richten met elke bestemming, zodat voorspelling niet meer betrouwbaar is. Daar loopt de techniek vast, want carrier-grade NAT en een strikte bedrijfsfirewall verwijderen beide de voorspelbaarheid die het schema nodig heeft, en geen enkele hoeveelheid nieuwe pogingen brengt die terug.

Keepalives, herstarts en het eindpunt dat beweegt

Een doorgestoken pad is een stroom en geen luisteraar, dus alles wat erop draait moet verandering overleven. Het moet de mapping levend houden met periodiek verkeer, merken wanneer het openbare eindpunt verschuift, en zich opnieuw opbouwen na een herstart van de router of een nieuwe adresuitgifte. Mesh VPN-producten stoppen die logica in hun eigen controlelaag, terwijl een gewone server het aan u overlaat. Keepalives helpen alleen zolang dezelfde mapping overleeft, en ze kosten accu op een mobiele client, daarom is een agressief interval niet gratis.

Een laptop die een uur slaapt, komt meestal terug op een ander openbaar eindpunt. Alles wat het pad herstelt, moet opnieuw van binnenuit lopen, wat dezelfde eis weer bij de client legt.

Drie manieren om een ontbrekende doorstuur te omzeilen

De eerste manier vraagt de router de vermelding zelf te maken, via UPnP IGD, NAT-PMP of PCP, wanneer de functie bestaat en aanstaat. De tweede geeft het verkeer aan een relay met een openbaar adres, wat altijd werkt en altijd bandbreedte plus een andere vertrouwensgrens kost. De derde keert de richting om: de interne host opent een uitgaande tunnel naar een openbare server en al het andere rijdt daarbinnen mee.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Een relay-eindpunt maakt die ruil zichtbaar in de clientconfiguratie, waar het eindpunt een relay is en niet het eigen adres van een peer. Permanente keepalive houdt de mapping warm, en de toegestane prefixen bepalen wat de client erover mag sturen. Een omgekeerde tunnel vanaf de interne host is hetzelfde idee met een andere eigenaar, en het vereist helemaal geen NAT-wijziging. Elk van de drie haalt de inkomende eis weg zonder een firewall te verslaan die ongevraagd verkeer van nature blokkeert, omdat het verkeer nog steeds binnen begint.

Pas de omweg aan bij wie de router bezit

Als u de router beheert, is een statische UDP-doorstuur eenvoudiger te auditen dan welk punchingschema dan ook en faalt hij op manieren die u ziet. Zo niet, zoek uit of de leverancier een relay of een gehoste controlelaag biedt, en of beleid het gebruik daarvan zou toestaan. Als geen van beide beschikbaar is, blijven een omgekeerde tunnel of het accepteren dat het eindpunt van buitenaf onbereikbaar is over. Opschrijven welke u gebruikte is belangrijker dan het klinkt, want de opties verschillen in wie het verkeer kan observeren en wat er gebeurt wanneer een derde partij iets verandert.

Let op of het pad dat u uiteindelijk had direct of via een relay was, want dat ene feit voorspelt zowel de latency als het faalgedrag. RFC 4787 blijft de referentie voor het mappinggedrag daaronder, en de mappingparagraaf lezen is sneller dan drie omwegen achter elkaar testen. De tabel kan het niet schelen welke optie u koos; hij legt alleen vast wat het volgende pakket mag doen.