Защо Samba отхвърля VPN клиенти, които достигат до сървъра

VPN клиент прави ping до файловия сървър, разрешава името му и пак не може да отвори споделяне. Хост политиката на Samba е един от четирите слоя, които могат да отхвърлят тази връзка, и тя е слоят, който хората редактират последен. Списъкът с разрешени адреси се проверява срещу адреса на източника, който smbd действително получава, а той може да не е адресът, който клиентът смята, че има. Когато този източник се определи правилно, неясният проблем с правата се превръща в промяна на конфигурацията в един ред.

Четири слоя, които се провалят с едно и също съобщение

Отказът може да дойде от маршрута, хост защитната стена, хост политиката на Samba или SMB идентичността. Всеки слой създава у клиента съобщение, което казва приблизително едно и също, затова гаданията изяждат един следобед. Подреждането на проверките от мрежата навътре премахва по-голямата част от гаданията.

Започнете с транспорта. Ако порт 445 никога не достига до сървъра, никаква настройка на Samba няма значение и прихващане на интерфейса на сървъра го решава за секунди. След това идва хост защитната стена на самия сървър, която може да изхвърли разрешен източник, преди smbd да го види. Едва след като тези две минат, списъкът с разрешени адреси става кандидат. Удостоверяването е последно, защото неуспешният вход и отказът на хоста изглеждат различно в журнала на сървъра, дори когато клиентът съобщава и двете като отказан достъп. Редът е по-важен от инструментите, защото всеки слой има команда, която му отговаря.

Намерете адреса на източника, който smbd действително вижда

При маршрутизиран достъп сървърът обикновено вижда адреса на клиента от VPN пула. При транслация на източника на шлюза той вижда вместо това LAN адреса на шлюза и всеки клиент зад този шлюз става неразличим.

Тази разлика решава дали запис в списъка с разрешени адреси е политика, или дупка. Разрешаването на транслационен адрес на шлюз приема всички зад него, което рядко е това, което правило за отделен клиент е трябвало да изрази. Четете източника от сървъра, а не от представата на клиента за собствения му адрес. Прихващането на интерфейса на сървъра е най-евтиният начин да го видите и същото прихващане доказва дали пакетът изобщо е пристигнал. Ограничете прихващането с брой пакети и добавете филтър за хост, след като знаете кой клиент следите. Таблицата на сесиите на Samba е другата половина на отговора: в smbstatus -b колоната за клиент във всеки ред на сесия е партньорът, който smbd е записал, и това е най-бързото потвърждение на адреса, който действително е достигнал до услугата.

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

Четете списъка с разрешени адреси така, както го чете Samba

Настройката hosts allow приема списък от адреси, мрежи или имена и може да стои глобално или вътре в споделяне. Два записа, които изглеждат еквивалентни за вас, може да не са еквивалентни за парсера, затова ефективната конфигурация е това, което трябва да се прегледа. Това означава обединения изглед, а не файлът, който случайно сте редактирали.

Илюстративна двойка префикси изглежда като реда по-долу и е пример, а не замяна на вече съществуващите записи. Запазете административните и приложните клиенти, които законно се свързват днес, и прочетете всеки списък за забрана в същия проход. Дали хостът ще бъде приет зависи от политиката като цяло, затова тествайте точния клиент, вместо да разсъждавате за приоритет. Разрешението за хост също не казва нищо за правата за споделяне или режимите на файловата система, които са отделни порти. Успехът от тестовите инструменти означава, че хост политиката приема този източник, и нищо повече.

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

Променете файла, който оцелява след рестарт

На нормален Linux хост пътят на конфигурацията е фиксиран и услугата го чете отново при рестарт. На рутер или устройство работещият smb.conf често се генерира при зареждане и ръчната промяна изчезва при следващия рестарт. Използвайте поддържания механизъм за персонализация на устройството, който обикновено е собствен конфигурационен файл.

Изкушението на този етап е да се презапише алтернативен фърмуер, защото една тема съобщи, че работи. Това е голяма промяна за малък проблем с политиката и извежда устройството извън поддържаното му състояние. Първо определете поддържаната контрола, защото повечето устройства показват списъка с разрешени адреси през собствения си интерфейс. Ако наистина не го правят, това ограничение е аргумент за друг хардуер, а не за неподдържана сборка.

Запишете кой файл сте променили и какво го генерира отново, за да не повтаря следващият човек диагностиката.

Тествайте един разрешен и един изключен клиент

Тествайте и двата изхода, не само желания. Разрешен клиент, който се свързва, доказва, че промяната работи; изключен клиент, който продължава да получава отказ, доказва, че правилото не е просто отворило всичко.

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

Когато връзката никога не достига до smbd, отговорът е в маршрутизацията или в защитната стена на сървъра. Ако хостът е разрешен, а входът се проваля, проблемът е в идентичността и разширяването на списъка с разрешени адреси отново няма да помогне. Пазете диагностичния изход поверителен, защото подробен журнал на Samba може да разкрие пътища на споделяния и имена на акаунти. Променяйте по един слой на опит, иначе следващият резултат няма да ви каже нищо.