Lokal Samba-deling forsvann etter at OpenVPN pusha DNS

Samba mistar lokale delingar i det augeblikket OpenVPN ho vert kopla til, og tunnelen er nesten aldri årsaka. Monteringa er i orden, NAS-en er oppe, og resolvaren tunnelen installerte svarar på spørsmål om eit namn han aldri har sett. Samba spør denne resolvaren tidleg i oppslagsrekkjefølgja si, trur på svaret og koplar til ei adresse der ingenting lyttar. Å reparere delinga tyder å reparere svaret, ikkje monteringa.

Fem kontrollar, i den rekkjefølgja som utelukkar flest moglegheiter per steg.

Kven svarar for kortnamnet

Spør operativsystemet, ikkje filhandsamaren. resolvectl status skriv ut DNS-tenarane som er knytte til kvar lenkje og markerer kva lenkje som er standardruta, og eit oppslag på kortnamnet rapporterer tenaren som svara. Køyr det éin gong for NAS-namnet og éin gong for eit namn du veit finst i kontordomenet. Viss dei to svara kjem frå ulike tenarar, har du funne splittinga.

Kontroller om svaret var eit negativt svar eller ei adresse. Eit negativt svar tyder at Samba burde ha gått vidare til ein annan mekanisme, og feilen er ein annan stad. Ei adresse tyder at Samba kopla til ein verkeleg stad og fekk ingenting tilbake.

Kvifor Samba trur på eit feil svar

Samba løyser namn gjennom ein fast sekvens sett av name resolve order. På dei fleste distribusjonar inneheld standardverdien host, som tyder DNS, og han køyrer før mekanismane berre for lokalnett som NetBIOS-kringkasting. Ein tunnel som pushar ein resolver får difor første avslag på kvart delingsnamn, òg eittetikettsnamn som aldri skulle ha forlate bygningen.

Vanlegvis returnerer eit ukjent namn eit negativt svar, og neste mekanisme får sin tur. Nokre resolvarar, særleg forbrukar-ISP-ar og offentlege, svarar på ukjende namn med ei søkjeside eller ei reklameadresse i staden. Det svaret ser ut som suksess for resolvarbiblioteket, så Samba sluttar å leite og ringer ei adresse som ikkje har noko med nettet ditt å gjere.

Resultatet er ei deling som forsvinn utan ein feildialog. Ingenting i den sekvensen er ein VPN-rutefeil, og difor verkar det framleis å pinga NAS-en medan det ikkje verkar å bla til han.

To reparasjonar med ulik rekkjevidde

Den smale reparasjonen held på den pusha resolvaren og endrar kva Samba får spørje han om. Legg til to linjer i Samba-konfigurasjonen som daemonen faktisk les, og start deretter tenesta på nytt:

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

Utan host på den lista er DNS ute av vegen for delingsoppslag, og eittetikettsnamn vert verande på det lokale segmentet. Kontornamn vert framleis løyste normalt for alle andre program, fordi dette berre endrar Samba. Prisen er at Samba ikkje lenger kan bruke DNS i det heile, så ei deling som vert adressert med eit fullt kvalifisert kontornamn, vert eit problem.

Den breie reparasjonen fjernar årsaka: slutt å pushe ein resolver som svarar på namn han ikkje eig, eller push ein splitta DNS-policy slik at berre kontorsuffiks når kontorets resolver. Det er det betre langsiktige svaret på eit administrert nettverk, fordi det òg vernar nettlesaren og pakkehandsamaren, men det krev administrativ tilgang på serversida og ein klient som lyder dei pusha innstillingane.

Vel éin med vilje. Ei resolverendring endrar namneoppslag for kvar applikasjon på éin gong, noko som er ein endringsregistrering, ikkje ei redigering for ein støttesamtale.

Suffikset kan forklare alt

Viss klienten òg pushar eit søkjesuffiks, vert eit kort lokalt namn skrive om til kontordomenet før det vert slått opp. Då lyg resolvaren slett ikkje: han vart stilt eit rettferdig spørsmål om eit kontornamn og gav eit riktig svar. Les det oppslåtte namnet i utdata frå resolvaren for å skilje dette frå reklameadresse-tilfellet, fordi dei to feila ser identiske ut i filhandsamaren.

Løysinga her er anten å bruke det fullt kvalifiserte lokale namnet eller å leggje til ein regel for splitta DNS som eig det lokale suffikset. Ingen av dei krev å røre Samba.

Prov det etter ei ny tilkopling

Test tre namn i éi økt: den lokale delinga ved kortnamn, ein kontorvert ved namn og ein vanleg nettstad. Viss det første verkar og det andre bryt, har reparasjonen flytta feilen i staden for å fjerne han. Viss det tredje bryt, gjekk resolverendringa lenger enn tenkt, og kvart oppslag er no mistenkjeleg.

Kopla deretter frå og til tunnelen på nytt, og gjenta alle tre. Pusha alternativ vert brukte på nytt ved kvar tilkopling, så ein reparasjon som berre fanst ved køyretid, kan forsvinne utan at ein konfigurasjonsfil vert endra. Noter resolvaren som eig kvart suffiks, og oppslagsrekkjefølgja som gjeld, og skriv ned datoen, fordi den neste klientoppdateringa er den openberre mistenkte når dette kjem tilbake.

Viss delinga framleis feilar etter alle fem kontrollane, fang den nøyaktige spørjinga og det nøyaktige svaret før du endrar noko anna. Det paret med linjer skil ein resolverfeil frå eit namn som verkeleg ikkje finst, og det er den raskaste overleveringsnotatet du kan skrive.