SoftEther NAT-i taga: otsene läbimurdmine või VPN Azure'i relee?

Dünaamiline DNS, NAT-i läbimurdmine ja VPN Azure teevad erinevaid töid. Valige tee enne kasutajate muutmist ja kinnitage seejärel, millist transporti seanss tegelikult kasutab.

Teie SoftEtheri server asub teenusepakkuja ruuteri taga, mida te ei saa muuta, ja kliendid ühenduvad siiski, nii et eeldate, et relee kannab kõike. Kas see on tõsi, sõltub sellest, milline mehhanism töö ära tegi: DNS-i nimi, koordineeritud UDP-tee või väljuv tunnel releesse. Kõik kolm võivad anda ühendatud kliendi ja nad ebaõnnestuvad erinevates tingimustes. Otsustage, millist teed te ostate, enne kui puudutate kasutajaid või jaoturikaid.

Kolm mehhanismi, kolm erinevat lubadust

Dünaamiline DNS on nimetamine. See hoiab hostinime suunatud muutuvale aadressile, et inimesed lõpetaksid numbri tagaajamise, ja ei tee midagi muud. Loomulik NAT-i läbimurdmine on koordineerimine: kaks SoftEtheri lõpp-punkti vahetavad teavet ja püüavad nende vaheliste tõlkeseadmete kaudu avada kasutatava UDP-tee. VPN Azure on relee: server helistab teenusesse välja ja kliendid saabuvad relee taristu hostinime kaudu.

Need kolm täiendavad üksteist, mitte ei ole ühe funktsiooni versioonid. Juurutus võib kasutada nimetamist, samal ajal kui selle ühendus sõltub tegelikult läbimurdmisest või releest.

Otsustage kliendi ja võrgu põhjal

Valik algab kliendist, sest läbimurdmine on olemas ainult loomulikus SoftEtheri ühendusmehhanismis. OpenVPN, L2TP/IPsec ja SSTP kuulajad samas serveris ei päri seda, kuigi nad jagavad hosti. Vaadake, mida kasutaja käivitab, ja seejärel, mida võrk lubab. Ettevõtte võrk, mis lubab ainult TCP 443, surub teid selle pordi relee poole, samas kui võrk, mis laseb läbi läbimurdmiseks vajalikud UDP-pordid, võib proovida otsest teed; kinnitage mõlemat tegeliku väljundpoliitika vastu.

Käsitsi kättesaadav kuulaja on endiselt legitiimne lahendus, kui administraator saab selle avaldada, kuid see on eraldi projekt oma adresseerimise ja tulemüüritööga.

Kinnitage, millise transpordi seanss valis

Ühenduse olek on ainus aus allikas kasutatava tee kohta. Lugege seda serveris ja lahendage hostinimi, mille klient sai.

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

SessionList näitab, millised seansid on ühendatud, ja SessionGet ühel neist teatab ühenduse tüübi, sealhulgas kas seanss saabus relee kaudu. Relee taristule lahenduv kirje ütleb teile, et seanss läbib kolmandat osapoolt, mida saate kinnitada selle marsruudi testimisel blokeerimisega. Loomuliku kliendiga võib UDP kiirendus nihutada andmetee juhtimisteest eemale, seega üks vaatlus ei kirjelda kogu seanssi. Aegunud dünaamiline DNS-i nimi pärast aadressi muutust ja relee, mis vastab, kui taustatee puudub, on kaks rikkerežiimi, mida tasub eraldi testida. Kirjutage üles, mida mõõtsite, mitte mida disain kavatses.

Planeerige, millest valitud tee sõltub

Iga tee kannab sõltuvust. Otsene läbimurdmine võib muutuda pärast võrguüleminekut või uut tõlkeseadet, samas kui relee seanss ebaõnnestub, kui teenus või selle kättesaadav port ebaõnnestub. Ühenduge uuesti teisest võrgust ja kinnitage serveri identiteet, mida klient kontrollis, hoides varem töötanud teed samas testis. Seejärel testige VPN-i taga olevat privaatset ressurssi, sest autoriseerimine, jaoturiliikmelisus, aadresside määramine ja tagasiteed jäävad igal juhul teie vastutuseks.

Kirjutage üles hostinimi, protokoll, funktsiooni seaded ja vaadeldud transport. Just see neljaosaline kirje võimaldab järgmisel inimesel töötava ühenduse taasesitada.

Seotud artiklid