Samba på en VPN-adress: varför lyssnaren försvinner

Delingen fungerar hela förmiddagen, tunneln återansluter vid lunch, och samma UNC-sökväg löper nu ut medan ping till servern fortfarande svarar. Ingenting har ändrats i delningens definition och VPN är uppe. Det som ändrades var den lokala adress som Samba var bunden till, och som inte längre finns efter att gränssnittet skapats på nytt. Det felet är ett problem i lyssnarens livscykel, inte ett behörighetsproblem.

Delingen fungerar tills tunneln startas om

Att binda en tjänst till en adress knyter dess socket till adressens livstid. När tunnelns gränssnitt förstörs och byggs upp igen försvinner den gamla adressen, och socketen som var bunden till den försvinner med den. Tjänsten fortsätter att köra, men ingenting lyssnar där klienterna dirigeras.

Ping kan fortfarande lyckas om den nya adressen svarar på ICMP, och därför ser nåbarheten bra ut medan delningen är död. Just den enda vilseledande framgången skickar folk till brandväggen.

Nåbarhet är inte en bindningsadress

Här blandas tre beslut. Rutten avgör om ett klientpaket kommer fram. Den lyssnande socketen avgör om något tar emot det på den lokala adressen. Delningens konfiguration och filsystemets behörigheter avgör vad som händer sedan. Bara den andra går sönder när gränssnittet skapas på nytt.

En adress från VPN-poolen är inte heller automatiskt en lokal bindningsadress. Den tillhör en klient, inte filservern. Ping är ett dåligt test för en filtjänst.

Håll också dessa ägare åtskilda i dokumentationen. En framtida ändring i VPN-poolen bör inte kräva redigering av Samba, och en ändring av delningsbehörigheter bör inte kräva omstart av tunneln.

Bind istället till en stabil adress

Den stabilare designen håller Samba på en fast adress och låter VPN föra klienterna dit. Serveradressen ändras inte när en tunnel fladdrar, så lyssnaren behöver aldrig följa ett gränssnitt. Åtkomsten upprätthålls då av VPN-vägen och värdens brandvägg, som är byggda för den uppgiften.

Om du måste binda till tunneln, förstå kontraktet i den installerade versionen. Parametrarna interfaces och bind interfaces only är inte samma sak, och dokumentationen om bindning varnar för intermittenta gränssnitt. Dynamisk lyssnarhantering finns på vissa plattformar, men det är en förmåga att verifiera, inte att anta. Läs tabellen före och efter en fladdring och jämför de två utskrifterna.

ss -ltnp | grep ':445'

Testa återanslutningen, inte det gröna ljuset

Verifiera lyssnaren efter en återanslutning, inte bara efter en tjänstestart. Skapa tunneln på nytt, läs sedan lyssningstabellen och bekräfta att socketen finns på den adress som klienterna dirigeras till. En grön tunnelindikator och en godkänd konfigurationskontroll bevisar inget av det.

smbclient -L //files.corp.example -U alice

Kör sedan en tillåten operation och en nekad sökväg från en klient, och upprepa efter en andra återanslutning. Om delningen bara fungerar till den första fladdringen är bindningen fortfarande knuten till gränssnittets livstid och designen är inte åtgärdad. Ändra bindningen eller tjänstadressen, och symtomet slutar komma tillbaka.