VPN už NAT, kurio negalite sukonfigūruoti: kas vis dar veikia

Kiekvienam tunelio galui reikia adreso ir prievado, kuriuos pasiektų kita pusė, o maršrutizatorius, kurio neadministruojate, yra įprasta priežastis, kodėl šis reikalavimas nepavyksta. Įdomu ne tai, kad triukai egzistuoja, o tai, kad kiekvienas jų priklauso nuo atvaizdavimo lentelės savybės, kurios nematote iš kliento. Dvi iš tų savybių nulemia beveik viską: kaip sukuriamas atvaizdavimas ir ar jis priima paketus iš adreso, su kuriuo vidus niekada nebuvo susisiekęs. Surikiuokite aplinką pagal šias savybes ir apeigos nustos būti folkloru.

Atvaizdavimo lentelė nulemia viską

Tinklo adresų vertimas laiko lentelę, kurioje vidinis adresas ir prievadas įrašomi prieš viešą adresą ir prievadą. Įrašą atitinkantys atsakymai verčiami atgal, o iš išorės atvykęs paketas be atitinkančio įrašo apskritai neturi paskirties vietos. Šis vienas elgesys paaiškina, kodėl už maršrutizatoriaus esantis klausytojas nepasiekiamas iš interneto. Jis taip pat paaiškina, kodėl pirmasis paketas kiekviena kryptimi turi kilti iš vidaus.

Pažiūrėkite į lentelę iš maršrutizatoriaus pusės ir apeigos tampa akivaizdžios: arba kažkas sukuria nuolatinį įrašą, arba sukuria laikiną ir palaiko jį šviežią, arba srautas niekada neina tuo keliu. Likusi straipsnio dalis yra tie trys atvejai iš eilės. Niekas čia nepriklauso nuo gamintojo funkcijos, viršijančios tai, ką fiksuoja lentelė.

Ką susitikimo tarnyba gali ir ko negali

UDP skylių prašymas naudoja išeinantį įrašą kaip laikiną angą, o ne nugali filtrą. Abi šalys susisiekia su susitikimo tarnyba, kuri sužino kiekvieną viešą galinį tašką ir praneša kitai pusei jos tašką. Tada abi siunčia viena į kitą, ir kiekvienas išeinantis paketas sukuria arba atnaujina įrašą, leidžiantį atsakymui įeiti. Tvarka yra tai, kas leidžia veikti, ir tvarka yra tai, kas daro tai trapiu: šalis, kuri siunčia anksčiau, nei kita pusė sukūrė savo įrašą, tiesiog numetama, o bandymas pakartoti po akimirkos pavyksta. Pati tarnyba neperduoda VPN srauto, todėl vienintelė jos svirtis yra laikas, kurį ji koordinuoja.

Atvaizdavimo elgesys nulemia likusią dalį, o RFC 4787 įvardija tris formas: nepriklausomą nuo galinio taško, priklausomą nuo adreso ir priklausomą nuo adreso bei prievado. Pastarojoje prievadas, į kurį šalis turi taikyti, keičiasi su kiekviena paskirties vieta, todėl prognozė nebėra patikima. Čia technika atsiduria aklavietėje, nes operatoriaus lygio NAT ir griežta įmonės užkarda abu pašalina nuspėjamumą, kurio schemai reikia, ir joks pakartojimų kiekis jo negrąžina.

Keepalive, perkrovimai ir judantis galinis taškas

Pradurtas kelias yra srautas, o ne klausytojas, todėl viskas, kas juo eina, turi atlaikyti pokyčius. Jis turi palaikyti atvaizdavimą gyvą periodiniu srautu, pastebėti, kada viešas galinis taškas pajuda, ir atsistatyti po maršrutizatoriaus perkrovimo ar adreso perskyrimo. Mesh VPN produktai tą logiką deda į savo valdymo plokštumą, o paprastas serveris palieka ją jums. Keepalive padeda tik tol, kol išlieka tas pats atvaizdavimas, ir eikvoja bateriją mobiliajame kliente, todėl agresyvus intervalas nėra nemokamas.

Valandą miegantis nešiojamasis kompiuteris paprastai grįžta kitu viešu galiniu tašku. Viskas, kas atkuria kelią, turi vėl veikti iš vidaus, o tai grąžina tą patį reikalavimą klientui.

Trys būdai apeiti trūkstamą peradresavimą

Pirmasis būdas prašo maršrutizatoriaus pačiam sukurti įrašą, per UPnP IGD, NAT-PMP arba PCP, kai funkcija yra ir įjungta. Antrasis perduoda srautą relei su viešu adresu, kuri visada veikia ir visada kainuoja pralaidumą bei kitą pasitikėjimo ribą. Trečiasis apverčia kryptį: vidinis hostas atidaro išeinantį tunelį į viešą serverį, o visa kita važiuoja jo viduje.

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

Relės galinis taškas padaro tą mainą matomą kliento konfigūracijoje, kur galinis taškas yra relė, o ne pačios šalies adresas. Nuolatinis keepalive palaiko atvaizdavimą šiltą, o leidžiami priešdėliai nulemia, ką klientas gali siųsti per jį. Atvirkštinis tunelis iš vidinio hosto yra ta pati idėja su kitu savininku, ir jam visai nereikia NAT pakeitimo. Kiekvienas iš trijų pašalina įėjimo reikalavimą nenugalėdamas užkardos, kuri pagal projektą blokuoja neprašytą srautą, nes srautas vis tiek prasideda viduje.

Pritaikykite apeigą maršrutizatoriaus savininkui

Jei administruojate maršrutizatorių, statinis UDP peradresavimas yra lengviau audituojamas nei bet kokia pradūrimo schema ir nepavyksta taip, kaip matote. Jei ne, išsiaiškinkite, ar gamintojas siūlo relę ar talpinamą valdymo plokštumą, ir ar politika leistų ja naudotis. Jei nė vieno nėra, lieka atvirkštinis tunelis arba priėmimas, kad galinis taškas neprieinamas iš išorės. Užrašyti, kurią naudojote, svarbiau, nei atrodo, nes variantai skiriasi tuo, kas gali stebėti srautą ir kas nutinka, kai trečioji šalis ką nors pakeičia.

Pažymėkite, ar kelias, kuriuo galiausiai ėjote, buvo tiesioginis, ar per relę, nes šis vienas faktas numato ir delsimą, ir gedimo elgesį. RFC 4787 tebėra atvaizdavimo elgesio po visu tuo nuoroda, o skaityti jo atvaizdavimo skyrių greičiau nei išbandyti tris apeigas iš eilės. Lentelė nekreipia dėmesio, kurį variantą pasirinkote; ji fiksuoja tik tai, ką leidžiama daryti kitam paketui.