Partajarea locală Samba a dispărut după ce OpenVPN a împins DNS

Samba pierde partajările locale în momentul în care OpenVPN se conectează, iar tunelul aproape niciodată nu este cauza. Montarea este în regulă, NAS-ul funcționează, iar resolverul instalat de tunel răspunde la întrebări despre un nume pe care nu l-a văzut niciodată. Samba întreabă acel resolver devreme în ordinea sa de căutare, crede răspunsul și se conectează la o adresă unde nimic nu ascultă. Repararea partajării înseamnă repararea răspunsului, nu a montării.

Cinci verificări, în ordinea care elimină cele mai multe posibilități la fiecare pas.

Cine răspunde pentru numele scurt

Întrebați sistemul de operare, nu managerul de fișiere. resolvectl status afișează serverele DNS asociate fiecărei legături și marchează care legătură este ruta implicită, iar o interogare a numelui scurt raportează serverul care a răspuns. Rulați-l o dată pentru numele NAS-ului și o dată pentru un nume despre care știți că există în domeniul biroului. Dacă cele două răspunsuri vin de la servere diferite, ați găsit divizarea.

Verificați dacă răspunsul a fost un răspuns negativ sau o adresă. Un răspuns negativ înseamnă că Samba ar fi trebuit să treacă la un alt mecanism, iar defectul este în altă parte. O adresă înseamnă că Samba s-a conectat la un loc real și nu a primit nimic înapoi.

De ce crede Samba un răspuns greșit

Samba rezolvă numele printr-o secvență fixă stabilită de name resolve order. Pe majoritatea distribuțiilor valoarea implicită include host, ceea ce înseamnă DNS, și rulează înaintea mecanismelor doar pentru rețeaua locală, cum ar fi difuzarea NetBIOS. De aceea un tunel care împinge un resolver primește primul refuz pentru fiecare nume de partajare, inclusiv nume cu o singură etichetă care nu ar fi trebuit niciodată să părăsească clădirea.

De obicei un nume necunoscut returnează un răspuns negativ, iar mecanismul următor primește rândul. Unele resolvere, mai ales cele ale ISP-urilor de consum și cele publice, răspund numelor necunoscute cu o pagină de căutare sau o adresă publicitară. Acel răspuns pare un succes pentru biblioteca resolverului, așa că Samba nu mai caută și apelează o adresă care nu are nicio legătură cu rețeaua dumneavoastră.

Rezultatul este o partajare care dispare fără o fereastră de eroare. Nimic din acea secvență nu este o defecțiune de rutare VPN, de aceea ping-ul către NAS încă funcționează, în timp ce navigarea către el nu funcționează.

Două reparații cu anvergură diferită

Reparația îngustă păstrează resolverul împins și schimbă ceea ce Samba are voie să-l întrebe. Adăugați două linii la configurația Samba pe care daemonul o citește efectiv, apoi reporniți serviciul:

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

Fără host în acea listă, DNS iese din calea căutării partajărilor, iar numele cu o singură etichetă rămân pe segmentul local. Numele biroului se rezolvă în continuare normal pentru orice alt program, pentru că acest lucru schimbă doar Samba. Costul este că Samba nu mai poate folosi deloc DNS, așa că o partajare adresată cu un nume complet calificat de birou devine o problemă.

Reparația largă elimină cauza: opriți împingerea unui resolver care răspunde la nume pe care nu le deține, sau împingeți o politică de DNS divizat astfel încât doar sufixele biroului să ajungă la resolverul biroului. Acesta este răspunsul mai bun pe termen lung într-o rețea administrată, pentru că protejează și browserul și managerul de pachete, dar necesită acces administrativ pe partea de server și un client care ascultă de setările împinse.

Alegeți una în mod deliberat. O schimbare de resolver modifică rezolvarea numelor pentru fiecare aplicație deodată, ceea ce este o înregistrare de modificare, nu o editare pentru un apel la suport.

Sufixul poate explica totul

Dacă clientul împinge și un sufix de căutare, un nume local scurt este rescris în domeniul biroului înainte de a fi interogat. Atunci resolverul nu minte deloc: i s-a pus o întrebare corectă despre un nume de birou și a dat un răspuns corect. Citiți numele interogat în ieșirea resolverului pentru a distinge acest caz de cel al adresei publicitare, pentru că cele două defecțiuni arată identic în managerul de fișiere.

Soluția aici este fie să folosiți numele local complet calificat, fie să adăugați o regulă de DNS divizat care deține sufixul local. Niciuna nu necesită atingerea Samba.

Dovediți-o după o reconectare

Testați trei nume într-o singură sesiune: partajarea locală după numele scurt, un host al biroului după nume și un site web obișnuit. Dacă primul funcționează și al doilea se strică, reparația a mutat defectul în loc să-l elimine. Dacă se strică al treilea, schimbarea resolverului a mers mai departe decât s-a intenționat și fiecare căutare este acum suspectă.

Apoi deconectați și reconectați tunelul și repetați toate trei. Opțiunile împinse sunt reaplicate la fiecare conectare, așa că o reparație care exista doar în timpul execuției poate dispărea fără ca vreun fișier de configurare să se schimbe. Notați resolverul care deține fiecare sufix și ordinea de căutare în vigoare, și notați data, pentru că următoarea actualizare a clientului este suspectul evident când acest lucru revine.

Dacă partajarea încă eșuează după toate cele cinci verificări, capturați interogarea exactă și răspunsul exact înainte de a schimba orice altceva. Acea pereche de linii distinge o defecțiune a resolverului de un nume care chiar nu există, și este cea mai rapidă notă de predare pe care o puteți scrie.