SoftEther za NAT: bezpośrednie przejście czy przekaźnik VPN Azure?

Dynamiczny DNS, przejście NAT i VPN Azure wykonują różne zadania. Wybierz ścieżkę przed edycją użytkowników, a następnie potwierdź, którego transportu sesja faktycznie używa.

Twój serwer SoftEther stoi za routerem dostawcy, którego nie możesz zmienić, a klienci nadal się łączą, więc zakładasz, że przekaźnik niesie wszystko. Czy to prawda, zależy od tego, który mechanizm wykonał pracę: nazwa DNS, skoordynowana ścieżka UDP czy tunel wyjściowy do przekaźnika. Wszystkie trzy mogą dać połączonego klienta i zawodzą w różnych warunkach. Zdecyduj, którą ścieżkę kupujesz, zanim dotkniesz użytkowników lub koncentratorów.

Trzy mechanizmy, trzy różne obietnice

Dynamiczny DNS to nazewnictwo. Utrzymuje nazwę hosta skierowaną na zmieniający się adres, żeby ludzie przestali gonić numer, i nie robi nic więcej. Rodzime przejście NAT to koordynacja: dwa punkty końcowe SoftEther wymieniają informacje i próbują otworzyć użyteczną ścieżkę UDP przez urządzenia tłumaczące między nimi. VPN Azure to przekaźnik: serwer łączy się wychodząco z usługą, a klienci przychodzą przez nazwę hosta w infrastrukturze przekaźnika.

Te trzy się uzupełniają, a nie są wersjami jednej funkcji. Wdrożenie może używać nazewnictwa, podczas gdy jego połączenie faktycznie zależy od przejścia lub od przekaźnika.

Decyduj na podstawie klienta i sieci

Wybór zaczyna się od klienta, bo przejście istnieje tylko w rodzimym mechanizmie połączenia SoftEther. OpenVPN, L2TP/IPsec i nasłuchiwacze SSTP na tym samym serwerze go nie dziedziczą, choć dzielą hosta. Spójrz, co będzie uruchamiał użytkownik, a potem, co dopuszcza sieć. Sieć korporacyjna, która dopuszcza tylko TCP 443, popycha cię do przekaźnika na tym porcie, natomiast sieć przepuszczająca porty UDP potrzebne do przejścia może spróbować ścieżki bezpośredniej; potwierdź jedno i drugie wobec rzeczywistej polityki wyjścia.

Ręcznie osiągalny nasłuchiwacz to nadal uzasadniony projekt, gdy administrator może go opublikować, ale to osobny projekt z własnym adresowaniem i pracą przy zaporze.

Potwierdź, który transport wybrała sesja

Stan połączenia to jedyne uczciwe źródło informacji o używanej ścieżce. Odczytaj go na serwerze i rozwiąż nazwę hosta, którą otrzymał klient.

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

SessionList pokazuje, które sesje są połączone, a SessionGet na jednej z nich raportuje typ połączenia, w tym czy sesja przyszła przez przekaźnik. Rekord, który rozwiązuje się na infrastrukturę przekaźnika, mówi ci, że sesja przechodzi przez stronę trzecią, co możesz potwierdzić, blokując tę trasę w teście. Z rodzimym klientem akceleracja UDP może odsunąć ścieżkę danych od ścieżki sterowania, więc jedna obserwacja nie opisuje całej sesji. Nieaktualna dynamiczna nazwa DNS po zmianie adresu i przekaźnik, który odpowiada, gdy brakuje trasy do backendu, to dwa tryby awarii warte osobnego przetestowania. Zapisz to, co zmierzyłeś, a nie to, co zamierzał projekt.

Zaplanuj, od czego zależy wybrana ścieżka

Każda ścieżka niesie zależność. Bezpośrednie przejście może się zmienić po przejściu sieciowym lub nowym urządzeniu tłumaczącym, natomiast sesja przekaźnika zawodzi, gdy zawodzi usługa lub jej osiągalny port. Połącz się ponownie z innej sieci i potwierdź tożsamość serwera, którą zweryfikował klient, zachowując wcześniej działającą ścieżkę w tym samym teście. Następnie przetestuj prywatny zasób za VPN, bo autoryzacja, członkostwo w koncentratorze, przydział adresów i trasy powrotne i tak pozostają twoją odpowiedzialnością.

Zapisz nazwę hosta, protokół, ustawienia funkcji i zaobserwowany transport. Właśnie ten czteroczęściowy zapis pozwala następnej osobie odtworzyć działające połączenie.

Powiązane artykuły