SoftEther VPN Azure: ścieżka przez przekaźnik, a nie otwarty port

Twój serwer stoi za routerem, którego nie możesz skonfigurować, więc oczywisty plan przekierowania portu jest niedostępny. VPN Azure istnieje właśnie dla tej sytuacji i rozwiązuje ją, odwracając kierunek pierwszego połączenia: serwer łączy się na zewnątrz z przekaźnikiem, a klienci docierają do przekaźnika zamiast do serwera. Zrozumienie tego odwrócenia wyjaśnia zarówno to, co naprawia usługa, jak i każdy limit, na który później natrafisz.

Co zmienia się na ścieżce

Przy zwykłym nasłuchu klient otwiera połączenie TCP do publicznego adresu, który router przekazuje do serwera. Przy przekaźniku serwer utrzymuje połączenie wychodzące do infrastruktury przekaźnika, a przekaźnik przyjmuje połączenia klientów i przekazuje ich ładunek czekającemu serwerowi. Żaden port wejściowy nie jest otwierany, nie jest wymagany adres statyczny, a router pozostaje nietknięty. Z punktu widzenia zapory serwer jest zwykłym klientem wychodzącym, dlatego restrykcyjne sieci go przepuszczają.

Przekaźnik przypisuje temu serwerowi nazwę w swojej własnej domenie, a klienci są konfigurowani tak, aby łączyli się właśnie tam.

Ta nazwa należy do usługi przekaźnika, która nie jest Microsoft Azure VPN Gateway, choć obie nazywają się Azure coś. Traktowanie ich jako wymiennych daje konfigurację, która nie może działać.

Które protokoły przetrwają przekaźnik

Przekaźnik przenosi protokół SoftEther, a projekt dokumentuje SSTP jako opcję klienta, co jest przydatne, ponieważ Windows dostarcza klienta SSTP. Nie staje się jednak uniwersalnym nośnikiem dla każdego nasłuchu na hoście: nasłuch OpenVPN, responder IPsec i usługa L2TP potrzebują własnego osiągalnego punktu końcowego, a żaden z nich nie jest przenoszony przez przekaźnik tylko dlatego, że serwer SoftEther jest połączony.

Profile klientów wskazują więc nazwę przekaźnika, a nie adres serwera, a istniejący profil zbudowany dla połączenia bezpośredniego nie będzie działał bez zmian. Sprawdź listę obsługiwanych klientów dla wersji, którą uruchamiasz, zanim zaprojektujesz rozwiązanie wokół protokołu, którego przekaźnik nie przenosi.

Czego przekaźnik za ciebie nie robi

Przekaźnik to transport. Nie tworzy użytkowników, wirtualnych koncentratorów, polityk dostępu ani tras i nic nie wie o sieciach prywatnych za twoim serwerem. Jeśli zdalni klienci muszą dotrzeć do podsieci LAN, serwer nadal potrzebuje konfiguracji mostu lub routingu, ścieżki powrotnej i polityki zapory, które to umożliwiają. Nakładające się plany adresowe na obu końcach są również niewidoczne dla przekaźnika i pozostają twoim problemem do rozwiązania.

Obsługiwane ustawienia zabezpieczeń również zależą od ciebie. Dokumentacja projektu zawiera przykłady starszych platform, a kopiowanie przestarzałych ustawień szyfrowania lub certyfikatów ze starego zrzutu ekranu to dobry sposób na zbudowanie tunelu, którego nikt nie może zaudytować. Korzystaj z aktualnych wskazówek dla wersji, którą uruchamiasz.

Walidacja certyfikatów i uwierzytelnianie użytkowników pozostają odpowiedzialnością serwera, a przekaźnik nigdy nie zastępuje żadnego z nich.

Eksploatuj go jako zależność

Dostępność obejmuje teraz stronę trzecią. Gdy przekaźnik jest nieosiągalny, klienci nie mogą się połączyć niezależnie od tego, jak zdrowy jest twój serwer, a awaria z zewnątrz wygląda jak problem klienta. Monitoruj ścieżkę przekaźnika oddzielnie od kondycji serwera i trzymaj udokumentowany plan awaryjny, taki jak bezpośredni nasłuch pod innym adresem, na dzień, w którym będzie to miało znaczenie.

Opóźnienie podąża za geografią przekaźnika, a nie bliskością twoich użytkowników, co warto zmierzyć, zanim obiecasz przez niego wydajność interaktywną.

Zweryfikuj tożsamość serwera, a następnie rzeczywistą ścieżkę aplikacji, nie tylko pomyślny baner połączenia, i sprawdź, czy potrzebny zasób jest osiągalny przez rodzinę adresów, którą przenosi przekaźnik. Zapisz nazwę przekaźnika, użyty protokół i plan awaryjny, ponieważ te trzy fakty odpowiadają na większość przyszłych pytań o to łącze.