SoftEther už NAT: tiesioginis prasiskverbimas ar VPN Azure relė?

Dinaminis DNS, NAT prasiskverbimas ir VPN Azure atlieka skirtingus darbus. Pasirinkite kelią prieš redaguodami naudotojus, tada patvirtinkite, kokį transportą sesija iš tikrųjų naudoja.

Jūsų SoftEther serveris stovi už tiekėjo maršrutizatoriaus, kurio negalite pakeisti, o klientai vis tiek jungiasi, todėl manote, kad relė neša viską. Ar tai tiesa, priklauso nuo to, kuris mechanizmas atliko darbą: DNS vardas, suderintas UDP kelias ar išėjimo tunelis į relę. Visi trys gali duoti prisijungusį klientą, ir jie sugenda skirtingomis sąlygomis. Nuspręskite, kurį kelią perkate, prieš liesdami naudotojus ar šakotuvus.

Trys mechanizmai, trys skirtingi pažadai

Dinaminis DNS yra vardijimas. Jis laiko prieglobos vardą nukreiptą į besikeičiantį adresą, kad žmonės nustotų vytis numerį, ir nieko daugiau nedaro. Natūralus NAT prasiskverbimas yra derinimas: du SoftEther galiniai taškai keičiasi informacija ir bando atidaryti naudingą UDP kelią per vertimo įrenginius tarp jų. VPN Azure yra relė: serveris skambina į paslaugą, o klientai atvyksta per prieglobos vardą relės infrastruktūroje.

Trys papildo vienas kitą, o ne yra vienos funkcijos versijos. Diegimas gali naudoti vardijimą, nors jo ryšys iš tikrųjų priklauso nuo prasiskverbimo arba nuo relės.

Spręskite pagal klientą ir tinklą

Pasirinkimas prasideda nuo kliento, nes prasiskverbimas egzistuoja tik natūraliame SoftEther ryšio mechanizme. OpenVPN, L2TP/IPsec ir SSTP klausytojai tame pačiame serveryje jo nepaveldi, nors dalijasi priegloba. Pažiūrėkite, ką vykdys naudotojas, o paskui, ką leidžia tinklas. Įmonės tinklas, leidžiantis tik TCP 443, stumia jus prie relės tame porte, o tinklas, praleidžiantis prasiskverbimui reikalingus UDP portus, gali bandyti tiesioginį kelią; patvirtinkite abu pagal tikrąją išėjimo politiką.

Rankiniu būdu pasiekiamas klausytojas vis dar yra teisėtas sprendimas, kai administratorius gali jį paskelbti, bet tai atskiras projektas su savo adresavimu ir ugniasienės darbu.

Patvirtinkite, kokį transportą pasirinko sesija

Ryšio būsena yra vienintelis sąžiningas naudojamo kelio šaltinis. Perskaitykite ją serveryje ir išspręskite prieglobos vardą, kurį gavo klientas.

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

SessionList rodo, kurios sesijos yra prisijungusios, o SessionGet vienoje iš jų praneša ryšio tipą, įskaitant tai, ar sesija atėjo per relę. Įrašas, kuris sprendžiasi į relės infrastruktūrą, pasako, kad sesija eina per trečiąją šalį, ką galite patvirtinti blokuodami tą maršrutą teste. Su natūraliu klientu UDP spartinimas gali nutolinti duomenų kelią nuo valdymo kelio, todėl vienas stebėjimas neaprašo visos sesijos. Pasenęs dinaminis DNS vardas po adreso pakeitimo ir relė, kuri atsako, kai trūksta backend kelio, yra du gedimų režimai, kuriuos verta tikrinti atskirai. Užrašykite, ką išmatavote, o ne ką dizainas ketino.

Planuokite, nuo ko priklauso pasirinktas kelias

Kiekvienas kelias turi priklausomybę. Tiesioginis prasiskverbimas gali pasikeisti po tinklo perėjimo ar naujo vertimo įrenginio, o relės sesija sugenda, kai sugenda paslauga arba jos pasiekiamas portas. Prisijunkite iš naujo iš kito tinklo ir patvirtinkite serverio tapatybę, kurią patikrino klientas, laikydami anksčiau veikusį kelią tame pačiame teste. Tada išbandykite privatų išteklių už VPN, nes autorizacija, šakotuvo narystė, adresų priskyrimas ir grįžimo maršrutai bet kuriuo atveju lieka jūsų atsakomybe.

Užrašykite prieglobos vardą, protokolą, funkcijos nustatymus ir stebėtą transportą. Būtent šis keturių dalių įrašas leidžia kitam žmogui atkurti veikiantį ryšį.

Susiję straipsniai