Jak czytać trasowanie DNS VPN dla każdego łącza z resolvectl
resolvectl status pokazuje serwery, domeny i trasę domyślną dla każdego łącza. Czytaj je razem, potem zapytaj o nazwę i zanotuj, które łącze odpowiedziało.
Uruchom resolvectl status i otrzymasz ścianę bloków dla każdego łącza, każdy z własnymi serwerami i własną linią domen. Linią, która decyduje o trasowaniu, jest lista domen, a nie adres serwera nazw, ponieważ lokalny stub przekazuje każde zapytanie do łącza, które rości sobie prawo do nazwy. Przeczytaj te roszczenia, zanim przeczytasz odpowiedź, potem zapytaj o nazwę i sprawdź, które łącze ją wytworzyło. Błędna odpowiedź z właściwego łącza to inny problem niż poprawna odpowiedź z niewłaściwego.
Co mówi każdy blok dla łącza
Każdy blok wymienia serwery, których resolver użyje dla tego interfejsu, listę domen i to, czy łącze jest trasą domyślną. Lista domen to zbiór roszczeń, a resolver stosuje dopasowanie najdłuższego sufiksu: zapytanie o host.corp.example jest roszczone przez łącze mające corp.example przed tym, które ma tylko trasę domyślną. Dwa łącza roszczące sobie ten sam sufiks zostawiają wynik priorytetowi i kolejności, dlatego duplikaty zasługują na uwagę najpierw. Linia bieżącego serwera pokazuje, który z wymienionych serwerów jest w danej chwili używany.
Adres stub, taki jak 127.0.0.53 w /etc/resolv.conf, mówi tylko, że stub jest z przodu. Nie nazywa źródła, które odpowiedziało, dlatego diagnoza oparta wyłącznie na resolv.conf grzęźnie.
Czytaj poprawnie trzy rodzaje wpisów domeny
| Wpis | Do czego rości sobie prawo | Częsty błąd |
|---|---|---|
| corp.example | domena trasowania i sufiks wyszukiwania: nazwy pod nią idą do tego łącza, a ciąg jest dodawany do nazw bosych | usunięty, bo trasowanie i tak wydaje się działać |
| ~corp.example | tylko trasa: nazwy pod nią idą do tego łącza, ale sufiks nie jest dodawany | przyjęto, że jest potrzebny do trasowania |
| ~. | trasa domyślna: rości sobie zapytania, których nie obejmuje żadne inne łącze | pozostawiony aktywny w profilu dzielonym, więc nazwy publiczne podążają za tunelem |
Tylda zmienia zachowanie wyszukiwania, nie trasowanie. Wpis bez tyldy jest zarówno domeną trasowania, jak i domeną wyszukiwania, więc nazwy pod nią są wysyłane do tego łącza, a do nazw jednoetykietowych dodawany jest sufiks. Wpis z tyldą trasuje ten sam sufiks, ale trzyma go poza listą wyszukiwania. Dlatego usunięcie tyldy zmienia to, które bose nazwy są rozwiązywane, i dlatego brakująca tylda jest problemem wyszukiwania, a nie awarią dzielonego DNS.
Wpis trasy domyślnej rości sobie wszystko, czego nie obejmuje żadne inne łącze. Profil pełnego tunelu zwykle go chce, a profil dzielony zwykle nie, ponieważ nazwy publiczne podróżują wtedy do prywatnego resolvera i mogą tam zawieść. Czytaj tabelę wobec intencji profilu, zamiast kopiować flagi między profilami. Gdy dwa łącza roszczą sobie ten sam sufiks, rozstrzygnij kwestię priorytetu, zanim zaczniesz cokolwiek innego edytować.
Zapytaj o nazwę i zobacz, które łącze odpowiedziało
Podpolecenie query wypisuje adres, protokół oraz łącze lub zakres, które wytworzyły odpowiedź. Sprawdź jedną nazwę, którą powinien rościć sobie prywatny sufiks, i jedną zwykłą nazwę publiczną, potem porównaj zgłoszone źródła. Jeśli nazwa prywatna odpowiada z łącza bezprzewodowego, roszczenia brakuje albo tunel jest wyłączony; jeśli nazwa publiczna w profilu dzielonym odpowiada z tunelu, trasa domyślna jest zbyt szeroka. Te dwa błędy w przeglądarce wyglądają identycznie, a w tym wyjściu przeciwnie.
resolvectl status
resolvectl query host.corp.exampleUważaj też na zgłoszony protokół, ponieważ odpowiedź z pamięci podręcznej lub z pliku hosts może przyjść bez pytania jakiegokolwiek źródła. Odpowiedź z pamięci podręcznej dowodzi, że nazwa kiedyś została rozwiązana, a nie że obecna polityka trasuje ją poprawnie.
Trzymaj trasowanie nazw osobno od trasowania pakietów
Decyzja resolvera nie tworzy ścieżki. Wybrany serwer nadal potrzebuje trasy do swojego adresu, a zwrócony adres nadal potrzebuje trasy do sieci prywatnej, więc poprawna polityka DNS może współistnieć z połączeniem, które nigdy się nie otwiera. Gdy nazwa się rozwiązuje, a aplikacja zawodzi, zbadaj adres i trasę zamiast ponownie zmieniać DNS. Rozwiązywanie nazw i osiągalność to dwa pytania z dwoma różnymi właścicielami.
Aplikacje mogą całkowicie obejść resolver systemowy przez własne ustawienie bezpiecznego DNS lub wbudowany resolver. Wynik resolvectl opisuje ścieżkę systemową, a przeglądarka, która go ignoruje, będzie niezgodna z każdym twoim testem. Sprawdź to ustawienie, zanim uznasz, że polityka jest zepsuta.
Zapisz adres, na który nazwa się rozwiązała, obok łącza. Poprawna nazwa wskazująca zły adres to problem rekordu, a nie trasowania.
Sprawdź ponownie po zmianie łącza
Ponowne połączenie lub przełączenie sieci bezprzewodowej odbudowuje stan łącza, a menedżer sieci może ponownie zainstalować swoje domeny i serwery na wszystkim, co ustawiono ręcznie. Potem zapytaj o te same dwie nazwy i porównaj z zapisaną linią bazową. Jeśli ręczna zmiana zniknęła, poprawka należy do profilu połączenia a nie do polecenia powłoki. To właśnie zapis przed i po czyni to widocznym.
Udostępniaj tylko nazwy i kontekst serwerów, których potrzebuje raport, ponieważ wewnętrzne sufiksy ujawniają topologię. Dokumentacja systemd-resolved dotycząca trasowania domen obejmuje regułę najdłuższego dopasowania i zachowanie tyldy, a jedno przeczytanie zapobiega większości błędów w tabeli powyżej: trasowanie zapytań w systemd-resolved.