VPN malantaŭ NAT, kiun vi ne povas agordi: kio ankoraŭ funkcias

Ĉiu tunela finpunkto bezonas adreson kaj pordon, kiujn la alia flanko povas atingi, kaj enkursigilo, kiun vi ne administras, estas la kutima kialo, ke tiu postulo malsukcesas. La interesa parto ne estas, ke ekzistas artifikoj, sed ke ĉiu el ili dependas de eco de mapada tabelo, kiun vi ne vidas de la kliento. Du el tiuj ecoj decidas preskaŭ ĉion: kiel mapado kreiĝas, kaj ĉu ĝi akceptas paketojn de adreso, kun kiu la interno neniam kontaktiĝis. Ordigu la medion laŭ tiuj ecoj kaj la solvoj ĉesas esti folkloro.

La mapada tabelo decidas ĉion

Retadresa traduko tenas tabelon, en kiu interna adreso kaj pordo estas registritaj kontraŭ publika adreso kaj pordo. Respondoj, kiuj kongruas kun registro, estas tradukataj reen, kaj paketo alvenanta de ekstere sen kongrua registro tute ne havas celon. Tiu unu konduto klarigas, kial aŭskultanto malantaŭ la enkursigilo estas neatingebla el la interreto. Ĝi ankaŭ klarigas, kial la unua paketo en ĉiu direkto devas ekesti interne.

Rigardu la tabelon de la flanko de la enkursigilo kaj la solvoj fariĝas evidentaj: aŭ io kreas daŭran registron, aŭ kreas provizoran kaj tenas ĝin freŝa, aŭ la trafiko tute ne prenas tiun vojon. La resto de la artikolo estas tiuj tri kazoj laŭorde. Nenio ĉi tie dependas de vendista funkcio preter tio, kion la tabelo registras.

Kion la rendevua servo povas kaj ne povas fari

UDP-truoborado uzas la eliran registron kiel provizoran malfermaĵon anstataŭ venki la filtrilon. Ambaŭ partneroj kontaktas rendevuan servon, kiu ekscias ĉiun publikan finpunkton kaj raportas al la alia flanko ĝian finpunkton. Poste ambaŭ sendas unu al la alia, kaj ĉiu elira paketo kreas aŭ refreŝigas la registron, kiu lasas la respondon eniri. La ordo estas tio, kio igas ĝin funkcii, kaj la ordo ankaŭ estas tio, kio igas ĝin delikata: partnero, kiu sendas antaŭ ol la alia flanko kreis sian registron, simple estas forĵetata, dum reprovo momenton poste sukcesas. La servo mem portas neniun VPN-trafikon, do ĝia sola levilo estas la tempigo, kiun ĝi kunordigas.

Mapada konduto decidas la reston, kaj RFC 4787 nomas la tri formojn: sendependa de finpunkto, dependa de adreso, kaj dependa de adreso kaj pordo. Ĉe la lasta, la pordo, kiun partnero devas celi, ŝanĝiĝas kun ĉiu celo, do antaŭdiro ĉesas esti fidinda. Tie la tekniko renkontas sian sakstraton, ĉar portanta NAT kaj severa entreprena fajroŝirmilo ambaŭ forigas la antaŭvideblecon, kiun la skemo bezonas, kaj neniu kvanto da reprovoj revenigas ĝin.

Keepalive, restartoj kaj la finpunkto, kiu moviĝas

Truoborita vojo estas fluo, ne aŭskultanto, do ĉio, kio kuras sur ĝi, devas travivi ŝanĝon. Ĝi devas teni la mapadon viva per perioda trafiko, rimarki kiam la publika finpunkto moviĝas, kaj restarigi post restarto de la enkursigilo aŭ reatribuo de la adreso. Mesh-VPN-produktoj metas tiun logikon en sian propran regan ebenon, dum simpla servilo lasas ĝin al vi. Keepalive helpas nur dum la sama mapado travivas, kaj ili konsumas baterion sur poŝa kliento, tial agresema intervalo ne estas senpaga.

Tekkomputilo, kiu dormas unu horon, kutime revenas sur alia publika finpunkto. Ĉio, kio restarigas la vojon, devas denove kuri de interne, kio remetas la saman postulon al la kliento.

Tri vojoj ĉirkaŭ mankanta plusendado

La unua vojo petas la enkursigilon mem krei la registron, per UPnP IGD, NAT-PMP aŭ PCP, kiam la funkcio ekzistas kaj estas ŝaltita. La dua transdonas la trafikon al relajso kun publika adreso, kio ĉiam funkcias kaj ĉiam kostas bendlarĝon plus alian fido-limon. La tria inversigas la direkton: la interna gastiganto malfermas eliran tunelon al publika servilo kaj ĉio alia veturas interne de ĝi.

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

Relajsa finpunkto igas tiun interŝanĝon videbla en la klienta agordo, kie la finpunkto estas relajso anstataŭ la propra adreso de partnero. Daŭra keepalive tenas la mapadon varma, kaj la permesitaj prefiksoj decidas, kion la kliento rajtas sendi tra ĝi. Inversa tunelo de la interna gastiganto estas la sama ideo kun alia posedanto, kaj ĝi bezonas neniun ŝanĝon de NAT. Ĉiu el la tri forigas la envenan postulon sen venki fajroŝirmilon, kiu laŭdezine blokas nepetitan trafikon, ĉar la trafiko ankoraŭ komenciĝas interne.

Alkongruigu la solvon al tiu, kiu posedas la enkursigilon

Se vi administras la enkursigilon, statika UDP-plusendado estas pli facile reviziebla ol iu ajn truoborada skemo kaj malsukcesas laŭ manieroj, kiujn vi vidas. Se ne, eksciu, ĉu la vendisto ofertas relajson aŭ gastigitan regan ebenon, kaj ĉu politiko permesas uzi ĝin. Se neniu estas havebla, la restantaj elektoj estas inversa tunelo aŭ akcepto, ke la finpunkto ne estas atingebla de ekstere. Registri, kiun vi uzis, gravas pli ol ĝi sonas, ĉar la elektoj diferencas laŭ tio, kiu povas observi la trafikon kaj kio okazas, kiam tria partio ŝanĝas ion.

Notu, ĉu la vojo, al kiu vi alvenis, estis rekta aŭ relajsa, ĉar tiu sola fakto antaŭdiras kaj latentecon kaj malsukcesan konduton. RFC 4787 restas la referenco por la mapada konduto sub ĉio tio, kaj legi ĝian mapadan sekcion estas pli rapide ol sinsekve testi tri solvojn. La tabelo ne zorgas, kiun opcion vi elektis; ĝi nur registras, kion la sekva paketo rajtas fari.