Lokal Samba-deling forsvant etter at OpenVPN pushet DNS

Samba mister lokale delinger i det øyeblikket OpenVPN den kobles til, og tunnelen er nesten aldri årsaken. Montering er i orden, NAS-en er oppe, og resolveren tunnelen installerte svarer på spørsmål om et navn den aldri har sett. Samba spør denne resolveren tidlig i oppslagsrekkefølgen sin, tror på svaret og kobler til en adresse der ingenting lytter. Å reparere delingen betyr å reparere svaret, ikke monteringen.

Fem kontroller, i den rekkefølgen som utelukker flest muligheter per steg.

Hvem svarer for kortnavnet

Spør operativsystemet, ikke filbehandleren. resolvectl status skriver ut DNS-serverne som er knyttet til hver lenke og markerer hvilken lenke som er standardruten, og et oppslag på kortnavnet rapporterer serveren som svarte. Kjør det én gang for NAS-navnet og én gang for et navn du vet finnes i kontordomenet. Hvis de to svarene kommer fra forskjellige servere, har du funnet splittelsen.

Kontroller om svaret var et negativt svar eller en adresse. Et negativt svar betyr at Samba burde ha gått videre til en annen mekanisme, og feilen er et annet sted. En adresse betyr at Samba koblet til et virkelig sted og ikke fikk noe tilbake.

Hvorfor Samba tror på et feil svar

Samba løser navn gjennom en fast sekvens satt av name resolve order. På de fleste distribusjoner inneholder standardverdien host, som betyr DNS, og den kjører før mekanismene bare for lokalnett som NetBIOS-kringkasting. En tunnel som pusher en resolver får derfor første avslag på hvert delingsnavn, også ettikettsnavn som aldri skulle forlate bygningen.

Vanligvis returnerer et ukjent navn et negativt svar, og neste mekanisme får sin tur. Noen resolvere, særlig forbruker-ISP-er og offentlige, svarer på ukjente navn med en søkeside eller en reklameadresse i stedet. Det svaret ser ut som suksess for resolverbiblioteket, så Samba slutter å lete og ringer en adresse som ikke har noe med nettverket ditt å gjøre.

Resultatet er en deling som forsvinner uten en feildialog. Ingenting i den sekvensen er en VPN-rutingsfeil, og derfor virker det fortsatt å pinge NAS-en mens det ikke virker å bla til den.

To reparasjoner med ulik rekkevidde

Den smale reparasjonen beholder den pushede resolveren og endrer hva Samba får spørre den om. Legg til to linjer i Samba-konfigurasjonen som daemonen faktisk leser, og start deretter tjenesten på nytt:

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

Uten host på den listen er DNS ute av veien for delingsoppslag, og ettikettsnavn blir værende på det lokale segmentet. Kontornavn løses fortsatt normalt for alle andre programmer, fordi dette bare endrer Samba. Prisen er at Samba ikke lenger kan bruke DNS i det hele tatt, så en deling som adresseres med et fullt kvalifisert kontornavn, blir et problem.

Den brede reparasjonen fjerner årsaken: slutt å pushe en resolver som svarer på navn den ikke eier, eller push en splittet DNS-policy slik at bare kontorsuffikser når kontorets resolver. Det er det bedre langsiktige svaret på et administrert nettverk, fordi det også beskytter nettleseren og pakkebehandleren, men det krever administrativ tilgang på serversiden og en klient som adlyder de pushede innstillingene.

Velg én med vilje. En resolverendring endrer navneoppslag for hver applikasjon på én gang, noe som er en endringsregistrering, ikke en redigering for en støttesamtale.

Suffikset kan forklare alt

Hvis klienten også pusher et søkesuffiks, skrives et kort lokalt navn om til kontordomenet før det slås opp. Da lyver resolveren slett ikke: den ble stilt et rettferdig spørsmål om et kontornavn og ga et riktig svar. Les det oppslåtte navnet i resolverens utdata for å skille dette fra reklameadresse-tilfellet, fordi de to feilene ser identiske ut i filbehandleren.

Løsningen her er enten å bruke det fullt kvalifiserte lokale navnet eller å legge til en regel for splittet DNS som eier det lokale suffikset. Ingen av dem krever å røre Samba.

Bevis det etter en ny tilkobling

Test tre navn i én økt: den lokale delingen ved kortnavn, en kontorvert ved navn og et vanlig nettsted. Hvis det første virker og det andre bryter, har reparasjonen flyttet feilen i stedet for å fjerne den. Hvis det tredje bryter, gikk resolverendringen lenger enn tiltenkt, og hvert oppslag er nå mistenkelig.

Koble deretter fra og til tunnelen på nytt, og gjenta alle tre. Pushede alternativer brukes på nytt ved hver tilkobling, så en reparasjon som bare fantes ved kjøretid, kan forsvinne uten at en konfigurasjonsfil endres. Noter resolveren som eier hvert suffiks, og oppslagsrekkefølgen som gjelder, og skriv ned datoen, fordi den neste klientoppdateringen er den åpenbare mistenkte når dette kommer tilbake.

Hvis delingen fortsatt feiler etter alle fem kontrollene, fang den nøyaktige spørringen og det nøyaktige svaret før du endrer noe annet. Det paret med linjer skiller en resolverfeil fra et navn som virkelig ikke finnes, og det er den raskeste overleveringsnotatet du kan skrive.