SoftEther malantaŭ NAT: rekta trairo aŭ VPN Azure-relajso?

Via SoftEther-servilo staras malantaŭ provizanta enkursigilo, kiun vi ne povas ŝanĝi, kaj klientoj ankoraŭ konektiĝas, do vi supozas, ke relajso portas ĉion. Ĉu tio veras, dependas de tio, kiu mekanismo faris la laboron: DNS-nomo, kunordigita UDP-vojo aŭ elira tunelo al relajso. Ĉiuj tri povas produkti konektitan klienton, kaj ili malsukcesas sub malsamaj kondiĉoj. Decidu, kiun vojon vi aĉetas, antaŭ ol tuŝi uzantojn aŭ hubojn.

Tri mekanismoj, tri malsamaj promesoj

Dinamika DNS estas nomado. Ĝi tenas gastigantnomon direktitan al ŝanĝiĝanta adreso, por ke homoj ĉesu postkuri la numeron, kaj ĝi faras nenion alian. Denaska NAT-trairo estas kunordigado: du SoftEther-finpunktoj interŝanĝas informojn kaj provas malfermi uzeblan UDP-vojon tra la tradukaj aparatoj inter ili. VPN Azure estas relajso: la servilo elkonektiĝas al la servo, kaj klientoj alvenas tra gastigantnomo en la infrastrukturo de la relajso.

La tri kompletigas unu la alian, ili ne estas versioj de unu funkcio. Enkonduko povas uzi nomadon dum sia konekto fakte dependas de la trairo aŭ de la relajso.

Decidu laŭ la kliento kaj la reto

La elekto komenciĝas ĉe la kliento, ĉar trairo ekzistas nur en la denaska SoftEther-konektmekanismo. OpenVPN, L2TP/IPsec kaj SSTP-auskultantoj sur la sama servilo ne heredas ĝin, kvankam ili dividas gastiganton. Rigardu, kion la uzanto rulos, poste kion la reto permesas. Kompania reto, kiu permesas nur TCP 443, puŝas vin al relajso sur tiu pordo, dum reto, kiu trapasigas la UDP-pordojn bezonatajn de trairo, povas provi rektan vojon; konfirmu ambaŭ kontraŭ la reala elira politiko.

Mane atingebla auskultanto ankoraŭ estas legitima dezajno, kiam administranto povas publikigi unu, sed ĝi estas aparta projekto kun propra adresado kaj fajroŝirma laboro.

Konfirmu, kiun transporton la seanco elektis

Konekta stato estas la sola honesta fonto por la vojo uzata. Legu ĝin sur la servilo, kaj solvu la gastigantnomon, kiun la kliento ricevis.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList montras, kiuj seancoj estas konektitaj, kaj SessionGet sur unu el ili raportas la konektan tipon, inkluzive ĉu la seanco alvenis tra la relajso. Rikordo, kiu solviĝas al relajsa infrastrukturo, diras al vi, ke la seanco pasas tra tria partio, kion vi povas konfirmi blokante tiun vojon en testoj. Kun denaska kliento, UDP-akcelado povas movi la datan vojon for de la kontrola vojo, do unu observo ne priskribas la tutan seanson. Malfreŝa dinamika DNS-nomo post adresa ŝanĝo, kaj relajso, kiu respondas dum la malantaŭa vojo mankas, estas du fiaskaj reĝimoj indaj je aparta testado. Notu, kion vi mezuris, ne kion la dezajno intencis.

Planu laŭ tio, de kio la elektita vojo dependas

Ĉiu vojo portas dependecon. Rekta trairo povas ŝanĝiĝi post reta transiro aŭ nova traduka aparato, dum relajsa seanco fiaskas kiam la servo aŭ ĝia atingebla pordo fiaskas. Rekonektiĝu el alia reto kaj konfirmu la servilan identecon, kiun la kliento kontrolis, tenante la antaŭe funkciantan vojon en la sama testo. Poste testu la privatan rimedon malantaŭ la VPN, ĉar rajtigo, huba membreco, adresa asigno kaj revenaj vojoj restas via respondeco en ĉiu kazo.

Notu la gastigantnomon, protokolon, funkciajn agordojn kaj observitan transporton. Ĝuste tiu kvarparta rikordo ebligas al la sekva persono reprodukti funkciantan konekton.