SoftEther VPN Azure: přenosová cesta přes relay, ne otevřený port

Váš server stojí za routerem, který nemůžete konfigurovat, takže zřejmý plán přesměrovat port není k dispozici. VPN Azure existuje právě pro takovou situaci a řeší ji obrácením směru prvního spojení: server se sám připojuje k relayi a klienti dosáhnou na relay místo na server. Pochopení tohoto obrácení vysvětluje, co služba řeší i každé omezení, na které později narazíte.

Co se v cestě mění

U běžného listeneru otevírá klient TCP spojení na veřejnou adresu, kterou váš router předává serveru. U relaye udržuje server odchozí spojení k relay infrastruktuře a relay přijímá klientská spojení a předává jejich data čekajícímu serveru. Neotevírá se žádný příchozí port, nevyžaduje se statická adresa a router zůstává nedotčen. Z pohledu firewallu je server běžný odchozí klient, a proto ho restriktivní sítě povolují.

Relay přidělí tomu serveru jméno na své vlastní domény a klienti se konfigurují tak, aby se připojovali tam.

To jméno patří relay službě, která není Microsoft Azure VPN Gateway, i když se obě jmenují Azure něco. Zacházet s nimi jako se zaměnitelnými vede ke konfiguraci, která nemůže fungovat.

Které protokoly relay přenese

Relay přenáší protokol SoftEther a projekt dokumentuje SSTP jako klientskou možnost, což je užitečné, protože Windows dodává SSTP klienta. Nestává se však obecným nosičem pro každý listener na hostiteli: OpenVPN listener, IPsec responder a služba L2TP potřebují každý svůj dostupný koncový bod a žádný z nich se relayem nepřenáší jen proto, že je připojen server SoftEther.

Klientské profily proto ukazují na jméno relaye, nikoli na adresu serveru, a existující profil postavený pro přímé připojení nebude fungovat beze změny. Projděte si seznam podporovaných klientů pro verzi, kterou provozujete, než budete navrhovat kolem protokolu, který relay nepřenáší.

Co relay za vás neudělá

Relay je přenos. Nevytváří uživatele, virtuální huby, přístupové politiky ani trasy a nic neví o privátních sítích za vaším serverem. Pokud mají vzdálení klienti dosáhnout podsítě LAN, server stále potřebuje konfiguraci mostu nebo směrování, zpětnou cestu a firewallovou politiku, díky kterým to funguje. Překrývající se adresní plány na obou koncích jsou pro relay také neviditelné a zůstávají vaším problémem k vyřešení.

Podporovaná bezpečnostní nastavení si také vybíráte sami. Dokumentace projektu obsahuje příklady starších platforem a kopírování zastaralých šifer nebo certifikátů ze starého snímku obrazovky je dobrý způsob, jak postavit tunel, který nikdo nedokáže auditovat. Používejte aktuální doporučení pro verzi, kterou provozujete.

Validace certifikátů a autentizace uživatelů zůstávají odpovědností serveru a relay je nikdy nenahradí.

Provozujte to jako závislost

Dostupnost teď zahrnuje třetí stranu. Když je relay nedostupný, klienti se nepřipojí bez ohledu na to, jak zdravý váš server je, a zvenku to vypadá jako problém klienta. Sledujte cestu přes relay odděleně od zdraví serveru a mějte zdokumentovanou zálohu, například přímý listener na jiné adrese, pro den, kdy na tom bude záležet.

Latence sleduje geografii relaye, ne blízkost vašich uživatelů, což stojí za změření, než slíbíte interaktivní výkon.

Ověřte identitu serveru a potom skutečnou aplikační cestu, ne jen úspěšný banner připojení, a zkontrolujte, zda je zdroj, který potřebujete, dostupný přes adresovou rodinu, kterou relay přenáší. Zaznamenejte jméno relaye, použitý protokol a zálohu, protože tyto tři skutečnosti odpovídají na většinu budoucích otázek o tomto spoji.