VPN aiz NAT, ko nevarat konfigurēt: kas joprojām darbojas

Katram tuneļa galam ir vajadzīga adrese un ports, ko otra puse var sasniegt, un maršrutētājs, ko jūs nepārvaldāt, ir parastais iemesls, kāpēc šī prasība neizpildās. Interesanti nav tas, ka pastāv triki, bet gan tas, ka katrs no tiem ir atkarīgs no kartēšanas tabulas īpašības, ko jūs neredzat no klienta. Divas no šīm īpašībām nosaka gandrīz visu: kā kartēšana tiek izveidota un vai tā pieņem paketes no adreses, ar kuru iekšpuse nekad nav sazinājusies. Sakārtojiet vidi pēc šīm īpašībām, un apiešanas risinājumi pārstāj būt folklora.

Kartēšanas tabula nosaka visu

Tīkla adrešu tulkošana uztur tabulu, kurā iekšējā adrese un ports tiek ierakstīti pret publisko adresi un portu. Atbildes, kas atbilst ierakstam, tiek tulkotas atpakaļ, un paketam, kas ierodas no ārpuses bez atbilstoša ieraksta, vispār nav galamērķa. Šī vienīgā uzvedība izskaidro, kāpēc klausītājs aiz maršrutētāja nav sasniedzams no interneta. Tā arī izskaidro, kāpēc pirmajam paketam katrā virzienā jānāk no iekšpuses.

Paskatieties uz tabulu no maršrutētāja puses, un apiešanas risinājumi kļūst acīmredzami: vai nu kaut kas izveido pastāvīgu ierakstu, vai izveido pagaidu un uztur to svaigu, vai arī trafiks nekad neiet šo ceļu. Pārējais raksts ir šie trīs gadījumi pēc kārtas. Nekas šeit nav atkarīgs no ražotāja funkcijas, kas pārsniedz to, ko tabula fiksē.

Ko satikšanās pakalpojums var un ko nevar

UDP caurumu izduršana izmanto izejošo ierakstu kā pagaidu atvērumu, nevis uzvar filtru. Abas puses sazinās ar satikšanās pakalpojumu, kas uzzina katru publisko galapunktu un paziņo otrai pusei tās galapunktu. Pēc tam abas sūta viena pret otru, un katrs izejošais pakets izveido vai atjauno ierakstu, kas ielaiž atbildi. Kārtība ir tas, kas liek tam darboties, un kārtība ir arī tas, kas padara to trauslu: puse, kas sūta pirms otras puses ieraksta izveides, vienkārši tiek izmesta, savukārt atkārtojums mirklī vēlāk izdodas. Pakalpojums pats nepārvadā VPN trafiku, tāpēc tā vienīgā svira ir laiks, ko tas koordinē.

Kartēšanas uzvedība nosaka pārējo, un RFC 4787 nosauc trīs formas: no galapunkta neatkarīgu, no adreses atkarīgu un no adreses un porta atkarīgu. Pēdējā portā, uz kuru pusei jāmērķē, mainās ar katru galamērķi, tāpēc prognoze vairs nav uzticama. Tur šī metode nonāk strupceļā, jo operatora līmeņa NAT un stingrs uzņēmuma ugunsmūris abi likvidē paredzamību, kas shēmai vajadzīga, un neviens atkārtojumu skaits to neatgriež.

Keepalive, pārstartēšanas un kustīgais galapunkts

Izurbts ceļš ir plūsma, nevis klausītājs, tāpēc visam, kas uz tā darbojas, jāiztur izmaiņas. Tam jāuztur kartēšana dzīva ar periodisku trafiku, jāpamana, kad publiskais galapunkts pārvietojas, un jāatjaunojas pēc maršrutētāja pārstartēšanas vai adreses atkārtotas piešķiršanas. Mesh VPN produkti šo loģiku liek savā vadības plaknē, bet vienkāršs serveris to atstāj jums. Keepalive palīdz tikai tik ilgi, kamēr iztur tā pati kartēšana, un tie tērē akumulatoru mobilajā klientā, tāpēc agresīvs intervāls nav bez maksas.

Stundu guļošs klēpjdators parasti atgriežas citā publiskajā galapunktā. Visam, kas atjauno ceļu, atkal jādarbojas no iekšpuses, kas atgriež to pašu prasību klientam.

Trīs veidi, kā apiet trūkstošo pāradresāciju

Pirmais veids lūdz maršrutētāju pašam izveidot ierakstu, izmantojot UPnP IGD, NAT-PMP vai PCP, ja funkcija pastāv un ir ieslēgta. Otrais nodod trafiku relejam ar publisku adresi, kas vienmēr darbojas un vienmēr maksā joslas platumu plus citu uzticēšanās robežu. Trešais apgriež virzienu: iekšējais resursdators atver izejošo tuneli uz publisku serveri, un viss pārējais brauc tā iekšienē.

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

Releja galapunkts padara šo darījumu redzamu klienta konfigurācijā, kur galapunkts ir relejs, nevis pašas puses adrese. Pastāvīgs keepalive uztur kartēšanu siltu, un atļautie prefiksi nosaka, ko klients drīkst sūtīt pa to. Apgriezts tunelis no iekšējā resursdatora ir tā pati ideja ar citu īpašnieku, un tam vispār nav vajadzīga NAT maiņa. Katrs no trim novērš ienākšanas prasību, neuzvarot ugunsmūri, kas pēc projekta bloķē nelūgtu trafiku, jo trafiks joprojām sākas iekšienē.

Pielāgojiet apiešanu tam, kam pieder maršrutētājs

Ja pārvaldāt maršrutētāju, statiska UDP pāradresācija ir vieglāk auditējama nekā jebkura izduršanas shēma, un tā neizdodas veidos, ko redzat. Ja ne, noskaidrojiet, vai ražotājs piedāvā releju vai mitinātu vadības plakni, un vai politika ļautu to izmantot. Ja nav neviena, paliek apgriezts tunelis vai pieņemšana, ka galapunkts nav sasniedzams no ārpuses. Pierakstīt, kuru izmantojāt, ir svarīgāk, nekā izklausās, jo varianti atšķiras ar to, kas var novērot trafiku un kas notiek, kad trešā puse kaut ko maina.

Ievērojiet, vai ceļš, pie kura nonācāt, bija tiešs vai caur releju, jo šis viens fakts paredz gan latentumu, gan atteices uzvedību. RFC 4787 joprojām ir atsauce uz kartēšanas uzvedību zem visa tā, un lasīt tā kartēšanas sadaļu ir ātrāk nekā pēc kārtas pārbaudīt trīs apiešanas risinājumus. Tabulai nav svarīgi, kuru variantu izvēlējāties; tā fiksē tikai to, ko drīkst darīt nākamais pakets.