OpenVPN działa w domu, ale nie w jednej sieci: UDP czy TCP?

Ten sam profil łączy się z domu i zatrzymuje w sieci hotelowej, kampusowej lub oddziału. Dane logowania się nie zmieniły, więc ciekawą zmienną jest ścieżka: co dzieje się z pakietami, zanim OpenVPN je odczyta. Porównanie czterech możliwych przyczyn w kolejności, w jakiej można je sprawdzić, jest lepsze niż zgadywanie na temat certyfikatów. Każda zostawia inny ślad, a to ślad je rozróżnia.

To, który etap zawiódł, mówi, które porównanie ma znaczenie

Log klienta już zapisuje, jak daleko dotarłeś. Wiersz mówiący, że negocjacja klucza TLS nie nastąpiła w limicie czasu, oznacza, że pierwszy pakiet wyszedł i nic użytecznego nie wróciło, co wskazuje na ścieżkę. Odrzucenie certyfikatu wygląda zupełnie inaczej: przychodzi odpowiedź, a potem konkretny błąd weryfikacji podaje przyczynę. Zanotuj ostatni wiersz przed pętlą ponowień, bo to jest wartość, którą porównujesz między sieciami.

Przechwytuj podczas ponawiania, a nie po fakcie. Na kliencie tcpdump -ni any udp port 1194 pokazuje, czy w ogóle wraca jakakolwiek odpowiedź. Powtórz to na interfejsie WAN serwera, którym zarządzasz, co ujawnia, czy te pakiety w ogóle docierają do drugiego końca.

Ruch jednostronny to najużyteczniejszy dostępny tu wynik, bo zamienia sporadyczną skargę w kierunek dochodzenia. Zachowaj pliki przechwytywania, bo następne zgłoszenie tego samego problemu łatwiej zamknąć dowodami niż opisem.

Filtrowanie UDP a zamknięty port

Wiele sieci dostępowych uważa utrzymujący się UDP za podejrzany, a niektórzy ISP się z tym zgadzają. Zamknięty port daje tę samą ciszę po stronie klienta. Różnica to selektywność: filtr bywa wybredny co do tego, które cele lub porty odrzuca, podczas gdy zamknięty port odrzuca wszystko skierowane do tego jednego portu.

Profil TCP na porcie 443 to zwykłe obejście, bo przypomina zwykły strumień HTTPS i przechodzi przez większość portali captive i filtrów wyjściowych. Muszą być spełnione dwa warunki. Serwer musi nasłuchiwać z proto tcp-server a klient musi się dopasować z proto tcp-client, a operator musi opublikować ten alternatywny endpoint. Przepisanie działającego profilu UDP na TCP 443 nic nie daje, gdy po drugiej stronie nic nie nasłuchuje.

Zamknięty port to problem konfiguracji, a nie cenzury. Serwer za domowym routerem potrzebuje przekierowania portu UDP, a zapora routera musi je dopuścić. Gdy port nigdy nie był dozwolony, każdy klient zawodzi na negocjacji niezależnie od danych logowania, a awaria podąża za serwerem, a nie za siecią.

Starsze protokoły wypadają na tym polu słabo. PPTP wymaga TCP 1723 plus GRE, a GRE to protokół IP 47, a nie port, więc zwykłe przekierowanie portu tego nie wyraża.

Gdy to przełącznik gubi pakiety

Zarządzany przełącznik może celowo gubić tunel. Niektóre modele HPE i Aruba udostępniają kontrolkę ochrony przed floodem UDP, czasem oznaczoną Prevent UDP Blat Attack, w sekcji zaawansowanego bezpieczeństwa. Gdy ta kontrolka jest aktywna, serwer za przełącznikiem nie odpowiada na nic, a każdy klient kończy się przekroczeniem czasu w ten sam sposób. Wyłączenie jej i zapisanie bieżącej konfiguracji to cała naprawa, ale dopiero po ustaleniu, że przełącznik naprawdę znajduje się na ścieżce.

Kontrdowody odróżniają gubienie przez przełącznik od blokady dostawcy. Przeczytaj liczniki interfejsu i log ochrony przed floodem, zanim otworzysz zgłoszenie u ISP. Routery konsumenckie z ochroną DoS lub floodem zawodzą w tej samej formie, podobnie jak każdy pośrednik z krótkim limitem bezczynności UDP. Uścisk dłoni, który nigdy się nie kończy, sugeruje gubienie, a tunel, który ginie po kilku minutach ciszy, sugeruje limit czasu.

Zapisz każde urządzenie między klientem a serwerem, zanim zmienisz profil. Poprawka zastosowana na złej warstwie wygląda dobrze do następnej sieci. Ta lista mówi też następnemu inżynierowi, gdzie patrzeć, bez powtarzania całego dochodzenia.

Nakładanie się adresów, które wygląda jak awaria DNS

Sieć dostępowa numerowana w 10.0.0.0/8 może nakładać się na pulę tunelu, a resolver zwykle mieszka w tej puli. Gdy laptop otrzymuje adres taki jak 10.184.178.50 z maską /8 w Wi-Fi, każde miejsce docelowe 10.x jest z definicji lokalne. Pakiety do 10.4.0.1 idą wtedy do LAN, tunel pozostaje aktywny, a rozwiązywanie nazw zawodzi.

ip addr ujawnia nakładanie na pierwszy rzut oka, a ip route get 10.4.0.1 pokazuje, gdzie pakiet naprawdę zostałby dostarczony. Ponieważ widocznym objawem jest awaria resolvera, często przetrwa ona kilka rund zmian DNS.

Ponownie ponumeruj pulę albo trzymaj tę sieć dostępową poza zakresem. Żadne ustawienie po stronie klienta nie naprawia nakładania.

Wybór między awaryjnym TCP a naprawą ścieżki

Wybierz awaryjne TCP, gdy nie kontrolujesz ścieżki, a użytkownicy muszą pracować dziś, i zaakceptuj jego koszty: TCP w TCP zachowuje się źle na łączach z utratą pakietów, a awaryjny profil wymaga listenera, który obsługujesz. Wybierz naprawę ścieżki, gdy blokada leży na twojej infrastrukturze, bo reguła zapory jest tańsza niż drugi listener. Tak czy inaczej przejdź przez warstwy po kolei: łącze, transport zewnętrzny, negocjacja, routing wewnętrzny. Etap, który zawiódł w tej sieci, to jedyny fakt, który ma znaczenie.

Zapisuj wynik według sieci, a nie według użytkownika. Następne zgłoszenie tej samej awarii zaczyna się wtedy od znanego etapu, a nie od teorii certyfikatów. Ten zapis jest też tym, co uzasadnia stały drugi listener, jeśli kiedykolwiek będzie potrzebny.