SoftEther za NAT: přímé proražení, nebo relay VPN Azure?

Dynamický DNS, proražení NAT a VPN Azure dělají různé věci. Zvolte cestu před úpravou uživatelů a potom potvrďte, který transport relace skutečně používá.

Váš server SoftEther stojí za routerem poskytovatele, který nemůžete změnit, a klienti se přesto připojují, takže předpokládáte, že všechno nese relay. Zda je to pravda, závisí na tom, který mechanismus práci vykonal: název DNS, koordinovaná cesta UDP nebo odchozí tunel k relay. Všechny tři mohou dát připojeného klienta a selhávají za různých podmínek. Rozhodněte, kterou cestu kupujete, než se dotknete uživatelů nebo hubů.

Tři mechanismy, tři různá zaslíbení

Dynamický DNS je pojmenování. Drží název hostitele namířený na měnící se adresu, aby lidé přestali honit číslo, a nic jiného nedělá. Nativní proražení NAT je koordinace: dva koncové body SoftEther si vyměňují informace a snaží se otevřít použitelnou cestu UDP přes překladová zařízení mezi nimi. VPN Azure je relay: server se vytáčí k službě a klienti přicházejí přes název hostitele v infrastruktuře relay.

Ty tři se doplňují, nejsou verzemi jedné funkce. Nasazení může používat pojmenování, zatímco jeho spojení ve skutečnosti závisí na proražení nebo na relay.

Rozhodujte podle klienta a sítě

Volba začíná u klienta, protože proražení existuje jen v nativním mechanismu připojení SoftEther. OpenVPN, L2TP/IPsec a posluchače SSTP na stejném serveru ho nedědí, i když sdílejí hostitele. Podívejte se, co bude uživatel spouštět, a potom, co síť dovoluje. Podniková síť, která povoluje jen TCP 443, vás tlačí k relay na tomto portu, zatímco síť, která propouští porty UDP potřebné pro proražení, může zkusit přímou cestu; potvrďte obojí proti skutečné politice odchodu.

Ručně dostupný posluchač je stále legitimní návrh, když ho správce může publikovat, ale je to samostatný projekt s vlastním adresováním a prací s firewallem.

Potvrďte, který transport si relace vybrala

Stav připojení je jediný poctivý zdroj o používané cestě. Přečtěte ho na serveru a přeložte název hostitele, který klient dostal.

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

SessionList ukazuje, které relace jsou připojené, a SessionGet na jedné z nich hlásí typ připojení, včetně toho, zda relace přišla přes relay. Záznam, který se překládá na infrastrukturu relay, vám říká, že relace prochází přes třetí stranu, což můžete potvrdit zablokováním té trasy v testu. S nativním klientem může UDP akcelerace odsunout datovou cestu od řídicí cesty, takže jedno pozorování nepopisuje celou relaci. Zastaralý název dynamického DNS po změně adresy a relay, který odpovídá, zatímco chybí cesta k backendu, jsou dva režimy selhání, které stojí za samostatné otestování. Zapište, co jste změřili, ne co návrh zamýšlel.

Plánujte podle toho, na čem zvolená cesta závisí

Každá cesta nese závislost. Přímé proražení se může změnit po přechodu sítě nebo po novém překladovém zařízení, zatímco relace relay selže, když selže služba nebo její dostupný port. Připojte se znovu z jiné sítě a potvrďte identitu serveru, kterou klient ověřil, a ponechte dříve funkční cestu ve stejném testu. Potom otestujte soukromý prostředek za VPN, protože autorizace, členství v hubu, přidělování adres a zpětné trasy zůstávají v obou případech vaší odpovědností.

Zapište název hostitele, protokol, nastavení funkce a pozorovaný transport. Právě tento čtyřdílný záznam umožní dalšímu člověku zopakovat funkční připojení.

Související články