Hvorfor Samba afviser VPN-klienter, der kan nå serveren
En VPN-klient kan nå Samba-serveren og alligevel blive afvist af hosts allow. Kontroller den kilde, smbd ser, og politikken på delingsniveau, før du redigerer.
En VPN-klient pinger filserveren, slår dens navn op og kan stadig ikke åbne en deling. Sambas værtspolitik er et af fire lag, der kan afvise den forbindelse, og det er det lag, folk redigerer sidst. Tilladelseslisten vurderes mod kildeadressen, som smbd faktisk modtager, og det er måske ikke den adresse, klienten tror, den har. Får du den kilde rigtigt, bliver et vagt tilladelsesproblem til en konfigurationsændring på én linje.
Fire lag, der fejler med samme besked
En afvisning kan komme fra ruten, værtens firewall, Sambas værtspolitik eller SMB-identiteten. Hvert lag giver klienten en besked, der siger nogenlunde det samme, og derfor koster gætteri en eftermiddag. Rækkefølgen af kontroller fra netværket og indad fjerner det meste af gætteriet.
Begynd med transporten. Hvis port 445 aldrig når serveren, betyder ingen Samba-indstilling noget, og en optagelse på serverens interface afgør det på sekunder. Derefter kommer værtens firewall på selve serveren, som kan kassere en tilladt kilde, før smbd overhovedet ser den. Først når de to er passeret, bliver tilladelseslisten en kandidat. Godkendelse kommer sidst, fordi en mislykket login og en værtens afvisning ser forskellige ud i serverloggen, selv når klienten rapporterer begge som adgang nægtet. Rækkefølgen er vigtigere end værktøjerne, fordi hvert lag har en kommando, der svarer på det.
Find den kildeadresse, smbd faktisk ser
Ved routet adgang ser serveren normalt klientens adresse fra VPN-puljen. Ved kildetranslation på gatewayen ser den i stedet gatewayens LAN-adresse, og hver klient bag den gateway bliver umulig at skelne.
Den forskel afgør, om en post i tilladelseslisten er politik eller et hul. Tillader man en oversat gatewayadresse, lukker man alle bag den ind, hvilket en regel pr. klient sjældent ville udtrykke. Læs kilden på serveren i stedet for ud fra klientens egen opfattelse af sin adresse. En optagelse på serverens interface er den billigste måde at se den, og samme optagelse beviser, om pakken overhovedet nåede frem. Begræns optagelsen med et pakkeantal, og tilføj et værtfilter, når du ved, hvilken klient du følger. Sambas sessionstabel er den anden halvdel af svaret: i smbstatus -b er klientkolonnen i hver sessionsrække den peer, smbd registrerede, og det er den hurtigste bekræftelse af den adresse, der faktisk nåede tjenesten.
sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'
Læs tilladelseslisten, som Samba læser den
Indstillingen hosts allow tager en liste af adresser, netværk eller navne, og den kan stå globalt eller inde i en deling. To poster, der ser ens ud for dig, er måske ikke ens for parseren, så den effektive konfiguration er det, der skal undersøges. Det betyder den sammenflettede visning og ikke den fil, du tilfældigvis redigerede.
Et illustrativt par præfikser ser ud som linjen nedenfor, og det er et eksempel og ikke en erstatning for de poster, der allerede er der. Behold de administrative og applikationsklienter, der legitimt forbinder i dag, og læs enhver blokeringsliste i samme gennemgang. Om en vært accepteres, afhænger af politikken som helhed, så test den præcise klient i stedet for at ræsonnere om forrang. Værttilladelse siger heller intet om delingstilladelser eller filsystemtilstande, som er separate gates. En succes fra testværktøjerne betyder, at værtspolitikken accepterer den kilde, og intet derudover.
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
Rediger den fil, der overlever en genstart
På en normal Linux-vært er konfigurationsstien fast, og tjenesten læser den igen ved genstart. På en router eller enhed genereres den kørende smb.conf ofte ved opstart, og en manuel ændring forsvinder ved næste genstart. Brug enhedens understøttede tilpasningsmekanisme, som normalt er en egen konfigurationsfil.
Fristelsen her er at flashe alternativ firmware, fordi en tråd rapporterede, at det virkede. Det er en stor ændring for et lille politikproblem, og det flytter enheden ud af dens understøttede tilstand. Identificér først den understøttede kontrol, da de fleste enheder viser tilladelseslisten via deres eget interface. Hvis de virkelig ikke gør det, er den begrænsning et argument for andet hardware og ikke for et ikke-understøttet build.
Notér, hvilken fil du ændrede, og hvad der genererer den igen, så den næste person ikke gentager diagnosen.
Test én tilladt og én udelukket klient
Test begge udfald, ikke kun det, du ønskede. En tilladt klient, der forbinder, beviser, at ændringen virker; en udelukket klient, der stadig afvises, beviser, at reglen ikke bare åbnede alt.
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
Når forbindelsen aldrig når smbd, ligger svaret i routing eller i serverens firewall. Hvis værten er tilladt, og login fejler, er identiteten problemet, og at udvide tilladelseslisten igen hjælper ikke. Hold diagnostisk output privat, fordi en udførlig Samba-log kan afsløre delingsstier og kontonavne. Skift ét lag pr. forsøg, ellers fortæller det næste resultat dig intet.