VPN iza NAT-a koji ne možete konfigurisati: šta još uvijek radi

Svaka krajnja tačka tunela treba adresu i port do kojih druga strana može doći, a ruter kojim ne upravljate uobičajen je razlog zašto taj zahtjev propada. Zanimljiv dio nije to što trikovi postoje, nego to što svaki ovisi o svojstvu tablice mapiranja koju ne vidite s klijenta. Dva od tih svojstava odlučuju gotovo o svemu: kako se mapiranje stvara i da li prihvata pakete s adrese s kojom unutrašnjost nikada nije komunicirala. Razvrstajte okruženje po tim svojstvima i zaobilazna rješenja prestaju biti folklor.

Tablica mapiranja odlučuje o svemu

Prevođenje mrežnih adresa drži tablicu u kojoj se unutrašnja adresa i port bilježe prema javnoj adresi i portu. Odgovori koji se podudaraju sa zapisom prevode se natrag, a paket koji dolazi izvana bez odgovarajućeg zapisa nema nikakvo odredište. To jedno ponašanje objašnjava zašto slušalac iza rutera nije dostupan s interneta. Također objašnjava zašto prvi paket u svakom smjeru mora nastati unutra.

Pogledajte tablicu s ruterove strane i zaobilazna rješenja postaju očigledna: ili nešto stvara trajni zapis, ili stvara privremeni i održava ga svježim, ili promet nikada ne ide tim putem. Ostatak ovog članka su ta tri slučaja redom. Ništa ovdje ne ovisi o značajci dobavljača izvan onoga što tablica bilježi.

Šta rendezvous servis može, a šta ne može

UDP probijanje rupa koristi izlazni zapis kao privremeni otvor umjesto da porazi filter. Oba partnera kontaktiraju rendezvous servis, koji sazna svaku javnu krajnju tačku i vraća drugoj strani njenu tačku. Zatim oba šalju jedno prema drugom, i svaki izlazni paket stvara ili osvježava zapis koji pušta odgovor unutra. Redoslijed je ono što ga čini funkcionalnim, a redoslijed je i ono što ga čini krhkim: partner koji pošalje prije nego što je druga strana stvorila svoj zapis jednostavno se odbacuje, dok ponovni pokušaj trenutak kasnije uspijeva. Sam servis ne nosi VPN promet, pa je njegov jedini utjecaj vrijeme koje koordinira.

Ponašanje mapiranja odlučuje o ostatku, a RFC 4787 imenuje tri oblika: neovisno o krajnjoj tački, ovisno o adresi i ovisno o adresi i portu. Kod posljednjeg se port koji partner mora ciljati mijenja sa svakim odredištem, pa predviđanje prestaje biti pouzdano. Tu tehnika dolazi do ćorsokaka, jer telekomunikacijski NAT i strogi korporativni firewall zajedno uklanjaju predvidljivost koju shema treba, i nikakvo ponavljanje je ne vraća.

Keepalive, restartovanja i krajnja tačka koja se pomjera

Probijena staza je tok, a ne slušalac, pa sve što radi iznad nje mora preživjeti promjenu. Mora održavati mapiranje živim periodičnim prometom, primijetiti kada se javna krajnja tačka pomjeri i ponovo se uspostaviti nakon restartovanja rutera ili dodjele nove adrese. Mesh VPN proizvodi tu logiku stavljaju u svoju kontrolnu ravan, dok običan server to ostavlja vama. Keepalive pomažu samo dok isto mapiranje preživi, a troše bateriju na mobilnom klijentu, zbog čega agresivan interval nije besplatan.

Laptop koji spava sat vremena obično se vraća na drugu javnu krajnju tačku. Sve što ponovo uspostavlja stazu mora ponovo raditi iznutra, što vraća isti zahtjev na klijenta.

Tri načina oko nedostajućeg prosljeđivanja

Prvi način traži od rutera da sam stvori zapis, kroz UPnP IGD, NAT-PMP ili PCP, kada značajka postoji i uključena je. Drugi predaje promet releju s javnom adresom, što uvijek radi i uvijek košta propusnost plus drugačiju granicu povjerenja. Treći okreće smjer: unutrašnji host otvara izlazni tunel prema javnom serveru i sve ostalo se vozi unutar njega.

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

Krajnja tačka releja čini tu razmjenu vidljivom u konfiguraciji klijenta, gdje je krajnja tačka relej, a ne vlastita adresa partnera. Trajni keepalive održava mapiranje toplim, a dopušteni prefiksi odlučuju šta klijent smije slati preko njega. Obrnuti tunel s unutrašnjeg hosta ista je ideja s drugim vlasnikom i ne treba nikakvu promjenu NAT-a. Svaki od tri uklanja dolazni zahtjev bez poraza firewalla koji po dizajnu blokira neželjeni promet, jer promet ipak počinje unutra.

Uskladite zaobilazno rješenje s onim ko posjeduje ruter

Ako upravljate ruterom, statično UDP prosljeđivanje lakše je revidirati od bilo koje sheme probijanja i pada na načine koje vidite. Ako ne, saznajte nudi li dobavljač relej ili hostovanu kontrolnu ravan i dopušta li politika njihovo korištenje. Ako nijedno nije dostupno, preostaju obrnuti tunel ili prihvatanje da krajnja tačka nije dostupna izvana. Bilježenje toga koji ste koristili važnije je nego što zvuči, jer se opcije razlikuju po tome ko može promatrati promet i šta se dogodi kada treća strana nešto promijeni.

Zabilježite je li staza do koje ste došli bila direktna ili preko releja, jer ta jedna činjenica predviđa i latenciju i ponašanje pri kvaru. RFC 4787 ostaje referenca za ponašanje mapiranja ispod svega toga, a čitanje njegovog odjeljka o mapiranju brže je od uzastopnog testiranja tri zaobilazna rješenja. Tablicu nije briga koju ste opciju odabrali; ona bilježi samo šta sljedeći paket smije raditi.