VPN bak NAT du ikkje kan konfigurere: kva som framleis verkar

Kvart tunellendepunkt treng ei adresse og ein port som den andre sida kan nå, og ein ruter du ikkje administrerer er den vanlege grunnen til at kravet ikkje blir oppfylt. Det interessante er ikkje at det finst triks, men at kvart av dei avheng av ein eigenskap ved ein mappingtabell du ikkje ser frå klienten. To av desse eigenskapane avgjer nesten alt: korleis ein mapping blir oppretta, og om han godtek pakkar frå ei adresse innsida aldri har kontakta. Sorter miljøet etter desse eigenskapane, og omvegane sluttar å vere folkeminne.

Mappingtabellen avgjer alt

Network Address Translation held ein tabell der ei intern adresse og ein port blir førde opp mot ei offentleg adresse og ein port. Svar som samsvarer med ei oppføring blir omsette tilbake, og ein pakke som kjem utanfrå utan samsvarande oppføring har ingen destinasjon i det heile. Den eine åtferda forklarer kvifor ein lyttar bak ruteren ikkje kan nåast frå internett. Ho forklarer også kvifor den første pakken i kvar retning må kome innanfrå.

Sjå på tabellen frå rutarsida, og omvegane blir openberre: anten opprettar noko ei permanent oppføring, eller noko opprettar ei mellombels og held ho fersk, eller trafikken tek aldri den vegen. Resten av artikkelen er desse tre tilfella i rekkjefølgje. Ingenting her avheng av ein leverandørfunksjon utover det tabellen registrerer.

Kva rendezvous-tenesta kan og ikkje kan gjere

UDP-holtaking brukar den utgåande oppføringa som ei mellombels opning i staden for å beseire filteret. Begge partane kontaktar ei rendezvous-teneste, som lærer kvar offentleg endepunkt og rapporterer endepunktet til den andre sida tilbake. Deretter sender begge mot kvarandre, og kvar utgåande pakke opprettar eller fornyar oppføringa som slepp svaret inn. Rekkjefølgja er det som får det til å verke, og rekkjefølgja er også det som gjer det skjørt: ein part som sender før den andre sida har oppretta oppføringa si, blir rett og slett droppa, medan eit nytt forsøk eit augneblink seinare lukkast. Tenesta sjølv ber ingen VPN-trafikk, så den einaste innverknaden hennar er timinga ho koordinerer.

Mappingåtferd avgjer resten, og RFC 4787 namngir dei tre formene: endepunktsuavhengig, adresseavhengig og adresse-og-portavhengig. Under den siste endrar porten ein part må sikte på seg med kvar destinasjon, så prediksjon sluttar å vere påliteleg. Der møter teknikken blindvegane sine, fordi carrier-grade NAT og ein streng bedriftsbrannmur begge fjernar føreseielegheita ordninga treng, og inga mengd nye forsøk bringer ho tilbake.

Keepalives, omstartar og endepunktet som flyttar seg

Ein utstukken veg er ein straum og ikkje ein lyttar, så alt som køyrer oppå han må tole endring. Han må halde mappingen i live med periodisk trafikk, merke når det offentlege endepunktet flyttar seg, og gjenopprette etter at ruteren startar på nytt eller adressa blir tildelt på nytt. Mesh VPN-produkt legg den logikken i sitt eige kontrollplan, medan ein vanleg tenar overlèt det til deg. Keepalives hjelper berre så lenge den same mappingen overlever, og dei kostar batteri på ein mobil klient, difor er eit aggressivt intervall ikkje gratis.

Ein laptop som søv i ein time kjem vanlegvis tilbake på eit anna offentleg endepunkt. Alt som gjenopprettar vegen må køyre på nytt innanfrå, noko som legg det same kravet tilbake på klienten.

Tre vegar rundt ei manglande videresending

Den første vegen ber ruteren opprette oppføringa sjølv, via UPnP IGD, NAT-PMP eller PCP, når funksjonen finst og er slått på. Den andre overlèt trafikken til eit relé med offentleg adresse, som alltid verkar og alltid kostar bandbreidd pluss ei anna tillitsgrense. Den tredje snur retninga: den interne verten opnar ein utgåande tunnel til ein offentleg tenar, og alt anna køyrer inni han.

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

Eit reléendepunkt gjer den handelen synleg i klientkonfigurasjonen, der endepunktet er eit relé og ikkje partens eiga adresse. Varig keepalive held mappingen varm, og dei tillatne prefiksa avgjer kva klienten kan sende over han. Ein omvendt tunnel frå den interne verten er den same ideen med ein annan eigar, og han krev inga NAT-endring i det heile. Kvar av dei tre fjernar kravet om innkomande trafikk utan å beseire ein brannmur som blokkerer uoppmoda trafikk av design, fordi trafikken framleis startar innanfrå.

Tilpass omvegen til den som eig ruteren

Dersom du administrerer ruteren, er ei statisk UDP-videresending enklare å revidere enn kva holtakingsordning som helst, og ho feilar på måtar du ser. Dersom ikkje, finn ut om leverandøren tilbyr eit relé eller eit hosta kontrollplan, og om policyen ville tillate bruk av det. Om ingen av delane er tilgjengelege, er dei gjenverande vala ein omvendt tunnel eller å godta at endepunktet ikkje kan nåast utanfrå. Å notere kva du brukte tyder meir enn det høyrest ut som, fordi vala skil seg i kven som kan observere trafikken og kva som skjer når ein tredjepart endrar noko.

Legg merke til om vegen du enda med var direkte eller via eit relé, fordi dette eine faktumet føresei både latens og feilåtferd. RFC 4787 er framleis referansen for mappingåtferda under alt dette, og å lese mappingavsnittet er raskare enn å teste tre omvegar etter kvarandre. Tabellen bryr seg ikkje om kva alternativ du valde; han registrerer berre kva den neste pakken har lov til å gjere.