Natywny klient SoftEther czy profil OpenVPN: wybierz właściwy port

Serwer SoftEther może jednocześnie odpowiadać na natywnym porcie SSL i na porcie zgodnym z OpenVPN, przez co oba wyglądają jak jedna usługa z dwojgiem drzwi. To dwie usługi z różnymi klientami, różnymi formatami konfiguracji i różnymi możliwościami. Wstawienie natywnego profilu do klienta OpenVPN kończy się niepowodzeniem podczas analizy, a błąd rzadko mówi dlaczego.

Najpierw wybierz nasłuch, potem klienta.

Dwa nasłuchy, dwa formaty konfiguracji

Protokół natywny używa klienta SoftEther i definicji połączenia, która nazywa serwer, port, wirtualny hub i użytkownika. Nasłuch zgodny z OpenVPN oczekuje profilu OpenVPN z dyrektywą remote, materiałem TLS i opcjami z dużo mniejszego obsługiwanego zestawu, niż oferuje samodzielny serwer OpenVPN. SoftEther nazywa to funkcją klonu OpenVPN, a klon to przydatna wskazówka co do wierności.

Zgodność to kwestia wersji. Sprawdź, co akceptuje wdrożona kompilacja, a nie co dokumentuje aktualny podręcznik OpenVPN.

Krok 1: ustal, który nasłuch włączył operator

Poproś o listę nasłuchów, zamiast zgadywać z numeru portu. Serwer odpowiadający przez TLS na 443 niekoniecznie jest punktem końcowym OpenVPN, ponieważ protokół natywny może używać tego samego portu. Sekcja podręcznika o zgodnych funkcjach serwera opisuje, jakie klony istnieją i jak się je włącza.

Jeśli możesz dotrzeć do hosta, przetestuj port, który ci podano, a nie port z poradnika: openssl s_client -connect vpn.example.com:443 -brief przynajmniej mówi, czy TLS tam jest.

Krok 2: użyj pasującego klienta i profilu

Dla dostępu natywnego zainstaluj klienta SoftEther, utwórz połączenie z danymi operatora i podłącz wirtualny adapter. Dla zgodnego nasłuchu zaimportuj profil OpenVPN wyeksportowany przez operatora z serwera, ponieważ zawiera materiał CA i klienta, którego ten nasłuch oczekuje. Nie składaj profilu ręcznie z ogólnego przykładu i nie wklejaj natywnej definicji połączenia do konfiguracji OpenVPN.

Błąd analizy przy imporcie to problem formatu, nie sieci, i nie powinien wysyłać cię do zapory.

Krok 3: zachowaj uczciwe porównanie

Jeśli operator publikuje oba, porównuj je, utrzymując urządzenie, sieć dostępu i zadanie bez zmian. Dwie ścieżki mogą się różnić uwierzytelnianiem, podsieciami, do których się podłączają, i tym, co serwer później robi z twoim ruchem. Wspólny host to nie wspólna zasada. Utrzymaj też zadanie bez zmian, ponieważ kopiowanie pliku i rozmowa wideo obciążają różne części tej samej ścieżki.

Opieraj się poprawkom, które pojawiają się za każdym razem, gdy import się nie powiedzie. Wyłączanie sprawdzania certyfikatów lub włączanie starych szyfrów, by przepchnąć profil, to regresja, nie funkcja zgodności.

Krok 4: zweryfikuj ścieżkę po połączeniu

Po połączeniu sprawdź otrzymany adres, trasy, które przyszły razem z nim, DNS i jeden zasób wewnętrzny. Po stronie natywnej wirtualny adapter jest interfejsem do sprawdzenia; po stronie OpenVPN jest to urządzenie tun lub tap utworzone przez klienta. Tak czy inaczej pytanie brzmi, czy wybrany nasłuch daje dostęp, którego potrzebujesz, co jest osobnym faktem od tego, czy tunel się podniósł. Zapisz adres przed i po, i porównaj je.

Zanotuj, który nasłuch i która wersja klienta dały działający wynik. Inaczej następna osoba powtórzyłaby odkrycie od numeru portu w górę.