Lokalni Samba share nestao je 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 svojem 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.

Tko odgovara za kratko ime

Pitajte operativni sustav, ne upravitelja datoteka. resolvectl status ispisuje DNS poslužitelje vezane uz svaku vezu i označava koja je veza zadana ruta, a upit za kratko ime prijavljuje poslužitelj 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 poslužitelja, pronašli ste razdvajanje.

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 slijed 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, poput NetBIOS broadcasta. Zato tunel koji gura resolver dobiva 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 dobiva red. Neki resolveri, posebno korisnički ISP-ovi i javni, na nepoznata imena odgovaraju stranicom za pretraživanje ili reklamnom adresom. Taj odgovor knjižnici 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 pogrešci. Ništa u tom slijedu nije kvar VPN usmjeravanja, zato ping prema NAS-u još radi, a pregledavanje prema njemu ne.

Dvije popravke različitog opsega

Uža popravka zadržava gurnuti resolver i mijenja što Samba smije pitati. Dodajte dva retka u Samba konfiguraciju koju demon doista čita, zatim restartajte uslugu:

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

Bez host na tom popisu 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 poslužiteljskoj 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 prepisuje se 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 toč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 ponovno spojite tunel i ponovite sva tri. Gurnute opcije ponovno se primjenjuju pri svakom spajanju, pa popravka koja je postojala samo u vremenu izvršavanja 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čit osumnjičenik kada se ovo vrati.

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