Nawala ang lokal na Samba share matapos itulak ng OpenVPN ang DNS

Nawawala ng Samba ang mga lokal na share sa sandaling OpenVPN kumonekta ito, at halos hindi kailanman ang tunnel ang dahilan. Maayos ang mount, buhay ang NAS, at ang resolver na inilagay ng tunnel ay sumasagot sa mga tanong tungkol sa isang pangalang hindi pa nito nakita. Tinatanong ng Samba ang resolver na iyon nang maaga sa pagkakasunod-sunod ng paghahanap nito, pinaniniwalaan ang sagot at kumokonekta sa isang address na walang nakikinig. Ang ayusin ang share ay nangangahulugang ayusin ang sagot, hindi ang mount.

Limang pagsusuri, sa pagkakasunod-sunod na nag-aalis ng pinakamaraming posibilidad bawat hakbang.

Sino ang sumasagot para sa maikling pangalan

Tanungin ang operating system, hindi ang file manager. Ipinapakita ng resolvectl status ang mga DNS server na naka-attach sa bawat link at minarkahan kung aling link ang default na ruta, at ang query para sa maikling pangalan ay nag-uulat ng server na sumagot. Patakbuhin ito nang isang beses para sa pangalan ng NAS at isang beses para sa isang pangalang alam mong umiiral sa domain ng opisina. Kung ang dalawang sagot ay mula sa magkaibang server, natagpuan mo ang paghahati.

Suriin kung ang sagot ay negatibong sagot o address. Ang negatibong sagot ay nangangahulugang dapat na lumipat ang Samba sa ibang mekanismo, at ang sira ay nasa ibang lugar. Ang address ay nangangahulugang kumonekta ang Samba sa isang tunay na lugar at walang nakuha.

Bakit pinaniniwalaan ng Samba ang maling sagot

Nilulutas ng Samba ang mga pangalan sa pamamagitan ng isang fixed na pagkakasunod-sunod na itinakda ng name resolve order. Sa karamihan ng distribusyon, kasama sa default ang host, na nangangahulugang DNS, at ito ay tumatakbo bago ang mga mekanismong para sa LAN lamang tulad ng broadcast ng NetBIOS. Kaya ang tunnel na nagtutulak ng resolver ay nakakakuha ng unang pagtanggi sa bawat pangalan ng share, kabilang ang mga pangalang may isang label na hindi dapat umalis sa gusali.

Karaniwang nagbabalik ng negatibong sagot ang hindi kilalang pangalan at ang susunod na mekanismo ay nakakakuha ng pagkakataon. Ang ilang resolver, lalo na ng mga consumer ISP at pampubliko, ay sumasagot sa mga hindi kilalang pangalan ng search page o advertising address. Ang sagot na iyon ay mukhang tagumpay sa library ng resolver, kaya tumitigil ang Samba sa paghahanap at nag-dial sa address na walang kinalaman sa iyong network.

Ang resulta ay isang share na nawawala nang walang dialog ng error. Wala sa pagkakasunod-sunod na iyon ang pagkabigo sa routing ng VPN, kaya gumagana pa rin ang ping sa NAS habang hindi gumagana ang pag-browse dito.

Dalawang pag-aayos na may magkaibang saklaw

Pinapanatili ng makitid na pag-aayos ang itinulak na resolver at binabago kung ano ang pinapayagang itanong ng Samba dito. Magdagdag ng dalawang linya sa configuration ng Samba na aktwal na binabasa ng daemon, pagkatapos i-restart ang serbisyo:

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

Kung walang host sa listahang iyon, lumalabas ang DNS sa landas para sa paghahanap ng share, at ang mga pangalang may isang label ay nananatili sa lokal na segment. Ang mga pangalan ng opisina ay nilulutas pa rin nang normal para sa bawat ibang programa, dahil binabago nito ang Samba lamang. Ang halaga ay hindi na magagamit ng Samba ang DNS nang lubusan, kaya ang share na inindeks sa isang buong kwalipikadong pangalan ng opisina ay nagiging problema.

Inaalis ng malawak na pag-aayos ang dahilan: itigil ang pagtutulak ng resolver na sumasagot sa mga pangalang hindi sa kanya, o itulak ang split-DNS na patakaran upang ang mga suffix ng opisina lamang ang umabot sa resolver ng opisina. Iyon ang mas mahusay na pangmatagalang sagot sa isang pinamamahalaang network dahil pinoprotektahan din nito ang browser at ang package manager, ngunit nangangailangan ito ng administrative access sa panig ng server at isang client na sumusunod sa itinulak na mga setting.

Pumili ng isa nang sinasadya. Binabago ng pagbabago ng resolver ang resolution ng pangalan para sa bawat application nang sabay, na isang change record, hindi isang pag-edit para sa isang tawag sa suporta.

Kaya ng suffix na ipaliwanag ang lahat

Kung nagtutulak din ang client ng search suffix, ang maikling lokal na pangalan ay isinusulat muli sa domain ng opisina bago ito tanungin. Kung gayon, hindi nagsisinungaling ang resolver: tinanong ito ng patas na tanong tungkol sa pangalan ng opisina at nagbigay ng tamang sagot. Basahin ang itinanong na pangalan sa output ng resolver upang makilala ito sa kaso ng advertising address, dahil magkapareho ang dalawang sira sa file manager.

Ang solusyon dito ay alinman sa gamitin ang buong kwalipikadong lokal na pangalan o magdagdag ng split-DNS na panuntunang nagmamay-ari ng lokal na suffix. Wala sa dalawa ang nangangailangan ng paghawak sa Samba.

Patunayan ito pagkatapos ng muling pagkonekta

Subukan ang tatlong pangalan sa isang sesyon: ang lokal na share sa maikling pangalan, isang host ng opisina sa pangalan, at isang ordinaryong website. Kung gumana ang una at masira ang pangalawa, inilipat ng pag-aayos ang sira sa halip na alisin ito. Kung masira ang pangatlo, lumampas ang pagbabago ng resolver sa nilalayon at ang bawat paghahanap ay kahina-hinala na.

Pagkatapos i-disconnect at ikonekta muli ang tunnel at ulitin ang tatlo. Ang itinulak na mga opsyon ay muling inilalapat sa bawat koneksyon, kaya ang pag-aayos na umiiral lamang sa runtime ay maaaring mawala nang walang pagbabago sa configuration file. Itala ang resolver na nagmamay-ari ng bawat suffix at ang pagkakasunod-sunod ng paghahanap na may bisa, at itala ang petsa, dahil ang susunod na update ng client ang halatang pinaghihinalaan kapag bumalik ito.

Kung nabigo pa rin ang share pagkatapos ng lahat ng limang pagsusuri, kunin ang eksaktong query at ang eksaktong sagot bago baguhin ang anumang iba. Ang pares ng linyang iyon ay nagtatangi ng sira ng resolver mula sa isang pangalang talagang wala, at ito ang pinakamabilis na handover note na maisusulat mo.