VPN bakom ett NAT du inte kan konfigurera: vad som fortfarande fungerar

Varje tunneländpunkt behöver en adress och en port som andra sidan kan nå, och en router du inte administrerar är det vanliga skälet till att kravet inte uppfylls. Det intressanta är inte att det finns knep, utan att varje knep beror på en egenskap hos en mappningstabell som du inte ser från klienten. Två av dessa egenskaper avgör nästan allt: hur en mappning skapas, och om den accepterar paket från en adress som insidan aldrig har kontaktat. Sortera miljön efter de egenskaperna och kringgåendena slutar vara folktro.

Mappningstabellen avgör allt

Nätverksadressöversättning håller en tabell där en intern adress och port registreras mot en offentlig adress och port. Svar som matchar en post översätts tillbaka, och ett paket som kommer utifrån utan matchande post har ingen destination alls. Det enda beteendet förklarar varför en lyssnare bakom routern inte går att nå från internet. Det förklarar också varför det första paketet i varje riktning måste komma inifrån.

Titta på tabellen från routerns sida och kringgåendena blir uppenbara: antingen skapar något en permanent post, eller skapar en tillfällig och håller den färsk, eller så tar trafiken aldrig den vägen. Resten av artikeln är de tre fallen i ordning. Inget här beror på en leverantörsfunktion utöver vad tabellen registrerar.

Vad rendezvous-tjänsten kan och inte kan göra

UDP-hole punching använder den utgående posten som en tillfällig öppning i stället för att besegra filtret. Båda parterna kontaktar en rendezvous-tjänst, som lär sig varje offentlig ändpunkt och rapporterar den andra sidans ändpunkt tillbaka. Sedan skickar båda mot varandra, och varje utgående paket skapar eller förnyar posten som släpper in svaret. Ordningen är det som får det att fungera, och ordningen är också det som gör det bräckligt: en part som skickar innan den andra sidan har skapat sin post slängs helt enkelt, medan ett nytt försök en stund senare lyckas. Tjänsten själv bär ingen VPN-trafik, så dess enda hävstång är den timing den samordnar.

Mappningsbeteendet avgör resten, och RFC 4787 namnger de tre formerna: ändpunktsberoende, adressberoende och adress-och-portberoende. Under den sista ändras porten en part måste rikta in sig på med varje destination, så förutsägelsen är inte längre tillförlitlig. Där möter tekniken sina återvändsgränder, eftersom operatörsnivå-NAT och en strikt företagsbrandvägg båda tar bort den förutsägbarhet som schemat behöver, och ingen mängd nya försök får tillbaka den.

Keepalives, omstarter och ändpunkten som flyttar sig

En genomstucken väg är ett flöde och inte en lyssnare, så allt som körs ovanpå den måste överleva förändring. Det måste hålla mappningen vid liv med periodisk trafik, märka när den offentliga ändpunkten flyttar sig och återupprättas efter att routern startat om eller adressen tilldelats på nytt. Mesh VPN-produkter lägger den logiken i sin egen kontrollplan, medan en vanlig server lämnar den till dig. Keepalives hjälper bara så länge samma mappning överlever, och de kostar batteri på en mobil klient, därför är ett aggressivt intervall inte gratis.

En laptop som sover en timme kommer oftast tillbaka på en annan offentlig ändpunkt. Allt som återupprättar vägen måste köras igen inifrån, vilket lägger samma krav tillbaka på klienten.

Tre vägar runt en saknad vidarebefordran

Den första vägen ber routern skapa posten själv, via UPnP IGD, NAT-PMP eller PCP, när funktionen finns och är påslagen. Den andra lämnar trafiken till ett relä med offentlig adress, vilket alltid fungerar och alltid kostar bandbredd plus en annan förtroendegräns. Den tredje vänder riktningen: den interna värden öppnar en utgående tunnel till en offentlig server och allt annat åker inuti den.

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

En reläändpunkt gör den affären synlig i klientkonfigurationen, där ändpunkten är ett relä och inte partens egen adress. Ihållande keepalive håller mappningen varm, och de tillåtna prefixen avgör vad klienten får skicka över den. En omvänd tunnel från den interna värden är samma idé med en annan ägare, och den kräver ingen NAT-ändring alls. Var och en av de tre tar bort kravet på inkommande trafik utan att besegra en brandvägg som enligt design blockerar oönskad trafik, eftersom trafiken fortfarande börjar inifrån.

Anpassa kringgåendet till den som äger routern

Om du administrerar routern är en statisk UDP-vidarebefordran lättare att granska än vilket håltagningsschema som helst och misslyckas på sätt du ser. Om inte, ta reda på om leverantören erbjuder ett relä eller en hostad kontrollplan, och om policyn skulle tillåta användning. Om inget av det finns kvarstår en omvänd tunnel eller att acceptera att ändpunkten inte går att nå utifrån. Att anteckna vilken du använde betyder mer än det låter, eftersom alternativen skiljer sig i vem som kan observera trafiken och vad som händer när en tredje part ändrar något.

Notera om vägen du hamnade på var direkt eller via ett relä, eftersom det enda faktumet förutsäger både latens och felbeteende. RFC 4787 är fortfarande referensen för mappningsbeteendet under allt detta, och att läsa dess mappningsavsnitt är snabbare än att testa tre kringgåenden i följd. Tabellen bryr sig inte om vilket alternativ du valde; den registrerar bara vad nästa paket får göra.