VPN agter NAT wat jy nie kan opstel nie: wat steeds werk

Elke tonnel-eindpunt benodig 'n adres en 'n poort wat die ander kant kan bereik, en 'n router wat jy nie administreer nie is die gewone rede waarom daardie vereiste misluk. Die interessante deel is nie dat truuks bestaan nie, maar dat elkeen afhang van 'n eienskap van 'n karteringstabel wat jy nie van die kliënt af kan sien nie. Twee van daardie eienskappe besluit byna alles: hoe 'n kartering geskep word, en of dit pakkies aanvaar van 'n adres wat die binnekant nog nooit gekontak het nie. Sorteer die omgewing volgens daardie eienskappe en die oplossings hou op om folklore te wees.

Die karteringstabel besluit alles

Netwerkadresomsetting hou 'n tabel waarin 'n interne adres en poort teenoor 'n publieke adres en poort aangeteken word. Antwoorde wat by 'n rekord pas, word terugvertaal, en 'n pakkie wat van buite aankom sonder 'n passende rekord het glad geen bestemming nie. Daardie enkele gedrag verduidelik waarom 'n luisteraar agter die router onbereikbaar is vanaf die internet. Dit verduidelik ook waarom die eerste pakkie in elke rigting van binne moet begin.

Kyk na die tabel van die router se kant af en die oplossings word duidelik: òf iets skep 'n permanente inskrywing, òf iets skep 'n tydelike een en hou dit vars, òf die verkeer neem nooit daardie pad nie. Die res van hierdie artikel is daardie drie gevalle in volgorde. Niks hier hang af van 'n verskafferfunksie verder as wat die tabel aanteken nie.

Wat die ontmoetingsdiens kan en nie kan doen nie

UDP-gatponsing gebruik die uitgaande rekord as 'n tydelike opening eerder as om die filter te verslaan. Albei eweknieë kontak 'n ontmoetingsdiens, wat elke publieke eindpunt leer en die ander kant se eindpunt terugrapporteer. Dan stuur albei na mekaar, en elke uitgaande pakkie skep of verfris die rekord wat die antwoord binneelaat. Die volgorde is wat dit laat werk, en die volgorde is ook wat dit broos maak: 'n eweknie wat stuur voordat die ander kant sy rekord geskep het, word bloot laat val, terwyl 'n herprobeerslag 'n oomblik later slaag. Die diens self dra geen VPN-verkeer nie, so sy enigste hefboom is die tydsberekening wat dit koördineer.

Karteringsgedrag besluit die res, en RFC 4787 noem die drie vorms: eindpunt-onafhanklik, adres-afhanklik, en adres-en-poort-afhanklik. Onder die laaste van dié verander die poort wat 'n eweknie moet teiken met elke bestemming, so voorspelling hou op om betroubaar te wees. Dit is waar die tegniek sy dooie punt bereik, want draerdiens-NAT en 'n streng korporatiewe firewall verwyder albei die voorspelbaarheid wat die skema nodig het, en geen mate van herprobeer bring dit terug nie.

Lewendhouers, herlaai en die eindpunt wat beweeg

'n Geponste pad is 'n vloei eerder as 'n luisteraar, so wat ook al daarbo loop, moet verandering oorleef. Dit moet die kartering lewendig hou met periodieke verkeer, agterkom wanneer die publieke eindpunt beweeg, en weer vestig nadat die router herlaai of die adres hertoegewys is. Mesh-VPN-produkte plaas daardie logika in hul eie beheervlak, terwyl 'n gewone bediener dit aan jou oorlaat. Lewendhouers help net terwyl dieselfde kartering oorleef, en hulle kos battery op 'n mobiele kliënt, daarom is 'n aggressiewe interval nie gratis nie.

'n Skootrekenaar wat 'n uur slaap, kom gewoonlik op 'n ander publieke eindpunt terug. Wat ook al die pad hervestig, moet weer van binne af loop, wat dieselfde vereiste terug op die kliënt plaas.

Drie maniere om 'n ontbrekende aanstuur te omseil

Die eerste manier vra die router om die inskrywing self te skep, via UPnP IGD, NAT-PMP of PCP, wanneer die funksie bestaan en aangeskakel is. Die tweede gee die verkeer aan 'n herleier met 'n publieke adres, wat altyd werk en altyd bandwydte plus 'n ander vertrouensgrens kos. Die derde keer die rigting om: die interne gasheer open 'n uitgaande tonnel na 'n publieke bediener en alles anders ry daarbinne.

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

'n Herleier-eindpunt maak daardie ruil sigbaar in die kliëntkonfigurasie, waar die eindpunt 'n herleier is eerder as 'n eweknie se eie adres. Aanhoudende lewendhouer hou die kartering warm, en die toegelate voorvoegsels besluit wat die kliënt daaroor mag stuur. 'n Omgekeerde tonnel vanaf die interne gasheer is dieselfde idee met 'n ander eienaar, en dit benodig glad geen NAT-verandering nie. Elkeen van die drie verwyder die inkomende vereiste sonder om 'n firewall te verslaan wat onversoekte verkeer per ontwerp blokkeer, want die verkeer begin steeds binne.

Pas die oplossing aan by wie die router besit

As jy die router administreer, is 'n statiese UDP-aanstuur makliker om te oudit as enige ponstegniek en misluk op maniere wat jy kan sien. As jy dit nie doen nie, vind uit of die verskaffer 'n herleier of 'n gehoste beheervlak bied, en of beleid die gebruik daarvan sou toelaat. As nie een beskikbaar is nie, is die oorblywende keuses 'n omgekeerde tonnel of aanvaar dat die eindpunt nie van buite bereikbaar is nie. Om aan te teken watter een jy gebruik het, maak meer saak as wat dit klink, want die opsies verskil in wie die verkeer kan waarneem en wat gebeur wanneer 'n derde party iets verander.

Let op of die pad waarmee jy geëindig het direk of herlei was, want daardie enkele feit voorspel beide latensie en foutgedrag. RFC 4787 bly die verwysing vir die karteringsgedrag onder dit alles, en om sy karteringafdeling te lees is vinniger as om drie oplossings in volgorde te toets. Die tabel gee nie om watter opsie jy gekies het nie; dit teken net aan wat die volgende pakkie mag doen.