Miért utasítja el a Samba azokat a VPN-klienseket, amelyek elérik a kiszolgálót

Egy VPN-kliens pingeli a fájlkiszolgálót, feloldja a nevét, és mégsem tud megosztást megnyitni. A Samba gazdagép-házirendje az egyik a négy réteg közül, amelyek elutasíthatják ezt a kapcsolatot, és ezt szerkesztik az emberek utoljára. Az engedélyezési lista ahhoz a forráscímhez mérődik, amelyet az smbd ténylegesen megkap, és ez nem feltétlenül az a cím, amelyről a kliens azt hiszi, hogy van neki. A forrás helyes meghatározása homályos jogosultsági problémából egysoros konfigurációmódosítást csinál.

Négy réteg, amely ugyanazzal az üzenettel bukik el

Az elutasítás jöhet az útvonalból, a gazdagép tűzfalából, a Samba gazdagép-házirendjéből vagy az SMB személyazonosságból. Minden réteg olyan üzenetet ad a kliensnek, amely nagyjából ugyanazt mondja, ezért a találgatás egy délutánba kerül. Az ellenőrzések hálózattól befelé történő sorrendezése a találgatások nagy részét megszünteti.

Kezdje a szállítással. Ha a 445-es port soha nem éri el a kiszolgálót, egyetlen Samba-beállítás sem számít, és a kiszolgáló interfészén készített csapdázás másodpercek alatt eldönti. Ezután jön a gazdagép tűzfala magán a kiszolgálón, amely még az smbd látása előtt eldobhat egy engedélyezett forrást. Csak miután ez a kettő átment, válik jelöltté az engedélyezési lista. A hitelesítés jön utolsóként, mert a sikertelen bejelentkezés és a gazdagép elutasítása másképp néz ki a kiszolgáló naplójában, még akkor is, ha a kliens mindkettőt hozzáférés-megtagadásként jelenti. A sorrend fontosabb az eszközöknél, mert minden rétegnek van egy parancsa, amely válaszol rá.

Keresse meg a forráscímet, amelyet az smbd ténylegesen lát

Irányított hozzáférésnél a kiszolgáló általában a VPN-készletből származó klienscímet látja. A forrásfordításnál az átjárón viszont az átjáró LAN-címét látja, és az átjáró mögötti minden kliens megkülönböztethetetlenné válik.

Ez a különbség dönti el, hogy az engedélyezési lista egy bejegyzése házirend-e vagy lyuk. Egy lefordított átjárócím engedélyezése mindenkit beenged mögötte, amit egy kliensenkénti szabály ritkán akart kifejezni. A forrást a kiszolgálón olvassa, ne a kliens saját címéről alkotott képzetéből. A kiszolgáló interfészén készített csapdázás a legolcsóbb módja annak, hogy lássa, és ugyanez a csapdázás bizonyítja, hogy a csomag egyáltalán megérkezett-e. Korlátozza a csapdázást csomagszámmal, és adjon hozzá gazdagépszűrőt, ha tudja, melyik klienst követi. A Samba munkamenet-táblázata a válasz másik fele: a smbstatus -b kimenetben minden munkamenet-sor kliens oszlopa az a partner, amelyet az smbd rögzített, és ez a leggyorsabb megerősítése annak a címnek, amely tényleg elérte a szolgáltatást.

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

Az engedélyezési listát úgy olvassa, ahogy a Samba olvassa

A hosts allow beállítás címek, hálózatok vagy nevek listáját veszi át, és megjelenhet globálisan vagy egy megosztáson belül. Két bejegyzés, amely Önnek egyenértékűnek tűnik, lehet, hogy nem egyenértékű az elemzőnek, ezért a tényleges konfigurációt kell megvizsgálni. Ez az egyesített nézetet jelenti, és nem azt a fájlt, amelyet véletlenül szerkesztett.

Egy szemléltető előtagpár úgy néz ki, mint az alábbi sor, és ez példa, nem pedig a már meglévő bejegyzések helyettesítése. Tartsa meg azokat az adminisztratív és alkalmazásklienseket, amelyek ma jogszerűen kapcsolódnak, és olvassa át az esetleges tiltólistát ugyanabban a menetben. Az, hogy egy gazdagépet elfogadnak-e, a házirendtől mint egésztől függ, ezért a pontos klienst tesztelje, ahelyett hogy az elsőbbségről okoskodna. A gazdagép-engedély semmit sem mond a megosztási engedélyekről vagy a fájlrendszer módjairól, amelyek külön kapuk. A teszthez használt eszközök sikeressége azt jelenti, hogy a gazdagép-házirend elfogadja azt a forrást, és semmi többet.

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

Módosítsa azt a fájlt, amely túléli az újraindítást

Egy szokásos Linux gazdagépen a konfiguráció útvonala rögzített, és a szolgáltatás újraindításkor újraolvassa. Egy útválasztón vagy készüléken a futó smb.conf-ot gyakran indításkor állítják elő, és a kézi szerkesztés a következő újraindításnál eltűnik. Használja a készülék támogatott testreszabási mechanizmusát, amely rendszerint saját konfigurációs fájl.

A kísértés ezen a ponton az, hogy alternatív firmware-t írjon fel, mert egy szál arról számolt be, hogy működik. Ez nagy változás egy kis házirendproblémához, és kiviszi az eszközt a támogatott állapotából. Először azonosítsa a támogatott vezérlést, mivel a legtöbb készülék a saját felületén keresztül mutatja az engedélyezési listát. Ha ez valóban nem így van, az a korlátozás más hardver mellett szóló érv, és nem egy nem támogatott build melletti.

Jegyezze fel, melyik fájlt módosította, és mi állítja elő újra, hogy a következő ember ne ismételje meg a diagnózist.

Teszteljen egy engedélyezett és egy kizárt klienst

Mindkét eredményt tesztelje, ne csak azt, amelyiket akarta. Egy engedélyezett kliens, amely csatlakozik, bizonyítja, hogy a módosítás működik; egy kizárt kliens, amelyet továbbra is elutasítanak, bizonyítja, hogy a szabály nem egyszerűen mindent nyitott meg.

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

Amikor a kapcsolat soha nem éri el az smbd-t, a válasz az útválasztásban vagy a kiszolgáló tűzfalában van. Ha a gazdagép engedélyezett, és a bejelentkezés meghiúsul, a probléma a személyazonosság, és az engedélyezési lista ismételt szélesítése nem segít. Tartsa privátnak a diagnosztikai kimenetet, mert egy részletes Samba-napló felfedheti a megosztási útvonalakat és a fiókneveket. Kísérletenként egy réteget változtasson, különben a következő eredmény semmit sem mond Önnek.