Lokalni Samba share nestao nakon što je OpenVPN gurnuo DNS

Samba gubi lokalne shareove u trenutku kada se OpenVPN poveže, a tunel gotovo nikada nije uzrok. Montiranje je u redu, NAS radi, a resolver koji je tunel instalirao odgovara na pitanja o imenu koje nikada nije vidio. Samba pita taj resolver rano u svom redoslijedu pretrage, vjeruje odgovoru i spaja se na adresu na kojoj ništa ne sluša. Popraviti share znači popraviti odgovor, a ne montiranje.

Pet provjera, redom koji na svakom koraku isključuje najviše mogućnosti.

Ko odgovara za kratko ime

Pitajte operativni sistem, ne upravitelja datoteka. resolvectl status ispisuje DNS servere vezane za svaku vezu i označava koja je veza zadana ruta, a upit za kratko ime prijavljuje server koji je odgovorio. Pokrenite ga jednom za NAS ime i jednom za ime za koje znate da postoji u office domeni. Ako dva odgovora dolaze s različitih servera, našli ste rascjep.

Provjerite je li odgovor bio negativan odgovor ili adresa. Negativan odgovor znači da je Samba trebala prijeći na drugi mehanizam, a kvar je negdje drugdje. Adresa znači da se Samba spojila na stvarno mjesto i nije dobila ništa.

Zašto Samba vjeruje pogrešnom odgovoru

Samba razrješava imena kroz fiksni niz koji postavlja name resolve order. Na većini distribucija zadana vrijednost uključuje host, što znači DNS, i on se izvršava prije mehanizama samo za lokalnu mrežu, kao što je NetBIOS broadcast. Zato tunel koji gura resolver dobija pravo prvog odbijanja za svako ime sharea, uključujući imena s jednom oznakom koja nikada nisu trebala napustiti zgradu.

Obično nepoznato ime vraća negativan odgovor i sljedeći mehanizam dobija red. Neki resolveri, posebno korisnički ISP-ovi i javni, na nepoznata imena odgovaraju stranicom za pretragu ili reklamnom adresom. Taj odgovor biblioteci resolvera izgleda kao uspjeh, pa Samba prestaje tražiti i bira adresu koja nema veze s vašom mrežom.

Rezultat je share koji nestaje bez dijaloga o grešci. Ništa u tom nizu nije kvar VPN rutiranja, zato ping prema NAS-u još radi, a pregledavanje prema njemu ne.

Dvije popravke različitog obima

Uža popravka zadržava gurnuti resolver i mijenja šta Samba smije pitati. Dodajte dva reda u Samba konfiguraciju koju demon zaista čita, zatim restartujte servis:

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

Bez host na tom spisku DNS izlazi iz puta za pretragu shareova, a imena s jednom oznakom ostaju na lokalnom segmentu. Office imena se i dalje normalno razrješavaju za svaki drugi program, jer ovo mijenja samo Sambu. Cijena je da Samba više uopće ne može koristiti DNS, pa share adresiran punim office imenom postaje problem.

Šira popravka uklanja uzrok: prestanite gurati resolver koji odgovara na imena koja ne posjeduje, ili gurnite politiku podijeljenog DNS-a tako da samo office sufiksi dolaze do office resolvera. To je bolji dugoročni odgovor u upravljanoj mreži jer štiti i preglednik i upravitelja paketa, ali zahtijeva administrativni pristup na serverskoj strani i klijenta koji sluša gurnute postavke.

Odaberite jednu namjerno. Promjena resolvera mijenja razrješavanje imena za svaku aplikaciju odjednom, što je zapis o promjeni, a ne izmjena za poziv podršci.

Sufiks može objasniti sve

Ako klijent gura i sufiks za pretragu, kratko lokalno ime se prepisuje u office domenu prije nego što se upita. Tada resolver uopće ne laže: postavljeno mu je pošteno pitanje o office imenu i dao je tačan odgovor. Pročitajte upitano ime u izlazu resolvera da to razlikujete od slučaja s reklamnom adresom, jer dva kvara izgledaju identično u upravitelju datoteka.

Popravka je ovdje ili koristiti puno kvalificirano lokalno ime, ili dodati pravilo podijeljenog DNS-a koje posjeduje lokalni sufiks. Niti jedno ne zahtijeva diranje Sambe.

Dokažite to nakon ponovnog spajanja

Testirajte tri imena u jednoj sesiji: lokalni share po kratkom imenu, office host po imenu i običnu web stranicu. Ako prvo radi, a drugo se pokvari, popravka je premjestila kvar umjesto da ga ukloni. Ako se treće pokvari, promjena resolvera je otišla dalje od predviđenog i svaka pretraga je sad sumnjiva.

Zatim odspojite i ponovo spojite tunel i ponovite sva tri. Gurnute opcije se ponovo primjenjuju pri svakom spajanju, pa popravka koja je postojala samo u radnom vremenu može nestati bez promjene konfiguracijske datoteke. Zapišite resolver koji posjeduje svaki sufiks i redoslijed pretrage koji je na snazi, i zabilježite datum, jer je sljedeće ažuriranje klijenta očigledan osumnjičeni kada se ovo vrati.

Ako share i dalje ne radi nakon svih pet provjera, zabilježite tačan upit i tačan odgovor prije nego što promijenite bilo šta drugo. Taj par redova razlikuje kvar resolvera od imena koje zaista ne postoji, i to je najbrža bilješka za primopredaju koju možete napisati.