Lokalny udział Samba zniknął po wypchnięciu DNS przez OpenVPN

Samba traci lokalne udziały w chwili, gdy OpenVPN się łączy, a tunel prawie nigdy nie jest przyczyną. Montowanie jest w porządku, NAS działa, a resolver zainstalowany przez tunel odpowiada na pytania o nazwę, której nigdy nie widział. Samba pyta ten resolver wcześnie w swojej kolejności wyszukiwania, wierzy odpowiedzi i łączy się z adresem, na którym nic nie nasłuchuje. Naprawa udziału oznacza naprawę odpowiedzi, a nie montowania.

Pięć kontroli, w kolejności, która na każdym kroku wyklucza najwięcej możliwości.

Kto odpowiada za krótką nazwę

Zapytaj system operacyjny, nie menedżer plików. resolvectl status wypisuje serwery DNS przypisane do każdego połączenia i oznacza, które jest trasą domyślną, a zapytanie o krótką nazwę zgłasza serwer, który odpowiedział. Uruchom to raz dla nazwy NAS i raz dla nazwy, o której wiesz, że istnieje w domenie biura. Jeśli obie odpowiedzi pochodzą z różnych serwerów, znalazłeś podział.

Sprawdź, czy odpowiedź była odpowiedzią negatywną, czy adresem. Odpowiedź negatywna oznacza, że Samba powinna była przejść do innego mechanizmu, a usterka jest gdzie indziej. Adres oznacza, że Samba połączyła się z realnym miejscem i nic nie dostała.

Dlaczego Samba wierzy błędnej odpowiedzi

Samba rozwiązuje nazwy przez stałą sekwencję ustawioną przez name resolve order. W większości dystrybucji domyślna wartość zawiera host, co oznacza DNS, i działa przed mechanizmami tylko dla sieci lokalnej, takimi jak rozgłaszanie NetBIOS. Tunel, który wypycha resolver, dostaje więc prawo pierwszego odmówienia dla każdej nazwy udziału, w tym nazw jednoczęściowych, które nigdy nie miały opuszczać budynku.

Zwykle nieznana nazwa zwraca odpowiedź negatywną i następny mechanizm dostaje swoją kolej. Niektóre resolvery, zwłaszcza u dostawców internetu i publiczne, odpowiadają na nieznane nazwy stroną wyszukiwania lub adresem reklamowym. Ta odpowiedź wygląda dla biblioteki resolvera jak sukces, więc Samba przestaje szukać i wybiera adres, który nie ma nic wspólnego z twoją siecią.

Wynikiem jest udział, który znika bez okna błędu. Nic w tej sekwencji nie jest awarią rutingu VPN, dlatego ping do NAS nadal działa, a przeglądanie go nie.

Dwie naprawy o różnym zasięgu

Wąska naprawa zachowuje wypchnięty resolver i zmienia to, o co Samba może go pytać. Dodaj dwie linie do konfiguracji Samby, którą demon faktycznie czyta, a następnie zrestartuj usługę:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

Bez host na tej liście DNS wypada ze ścieżki wyszukiwania udziałów, a nazwy jednoczęściowe zostają w segmencie lokalnym. Nazwy biura nadal rozwiązują się normalnie dla każdego innego programu, bo to zmienia tylko Sambę. Kosztem jest to, że Samba nie może już w ogóle używać DNS, więc udział adresowany pełną nazwą biura staje się problemem.

Szeroka naprawa usuwa przyczynę: przestań wypychać resolver, który odpowiada na nazwy, których nie posiada, albo wypchnij politykę podzielonego DNS, aby tylko sufiksy biura docierały do resolvera biura. To lepsza odpowiedź długoterminowa w zarządzanej sieci, ponieważ chroni też przeglądarkę i menedżer pakietów, ale wymaga dostępu administracyjnego po stronie serwera i klienta, który słucha wypchniętych ustawień.

Wybierz jedną świadomie. Zmiana resolvera zmienia rozwiązywanie nazw dla każdej aplikacji naraz, co jest zapisem zmiany, a nie edycją na potrzeby zgłoszenia do wsparcia.

Sufiks może wyjaśnić wszystko

Jeśli klient wypycha też sufiks wyszukiwania, krótka nazwa lokalna jest przepisywana na domenę biura, zanim zostanie zapytana. Wtedy resolver wcale nie kłamie: zadano mu uczciwe pytanie o nazwę biura i udzielił poprawnej odpowiedzi. Przeczytaj zapytaną nazwę w danych wyjściowych resolvera, aby odróżnić to od przypadku adresu reklamowego, ponieważ obie usterki wyglądają w menedżerze plików identycznie.

Rozwiązaniem jest tu albo użycie pełnej nazwy lokalnej, albo dodanie reguły podzielonego DNS, która posiada lokalny sufiks. Żadne z nich nie wymaga dotykania Samby.

Udowodnij to po ponownym połączeniu

Przetestuj trzy nazwy w jednej sesji: udział lokalny po krótkiej nazwie, host biura po nazwie i zwykłą stronę internetową. Jeśli pierwsze działa, a drugie się psuje, naprawa przeniosła usterkę zamiast ją usunąć. Jeśli psuje się trzecie, zmiana resolvera poszła dalej niż zamierzano i każde wyszukiwanie jest teraz podejrzane.

Następnie rozłącz i ponownie połącz tunel i powtórz wszystkie trzy. Wypchnięte opcje są stosowane ponownie przy każdym połączeniu, więc naprawa istniejąca tylko w czasie działania może zniknąć bez zmiany pliku konfiguracji. Zapisz resolver, który posiada każdy sufiks, oraz obowiązującą kolejność wyszukiwania, i zanotuj datę, ponieważ następna aktualizacja klienta jest oczywistym podejrzanym, gdy to wróci.

Jeśli udział nadal zawodzi po wszystkich pięciu kontrolach, przechwyć dokładne zapytanie i dokładną odpowiedź, zanim zmienisz cokolwiek innego. Ta para linii odróżnia usterkę resolvera od nazwy, która naprawdę nie istnieje, i jest najszybszą notatką przekazania, jaką możesz napisać.