VPN NAT-i taga, mida te ei saa seadistada: mis ikka töötab

Iga tunnelipunkt vajab aadressi ja porti, kuhu teine pool pääseb, ja ruuter, mida te ei halda, on tavaline põhjus, miks see nõue ei täitu. Huvitav ei ole see, et trikid olemas on, vaid see, et igaüks neist sõltub vastendustabeli omadusest, mida te kliendist ei näe. Kaks neist omadustest otsustavad peaaegu kõik: kuidas vastendus tekib ja kas see võtab vastu pakette aadressilt, millega sisemus pole kunagi ühendust võtnud. Järjestage keskkond nende omaduste järgi ja möödukahendid lakkavad olemast rahvaluule.

Vastendustabel otsustab kõik

Võrguaadresside tõlkimine peab tabelit, kus sisemine aadress ja port on kirjas avaliku aadressi ja pordi vastas. Kirjega sobivad vastused tõlgitakse tagasi, ja väljast saabunud paketil, millel pole sobivat kirjet, pole üldse sihtkohta. See üks käitumine selgitab, miks ruuteri taga olev kuulaja on internetist kättesaamatu. See selgitab ka, miks esimene pakett kummaski suunas peab pärinema seestpoolt.

Vaadake tabelit ruuteri poolt ja möödukahendid muutuvad ilmselgeks: kas miski loob püsiva kirje, või loob ajutise ja hoiab seda värskena, või liiklus ei lähegi seda teed. Ülejäänud artikkel on need kolm juhtumit järjekorras. Miski siin ei sõltu müüja funktsioonist peale selle, mida tabel kirja paneb.

Mida kohtumisteenus suudab ja mida mitte

UDP-aukude löömine kasutab väljuvat kirjet ajutise avausena, selle asemel et filtrit võita. Mõlemad partnerid võtavad ühendust kohtumisteenusega, mis saab teada iga avaliku lõpp-punkti ja teatab teisele poolele tema lõpp-punkti. Seejärel saadavad mõlemad teineteise suunas ja iga väljuv pakett loob või värskendab kirjet, mis laseb vastuse sisse. Järjekord on see, mis paneb selle tööle, ja järjekord on ka see, mis teeb selle hapraks: partner, kes saadab enne, kui teine pool on oma kirje loonud, lihtsalt visatakse kõrvale, samas kui katse hetk hiljem õnnestub. Teenus ise ei kanna VPN-liiklust, seega on selle ainus hoob ajastus, mida ta koordineerib.

Vastenduskäitumine otsustab ülejäänu, ja RFC 4787 nimetab kolm kuju: lõpp-punktist sõltumatu, aadressist sõltuv ning aadressist ja pordist sõltuv. Viimase puhul muutub port, mida partner peab sihtima, iga sihtkohaga, nii et prognoosimine ei ole enam usaldusväärne. Seal jõuab tehnika tupikuni, sest operaatori tasandi NAT ja range ettevõtte tulemüür kõrvaldavad mõlemad selle etteaimatavuse, mida skeem vajab, ja ükski korduskatsete hulk ei too seda tagasi.

Keepalive'id, taaskäivitused ja lõpp-punkt, mis liigub

Läbi löödud tee on voog, mitte kuulaja, seega peab kõik selle peal jooksev muutusele vastu pidama. See peab hoidma vastendust elus perioodilise liiklusega, märkama, millal avalik lõpp-punkt liigub, ja taastuma pärast ruuteri taaskäivitust või aadressi ümberjagamist. Mesh-VPN tooted panevad selle loogika oma juhtimistasandile, samas kui tavaline server jätab selle teie hooleks. Keepalive'id aitavad ainult seni, kuni sama vastendus püsib, ja need kulutavad mobiilsel kliendil akut, mistõttu agressiivne intervall ei ole tasuta.

Sülearvuti, mis magab tund aega, naaseb tavaliselt teise avaliku lõpp-punkti peale. Kõik, mis tee taastab, peab uuesti seestpoolt tööle hakkama, mis paneb sama nõude tagasi kliendile.

Kolm moodust puuduva suunamise vältimiseks

Esimene moodus palub ruuteril kirje ise luua, UPnP IGD, NAT-PMP või PCP kaudu, kui funktsioon on olemas ja sisse lülitatud. Teine annab liikluse üle avaliku aadressiga releele, mis töötab alati ja maksab alati ribalaiust pluss teistsugust usalduspiiri. Kolmas pöörab suuna ümber: sisemine host avab väljuva tunneli avaliku serverini ja kõik muu sõidab selle sees.

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

Relee lõpp-punkt teeb selle vahetuse kliendi seadistuses nähtavaks, kus lõpp-punkt on relee, mitte partneri enda aadress. Püsiv keepalive hoiab vastenduse soojana ja lubatud prefiksid otsustavad, mida klient sealtkaudu saata tohib. Pöördtunnel sisemisest hostist on sama idee teise omanikuga ja see ei vaja üldse NAT-i muutmist. Iga kolmest eemaldab sissetuleva nõude, ilma et võidaks tulemüüri, mis blokeerib soovimatu liikluse projekti järgi, sest liiklus algab ikka seestpoolt.

Sobitage möödukahend sellega, kellele ruuter kuulub

Kui te ruuterit haldate, on staatiline UDP-suunamine lihtsamini auditeeritav kui ükski aukude löömise skeem ja see ebaõnnestub viisil, mida te näete. Kui ei, uurige, kas müüja pakub releed või majutatud juhtimistasandit, ja kas poliitika lubaks seda kasutada. Kui kumbagi pole, jäävad valikusse pöördtunnel või leppimine sellega, et lõpp-punkt ei ole väljast kättesaadav. Kirja panemine, millist te kasutasite, on tähtsam, kui see kõlab, sest valikud erinevad selle poolest, kes saab liiklust jälgida ja mis juhtub, kui kolmas osapool midagi muudab.

Pange tähele, kas tee, milleni jõudsite, oli otsene või relee kaudu, sest see üks fakt ennustab nii latentsust kui ka rikke käitumist. RFC 4787 jääb selle kõige all oleva vastenduskäitumise viiteks ja selle vastenduspeatüki lugemine on kiirem kui kolme möödukahendi järjestikune katsetamine. Tabelit ei huvita, millise valiku te tegite; see registreerib vaid, mida järgmisel paketil on lubatud teha.