OpenVPN na porcie 53: trzy rozmowy, które ludzie mylą
Rozwiązywanie nazwy punktu końcowego, transport szyfrowany i DNS po tunelu to trzy rozmowy. Ustal, który etap zawiódł, zanim zmienisz port lub resolver.
Raporty mówiące, że VPN jest zablokowany na porcie 53, mieszają trzy obserwacje, które zawodzą z różnych powodów. Rozwiązywanie nazwy punktu końcowego odbywa się, zanim powstanie tunel, transport szyfrowany to osobna rozmowa, a zapytania DNS wykonywane później są trzecią. Każda ma własny podpis awarii, a tylko jedna z nich w ogóle dotyczy DNS.
Przed zmianą czegokolwiek posortuj pakiety według celu, bo poprawka podąża za etapem.
Trzy rozmowy, jeden numer portu
Pierwsza rozmowa to wyszukanie nazwy punktu końcowego: twoja maszyna pyta skonfigurowany resolver, gdzie znajduje się vpn.example.com, a odpowiedź przychodzi zwykłym DNS, zanim klient wyśle choćby jeden pakiet tunelu. Druga to sam transport OpenVPN, który łączy się z adresem uzyskanym z wyszukania, na protokole i porcie wskazanych przez profil. Trzecia odbywa się po podniesieniu tunelu, gdy aplikacje proszą o nazwy, a wypchnięte ustawienia resolvera decydują, kto odpowie.
Te trzy mogą zakończyć się sukcesem lub porażką niezależnie. Klient może doskonale rozwiązać swój punkt końcowy i nadal nie dotrzeć do nasłuchu, a także ustanowić tunel, gdy każde wewnętrzne wyszukanie nazwy zawodzi, bo ustawienia DNS nigdy nie dotarły.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Czytaj tabelę jako listę kontrolną, a nie jako opis. Jeśli nazwa punktu końcowego się nie rozwiązuje, nic później nie może działać, a tunel nigdy się nie zaczyna.
Numer portu nie nazywa aplikacji
Port 53 niesie DNS z konwencji, a operator OpenVPN może tam również opublikować nasłuch, i właśnie dlatego ten numer jest słabym identyfikatorem. Sesja OpenVPN na UDP 53 nadal jest sesją OpenVPN, a zapytanie DNS do serwera na porcie 53 nic nie mówi o tym, czy tunel jest dozwolony. Wiersze proto i remote profilu określają zewnętrzny punkt końcowy; numer portu sam niczego nie określa.
Przy diagnozie tnie to w obie strony: ogólna próba UDP na port 53 dowodzi, że odpowiada port, a nie że odpowiada usługa VPN. Testuj prawdziwym klientem i prawdziwym profilem, bo tylko to ćwiczy uścisk dłoni, którego oczekuje usługa.
Udowodnij nasłuch, zanim obwinisz sieć
Na serwerze sprawdź, co jest przypisane, za pomocą ss -lunp | grep 53 i porównaj z protokołem oraz portem profilu. Z sieci klienta uruchom klienta z większą szczegółowością, aby dziennik pokazał, którego adresu i transportu próbował. Jeśli serwer nasłuchuje, a pakiety klienta nie docierają, to ścieżka lub polityka je odrzuca, i to jest rozmowa z właścicielem sieci, a nie powód do zmiany portu.
Inny port pomaga tylko wtedy, gdy usługa naprawdę tam nasłuchuje i wdrożenie na to pozwala. Przenoszenie nasłuchu, aby ominąć filtrowanie zarządzanej sieci, jest decyzją polityki, a nie krokiem rozwiązywania problemów. Zapytaj właściciela sieci, co jest dozwolone, zanim zmienisz usługę, bo obejście łamiące politykę i tak zostanie później zamknięte. Zapisz tę odpowiedź obok profilu, aby następna osoba nie powtarzała prośby.
Sprawdź DNS po tunelu, osobno
Gdy tunel jest podniesiony, sprawdź stan resolvera na interfejsie VPN i odpytaj jedną nazwę wewnętrzną i jedną publiczną. Jeśli nazwy wewnętrzne zawodzą, gdy tunel niesie ruch, wypchnięte ustawienia DNS nie zostały zastosowane, co jest kwestią integracji klienta, a nie transportu. Jeśli nazwy publiczne zawodzą, a wewnętrzne działają, polityka podzielonego tunelu robi to, do czego została skonfigurowana.
Zmiany DNS zostaw właścicielowi resolvera. Nadpisanie zarządzanej konfiguracji resolvera, aby jeden test przeszedł, może zepsuć prywatne nazwy dla wszystkiego innego na maszynie. Jeśli tunel wypycha resolver, a klient go ignoruje, napraw integrację klienta zamiast dodawać statyczny wpis gdzie indziej. Statyczne wpisy ukrywają awarię, dopóki ktoś nie zmieni sieci. Zapisz, który resolver powinien odpowiadać za każdą przestrzeń nazw.