VPN bag NAT, du ikke kan konfigurere: hvad der stadig virker

Hvert tunnelepunkt har brug for en adresse og en port, som den anden side kan nå, og en router, du ikke administrerer, er den sædvanlige grund til, at kravet ikke opfyldes. Det interessante er ikke, at der findes tricks, men at hvert af dem afhænger af en egenskab ved en mappingtabel, du ikke kan se fra klienten. To af de egenskaber afgør næsten alt: hvordan en mapping oprettes, og om den accepterer pakker fra en adresse, som indersiden aldrig har kontaktet. Sortér miljøet efter de egenskaber, og omvejene holder op med at være folklore.

Mappingtabellen afgør alt

Netværksadresseoversættelse holder en tabel, hvor en intern adresse og port står opført over for en offentlig adresse og port. Svar, der matcher en post, oversættes tilbage, og en pakke, der ankommer udefra uden en matchende post, har slet ingen destination. Den ene adfærd forklarer, hvorfor en lytter bag routeren ikke kan nås fra internettet. Den forklarer også, hvorfor den første pakke i hver retning skal komme indefra.

Se på tabellen fra routerens side, og omvejene bliver indlysende: enten opretter noget en permanent post, eller også opretter noget en midlertidig og holder den frisk, eller også tager trafikken slet ikke den vej. Resten af artiklen er de tre tilfælde i rækkefølge. Intet her afhænger af en leverandørfunktion ud over det, tabellen registrerer.

Hvad rendezvous-tjenesten kan og ikke kan

UDP-hulning bruger den udgående post som en midlertidig åbning i stedet for at besejre filteret. Begge parter kontakter en rendezvous-tjeneste, som lærer hvert offentligt endepunkt og rapporterer den anden sides endepunkt tilbage. Derefter sender begge mod hinanden, og hver udgående pakke opretter eller fornyer den post, der lukker svaret ind. Rækkefølgen er det, der får det til at virke, og rækkefølgen er også det, der gør det skrøbeligt: en part, der sender, før den anden side har oprettet sin post, bliver ganske enkelt droppet, mens et nyt forsøg et øjeblik senere lykkes. Tjenesten selv bærer ingen VPN-trafik, så dens eneste løftestang er den timing, den koordinerer.

Mappingadfærd afgør resten, og RFC 4787 navngiver de tre former: endepunktsuafhængig, adresseafhængig og adresse-og-port-afhængig. Under den sidste ændrer den port, en part skal ramme, sig med hver destination, så forudsigelse holder op med at være pålidelig. Det er her, teknikken løber ind i blindgyder, fordi carrier-grade NAT og en streng virksomhedsfirewall begge fjerner den forudsigelighed, som skemaet har brug for, og ingen mængde af nye forsøg bringer den tilbage.

Keepalives, genstarter og det endepunkt, der flytter sig

En udhulet sti er en strøm og ikke en lytter, så alt, der kører oven på den, skal overleve forandring. Den skal holde mappingen i live med periodisk trafik, bemærke når det offentlige endepunkt flytter sig, og genoprette efter routerens genstart eller når adressen tildeles på ny. Mesh VPN-produkter lægger den logik i deres egen kontrolplan, mens en almindelig server overlader det til dig. Keepalives hjælper kun, så længe den samme mapping overlever, og de koster batteri på en mobil klient, hvorfor et aggressivt interval ikke er gratis.

En bærbar computer, der sover i en time, vender normalt tilbage på et andet offentligt endepunkt. Alt, der genopretter stien, skal køre igen indefra, hvilket lægger det samme krav tilbage på klienten.

Tre veje uden om en manglende videresendelse

Den første vej beder routeren om selv at oprette posten, via UPnP IGD, NAT-PMP eller PCP, når funktionen findes og er slået til. Den anden giver trafikken til et relæ med en offentlig adresse, hvilket altid virker og altid koster båndbredde plus en anden tillidsgrænse. Den tredje vender retningen: den interne vært åbner en udgående tunnel til en offentlig server, og alt andet kører indeni den.

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

Et relæendepunkt gør den handel synlig i klientkonfigurationen, hvor endepunktet er et relæ og ikke en parts egen adresse. Vedvarende keepalive holder mappingen varm, og de tilladte præfikser afgør, hvad klienten må sende over den. En omvendt tunnel fra den interne vært er den samme idé med en anden ejer, og den kræver slet ingen NAT-ændring. Hver af de tre fjerner kravet om indgående trafik uden at besejre en firewall, der per design blokerer uopfordret trafik, fordi trafikken stadig starter indefra.

Tilpas omvejen til den, der ejer routeren

Hvis du administrerer routeren, er en statisk UDP-videresendelse lettere at revidere end ethvert hulningsskema og fejler på måder, du kan se. Hvis ikke, find ud af, om leverandøren tilbyder et relæ eller en hostet kontrolplan, og om politikken ville tillade brug af den. Hvis ingen af delene findes, er de resterende valg en omvendt tunnel eller at acceptere, at endepunktet ikke kan nås udefra. At nedskrive, hvilken du brugte, betyder mere, end det lyder, fordi valgene adskiller sig i, hvem der kan observere trafikken, og hvad der sker, når en tredjepart ændrer noget.

Bemærk, om den sti, du endte med, var direkte eller via relæ, fordi den ene kendsgerning forudsiger både latens og fejlopførsel. RFC 4787 er stadig referencen for mappingadfærden under det hele, og at læse dens afsnit om mapping er hurtigere end at teste tre omveje efter hinanden. Tabellen er ligeglad med, hvilken mulighed du valgte; den registrerer kun, hvad den næste pakke må gøre.