ip netns exec i DNS: dlaczego nazwy zawodzą wewnątrz przestrzeni nazw

Polecenie dociera do 10.8.0.5 wewnątrz przestrzeni nazw VPN bez żadnych skarg, a to samo polecenie zawodzi w chwili, gdy używa nazwy hosta. Przestrzeń nazw ma własne interfejsy, trasy i gniazda; nie ma własnego pliku resolvera. Jeśli coś nie umieści tam jednego, proces w środku czyta /etc/resolv.conf hosta i pyta serwer, który może być nieosiągalny z tego stosu sieciowego.

To problem wyboru pliku, a nie problem routingu, i właśnie dlatego docelowy adres liczbowy nadal działa.

Sprawdź widok resolvera, który proces faktycznie otrzymuje

Nie zakładaj, że użyta powłoka jest równoważna procesowi, który debugujesz. Aplikacja graficzna, jednostka systemd i kontener mogą każdy wejść w inny kontekst montowania lub sieci. Uruchom wyszukiwanie tą samą ścieżką startową i wypisz plik resolvera od środka.

Dla przestrzeni nazw utworzonej za pomocą ip netns add sprawdzenie tylko do odczytu jest krótkie:

ip netns exec vpn cat /etc/resolv.conf

Zwróć uwagę, czy wynik wskazuje osiągalny adres, stub loopback czy dowiązanie symboliczne prowadzące do miejsca o innej osiągalności.

Co narzędzie pomocnicze exec faktycznie montuje

Narzędzie ip-netns dokumentuje konfigurację dla każdej przestrzeni nazw w /etc/netns/NAME/. Gdy uruchamia proces, pomocnik tworzy przestrzeń nazw montowania i montuje te pliki nad ich zwykłymi ścieżkami, więc proces widzi kopię właściwą dla przestrzeni nazw. To wygoda właśnie tego programu startowego. Wejście do przestrzeni nazw sieci inną drogą, na przykład przez unshare lub środowisko uruchomieniowe kontenerów, nie odtwarza tego automatycznie.

Resolver loopback jest tu pułapką: 127.0.0.53 oznacza własny loopback przestrzeni nazw, a nie stub hosta. Stub nasłuchujący tylko w przestrzeni nazw hosta nie staje się usługą w nowej.

Wybierz resolver, do którego przestrzeń nazw może dotrzeć

Niezależnie od tego, jaki serwer wymienia plik, wciąż potrzebuje on trasy z tej przestrzeni nazw. Publiczny resolver może odpowiadać na nazwy publiczne i mimo to zawodzić dla strefy wewnętrznej, bo usługa prywatna jest osiągalna tylko przez tunel. Sprawdzaj trasę jednocześnie z adresem, a nie po tym, jak wyszukiwanie już zawiodło.

Aplikacje z własnym resolverem, takie jak ta korzystająca z DNS over HTTPS, mogą całkowicie zignorować ten plik. Jeśli narzędzie ma własne ustawienie DNS, zmiana resolv.conf nic w nim nie zmieni, a przestrzeń nazw nigdy nie była problemem.

Zapisz plik we właściwym miejscu

Utwórz plik dla przestrzeni nazw w /etc/netns/NAME/resolv.conf i pozwól programowi startowemu go przedstawić. Trzymaj go minimalnie: jeden lub dwa osiągalne serwery i domeny wyszukiwania potrzebne zadaniu. Nie edytuj wygenerowanego pliku resolvera hosta, aby naprawić widok przeznaczony dla jednej grupy procesów, bo to zmienia każdą aplikację na maszynie. Jeśli host używa menedżera resolvera, skonfiguruj ścieżkę przestrzeni nazw przez tego menedżera, zamiast walczyć z nim.

Zapisz zawartość pliku w runbooku. Inaczej następna osoba przetestuje resolver hosta, zobaczy działającą odpowiedź i wywnioskuje, że przestrzeń nazw jest w porządku.

Przetestuj ponownie całą ścieżkę

Testuj wewnątrz przestrzeni nazw z adresem liczbowym, nazwą wewnętrzną i nazwą publiczną. Ta sekwencja oddziela osiągalność od rozwiązywania i oddziela strefy wewnętrzne od publicznych. Następnie odtwórz przestrzeń nazw i powtórz, bo plik istniejący tylko w działającej instancji znika razem z nią.

Potwierdź, że plik otrzymuje proces, a nie powłoka. Wyszukiwanie, które działa z interaktywnej powłoki i zawodzi z usługi, jest ustaleniem dotyczącym kontekstu montowania, i warto je zapisać przed następnym incydentem zamiast odkrywać od nowa od zera.