Waarom Samba VPN-clients weigert die de server wel bereiken

Een VPN-client pingt de fileserver, lost de naam op en kan toch geen share openen. Het hostbeleid van Samba is een van de vier lagen die die verbinding kunnen weigeren, en het is de laag die mensen als laatste aanpassen. De toelatingslijst wordt getoetst aan het bronadres dat smbd werkelijk ontvangt, en dat is misschien niet het adres dat de client denkt te hebben. Als u die bron goed vaststelt, wordt een vaag rechtenprobleem een configuratiewijziging van één regel.

Vier lagen die falen met dezelfde melding

Een weigering kan komen van de route, de firewall van de host, het hostbeleid van Samba of de SMB-identiteit. Elke laag geeft de client een melding die ongeveer hetzelfde zegt, daarom kost gissen een middag. De controles van het netwerk naar binnen ordenen haalt het meeste giswerk weg.

Begin bij het transport. Als poort 445 de server nooit bereikt, maakt geen enkele Samba-instelling uit, en een opname op de interface van de server beslecht het in seconden. Daarna komt de firewall van de host op de server zelf, die een toegestane bron kan weggooien voordat smbd die ooit ziet. Pas nadat die twee slagen, wordt de toelatingslijst een kandidaat. Authenticatie komt het laatst, omdat een mislukte login en een weigering van de host er in het serverlog anders uitzien, ook wanneer de client beide als toegang geweigerd meldt. De volgorde is belangrijker dan de gereedschappen, want elke laag heeft een commando dat er antwoord op geeft.

Vind het bronadres dat smbd werkelijk ziet

Bij gerouteerde toegang ziet de server meestal het adres van de client uit de VPN-pool. Bij brontranslatie op de gateway ziet hij in plaats daarvan het LAN-adres van de gateway, en elke client achter die gateway wordt niet te onderscheiden.

Dat verschil bepaalt of een vermelding in de toelatingslijst beleid is of een gat. Een vertaald gatewayadres toestaan laat iedereen erachter binnen, wat een regel per client zelden wilde uitdrukken. Lees de bron op de server en niet uit de aanname van de client over zijn eigen adres. Een opname op de interface van de server is de goedkoopste manier om die te zien, en dezelfde opname bewijst of het pakket überhaupt aankwam. Beperk de opname met een packetcount en voeg een hostfilter toe zodra u weet welke client u volgt. De sessietabel van Samba is de andere helft van het antwoord: in smbstatus -b is de clientkolom van elke sessieregel de peer die smbd heeft vastgelegd, en dat is de snelste bevestiging van het adres dat de dienst werkelijk bereikte.

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

Lees de toelatingslijst zoals Samba die leest

De instelling hosts allow neemt een lijst met adressen, netwerken of namen, en kan globaal of binnen een share staan. Twee vermeldingen die u gelijk lijken, zijn dat voor de parser misschien niet, dus de effectieve configuratie is wat u moet inspecteren. Dat betekent de samengevoegde weergave en niet het bestand dat u toevallig hebt aangepast.

Een illustratief paar prefixen ziet eruit als de regel hieronder, en dat is een voorbeeld en geen vervanging van de vermeldingen die er al zijn. Behoud de administratieve en applicatieclients die vandaag legitiem verbinden, en lees elke blokkeerlijst in dezelfde ronde. Of een host wordt toegelaten hangt van het beleid als geheel af, dus test de exacte client in plaats van te redeneren over voorrang. Hosttoestemming zegt ook niets over share-rechten of bestandssysteemmodi, die aparte poorten zijn. Succes van de testhulpmiddelen betekent dat het hostbeleid die bron toelaat, en niets meer.

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

Wijzig het bestand dat een herstart overleeft

Op een normale Linux-host is het configuratiepad vast en leest de dienst het bij herstart opnieuw. Op een router of apparaat wordt de draaiende smb.conf vaak bij het opstarten gegenereerd, en een handmatige aanpassing verdwijnt bij de volgende herstart. Gebruik het ondersteunde aanpassingsmechanisme van het apparaat, dat meestal een eigen configuratiebestand is.

De verleiding is hier om alternatieve firmware te flashen omdat één thread meldde dat het werkte. Dat is een grote wijziging voor een klein beleidsprobleem, en het brengt het apparaat buiten zijn ondersteunde toestand. Stel eerst de ondersteunde bediening vast, want de meeste apparaten tonen de toelatingslijst via hun eigen interface. Als ze dat echt niet doen, is die beperking een argument voor andere hardware en niet voor een niet-ondersteunde build.

Leg vast welk bestand u hebt gewijzigd en wat dat opnieuw genereert, zodat de volgende persoon de diagnose niet herhaalt.

Test één toegestane en één uitgesloten client

Test beide uitkomsten, niet alleen de gewenste. Een toegestane client die verbindt bewijst dat de wijziging werkt; een uitgesloten client die nog steeds wordt geweigerd bewijst dat de regel niet simpelweg alles heeft opengesteld.

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

Als de verbinding smbd nooit bereikt, zit het antwoord in de routering of in de firewall van de server. Als de host is toegestaan en de login mislukt, is de identiteit het probleem en helpt de toelatingslijst opnieuw verbreden niet. Houd diagnostische uitvoer privé, want een uitgebreid Samba-log kan sharepaden en accountnamen blootleggen. Wijzig één laag per poging, anders vertelt het volgende resultaat u niets.