DNS przez VPN przejmuje każde zapytanie: popraw dns-priority w NetworkManagerze

Podłącz VPN biurowy i nagle każde zapytanie o nazwę trafia do firmowego resolvera. Nazwy publiczne nadal się rozwiązują, więc nic nie wygląda na zepsute, dopóki nie zawiedzie nazwa lokalnej drukarki albo rekord split-horizon nie zwróci adresu biura. W niektórych instalacjach Fedory dzieje się odwrotnie: resolver dostawcy nadal odpowiada po podniesieniu tunelu. Jedno i drugie to jedno pytanie — który resolver jest właścicielem tego zapytania — a w systemach NetworkManager odpowiedź mieszka we właściwościach DNS każdego połączenia.

Dwa połączenia, jeden zwycięski resolver

Każde połączenie deklaruje priorytet DNS. Połączenia zwykłe mają domyślnie 50, a połączenia VPN 0, i wygrywa niższa wartość. Właśnie ten domyślny priorytet sprawia, że połączenie VPN po cichu wyprzedza połączenie kablowe dla każdej domeny, której rości sobie prawo: zero bije pięćdziesiąt, choć nikt tego nie wybrał.

Priorytet porządkuje kandydatów. Nie ogranicza, o co pyta się zwycięzcę. Połączenie VPN bez domeny wyszukiwania rości sobie wszystko, więc preferowanie go wysyła także zapytania publiczne do tunelu, a w projekcie tunelu dzielonego tam, dokąd przekazuje firmowy resolver.

Priorytet ustala kolejność, lista wyszukiwania — własność

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Lista wyszukiwania to deklaracja własności. Naga domena, taka jak corp.example, staje się sufiksem wyszukiwania i domeną routingu. Forma tylko do routingu ~corp.example wysyła zapytania pod tym sufiksem do tego połączenia, nie dodając domeny do krótkich nazw. Ta tylda to różnica między „spytaj ten serwer” a „spytaj ten serwer i dokończ moje pisanie”.

Używaj obu form, gdy użytkownicy wpisują krótkie nazwy hostów, a rekordy są adresowane także pełnymi nazwami kwalifikowanymi. Używaj tylko formy routingu, gdy chcesz podziału bez zmiany tego, jak resolver dopełnia nagą nazwę.

Następnie uczyń preferencję jawną i aktywuj połączenie ponownie:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Priorytet ujemny to udokumentowany sposób powiedzenia „preferuj to połączenie”, a ustawienie obu rodzin adresów utrzymuje spójne zachowanie na hoście z łącznością IPv6. Zmiana właściwości bez ponownej aktywacji połączenia nie zmienia niczego z tego, co działa teraz, dlatego sekwencja kończy się jawnym up.

Pozwól systemd-resolved utrzymać podział

Domyślna wtyczka dnsmasq wtłacza zapytania do jednego lokalnego resolvera, więc rozdzielenie na łącza pozostaje zgrubne. systemd-resolved pokazuje podział na łącza, a resolvectl query nazywa łącze, które odpowiedziało.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Potem łącze firmowe niesie corp.example, a publiczny resolver obsługuje resztę. Gdy zapytanie trafi na niewłaściwe łącze, polecenie nazywa łącze, które na nie odpowiedziało, i wiedza o tym jest lepsza niż znajomość samego adresu.

Dopasuj projekt DNS do typu tunelu

Projekty prywatności, które wysyłają wszystko przez tunel, nie powinny mieć listy podziału, bo oddałaby publiczne nazwy lokalnemu resolverowi i zniweczyła zamiar. Projekty tunelu dzielonego jej potrzebują: bez niej firmowy resolver widzi każde publiczne zapytanie, a konfiguracja psuje się w chwili, gdy tunel pada.

Jest też kill switch, który blokuje DNS poza tunelem. Nazwy rozwiązują się dla stref tunelu i zawodzą wszędzie indziej, choć połączenie jest całkowicie zdrowe. Realne odpowiedzi to wyraźne pozwolenie dla resolvera LAN albo lokalna pamięć podręczna przekazująca tylko strefę firmową, i każde z nich jest wyjątkiem z właścicielem, a nie usterką tunelu.

Profil, który przy starcie interfejsu przepisuje konfigurację resolvera, zachowuje się niemal tak samo: gdy lokalny resolver staje się nieosiągalny, rozwiązują się tylko nazwy znane tunelowi. Niezależnie od mechanizmu zapisz, które nazwy mają działać w którym stanie, i przekaż tę listę osobie obsługującej zgłoszenia.

Sprawdź na łączach, a potem jeszcze raz po ponownym połączeniu

Zapytaj o jedną nazwę wewnętrzną i jedną publiczną, i zobacz, dokąd zapytanie naprawdę trafia. Strona kontroli wycieków mówi, który resolver odpowiedział, a nie które łącze wybrał system, więc nic nie mówi o kolejności, którą właśnie ustawiłeś.

Uruchom oba zapytania ponownie po rozłączeniu i ponownym połączeniu. Priorytety są stosowane od nowa, gdy połączenie się aktywuje, a stare dowiązanie symboliczne może przetrwać aktualizację, której nikt nie pamięta. To, co chcesz mieć zapisane na końcu, to który resolver jest właścicielem którego sufiksu, plus sprawdzenie, które będzie aktualne także jutro.