VPN bak NAT du ikke kan konfigurere: hva som fortsatt virker

Hvert tunellendepunkt trenger en adresse og en port som den andre siden kan nå, og en ruter du ikke administrerer er den vanlige grunnen til at kravet ikke oppfylles. Det interessante er ikke at det finnes triks, men at hvert av dem avhenger av en egenskap ved en mappingtabell du ikke ser fra klienten. To av disse egenskapene avgjør nesten alt: hvordan en mapping opprettes, og om den godtar pakker fra en adresse innsiden aldri har kontaktet. Sorter miljøet etter disse egenskapene, og omveiene slutter å være folkeminne.

Mappingtabellen avgjør alt

Network Address Translation holder en tabell der en intern adresse og port føres opp mot en offentlig adresse og port. Svar som samsvarer med en oppføring oversettes tilbake, og en pakke som kommer utenfra uten samsvarende oppføring har ingen destinasjon i det hele tatt. Den ene atferden forklarer hvorfor en lytter bak ruteren ikke kan nås fra internett. Den forklarer også hvorfor den første pakken i hver retning må komme innenfra.

Se på tabellen fra ruterens side, og omveiene blir åpenbare: enten oppretter noe en permanent oppføring, eller noe oppretter en midlertidig og holder den fersk, eller trafikken tar aldri den veien. Resten av artikkelen er disse tre tilfellene i rekkefølge. Ingenting her avhenger av en leverandørfunksjon utover det tabellen registrerer.

Hva rendezvous-tjenesten kan og ikke kan gjøre

UDP-hulaking bruker den utgående oppføringen som en midlertidig åpning i stedet for å beseire filteret. Begge partene kontakter en rendezvous-tjeneste, som lærer hvert offentlige endepunkt og rapporterer den andre sidens endepunkt tilbake. Deretter sender begge mot hverandre, og hver utgående pakke oppretter eller fornyer oppføringen som slipper svaret inn. Rekkefølgen er det som får det til å virke, og rekkefølgen er også det som gjør det skjørt: en part som sender før den andre siden har opprettet oppføringen sin, blir ganske enkelt droppet, mens et nytt forsøk et øyeblikk senere lykkes. Tjenesten selv bærer ingen VPN-trafikk, så dens eneste innflytelse er timingen den koordinerer.

Mappingatferd avgjør resten, og RFC 4787 navngir de tre formene: endepunktsuavhengig, adresseavhengig og adresse-og-portavhengig. Under den siste endres porten en part må sikte på med hver destinasjon, så prediksjon slutter å være pålitelig. Der møter teknikken sine blindveier, fordi carrier-grade NAT og en streng bedriftsbrannmur begge fjerner forutsigbarheten ordningen trenger, og ingen mengde nye forsøk bringer den tilbake.

Keepalives, omstarter og endepunktet som flytter seg

En utstukket vei er en strøm og ikke en lytter, så alt som kjører oppå den må tåle endring. Den må holde mappingen i live med periodisk trafikk, merke når det offentlige endepunktet flytter seg, og gjenopprette etter at ruteren starter på nytt eller adressen tildeles på nytt. Mesh VPN-produkter legger den logikken i sitt eget kontrollplan, mens en vanlig server overlater det til deg. Keepalives hjelper bare så lenge den samme mappingen overlever, og de koster batteri på en mobil klient, derfor er et aggressivt intervall ikke gratis.

En laptop som sover i en time kommer vanligvis tilbake på et annet offentlig endepunkt. Alt som gjenoppretter veien må kjøre på nytt innenfra, noe som legger det samme kravet tilbake på klienten.

Tre veier rundt en manglende videresending

Den første veien ber ruteren opprette oppføringen selv, via UPnP IGD, NAT-PMP eller PCP, når funksjonen finnes og er slått på. Den andre overlater trafikken til et relé med offentlig adresse, som alltid virker og alltid koster båndbredde pluss en annen tillitsgrense. Den tredje snur retningen: den interne verten åpner en utgående tunnel til en offentlig server, og alt annet kjører inni den.

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

Et reléendepunkt gjør den handelen synlig i klientkonfigurasjonen, der endepunktet er et relé og ikke partens egen adresse. Vedvarende keepalive holder mappingen varm, og de tillatte prefiksene avgjør hva klienten kan sende over den. En omvendt tunnel fra den interne verten er den samme ideen med en annen eier, og den krever ingen NAT-endring i det hele tatt. Hver av de tre fjerner kravet om innkommende trafikk uten å beseire en brannmur som blokkerer uanmodet trafikk av design, fordi trafikken fortsatt starter innenfra.

Tilpass omveien til den som eier ruteren

Hvis du administrerer ruteren, er en statisk UDP-videresending enklere å revidere enn enhver hulakingsordning, og den feiler på måter du ser. Hvis ikke, finn ut om leverandøren tilbyr et relé eller et hostet kontrollplan, og om policyen ville tillate bruk av det. Hvis ingen av delene er tilgjengelig, er de gjenværende valgene en omvendt tunnel eller å akseptere at endepunktet ikke kan nås utenfra. Å notere hvilken du brukte betyr mer enn det høres ut som, fordi valgene skiller seg i hvem som kan observere trafikken og hva som skjer når en tredjepart endrer noe.

Legg merke til om veien du endte med var direkte eller via et relé, fordi dette ene faktumet forutsier både latens og feilatferd. RFC 4787 er fortsatt referansen for mappingatferden under alt dette, og å lese mappingavsnittet er raskere enn å teste tre omveier etter hverandre. Tabellen bryr seg ikke om hvilket alternativ du valgte; den registrerer bare hva den neste pakken har lov til å gjøre.