SoftEther NAT atzean: zuzeneko zeharkatzea edo VPN Azure errele bat?

Zure SoftEther zerbitzaria aldatu ezin duzun hornitzailearen router baten atzean dago, eta bezeroak oraindik konektatzen dira, beraz errele batek dena daramala suposatzen duzu. Hori egia den ala ez lan egitea zein mekanismok egin zuen araberakoa da: DNS izen bat, koordinatutako UDP bide bat edo errele baterako irteerako tunel bat. Hirurek bezero konektatu bat sor dezakete, eta baldintza desberdinetan huts egiten dute. Zein bide erosten duzun erabaki erabiltzaile edo hubak ukitu aurretik.

Hiru mekanismo, hiru promes desberdin

DNS dinamikoa izendapena da. Ostalari-izen bat aldakorra den helbide batera zuzenduta edukitzen du jendeak zenbakiaren atzetik ibiltzeari uzteko, eta ez du besterik egiten. Jatorrizko NAT zeharkatzea koordinazioa da: SoftEther mutur bi informazioa trukatzen dute eta haien artean dauden itzulpen gailuen bidez erabilgarria den UDP bide bat irekitzen saiatzen dira. VPN Azure errele bat da: zerbitzariak kanpora deitzen dio zerbitzuari, eta bezeroak errelearen azpiegituran dagoen ostalari-izen baten bidez iristen dira.

Hirurak osagarriak dira, ez dira funtzio baten bertsioak. Hedapen batek izendapena erabil dezake, baina bere konexioa zeharkatzearen edo errelearen mende egon ohi da.

Erabakia bezerotik eta saretik hartu

Aukera bezerotik hasten da, zeharkatzea SoftEther-en jatorrizko konexio mekanismoan bakarrik baitago. OpenVPN, L2TP/IPsec eta SSTP entzuleek zerbitzari berean ez dute heredatzen, ostalari bat partekatu arren. Begiratu erabiltzaileak zer exekutatuko duen, eta gero sareak zer baimentzen duen. TCP 443 soilik baimentzen duen enpresa sare batek portu horretako errele baterantz bultzatzen zaitu, eta zeharkatzeak behar dituen UDP portuak pasatzen uzten dituen sare batek bide zuzena saia dezake; egiaztatu biak irteera politika errealaren aurka.

Eskuz irisgarria den entzule bat diseinu legitimoa da oraindik administratzaile batek argitara dezakeenean, baina bere helbideratze eta suebaki lan propioa duen proiektu bereizia da.

Egiaztatu saioak zein garraio aukeratu zuen

Konexio-egoera da erabiltzen ari den bidearen iturri zintzo bakarra. Irakurri zerbitzarian, eta ebatzi bezeroak jaso zuen ostalari-izena.

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

SessionList-ek zein saio dauden konektatuta erakusten du, eta horietako baten gaineko SessionGet-ek konexio mota jakinarazten du, saioa errelearen bidez iritsi den barne. Errelearen azpiegiturara ebazten den erregistro batek saioa hirugarren baten bidez pasatzen dela esaten dizu, eta proba batean bide hori blokeatuz egiaztatu dezakezu. Jatorrizko bezero batekin, UDP azelerazioak datu-bidea kontrol-bidetik urrun dezake, beraz behaketa batek ez du saio osoa deskribatzen. Helbide aldaketaren ondoren zaharkituta geratu den DNS dinamiko izen batek eta backend bidea falta den bitartean erantzuten duen errele batek proba bereizia merezi duten bi hutsegite modu dira. Idatzi neurtu duzuna, ez diseinuak asmo zuena.

Planifikatu aukeratutako bidea zeren mende dagoen

Bide bakoitzak menpekotasun bat darama. Zeharkatze zuzena sare trantsizio baten edo itzulpen gailu berri baten ondoren alda daiteke, eta errele saioak huts egiten du zerbitzuak edo bere portu irisgarriak huts egiten duenean. Berreraiki konexioa beste sare batetik eta egiaztatu bezeroak egiaztatu zuen zerbitzari identitatea, aurrez funtzionatzen zuen bidea proba berean mantenduz. Gero probatu VPNaren atzean dagoen baliabide pribatua, baimenak, hub kidetza, helbide esleipena eta itzulera bideak edozein kasutan zure erantzukizuna izaten jarraitzen baitute.

Idatzi ostalari-izena, protokoloa, funtzioaren ezarpenak eta behatutako garraioa. Lau zatiko erregistro horrek ahalbidetzen dio hurrengoari funtzionatzen duen konexio bat errepikatzea.