Vietinis Samba bendrinimas dingo po to, kai OpenVPN stūmė DNS

Samba praranda vietinius bendrinimus tą akimirką, kai OpenVPN prisijungia, ir tunelis beveik niekada nėra priežastis. Prijungimas tvarkingas, NAS veikia, o tunelio įdiegtas resolveris atsakinėja į klausimus apie vardą, kurio niekada nematė. Samba klausia šio resolverio anksti savo paieškos tvarkoje, tiki atsakymu ir jungiasi prie adreso, kuriame niekas neklauso. Sutaisyti bendrinimą reiškia sutaisyti atsakymą, o ne prijungimą.

Penki patikrinimai ta tvarka, kuri kiekviename žingsnyje pašalina daugiausia galimybių.

Kas atsako už trumpą vardą

Klauskite operacinės sistemos, o ne failų tvarkyklės. resolvectl status išspausdina DNS serverius, susietus su kiekviena jungtimi, ir pažymi, kuri jungtis yra numatytasis maršrutas, o trumpo vardo užklausa praneša atsakiusį serverį. Paleiskite jį vieną kartą NAS vardui ir vieną kartą vardui, kuris, kaip žinote, egzistuoja biuro domene. Jei du atsakymai ateina iš skirtingų serverių, radote skilimą.

Patikrinkite, ar atsakymas buvo neigiamas atsakymas, ar adresas. Neigiamas atsakymas reiškia, kad Samba turėjo pereiti prie kito mechanizmo, o gedimas yra kitur. Adresas reiškia, kad Samba prisijungė prie tikros vietos ir nieko negavo.

Kodėl Samba tiki klaidingu atsakymu

Samba išsprendžia vardus fiksuota seka, kurią nustato name resolve order. Daugumoje distribucijų numatytoji reikšmė apima host, tai reiškia DNS, ir ji vykdoma prieš tik vietiniam tinklui skirtus mechanizmus, tokius kaip NetBIOS transliacija. Todėl tunelis, stumiantis resolverį, gauna pirmojo atmetimo teisę kiekvienam bendrinimo vardui, įskaitant vienos etiketės vardus, kurie niekada neturėjo palikti pastato.

Paprastai nežinomas vardas grąžina neigiamą atsakymą ir kitas mechanizmas gauna eilę. Kai kurie resolveriai, ypač vartotojų ISP ir viešieji, į nežinomus vardus atsako paieškos puslapiu arba reklaminiu adresu. Toks atsakymas resolverio bibliotekai atrodo kaip sėkmė, todėl Samba nustoja ieškoti ir renkasi adresą, neturintį nieko bendra su jūsų tinklu.

Rezultatas – bendrinimas, kuris dingsta be klaidos dialogo. Niekas toje sekoje nėra VPN maršrutizavimo gedimas, todėl ping į NAS vis dar veikia, o naršymas į jį neveikia.

Du taisymai skirtingos apimties

Siauras taisymas palieka stumiamą resolverį ir keičia, ko Samba gali jo klausti. Pridėkite dvi eilutes prie Samba konfigūracijos, kurią demonas iš tikrųjų skaito, tada iš naujo paleiskite paslaugą:

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

Be host tame sąraše DNS išeina iš bendrinimų paieškos kelio, o vienos etiketės vardai lieka vietiniame segmente. Biuro vardai vis dar sprendžiami įprastai kiekvienai kitai programai, nes tai keičia tik Sambą. Kaina ta, kad Samba nebegali visiškai naudoti DNS, todėl bendrinimas, adresuojamas visiškai kvalifikuotu biuro vardu, tampa problema.

Platusis taisymas pašalina priežastį: nustokite stumti resolverį, kuris atsako už vardus, kurių jam nepriklauso, arba stumkite padalinto DNS politiką, kad biuro resolverį pasiektų tik biuro priesagos. Tai geresnis ilgalaikis atsakymas valdomame tinkle, nes apsaugo ir naršyklę, ir paketų tvarkyklę, bet reikia administracinės prieigos serverio pusėje ir kliento, kuris paklūsta stumiamiems nustatymams.

Pasirinkite vieną sąmoningai. Resolverio pakeitimas keičia vardų sprendimą visoms programoms iš karto, o tai yra pakeitimo įrašas, ne redagavimas palaikymo skambučiui.

Priesaga gali paaiškinti viską

Jei klientas taip pat stumia paieškos priesagą, trumpas vietinis vardas perrašomas į biuro domeną prieš užklausą. Tada resolveris visiškai nemeluoja: jo buvo sąžiningai paklausta apie biuro vardą ir jis davė teisingą atsakymą. Skaitykite užklaustą vardą resolverio išvestyje, kad atskirtumėte tai nuo reklaminio adreso atvejo, nes failų tvarkyklėje abu gedimai atrodo vienodai.

Sprendimas čia yra naudoti visiškai kvalifikuotą vietinį vardą arba pridėti padalinto DNS taisyklę, kuriai priklauso vietinė priesaga. Nė vienas nereikalauja liesti Samba.

Įrodykite tai po pakartotinio prisijungimo

Vienoje sesijoje išbandykite tris vardus: vietinį bendrinimą trumpu vardu, biuro mazgą vardu ir įprastą svetainę. Jei pirmasis veikia, o antrasis lūžta, taisymas perkėlė gedimą, o ne jį pašalino. Jei lūžta trečiasis, resolverio pakeitimas nuėjo toliau nei numatyta, ir kiekviena paieška dabar įtartina.

Tada atjunkite ir vėl prijunkite tunelį ir pakartokite visus tris. Stumiami nustatymai iš naujo taikomi kiekvieno prisijungimo metu, todėl taisymas, egzistavęs tik vykdymo metu, gali dingti nepasikeitus konfigūracijos failui. Užrašykite resolverį, kuriam priklauso kiekviena priesaga, ir galiojančią paieškos tvarką, ir pažymėkite datą, nes kitas kliento atnaujinimas yra akivaizdus įtariamasis, kai tai sugrįš.

Jei bendrinimas vis dar nepavyksta po visų penkių patikrinimų, užfiksuokite tikslią užklausą ir tikslų atsakymą prieš ką nors kita keisdami. Ši eilučių pora atskiria resolverio gedimą nuo vardo, kurio tikrai nėra, ir tai yra greičiausia perdavimo pastaba, kurią galite parašyti.