OpenVPN wysłał serwer DNS, ale Linux go ignoruje

Wysłany serwer DNS jest w logu, tunel działa, a wewnętrzne nazwy nadal zawodzą. W samym wysyłaniu nic nie jest zepsute; ustawienie dotarło i tam się zatrzymało. Wysłana opcja DNS to komunikat do klienta, a nie polecenie dla resolvera systemu operacyjnego, i właśnie przekazanie między nimi jest miejscem, w którym kończy się większość takich przypadków. Pięć kontroli, po kolei, znajduje przekazanie, do którego nie doszło.

Kontrola pierwsza: jak zaczyna się połączenie

Właściciel połączenia decyduje, kto może zastosować ustawienia resolvera. Bezpośrednie polecenie openvpn z powłoki nie posiada niczego poza własnym procesem, podczas gdy jednostka systemd, NetworkManager albo klient dostawcy mają każdy własny sposób publikowania DNS. Przeczytaj listę procesów i nazwę jednostki, zanim którekolwiek z nich założysz.

Proces z wiersza poleceń nie jest automatycznie połączeniem NetworkManagera, a połączenie NetworkManagera nie jest automatycznie tym, co napisało resolv.conf. Te dwa założenia wyjaśniają większość zmarnowanych godzin w tym dochodzeniu. Zapytaj, który komponent opublikowałby DNS dla interfejsu, który naprawdę widzisz.

Zapisz właściciela, zanim przejdziesz dalej. Każda późniejsza kontrola od niego zależy.

Kontrola druga: co tak naprawdę zawiera połączenie resolvera

Na hoście z systemd-resolved resolvectl status wylicza każde połączenie wraz z jego serwerami DNS i domenami. Znajdź połączenie tunelu i przeczytaj jego wpisy, i nie zakładaj, że interfejs nazywa się tun0, bo numeracja idzie w kolejności tworzenia. Jeśli wysłanego adresu nie ma na połączeniu, zawiodło przekazanie, a nie zapytanie.

Jeśli adres jest obecny, następne pytanie brzmi, jakie domeny rości sobie to połączenie. Połączenie bez listy domen odpowiada tylko na nazwy, o które pyta się bezpośrednio, a to rzadko jest tym, czego chce wdrożenie split-DNS. Sam adres jest konieczny, ale niewystarczający.

Porównaj nazwę połączenia w wyniku resolvera z nazwą interfejsu w logu VPN, zanim wyciągniesz jakikolwiek wniosek. Niezgodność tam zwykle oznacza, że wiersz logu pochodzi z innego procesu.

Kontrola trzecia: czy przestrzeń nazw wybiera to połączenie

Resolver może mieć właściwy serwer i mimo to nie być pytany. Domena na połączenie decyduje, które zapytania idą do którego połączenia, a bez domeny routingu prywatna przestrzeń nazw wraca do tego, co mówi połączenie domyślne. Dlatego resolvectl query dla nazwy wewnętrznej może się udać, podczas gdy aplikacja nadal zawodzi. Aplikacja może używać zupełnie innej ścieżki resolvera.

Sprawdź przypisanie domeny, nie tylko adres serwera. Domena zapisana jako ~corp.example jest domeną routingu, a tylda zmienia sposób dopasowywania nazwy.

Jeśli aplikacja ma własny resolver, testuj tym samym mechanizmem, którego używa ona, a nie narzędziem systemowym. Narzędzie zapytań omijające systemowy resolver zadziała niezależnie od stanu połączenia.

Kontrola czwarta: jeden właściciel, a nie dwóch

Jeśli NetworkManager już zarządza VPN i stanem resolvera, dodanie niepowiązanego skryptu hook tworzy konkurujących pisarzy. Hook dostarczany przez pakiet dla systemd-resolved jest wspieraną integracją i oczekuje określonego cyklu życia: script-security 2, ścieżka up, up-restart, ścieżka down i down-pre. Te opcje sprawiają, że rejestracja i usuwanie następują w odpowiednich momentach, a nie tylko przy pierwszym połączeniu.

Użyj zainstalowanej ścieżki z pakietu, a nie ilustracyjnej skopiowanej z poradnika. Uprawnienia też mają znaczenie, bo hook działa po obniżeniu uprawnień.

Edytowanie skryptu resolvera dystrybucji, aby zmienić jego cel wyjściowy, zapisuje obejście dla jednego hosta. To nie jest ogólna naprawa.

Kontrola piąta: ten sam wynik po ponownym połączeniu

Połącz się ponownie i przeczytaj połączenie jeszcze raz. Rejestracja, która pojawia się raz i znika przy następnym przejściu, to awaria, dla której istnieje cała ta lista kontrolna. Testuj po uśpieniu, po wymuszonym ponownym połączeniu i po restarcie usługi resolvera. Każde przejście sprawdza inne założenie o kolejności.

Dopiero gdy wszystkie pięć kontroli przejdzie przy ponownym połączeniu, możesz powiedzieć, że wysłane ustawienia są w użyciu. Wszystko wcześniej to migawka szczęśliwego momentu.