OpenVPN wysyła DNS, ale twój resolver może go nigdy nie zobaczyć

Log klienta pokazuje wysłany serwer DNS, tunel jest połączony, a nazwa wewnętrzna nadal się nie rozwiązuje. W samym wysyłaniu nic nie jest zepsute. Opcja dotarła, a resolver systemu operacyjnego nigdy jej nie użył, ponieważ w większości klientów Unix OpenVPN przekazuje wartość i zostawia aplikację platformie.

Objaw: log pokazuje DNS, a nazwy nadal zawodzą

OpenVPN dhcp-option przenosi informacje o DNS i domenie, a klient zapisuje, co otrzymał. W niektórych implementacjach klient stosuje te ustawienia wewnętrznie; w innych eksportuje je dla skryptu integracyjnego lub usługi sieciowej. Wiersz logu opisuje tylko pierwszą połowę historii. Druga połowa dzieje się tam, gdzie klient nie ma kontroli. Tam zwykle mieszka awaria.

Dlatego połączony tunel i zawodząca nazwa wewnętrzna tak często współistnieją. Wartość jest, konsumenta brakuje albo jest źle skonfigurowany, a resolver po cichu nadal używa publicznego serwera, którego używał przed połączeniem.

Odebrane to nie zastosowane

Klient może zalogować wysłaną wartość DNS, podczas gdy resolver systemowy nadal należy do innej usługi. Przeglądarka może też mieć własną politykę szyfrowanego DNS, która całkowicie omija resolver systemowy, co daje pamiętną sytuację, w której jedna aplikacja rozwiązuje nazwy wewnętrzne, a inna nie.

Sprawdź obsługiwaną integrację implementacji, zamiast zakładać, że każdy klient Unix przepisuje ten sam plik. To założenie jest powodem, dla którego ludzie edytują konfigurację resolvera, której nic nie czyta.

Znajdź właściciela resolvera na każdej platformie

W Windows tabela zasad rozwiązywania nazw może kierować określone sufiksy do określonych serwerów, a klient VPN może tam instalować reguły. Sprawdź zasady, nie tylko listę DNS adaptera. W Linux konfiguracją może zarządzać NetworkManager albo systemd-resolved, a to, który z nich to robi, decyduje, co zachowa ponowne połączenie.

Odczytaj stan rzeczywisty narzędziem, które naprawdę odpowiada na zapytania: resolvectl query internal.example.net na hoście z systemd-resolved albo odpowiednikiem platformy. Następnie porównaj tę odpowiedź z serwerem DNS, który według logu klienta został wysłany.

Unikaj uruchamiania kilku usług, które bez koordynacji nadpisują ustawienia resolvera. Dwaj właściciele dają wynik, który wygląda na przerywany, a każde ponowne połączenie zdaje się go losowo naprawiać lub psuć.

Skrypty i foreign_option

OpenVPN eksportuje wysłane opcje do skryptów przez zmienne o nazwie foreign_option_N, a skrypt może przetłumaczyć je na polecenia resolvera. Ten układ jest obsługiwaną integracją, nie automatycznym zachowaniem, i trzeba go zainstalować oraz wywołać na kliencie.

Jeśli polegasz na skrypcie, zapisuj jego wykonanie i kod wyjścia. Skrypt, który działa, ale po cichu zawodzi, pozostawia ten sam objaw co brak skryptu, i trudniej go zauważyć, bo konfiguracja wygląda na kompletną. Sprawdzaj wyjście skryptu, nie plik skryptu. Istniejący plik to nie skrypt, który zadziałał.

Testuj nazwę, nie log

Po połączeniu zapytaj klienta o nazwę hosta dostępną tylko wewnętrznie, potem o nazwę publiczną, a następnie sprawdź, który serwer odpowiedział. W działającej konfiguracji obie odpowiedzi pochodzą z różnych miejsc i obie powinny zgadzać się z projektem.

Jeśli nazwa się rozwiązuje, ale usługa zawodzi, przejdź do routingu i dostępu aplikacji zamiast ponownie zmieniać DNS. Podręcznik OpenVPN dokumentuje dhcp-option i środowisko skryptów; użyj go, aby potwierdzić, co twój klient ma stosować, zanim edytujesz kolejny plik resolvera.