Зошто 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 може да открие патеки на споделување и имиња на сметки. Менувајте еден слој по обид, инаку следниот резултат нема да ви каже ништо.