SoftEther VPN Azure: cesta cez relay, nie otvorený port

Váš server stojí za routerom, ktorý nemôžete konfigurovať, takže zrejmý plán presmerovať port nie je k dispozícii. VPN Azure existuje presne pre túto situáciu a rieši ju obrátením smeru prvého spojenia: server sa pripája k relayu a klienti dosiahnu relay namiesto servera. Pochopenie tohto obrátenia vysvetľuje, čo služba rieši, aj každé obmedzenie, na ktoré neskôr narazíte.

Čo sa na ceste mení

Pri bežnom listeneri otvára klient TCP spojenie na verejnú adresu, ktorú váš router preposiela serveru. Pri relayi udržiava server odchádzajúce spojenie k relay infraštruktúre a relay prijíma klientske spojenia a odovzdáva ich dátovú záťaž čakajúcemu serveru. Neotvára sa žiadny prichádzajúci port, nevyžaduje sa statická adresa a router zostáva nedotknutý. Z pohľadu firewallu je server bežný odchádzajúci klient, a preto ho reštriktívne siete povoľujú.

Relay pridelí tomu serveru názov vo svojej vlastnej doméne a klienti sa konfigurujú tak, aby sa pripájali tam.

Ten názov patrí relay službe, ktorá nie je Microsoft Azure VPN Gateway, aj keď sa obe volajú Azure niečo. Zaobchádzanie s nimi ako so zameniteľnými vedie ku konfigurácii, ktorá nemôže fungovať.

Ktoré protokoly relay prenesie

Relay prenáša protokol SoftEther a projekt dokumentuje SSTP ako klientsku možnosť, čo je užitočné, pretože Windows dodáva SSTP klienta. Nestáva sa však všeobecným nosičom pre každý listener na hostiteľovi: OpenVPN listener, IPsec responder a služba L2TP potrebujú každý svoj dostupný koncový bod a žiadny z nich sa neprenáša cez relay len preto, že je pripojený server SoftEther.

Klientske profily preto ukazujú na názov relayu, nie na adresu servera, a existujúci profil vytvorený pre priame pripojenie nebude fungovať bez zmien. Pred navrhovaním okolo protokolu, ktorý relay neprenáša, si pozrite zoznam podporovaných klientov pre verziu, ktorú prevádzkujete.

Čo relay za vás neurobí

Relay je prenos. Nevytvára používateľov, virtuálne huby, prístupové politiky ani trasy a nič nevie o privátnych sieťach za vaším serverom. Ak majú vzdialení klienti dosiahnuť podsiet LAN, server stále potrebuje konfiguráciu mosta alebo smerovania, spätnú cestu a firewallovú politiku, ktoré to umožňujú. Prekrývajúce sa adresné plány na oboch koncoch sú tiež pre relay neviditeľné a zostávajú vaším problémom na vyriešenie.

Podporované bezpečnostné nastavenia si tiež vyberáte sami. Dokumentácia projektu obsahuje príklady starších platforiem a kopírovanie zastaraných šifrovacích alebo certifikátových nastavení zo starého snímku obrazovky je dobrý spôsob, ako postaviť tunel, ktorý nikto nevie auditovať. Používajte aktuálne odporúčania pre verziu, ktorú prevádzkujete.

Validácia certifikátov a autentifikácia používateľov zostávajú zodpovednosťou servera a relay nikdy nenahradí ani jedno z nich.

Prevádzkujte to ako závislosť

Dostupnosť teraz zahŕňa tretiu stranu. Keď je relay nedostupný, klienti sa nepripoja bez ohľadu na to, aký zdravý je váš server, a zvonku to vyzerá ako problém klienta. Sledujte cestu cez relay oddelene od zdravia servera a majte zdokumentovanú zálohu, napríklad priamy listener na inej adrese, pre deň, keď na tom bude záležať.

Latencia sleduje geografiu relayu, nie blízkosť vašich používateľov, čo stojí za meranie predtým, ako sľúbite interaktívny výkon cez neho.

Overte identitu servera a potom skutočnú aplikačnú cestu, nie len úspešný banner pripojenia, a skontrolujte, či je zdroj, ktorý potrebujete, dostupný cez adresnú rodinu, ktorú relay prenáša. Zaznamenajte názov relayu, použitý protokol a zálohu, pretože tieto tri skutočnosti odpovedajú na väčšinu budúcich otázok o tomto prepojení.