Dlaczego Samba odrzuca klientów VPN, którzy docierają do serwera

Klient VPN pinguje serwer plików, rozwiązuje jego nazwę i mimo to nie może otworzyć udziału. Polityka hostów Samby jest jedną z czterech warstw, które mogą odrzucić to połączenie, i właśnie ją ludzie edytują na końcu. Lista dozwolonych jest oceniana względem adresu źródłowego, który smbd faktycznie otrzymuje, a to może nie być adres, który klient uważa za swój. Prawidłowe ustalenie tego źródła zamienia niejasny problem uprawnień w jednoliniową zmianę konfiguracji.

Cztery warstwy, które zawodzą z tym samym komunikatem

Odmowa może pochodzić z trasy, z zapory hosta, z polityki hostów Samby albo z tożsamości SMB. Każda warstwa daje klientowi komunikat mówiący mniej więcej to samo, dlatego zgadywanie kosztuje pół dnia. Uporządkowanie kontroli od sieci do środka usuwa większość zgadywania.

Zacznij od transportu. Jeśli port 445 nigdy nie dociera do serwera, żadne ustawienie Samby nie ma znaczenia, a przechwycenie na interfejsie serwera rozstrzyga to w sekundach. Następnie jest zapora hosta na samym serwerze, która może odrzucić dozwolone źródło, zanim smbd je w ogóle zobaczy. Dopiero gdy te dwie warstwy przejdą, lista dozwolonych staje się kandydatem. Uwierzytelnianie jest ostatnie, bo nieudane logowanie i odmowa hosta wyglądają inaczej w logu serwera, nawet gdy klient zgłasza oba jako odmowę dostępu. Kolejność jest ważniejsza niż narzędzia, bo każda warstwa ma polecenie, które na nią odpowiada.

Znajdź adres źródłowy, który smbd faktycznie widzi

Przy dostępie trasowanym serwer zwykle widzi adres klienta z puli VPN. Przy translacji źródła na bramie widzi zamiast tego adres LAN bramy, a każdy klient za tą bramą staje się nierozróżnialny.

Ta różnica decyduje, czy wpis na liście dozwolonych jest polityką, czy dziurą. Zezwolenie na przetłumaczony adres bramy wpuszcza wszystkich za nią, czego reguła dla pojedynczego klienta rzadko chciała wyrazić. Czytaj źródło na serwerze, a nie z wyobrażenia klienta o własnym adresie. Przechwycenie na interfejsie serwera to najtańszy sposób, by je zobaczyć, a to samo przechwycenie dowodzi, czy pakiet w ogóle dotarł. Ogranicz przechwycenie liczbą pakietów i dodaj filtr hosta, gdy wiesz, którego klienta śledzisz. Tabela sesji Samby to druga połowa odpowiedzi: w smbstatus -b kolumna klienta w każdym wierszu sesji to partner zapisany przez smbd, i to jest najszybsze potwierdzenie adresu, który naprawdę dotarł do usługi.

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

Czytaj listę dozwolonych tak, jak czyta ją Samba

Ustawienie hosts allow przyjmuje listę adresów, sieci lub nazw i może występować globalnie albo wewnątrz udziału. Dwa wpisy, które dla ciebie wyglądają równoważnie, mogą nie być równoważne dla parsera, więc sprawdzać trzeba właśnie konfigurację efektywną. To oznacza widok scalony, a nie plik, który przypadkiem edytowałeś.

Ilustracyjna para prefiksów wygląda jak wiersz poniżej, i jest to przykład, a nie zamiennik istniejących wpisów. Zachowaj klientów administracyjnych i aplikacyjnych, które dziś łączą się legalnie, i przeczytaj każdą listę blokad w tym samym przebiegu. To, czy host zostanie przyjęty, zależy od polityki jako całości, więc testuj dokładnego klienta, zamiast rozważać pierwszeństwo. Zezwolenie hosta nie mówi też nic o uprawnieniach udziału ani trybach systemu plików, które są osobnymi bramami. Sukces narzędzi testowych oznacza, że polityka hostów przyjmuje to źródło, i nic więcej.

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

Zmień plik, który przetrwa restart

Na zwykłym hoście Linux ścieżka konfiguracji jest stała, a usługa czyta ją ponownie przy restarcie. Na routerze lub urządzeniu działający smb.conf jest często generowany przy starcie, a ręczna zmiana znika przy następnym restarcie. Użyj obsługiwanego mechanizmu dostosowania urządzenia, którym zwykle jest osobny plik konfiguracji.

Pokusa w tym miejscu to wgranie alternatywnego firmware, bo jeden wątek doniósł, że to działa. To duża zmiana przy małym problemie z polityką i wyprowadza urządzenie ze stanu objętego wsparciem. Najpierw ustal obsługiwaną kontrolę, ponieważ większość urządzeń pokazuje listę dozwolonych przez własny interfejs. Jeśli naprawdę tego nie robią, to ograniczenie jest argumentem za innym sprzętem, a nie za nieobsługiwaną kompilacją.

Zapisz, który plik zmieniłeś i co go ponownie generuje, aby następna osoba nie powtarzała diagnostyki.

Przetestuj jednego dozwolonego i jednego wykluczonego klienta

Przetestuj oba wyniki, nie tylko ten, którego chciałeś. Dozwolony klient, który się łączy, dowodzi, że zmiana działa; wykluczony klient, który nadal jest odrzucany, dowodzi, że reguła nie otworzyła po prostu wszystkiego.

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

Gdy połączenie nigdy nie dociera do smbd, odpowiedź jest w trasowaniu lub w zaporze serwera. Jeśli host jest dozwolony, a logowanie zawodzi, problemem jest tożsamość i dalsze poszerzanie listy dozwolonych nie pomoże. Trzymaj dane diagnostyczne prywatnie, bo szczegółowy log Samby może ujawnić ścieżki udziałów i nazwy kont. Zmieniaj jedną warstwę na próbę, inaczej następny wynik nic ci nie powie.