Twój montaż CIFS zawodzi przez VPN z powodu kolejności w nsswitch

Udział odpowiada po adresie i wisi po nazwie, więc wyszukiwanie ginie, zanim SMB się zacznie. Porównaj getent z host, a potem przeczytaj wiersz hosts po kolei.

Tunel jest włączony. Serwer plików odpowiada na ping po adresie. Potem mount.cifs z nazwą hosta siedzi tam przez chwilę i zgłasza, że host jest nieosiągalny, a ty zaczynasz odbudowywać profil VPN, który nigdy nie był problemem. W Linuksie nazwę rozwiązuje glibc, zanim powstanie jakikolwiek pakiet SMB, a kolejność w tym resolverze może zakończyć wyszukiwanie, zanim DNS zostanie w ogóle zapytany. Oto droga, którą idę, zaczynając od polecenia, które zawiodło, a nie od klienta.

Czytaj błąd we właściwym miejscu

Dwa narzędzia idą różnymi drogami do tej samej nazwy, a ich porównanie kosztuje jedno polecenie. getent przechodzi przez skonfigurowany stos usług nazw; host i dig pytają DNS bezpośrednio i ignorują ten stos. Jeśli bezpośrednie zapytanie zwraca adres, a getent nic nie zwraca, serwer DNS jest osiągalny i to twoja konfiguracja resolvera zawodzi.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

Trzecie polecenie jest rozstrzygające: wymusza źródło DNS i pomija resztę stosu. Kiedy ono działa, a zwykły getent nie, dowiodłeś, że winna jest kolejność, a nie tunel i nie serwer.

Wiersz hosts to sekwencja, która zatrzymuje się wcześnie

Resolver glibc czyta /etc/nsswitch.conf i przechodzi przez wpis hosts: od lewej do prawej. Wiele dystrybucji dostarcza wiersz, w którym wyszukiwanie multicast jest pierwsze, z dołączoną akcją wczesnego powrotu. Ta akcja nie jest ozdobą: gdy mDNS odpowiada “not found”, [NOTFOUND=return] kończy całe wyszukiwanie, więc nazwa firmowa nigdy nie trafia do resolvera narzuconego przez VPN. Nic tego nie loguje, bo nie wysłano żadnego zapytania, które resolver mógłby odrzucić. Dlatego montaż wygląda, jakby wisiał, a potem zgłasza nieosiągalny host.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

Przenieś DNS przed akcję wczesnego powrotu, zamiast usuwać mDNS, i zmieniaj to przez zarządzanie konfiguracją. Ręczna poprawka przetrwa do następnego builda obrazu, a potem ten sam bilet przychodzi z innej maszyny, która nie pamięta poprawki.

Resolver to nie domena wyszukiwania

Rozwiązywanie wymaga też, aby nazwa została wypróbowana. Niepełna nazwa jak fileserver staje się fileserver.corp.example tylko wtedy, gdy do interfejsu niosącego zapytanie jest dołączona domena wyszukiwania. VPN, który narzuca serwer DNS bez listy wyszukiwania, tworzy bardzo konkretny podział: pełna nazwa jest rozwiązywana, a każda krótka nazwa zawodzi.

Przetestuj obie formy przed edycją profilu, bo oba błędy wskazują w różne strony. Na hoście z systemd-resolved link tunelu ma własne serwery i domeny routingu, więc czytaj link, a nie plik globalny.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

Jeśli zapytanie jest przypisane do linku, który nie niesie tunelu, brakuje domeny routingu, mimo że adres DNS jest obecny. To problem polityki w konfiguracji resolved, a nie problem routingu w tunelu.

Kontenery noszą własną kopię odpowiedzi

Kontener zbudowany z ogólnego obrazu zwykle dostarcza stały resolv.conf. Zmiany resolvera na hoście do niego nie docierają, podobnie jak domena wyszukiwania, więc zadanie build, które montuje udział przez tunel, zawodzi, podczas gdy to samo polecenie poza kontenerem działa. Daj kontenerowi własne ustawienia DNS i wyszukiwania w pliku compose albo w argumentach run, a nie tylko w profilu hosta.

Sprawdź wewnątrz kontenera, zanim obwinisz obraz. Dwa polecenia odtwarzają całą diagnozę w kilka sekund, a drugie dowodzi, który resolver naprawdę odpowiedział.

Dopiero wtedy spójrz na udział i filtr

Gdy nazwa się rozwiąże, pozostałe błędy są zwykłymi problemami sieciowymi. SMB potrzebuje TCP 445 do serwera, a przeglądanie listy grupy roboczej zależy od usług nazw, których tunel prawdopodobnie nie przekazuje. Mapuj po nazwie hosta, zamiast czekać, aż lista się wypełni, i pozwól klientowi powiedzieć, na którym etapie się zatrzymał. Odrzucone połączenie i cichy timeout też warto rozdzielić, bo pierwsze zwykle znaczy, że coś odpowiedziało, a drugie, że nic nie odpowiedziało.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

Rozwiązany adres z odrzuconym lub wygasłym portem 445 to problem firewalla lub listenera po drugiej stronie. Nierozwiązana nazwa to problem resolvera. A montaż, który się uwierzytelnia, ale zwraca błędy uprawnień, nie jest ani jednym, ani drugim, więc nie otwieraj ponownie pytania o sieć, gdy sesja jest już nawiązana.

Trzymaj wniosek tak wąski jak dowody. Kiedy adres działa, a nazwa nie, tunel robi swoje, a poprawka należy do kolejności resolvera, domeny wyszukiwania albo własnej konfiguracji kontenera.

Powiązane artykuły