VPN za NAT, ki ga ne morete konfigurirati: kaj še deluje

Vsaka končna točka tunela potrebuje naslov in vrata, ki jih druga stran lahko doseže, usmerjevalnik, ki ga ne upravljate, pa je običajen razlog, da ta zahteva ne uspe. Zanimivo ni to, da triki obstajajo, ampak da je vsak odvisen od lastnosti tabele preslikav, ki je s odjemalca ne vidite. Dve od teh lastnosti odločata skoraj o vsem: kako nastane preslikava in ali sprejema pakete z naslova, s katerim notranjost nikoli ni komunicirala. Razvrstite okolje po teh lastnostih in obvozi ne bodo več folklora.

Tabela preslikav odloča o vsem

Pretvorba omrežnih naslovov vodi tabelo, v kateri sta notranji naslov in vrata zapisana proti javnemu naslovu in vratom. Odgovori, ki ustrezajo zapisu, se pretvorijo nazaj, paket, ki pride od zunaj brez ustreznega zapisa, pa nima nobenega cilja. To eno vedenje pojasnjuje, zakaj je poslušalec za usmerjevalnikom nedosegljiv z interneta. Pojasnjuje tudi, zakaj mora prvi paket v vsaki smeri izvirati od znotraj.

Poglejte tabelo z usmerjevalnikove strani in obvozi postanejo očitni: ali nekaj ustvari trajen vnos, ali ustvari začasen in ga ohranja svežega, ali promet nikoli ne gre po tej poti. Preostanek članka so ti trije primeri po vrsti. Nič tu ni odvisno od funkcije proizvajalca prek tega, kar tabela zabeleži.

Kaj lahko in česa ne more storiti storitev srečanja

UDP hole punching uporablja odhodni zapis kot začasno odprtino, namesto da bi premagal filter. Oba partnerja stopita v stik s storitvijo srečanja, ki se nauči vsake javne končne točke in drugi strani sporoči njeno točko. Nato oba pošljeta drug proti drugemu in vsak odhodni paket ustvari ali osveži zapis, ki spusti odgovor noter. Vrstni red je tisto, kar deluje, in vrstni red je tudi tisto, kar je krhko: partner, ki pošlje, preden je druga stran ustvarila svoj zapis, se preprosto zavrže, medtem ko poskus trenutek kasneje uspe. Storitev sama ne prenaša prometa VPN, zato je njena edina vzvod čas, ki ga usklajuje.

Vedenje preslikav odloča o preostalem, in RFC 4787 poimenuje tri oblike: neodvisno od končne točke, odvisno od naslova in odvisno od naslova ter vrat. Pri zadnji se vrata, na katera mora partner ciljati, spreminjajo z vsakim ciljem, zato napoved ni več zanesljiva. Tam tehnika naleti na slepo ulico, ker operaterski NAT in stroga poslovna požarna pregrada odstranita predvidljivost, ki jo shema potrebuje, in nobena količina ponovnih poskusov je ne vrne.

Keepalive, ponovni zagoni in končna točka, ki se premika

Prebodena pot je tok, ne poslušalec, zato mora vse, kar teče po njej, preživeti spremembo. Vzdrževati mora preslikavo živo s periodičnim prometom, opaziti, kdaj se javna končna točka premakne, in se znova vzpostaviti po ponovnem zagonu usmerjevalnika ali dodelitvi naslova. Izdelki mesh VPN to logiko dajo v svojo krmilno ravnino, medtem ko navaden strežnik to prepusti vam. Keepalive pomagajo le, dokler preživi ista preslikava, in na mobilnem odjemalcu pijejo baterijo, zato agresiven interval ni brezplačen.

Prenosnik, ki spi eno uro, se običajno vrne na drugi javni končni točki. Vse, kar pot znova vzpostavi, mora znova teči od znotraj, kar vrne isto zahtevo na odjemalca.

Trije načini okoli manjkajočega posredovanja

Prvi način prosi usmerjevalnik, da vnos ustvari sam, prek UPnP IGD, NAT-PMP ali PCP, ko funkcija obstaja in je vklopljena. Drugi preda promet releju z javnim naslovom, kar vedno deluje in vedno stane pasovno širino ter drugačno mejo zaupanja. Tretji obrne smer: notranji gostitelj odpre odhodni tunel do javnega strežnika in vse ostalo se pelje v njem.

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

Končna točka releja naredi to izmenjavo vidno v konfiguraciji odjemalca, kjer je končna točka rele in ne partnerjev lastni naslov. Trajni keepalive ohranja preslikavo toplo, dovoljene predpone pa odločajo, kaj lahko odjemalec pošlje po njej. Povratni tunel z notranjega gostitelja je ista zamisel z drugim lastnikom in ne potrebuje nobene spremembe NAT. Vsak od treh odstrani zahtevo po vhodu, ne da bi premagal požarno pregrado, ki nezaželen promet blokira že po zasnovi, ker promet še vedno začne znotraj.

Prilagodite obvoz temu, kdo ima usmerjevalnik

Če usmerjevalnik upravljate, je statično posredovanje UDP lažje pregledati kot katero koli shemo prebadanja in ne uspe na načine, ki jih vidite. Če ne, ugotovite, ali ponudnik ponuja rele ali gostujočo krmilno ravnino in ali bi politika dovolila uporabo. Če ni na voljo nič od tega, ostaneta povratni tunel ali sprejetje, da končna točka od zunaj ni dosegljiva. Zapisati, katero ste uporabili, je pomembneje, kot se sliši, ker se možnosti razlikujejo po tem, kdo lahko opazuje promet in kaj se zgodi, ko tretja stran kaj spremeni.

Opazite, ali je bila pot, do katere ste prišli, neposredna ali prek releja, ker to eno dejstvo napoveduje tako zakasnitev kot vedenje ob napaki. RFC 4787 ostaja referenca za vedenje preslikav pod vsem tem, in branje njegovega razdelka o preslikavah je hitrejše od zaporednega preizkušanja treh obvozov. Tabeli ni mar, katero možnost ste izbrali; zabeleži le, kaj sme storiti naslednji paket.