proto udp czy tcp-client: który słyszy twój serwer?

Profil, który działał w zeszłym miesiącu, teraz kończy się przekroczeniem czasu, a ktoś proponuje zmianę proto udp na proto tcp-client. Czasem to właściwy krok, a czasem powstaje klient, który łączy się z portem, na którym nic nie nasłuchuje, bo serwer nigdy nie został skonfigurowany dla drugiego transportu. Dyrektywa opisuje, jak mówi twoja strona; nie może utworzyć nasłuchu po drugiej stronie. Przeczytaj profil i serwer razem, zanim zmienisz którykolwiek z nich.

Przeczytaj transport używany przez wybrane połączenie

Profil może zawierać kilka wpisów remote, a każdy może wskazywać własny transport. Klient przechodzi je po kolei, więc wiersz widziany jako pierwszy niekoniecznie jest tym, który obowiązuje.

Znajdź wpis, który jest faktycznie próbowany, a następnie przeczytaj jego transport. Kolejność ma znaczenie, ponieważ klient nie przechodzi dalej po cichu. Niektóre kompilacje próbują następnego wpisu dopiero po przekroczeniu czasu, więc działająca alternatywa na dole pliku jest osiągana kilka sekund później, niż się spodziewasz. Śledź w dzienniku, który punkt końcowy jest próbowany, zamiast zakładać, że wygrał pierwszy wiersz.

Jeśli plik ma jeden wiersz proto u góry i kilka wpisów remote poniżej, ten wiersz jest wartością domyślną dla każdego remote, który go nie nadpisuje. Lokalna zmiana wartości domyślnej nic nie daje wpisowi remote, który wskazuje własny transport.

grep -nE '^(remote|proto)\b' client.ovpn

UDP i TCP nie są ustawieniem prędkości

UDP wysyła datagramy bez budowania uporządkowanego strumienia, więc ruch samego tunelu nie jest pakowany w drugi niezawodny transport. TCP daje ścieżkę przez sieci, które odrzucają lub blokują UDP, kosztem zagnieżdżonej retransmisji, która może sprawić, że łącze z utratą pakietów będzie odczuwane gorzej.

To wymiana osiągalności, a nie uniwersalny ranking. Właściwy wybór to ten, na który pozwala sieć przed klientem. Ścieżka, która odrzuca UDP na porcie VPN, nigdy się nie dogada, niezależnie od tego, jak dobrze napisany jest profil. Przetestuj ścieżkę, a potem wybierz transport.

Wybieranie między nimi wyłącznie na podstawie pomiaru jest błędem, bo odpowiedź zależy od tego, na co pozwala sieć przed tobą. Hotel lub firmowe proxy może zezwalać tylko na wychodzący TCP na 443 i nic więcej, dlatego dostawcy oferują ten wariant. To nadal połączenie OpenVPN na tym porcie, a nie sesja HTTPS, nawet jeśli numer portu jest znajomy.

Co naprawdę oznacza tcp-client

Dyrektywa po stronie klienta nazywa stronę inicjującą połączenie TCP. Strona serwera używa własnej formy nasłuchu, a skopiowanie słowa klienta do konfiguracji serwera tworzy nasłuch, który oczekuje połączenia przychodzącego, a nie taki, który je przyjmuje.

Dopasowanie oznacza, że obie strony zgadzają się co do transportu, a nie że dzielą ten sam ciąg.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Zapytaj serwer, na czym nasłuchuje, zanim uznasz profil za błędny. Nasłuch UDP nie pojawia się na liście gniazd TCP i odwrotnie również jest prawdą, więc patrz na widok właściwy dla protokołu, a nie ogólny.

Gdy profil się importuje, ale nigdy nie łączy

Zaimportowany profil, który od razu kończy się przekroczeniem czasu, zwykle zawodzi przed jakimkolwiek uwierzytelnieniem. Pakiet trafia do portu bez nasłuchu albo sieć po cichu go odrzuca.

Przetestuj ścieżkę najprościej, jak to możliwe: połącz się z tym samym hostem i portem z transportem, który deklaruje profil, z tej samej sieci co zawodzący klient.

Jeśli test UDP nic nie otrzymuje, a test TCP się łączy, serwer oferuje drugi transport, a profil jest po prostu przestarzały. Jeśli żaden nie odpowiada, problem leży wyżej niż wybór transportu i żadna edycja profilu go nie naprawi. Rozróżnienie tych dwóch przypadków zajmuje minutę i oszczędza godzinę debugowania certyfikatów, które nigdy nie było istotne.

Zapisz działający transport

Gdy kombinacja działa, zapisz ją wraz z serwerem, portem i protokołem oraz zaznacz, z której sieci ją testowano.

W przeciwnym razie następna osoba, która natrafi na przekroczenie czasu, powtórzy ten sam eksperyment w drugą stronę i być może zmieni serwer, który był w porządku.

Jeśli dostawca publikuje oba warianty, zachowaj oba pliki i oznacz je według sieci, do której pasują. Dwa jasno nazwane profile zapobiegają przypadkowemu pomieszaniu transportu klienta z nasłuchem serwera, który nigdy nie został dla niego skonfigurowany.