Lokal Samba-delning försvann efter att OpenVPN tryckt ut DNS

Samba tappar lokala delningar i samma ögonblick som OpenVPN den ansluts, och tunneln är nästan aldrig orsaken. Montering är i ordning, NAS-en är igång, och resolvern som tunneln installerade svarar på frågor om ett namn den aldrig har sett. Samba frågar den resolvern tidigt i sin sökordning, tror på svaret och ansluter till en adress där ingenting lyssnar. Att reparera delningen betyder att reparera svaret, inte monteringen.

Fem kontroller, i den ordning som utesluter flest möjligheter per steg.

Vem svarar för kortnamnet

Fråga operativsystemet, inte filhanteraren. resolvectl status skriver ut DNS-servrarna som är kopplade till varje länk och markerar vilken länk som är standardvägen, och en fråga om kortnamnet rapporterar servern som svarade. Kör det en gång för NAS-namnet och en gång för ett namn du vet finns i kontorsdomänen. Om de två svaren kommer från olika servrar har du hittat delningen.

Kontrollera om svaret var ett negativt svar eller en adress. Ett negativt svar betyder att Samba borde ha gått vidare till en annan mekanism, och felet ligger någon annanstans. En adress betyder att Samba anslöt till en verklig plats och inte fick något tillbaka.

Varför Samba tror på ett felaktigt svar

Samba löser namn genom en fast sekvens som sätts av name resolve order. På de flesta distributioner innehåller standardvärdet host, vilket betyder DNS, och det körs före mekanismerna bara för lokalnät som NetBIOS-sändning. En tunnel som trycker ut en resolver får därför första avslaget på varje delningsnamn, även ettikettsnamn som aldrig skulle lämna byggnaden.

Vanligtvis returnerar ett okänt namn ett negativt svar och nästa mekanism får sin tur. Vissa resolvrar, särskilt konsument-ISP:ers och offentliga, svarar på okända namn med en söksida eller en reklamadress i stället. Det svaret ser ut som framgång för resolverbiblioteket, så Samba slutar leta och ringer en adress som inte har något med ditt nätverk att göra.

Resultatet är en delning som försvinner utan en feldialog. Ingenting i den sekvensen är ett VPN-routningsfel, och därför fungerar det fortfarande att pinga NAS-en medan det inte fungerar att bläddra till den.

Två reparationer med olika räckvidd

Den snäva reparationen behåller den påtvingade resolvern och ändrar vad Samba får fråga den om. Lägg till två rader i Samba-konfigurationen som daemonen faktiskt läser och starta sedan om tjänsten:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

Utan host i den listan är DNS ute ur vägen för delningssökningar, och ettikettsnamn stannar på det lokala segmentet. Kontorsnamn löses fortfarande normalt för alla andra program, eftersom detta bara ändrar Samba. Priset är att Samba inte längre kan använda DNS alls, så en delning som adresseras med ett fullt kvalificerat kontorsnamn blir ett problem.

Den breda reparationen tar bort orsaken: sluta trycka ut en resolver som svarar på namn den inte äger, eller tryck ut en delad DNS-policy så att bara kontorssuffix når kontorets resolver. Det är det bättre långsiktiga svaret i ett hanterat nätverk, eftersom det också skyddar webbläsaren och pakethanteraren, men det kräver administrativ åtkomst på serversidan och en klient som lyder de påtvingade inställningarna.

Välj en med avsikt. En resolverändring ändrar namnmatchningen för varje program på en gång, vilket är en ändringsregistrering, inte en redigering för ett supportärende.

Suffixet kan förklara allt

Om klienten också trycker ut ett söksuffix skrivs ett kort lokalt namn om till kontorsdomänen innan det slås upp. Då ljuger resolvern inte alls: den fick en rättvis fråga om ett kontorsnamn och gav ett korrekt svar. Läs det eftersökta namnet i resolverns utdata för att skilja detta från reklamadressfallet, eftersom de två felen ser identiska ut i filhanteraren.

Lösningen här är antingen att använda det fullt kvalificerade lokala namnet eller att lägga till en regel för delad DNS som äger det lokala suffixet. Ingen av dem kräver att man rör Samba.

Bevisa det efter en återanslutning

Testa tre namn i en session: den lokala delningen med kortnamn, en kontorsvärd med namn och en vanlig webbplats. Om den första fungerar och den andra bryts har reparationen flyttat felet i stället för att ta bort det. Om den tredje bryts gick resolverändringen längre än avsett och varje uppslag är nu misstänkt.

Koppla sedan från och till tunneln igen och upprepa alla tre. Påtvingade alternativ tillämpas på nytt vid varje anslutning, så en reparation som bara fanns vid körning kan försvinna utan att någon konfigurationsfil ändras. Anteckna resolvern som äger varje suffix och den sökordning som gäller, och notera datumet, eftersom nästa klientuppdatering är den uppenbara misstänkta när detta återkommer.

Om delningen fortfarande misslyckas efter alla fem kontrollerna, fånga den exakta frågan och det exakta svaret innan du ändrar något annat. Det radparet skiljer ett resolverfel från ett namn som verkligen inte finns, och det är den snabbaste överlämningsanteckningen du kan skriva.