Jakie protokoły ten publiczny węzeł VPN naprawdę oferuje?
To, że oprogramowanie serwera obsługuje protokół, nie oznacza, że ten węzeł go włączył. Sprawdź punkt końcowy, profil i etap, który naprawdę zawodzi.
Oprogramowanie go obsługuje, więc węzeł go oferuje. Ten wniosek jest błędny wystarczająco często, by stać się regułą: wdrożenie SoftEther może włączyć dowolny podzbiór swoich zgodnych metod połączenia, a publiczny węzeł to wdrożenie z właścicielem i konfiguracją. To, z czym możesz się połączyć, zależy od tego węzła, a nie od listy funkcji projektu, który uruchamia. Właśnie w luce między nimi żyje większość zgłoszeń „protokół jest zepsuty”.
Co naprawdę obiecuje lista projektu
Funkcje protokołów projektu opisują, co serwer potrafi. Dany węzeł włącza niektóre z tych nasłuchów, a inne nie, a operator może zmienić ten zbiór bez dotykania wersji oprogramowania. Dlatego dwa węzły tej samej kompilacji zachowują się różnie, a profil, który działa przeciw jednemu, nic nie dowodzi o kolejnym celu. Własna lista węzła ma większe znaczenie niż strona projektu, gdy wybierasz, gdzie się połączyć.
Czytaj listę jako pięć pól, nie jako menu: punkt końcowy, port, transport, rodzina protokołów i metoda uwierzytelniania. Publiczny węzeł, który reklamuje SSTP powiedział ci o nasłuchu na porcie; nie powiedział, jaki certyfikat przedstawia ani czy twoje konto tam działa. Porównanie tych pięciu pól z twoim profilem jest szybsze niż jakakolwiek reinstalacja klienta i daje pisemne oczekiwanie, które możesz później przetestować.
Dopasuj profil do punktu końcowego, który nazywa
Rodzimy wpis SoftEther nie jest automatycznie konfiguracją OpenVPN, nawet gdy oba pojawiają się na jednej stronie dostawcy pod jednym nagłówkiem. Gdy węzeł publikuje zarówno nasłuch TCP, jak i UDP dla OpenVPN, traktuj je jako dwa punkty końcowe: profil zmieniony z jednego na drugi wskazuje nasłuch, którego nikt nie włączył. Etykieta transportu w pliku jest częścią adresu, a nie ustawieniem kosmetycznym.
To, że klient akceptuje zaimportowany plik, dowodzi, że plik się parsuje. Nie mówi nic o tym, czy po drugiej stronie czeka zdalny nasłuch, dlatego pierwsza próba połączenia jest prawdziwym testem. Porównaj wiersz remote profilu z ogłoszonym hostem i portem węzła, zanim obwinisz protokół.
Zbadaj etap, który zawodzi
Host, który odpowiada na ruch sieciowy, nadal może nie mieć zamierzonej usługi VPN, a host, który odrzuca jeden protokół, niekoniecznie jest wyłączony dla wszystkich. Te dwa błędy wysyłają ludzi w przeciwnych kierunkach tego samego popołudnia. Jeden goni zaporę, która jest w porządku; drugi reinstaluje klienta, który nigdy nie był problemem. Zbadaj każdą ścieżkę osobno, aby odpowiedź opisywała jeden nasłuch, a nie całego hosta.
Te pięć kontroli obejmuje typowe metody publicznych węzłów. Wykonuj je z tej samej sieci, której używa klient, ponieważ filtrowany port wygląda z daleka identycznie jak brakujący nasłuch.
nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example| Wynik | Etap | Co to wyklucza |
|---|---|---|
| Połączenie odrzucone lub przekroczony czas | Transport | Brak nasłuchu, filtrowany lub zły port |
| Błąd uścisku dłoni TLS lub tożsamości | Certyfikat | Dostępność protokołu; nasłuch odpowiedział |
| AUTH_FAILED lub odrzucenie konta | Uwierzytelnianie | Punkt końcowy; problemem są dane logowania |
| UDP 500 i 4500 milczą | Negocjacja IPsec | ESP i L2TP są blokowane przed uwierzytelnianiem |
Przypisz każdy zaobserwowany błąd do jego wiersza, zanim cokolwiek zmienisz. Błąd tożsamości TLS dowodzi, że nasłuch istnieje, więc przepisanie profilu na inny protokół wyrzuciłoby działający dowód. Odrzucone połączenie dowodzi tylko, że ten port nie odpowiedział, co jest znacznie węższym twierdzeniem niż „węzeł nie obsługuje OpenVPN”.
Zachowaj błąd, zanim cokolwiek zmienisz
Zapisz dokładny wynik: przekroczenie czasu, błąd tożsamości certyfikatu, odrzucenie konta i odmowa na poziomie aplikacji to cztery różne wyniki. Tylko pierwszy dotyczy niedostępnego protokołu, a tylko ostatni dotyczy uprawnienia po udanym połączeniu. Zresetowanie klienta lub zmiana protokołu niszczy to rozróżnienie, ponieważ następna awaria przychodzi z inną historią i bez linii bazowej do porównania.
Nie osłabiaj weryfikacji, aby niezgodny profil wydawał się działać. Wyłączona kontrola certyfikatu zamienia wyraźny błąd tożsamości w połączenie z czymś, do czego nie zamierzałeś dotrzeć, a uzyskany sukces jest gorszy od pierwotnego błędu, ponieważ ukrywa, który etap był zły.
Sprawdzaj ponownie dla każdego węzła, za każdym razem
Rodzime opcje SSL, OpenVPN, L2TP/IPsec i SSTP na liście publicznych węzłów opisują konfigurację tego węzła w danej chwili. To samo oprogramowanie gdzie indziej może przedstawiać inny zestaw, a dostawca może wycofać nasłuch między twoją zakładką a następną próbą. Stare notatki opisują stare wdrożenia.
Zapisz zweryfikowany profil wraz z jego punktem końcowym i metodą, a następnie powtórz badanie, gdy węzeł się zmieni lub połączenie zacznie zawodzić. Specyfikacja protokołu SoftEther jest odniesieniem do tego, co oprogramowanie potrafi; własna lista węzła jest odniesieniem do tego, co robi. Trzymaj oba dokumenty osobno, a diagnoza staje się krótsza.