SoftEther za NAT: priame prerazenie alebo relay VPN Azure?

Dynamický DNS, prerazenie NAT a VPN Azure robia rôzne úlohy. Vyberte cestu pred úpravou používateľov, potom potvrďte, ktorý transport relácia skutočne používa.

Váš server SoftEther stojí za routerom poskytovateľa, ktorý nemôžete zmeniť, a klienti sa napriek tomu pripájajú, takže predpokladáte, že všetko nesie relay. Či je to pravda, závisí od toho, ktorý mechanizmus prácu vykonal: názov DNS, koordinovaná cesta UDP alebo odchádzajúci tunel k relay. Všetky tri môžu dať pripojeného klienta a zlyhávajú za rôznych podmienok. Rozhodnite, ktorú cestu kupujete, skôr než sa dotknete používateľov alebo hubov.

Tri mechanizmy, tri rôzne sľuby

Dynamický DNS je pomenovanie. Drží názov hostiteľa nasmerovaný na meniacu sa adresu, aby ľudia prestali naháňať číslo, a nič iné nerobí. Natívne prerazenie NAT je koordinácia: dva koncové body SoftEther si vymieňajú informácie a snažia sa otvoriť použiteľnú cestu UDP cez prekladové zariadenia medzi nimi. VPN Azure je relay: server sa vytáča k službe a klienti prichádzajú cez názov hostiteľa v infraštruktúre relay.

Tieto tri sa dopĺňajú, nie sú verziami jednej funkcie. Nasadenie môže používať pomenovanie, zatiaľ čo jeho spojenie v skutočnosti závisí od prerazenia alebo od relay.

Rozhodujte podľa klienta a siete

Voľba začína pri klientovi, pretože prerazenie existuje len v natívnom mechanizme pripojenia SoftEther. OpenVPN, L2TP/IPsec a poslucháče SSTP na tom istom serveri ho nededí, aj keď zdieľajú hostiteľa. Pozrite sa, čo bude používateľ spúšťať, a potom, čo sieť dovoľuje. Podniková sieť, ktorá povoľuje len TCP 443, vás tlačí k relay na tomto porte, zatiaľ čo sieť, ktorá prepúšťa porty UDP potrebné na prerazenie, môže skúsiť priamu cestu; potvrďte oboje voči skutočnej politike odchodu.

Ručne dostupný poslucháč je stále legitímny návrh, keď ho správca môže publikovať, ale je to samostatný projekt s vlastným adresovaním a prácou s firewallom.

Potvrďte, ktorý transport si relácia vybrala

Stav pripojenia je jediný čestný zdroj o používanej ceste. Prečítajte ho na serveri a preložte názov hostiteľa, ktorý klient dostal.

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

SessionList ukazuje, ktoré relácie sú pripojené, a SessionGet na jednej z nich hlási typ pripojenia vrátane toho, či relácia prišla cez relay. Záznam, ktorý sa prekladá na infraštruktúru relay, vám hovorí, že relácia prechádza cez tretiu stranu, čo môžete potvrdiť zablokovaním tej trasy v teste. S natívnym klientom môže UDP akcelerácia odsunúť dátovú cestu od riadiacej cesty, takže jedno pozorovanie neopisuje celú reláciu. Zastaraný názov dynamického DNS po zmene adresy a relay, ktorý odpovedá, zatiaľ čo chýba cesta k backendu, sú dva režimy zlyhania, ktoré stoja za samostatné otestovanie. Zapíšte, čo ste zmerali, nie čo návrh zamýšľal.

Plánujte podľa toho, na čom závisí zvolená cesta

Každá cesta nesie závislosť. Priame prerazenie sa môže zmeniť po prechode siete alebo po novom prekladovom zariadení, zatiaľ čo relácia relay zlyhá, keď zlyhá služba alebo jej dostupný port. Pripojte sa znova z inej siete a potvrďte identitu servera, ktorú klient overil, a ponechajte predtým funkčnú cestu v tom istom teste. Potom otestujte súkromný prostriedok za VPN, pretože autorizácia, členstvo v hube, prideľovanie adries a spätné trasy zostávajú v každom prípade vašou zodpovednosťou.

Zapíšte názov hostiteľa, protokol, nastavenia funkcie a pozorovaný transport. Práve tento štvordielny záznam umožní ďalšiemu človeku zopakovať funkčné pripojenie.

Súvisiace články