SoftEther aiz NAT: tieša caureja vai VPN Azure relejs?

Jūsu SoftEther serveris atrodas aiz pakalpojumu sniedzēja maršrutētāja, kuru nevarat mainīt, un klienti joprojām savienojas, tāpēc pieņemat, ka relejs nes visu. Vai tas ir taisnība, ir atkarīgs no tā, kurš mehānisms veica darbu: DNS nosaukums, saskaņots UDP ceļš vai izejošais tunelis uz releju. Visi trīs var radīt savienotu klientu, un tie neizdodas dažādos apstākļos. Izlemiet, kuru ceļu pērkat, pirms aiztiecat lietotājus vai centrmezglus.

Trīs mehānismi, trīs dažādi solījumi

Dinamiskais DNS ir nosaukumu piešķiršana. Tas uztur resursdatora nosaukumu vērstu uz mainīgu adresi, lai cilvēki pārstātu dzīties pēc numura, un neko citu nedara. Vietējā NAT caureja ir koordinācija: divi SoftEther galapunkti apmainās ar informāciju un mēģina atvērt lietojamu UDP ceļu caur tulkošanas ierīcēm starp tiem. VPN Azure ir relejs: serveris pieslēdzas pakalpojumam uz āru, un klienti ierodas caur resursdatora nosaukumu releja infrastruktūrā.

Šie trīs papildina viens otru, nevis ir vienas funkcijas versijas. Izvietojums var izmantot nosaukumu piešķiršanu, kamēr tā savienojums faktiski ir atkarīgs no caurejas vai releja.

Izlemiet pēc klienta un tīkla

Izvēle sākas ar klientu, jo caureja pastāv tikai vietējā SoftEther savienojuma mehānismā. OpenVPN, L2TP/IPsec un SSTP klausītāji tajā pašā serverī to nemanto, lai gan dala vienu resursdatoru. Paskatieties, ko lietotājs palaidīs, un pēc tam, ko tīkls atļauj. Uzņēmuma tīkls, kas atļauj tikai TCP 443, virza jūs uz releju šajā portā, savukārt tīkls, kas laiž cauri caurejai nepieciešamos UDP portus, var mēģināt tiešu ceļu; pārbaudiet abus pret faktisko izejas politiku.

Manuāli sasniedzams klausītājs joprojām ir likumīgs risinājums, ja administrators var publicēt vienu, taču tas ir atsevišķs projekts ar savu adresāciju un ugunsmūra darbu.

Pārbaudiet, kuru transportu sesija izvēlējās

Savienojuma statuss ir vienīgais godīgais izmantotā ceļa avots. Izlasiet to serverī un atrisiniet resursdatora nosaukumu, ko klients saņēma.

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

SessionList parāda, kuras sesijas ir savienotas, un SessionGet uz vienas no tām ziņo savienojuma tipu, tostarp vai sesija ieradās caur releju. Ieraksts, kas atrisinās uz releja infrastruktūru, pasaka, ka sesija iet caur trešo pusi, ko varat apstiprināt, bloķējot šo maršrutu testā. Ar vietējo klientu UDP paātrinājums var pārvietot datu ceļu prom no vadības ceļa, tāpēc viens novērojums neapraksta visu sesiju. Novecojis dinamisks DNS nosaukums pēc adreses maiņas un relejs, kas atbild, kamēr trūkst backend ceļa, ir divi kļūmju režīmi, kurus vērts pārbaudīt atsevišķi. Pierakstiet to, ko izmērījāt, nevis to, ko dizains bija iecerējis.

Plānojiet, no kā atkarīgs izvēlētais ceļš

Katrs ceļš nes atkarību. Tieša caureja var mainīties pēc tīkla pārejas vai jaunas tulkošanas ierīces, savukārt releja sesija neizdodas, kad neizdodas pakalpojums vai tā sasniedzamais ports. Savienojieties no jauna no cita tīkla un apstipriniet servera identitāti, ko klients pārbaudīja, paturot iepriekš strādājošo ceļu tajā pašā testā. Pēc tam pārbaudiet privāto resursu aiz VPN, jo autorizācija, centrmezgla dalība, adrešu piešķiršana un atgriešanās maršruti jebkurā gadījumā paliek jūsu atbildība.

Pierakstiet resursdatora nosaukumu, protokolu, funkcijas iestatījumus un novēroto transportu. Tieši šis četrdaļīgais ieraksts ļauj nākamajam cilvēkam atveidot strādājošu savienojumu.