Kolejność wpisów w Debian resolvconf: wpis VPN na pierwszym miejscu

Serwer nazw VPN wciąż ląduje poniżej tego z LAN, a edycja /etc/resolv.conf naprawia to na kilka minut. Ten plik jest generowany, więc poprawka nigdy się nie utrzymuje. W resolvconf Debiana wejściem sortowania jest /etc/resolvconf/interface-order i sortuje on nazwy wpisów, a nie adresy DNS. Zanim dotkniesz któregokolwiek z dwóch plików, potwierdź, który stos resolvera naprawdę rządzi.

Potwierdź, że resolvconf posiada wynik

Zacznij od pytania, co zapisało bieżący plik i co zapisze go ponownie. Pakiet resolvconf opisuje siebie jako szkielet dynamicznej konfiguracji resolvera, a host z systemd-resolved lub resolverem zarządzanym przez NetworkManager może wyglądać z zewnątrz tak samo, a stosować zupełnie inną politykę.

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

Jeśli rozwiązana ścieżka nie prowadzi do katalogu uruchomieniowego resolvconf, zatrzymaj się tutaj: ten poradnik należy do innego stosu.

Dopiero po tym sprawdzeniu warto wypisać wpisy, które resolvconf obecnie trzyma.

Przeczytaj wpisy, zanim napiszesz wzorce

interface-order dopasowuje nazwy wpisów dostawcy, a nie adresy i nie nazwy interfejsów jądra. Wypisz, co jest zarejestrowane, aby twoje wzorce odwoływały się do istniejących pozycji.

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

Nazwa wpisu zwykle zawiera przyrostek identyfikujący dostawcę, więc wpis tunelu i wpis DHCP mogą dzielić prefiks interfejsu, a mimo to sortować się inaczej. Skopiuj dokładne nazwy z listingu katalogu. Nie wnioskuj nazwy z nazwy interfejsu, bo to integracja klienta decyduje, co zostanie zarejestrowane. Wymyślona nazwa nigdy nie pasuje, a wpis trafia do wzorca łapiącego wszystko, bez żadnego komunikatu o błędzie.

Zapisz kolejność jako wzorce pierwszego dopasowania

Plik jest listą wzorców glob powłoki, po jednym w wierszu. Wpis zajmuje pozycję pierwszego wzorca, do którego pasuje, więc szeroki wzorzec nad konkretnym czyni konkretny wiersz nieosiągalnym.

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

Umieść konkretny wzorzec tunelu nad wzorcem łapiącym wszystko i nad wzorcem interfejsu fizycznego.

Zachowaj pozostałe wiersze, które plik już miał. Zastąpienie całej polityki przykładem to sposób, w jaki niepowiązani dostawcy po cichu się przesuwają; zmień jeden wiersz, wygeneruj ponownie i porównaj. Wzorce nie mogą zawierać spacji, ukośników ani wiodącej kropki czy tyldy, a puste wiersze i komentarze z hashem są ignorowane.

Wygeneruj ponownie i sprawdź wynik

Kolejność działa, gdy skrypty aktualizacyjne przebudują plik. Uruchom obsługiwaną ścieżkę aktualizacji zamiast edytować wygenerowany wynik, a potem odczytaj, co resolver naprawdę otrzymał.

resolvconf -u
cat /etc/resolv.conf

Sprawdź dwa zapytania, nie jedno: nazwę prywatną, która powinna rozwiązać się przez tunel, i publiczną nazwę kontrolną. Jeśli nazwa prywatna nadal zawodzi, gdy kolejność wygląda poprawnie, problemem jest trasowanie przestrzeni nazw, a nie priorytet wpisów, i żadne przestawienie tego nie naprawi. Porównuj każdą odpowiedź z serwerem, który ją zwrócił, nie tylko z powodzeniem. Nazwa prywatna odpowiedziana przez zły resolver to nadal błąd, a dla użytkownika wygląda to jak awaria DNS.

Wycofaj nieaktualny wpis zamiast go degradować

Nieaktualny wpis VPN, który wraca po rozłączeniu, to błąd cyklu życia w integracji klienta. Przeniesienie go na dół ukrywa objaw i zostawia martwy resolver na liście.

Wycofaj go przez komponent, który go rejestruje, a następnie potwierdź, że katalog wpisów go już nie wymienia.

Zapisz nazwę dostawcy, zmieniony wzorzec i dwa wykonane zapytania. Następna osoba potrzebuje tych nazw bardziej niż opowieści.