Lokale Samba-share verdween nadat OpenVPN DNS pushte

Samba verliest lokale shares op het moment dat OpenVPN verbinding maakt, en de tunnel is bijna nooit de oorzaak. De mount is in orde, de NAS is aan, en de resolver die de tunnel heeft geïnstalleerd beantwoordt vragen over een naam die hij nooit heeft gezien. Samba vraagt die resolver vroeg in zijn zoekvolgorde, gelooft het antwoord en verbindt met een adres waar niets luistert. De share repareren betekent het antwoord repareren, niet de mount.

Vijf controles, in de volgorde die per stap de meeste mogelijkheden uitsluit.

Wie antwoordt voor de korte naam

Vraag het besturingssysteem, niet de bestandsbeheerder. resolvectl status toont de DNS-servers die aan elke verbinding zijn gekoppeld en markeert welke verbinding de standaardroute is, en een query voor de korte naam meldt de server die heeft geantwoord. Voer het één keer uit voor de NAS-naam en één keer voor een naam waarvan u weet dat die in het kantoordomein bestaat. Als de twee antwoorden van verschillende servers komen, hebt u de splitsing gevonden.

Controleer of het antwoord een negatief antwoord of een adres was. Een negatief antwoord betekent dat Samba had moeten doorgaan naar een ander mechanisme, en de fout ligt elders. Een adres betekent dat Samba verbinding maakte met een echte plek en niets terugkreeg.

Waarom Samba een verkeerd antwoord gelooft

Samba lost namen op via een vaste volgorde die door name resolve order wordt ingesteld. Op de meeste distributies bevat de standaard host, wat DNS betekent, en dat draait vóór de alleen-LAN-mechanismen zoals NetBIOS-broadcast. Een tunnel die een resolver pusht krijgt daardoor het eerste weigeringsrecht op elke sharenaam, inclusief namen met één label die nooit het gebouw hadden mogen verlaten.

Normaal gesproken geeft een onbekende naam een negatief antwoord en krijgt het volgende mechanisme een beurt. Sommige resolvers, vooral die van consumenten-ISP's en openbare, antwoorden onbekende namen met een zoekpagina of een advertentieadres. Dat antwoord lijkt voor de resolverbibliotheek een succes, dus Samba stopt met zoeken en kiest een adres dat niets met uw netwerk te maken heeft.

Het resultaat is een share die verdwijnt zonder foutdialoog. Niets in die volgorde is een VPN-routeringsfout, daarom werkt ping naar de NAS nog steeds terwijl browsen ernaar niet werkt.

Twee reparaties met verschillende reikwijdte

De smalle reparatie houdt de gepushte resolver en verandert wat Samba hem mag vragen. Voeg twee regels toe aan de Samba-configuratie die de daemon daadwerkelijk leest, en herstart vervolgens de dienst:

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

Zonder host in die lijst is DNS buiten het pad voor share-zoekopdrachten, en namen met één label blijven op het lokale segment. Kantoornamen worden voor elk ander programma nog steeds normaal opgelost, omdat dit alleen Samba verandert. De prijs is dat Samba helemaal geen DNS meer kan gebruiken, dus een share die met een volledig gekwalificeerde kantoornaam wordt geadresseerd, wordt een probleem.

De brede reparatie verwijdert de oorzaak: stop met het pushen van een resolver die namen beantwoordt die hij niet bezit, of push een split-DNS-beleid zodat alleen kantoorachtervoegsels de kantoorresolver bereiken. Dat is het betere antwoord op lange termijn in een beheerd netwerk, omdat het ook de browser en de pakketbeheerder beschermt, maar het vereist administratieve toegang aan de serverkant en een client die de gepushte instellingen gehoorzaamt.

Kies er bewust één. Een resolverwijziging verandert de naamresolutie voor elke toepassing tegelijk, wat een wijzigingsrecord is, geen bewerking voor een supportgesprek.

Het achtervoegsel kan alles verklaren

Als de client ook een zoekachtervoegsel pusht, wordt een korte lokale naam herschreven naar het kantoordomein voordat erop wordt gezocht. Dan liegt de resolver helemaal niet: hem werd een eerlijke vraag over een kantoornaam gesteld en hij gaf een correct antwoord. Lees de opgevraagde naam in de uitvoer van de resolver om dit te onderscheiden van het geval met het advertentieadres, want de twee fouten zien er in de bestandsbeheerder identiek uit.

De oplossing hier is ofwel de volledig gekwalificeerde lokale naam gebruiken, ofwel een split-DNS-regel toevoegen die het lokale achtervoegsel bezit. Geen van beide vereist Samba aan te raken.

Bewijs het na een herverbinding

Test drie namen in één sessie: de lokale share op korte naam, een kantoorhost op naam en een gewone website. Als de eerste werkt en de tweede breekt, heeft de reparatie de fout verplaatst in plaats van verwijderd. Als de derde breekt, is de resolverwijziging verder gegaan dan bedoeld en is elke zoekopdracht nu verdacht.

Verbreek en herstel daarna de tunnel en herhaal alle drie. Gepushte opties worden bij elke verbinding opnieuw toegepast, dus een reparatie die alleen tijdens runtime bestond kan verdwijnen zonder dat een configuratiebestand verandert. Noteer de resolver die elk achtervoegsel bezit en de zoekvolgorde die geldt, en noteer de datum, want de volgende clientupdate is de voor de hand liggende verdachte wanneer dit terugkomt.

Als de share na alle vijf controles nog steeds mislukt, leg dan de exacte query en het exacte antwoord vast voordat u iets anders verandert. Dat paar regels onderscheidt een resolverfout van een naam die echt niet bestaat, en het is de snelste overdrachtsnotitie die u kunt schrijven.