Varför Samba nekar VPN-klienter som når servern
En VPN-klient kan nå Samba-servern och ändå nekas av hosts allow. Kontrollera källan som smbd ser och policyn på delningsnivå innan du redigerar.
En VPN-klient pingar filservern, slår upp dess namn och kan ändå inte öppna en delning. Sambas värdpolicy är ett av fyra lager som kan neka den anslutningen, och det är lagret folk redigerar sist. Tillåtelselistan utvärderas mot källadressen som smbd faktiskt tar emot, och det är kanske inte den adress klienten tror att den har. Får du den källan rätt blir ett vagt behörighetsproblem en konfigurationsändring på en rad.
Fyra lager som misslyckas med samma meddelande
En nekning kan komma från rutten, värdens brandvägg, Sambas värdpolicy eller SMB-identiteten. Varje lager ger klienten ett meddelande som säger ungefär samma sak, därför kostar gissande en eftermiddag. Att ordna kontrollerna från nätet och inåt tar bort det mesta av gissandet.
Börja med transporten. Om port 445 aldrig når servern spelar ingen Samba-inställning roll, och en inspelning på serverns gränssnitt avgör det på sekunder. Därefter kommer värdens brandvägg på själva servern, som kan kasta bort en tillåten källa innan smbd ens ser den. Först när de två passerat blir tillåtelselistan en kandidat. Autentiseringen kommer sist, eftersom en misslyckad inloggning och en värdnekning ser olika ut i serverloggen, även när klienten rapporterar båda som nekad åtkomst. Ordningen är viktigare än verktygen, eftersom varje lager har ett kommando som svarar på det.
Hitta den källadress som smbd faktiskt ser
Med routad åtkomst ser servern vanligtvis klientens adress från VPN-poolen. Med källöversättning på gatewayen ser den i stället gatewayens LAN-adress, och varje klient bakom den gatewayen blir omöjlig att skilja.
Den skillnaden avgör om en post i tillåtelselistan är policy eller ett hål. Att tillåta en översatt gatewayadress släpper in alla bakom den, vilket en regel per klient sällan ville uttrycka. Läs källan på servern och inte utifrån klientens egen uppfattning om sin adress. En inspelning på serverns gränssnitt är det billigaste sättet att se den, och samma inspelning bevisar om paketet ens kom fram. Begränsa inspelningen med ett paketantal och lägg till ett värd-filter när du vet vilken klient du följer. Sambas sessionstabell är den andra halvan av svaret: i smbstatus -b är klientkolumnen i varje sessionsrad den peer som smbd registrerade, och det är den snabbaste bekräftelsen på adressen som faktiskt nådde tjänsten.
sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'
Läs tillåtelselistan så som Samba läser den
Inställningen hosts allow tar en lista med adresser, nätverk eller namn, och den kan stå globalt eller inne i en delning. Två poster som ser likvärdiga ut för dig är kanske inte likvärdiga för parsern, så den effektiva konfigurationen är det som måste granskas. Det betyder den sammanslagna vyn och inte filen du råkade redigera.
Ett illustrativt par prefix ser ut som raden nedan, och det är ett exempel och inte en ersättning för posterna som redan finns. Behåll de administrativa klienterna och applikationsklienterna som ansluter lagligt i dag, och läs igenom eventuella blockeringslistor i samma genomgång. Om en värd godtas beror på policyn som helhet, så testa den exakta klienten i stället för att resonera om prioritet. Värdtillstånd säger heller ingenting om delningsbehörigheter eller filsystemslägen, som är separata portar. Framgång från testverktygen betyder att värdpolicyn godtar den källan, och inget mer.
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
Ändra filen som överlever en omstart
På en vanlig Linux-värd är konfigurationssökvägen fast och tjänsten läser den igen vid omstart. På en router eller enhet genereras den körande smb.conf ofta vid uppstart, och en manuell ändring försvinner vid nästa omstart. Använd enhetens stödda anpassningsmekanism, som vanligtvis är en egen konfigurationsfil.
Frestelsen här är att flasha alternativ firmware eftersom en tråd rapporterade att det fungerade. Det är en stor ändring för ett litet policyproblem, och det flyttar enheten ur sitt stödda tillstånd. Identifiera först den stödda kontrollen, eftersom de flesta enheter visar tillåtelselistan via sitt eget gränssnitt. Om de verkligen inte gör det är den begränsningen ett argument för annan hårdvara och inte för ett icke-stött bygge.
Anteckna vilken fil du ändrade och vad som genererar den igen, så att nästa person inte upprepar diagnosen.
Testa en tillåten och en utesluten klient
Testa båda utfallen, inte bara det du ville ha. En tillåten klient som ansluter bevisar att ändringen fungerar; en utesluten klient som fortfarande nekas bevisar att regeln inte bara öppnade allt.
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 anslutningen aldrig når smbd ligger svaret i routningen eller i serverns brandvägg. Om värden är tillåten och inloggningen misslyckas är identiteten problemet, och att vidga tillåtelselistan igen hjälper inte. Håll diagnostikutdata privat, eftersom en detaljerad Samba-logg kan avslöja delningssökvägar och kontonamn. Ändra ett lager per försök, annars säger nästa resultat dig ingenting.