Plaaslike Samba-deel het verdwyn nadat OpenVPN DNS gestoot het

Samba verloor plaaslike dele op die oomblik wanneer OpenVPN verbind, en die tonnel is byna nooit die oorsaak nie. Die aankoppeling is in orde, die NAS is aan, en die oplosser wat die tonnel geïnstalleer het, antwoord vrae oor 'n naam wat hy nog nooit gesien het nie. Samba vra daardie oplosser vroeg in sy opsoekorde, glo die antwoord en verbind na 'n adres waar niks luister nie. Om die deel reg te maak beteken om die antwoord reg te maak, nie die aankoppeling nie.

Vyf kontroles, in die volgorde wat per stap die meeste moontlikhede uitskakel.

Wie antwoord vir die kort naam

Vra die bedryfstelsel, nie die lêerbestuurder nie. resolvectl status wys die DNS-bediensers wat aan elke skakel gekoppel is en merk watter skakel die verstekroete is, en 'n navraag vir die kort naam rapporteer die bediener wat geantwoord het. Voer dit een keer uit vir die NAS-naam en een keer vir 'n naam waarvan jy weet dit bestaan in die kantoor se domein. As die twee antwoorde van verskillende bedieners kom, het jy die splitsing gevind.

Kontroleer of die antwoord 'n negatiewe antwoord of 'n adres was. 'n Negatiewe antwoord beteken Samba moes na 'n ander meganisme oorgegaan het, en die fout lê elders. 'n Adres beteken Samba het êrens regtig verbind en niks teruggekry.

Waarom Samba 'n verkeerde antwoord glo

Samba los name op deur 'n vaste reeks wat deur name resolve order bepaal word. Op die meeste verspreidings sluit die verstek host in, wat DNS beteken, en dit loop voor die slegs-LAN-meganismes soos NetBIOS-uitsending. 'n Tonnel wat 'n oplosser stoot, kry dus eerste weiering op elke deelnaam, insluitend enkel-etiket-name wat nooit bedoel was om die gebou te verlaat nie.

Gewoonlik gee 'n onbekende naam 'n negatiewe antwoord terug en kry die volgende meganisme 'n beurt. Sommige oplossers, veral verbruiker-ISP's en publieke oplossers, antwoord onbekende name met 'n soekbladsy of 'n advertensie-adres. Daardie antwoord lyk vir die oplosser-biblioteek soos sukses, so Samba hou op soek en skakel 'n adres wat niks met jou netwerk te doen het nie.

Die resultaat is 'n deel wat verdwyn sonder 'n foutdialoog. Niks in daardie reeks is 'n VPN-roeteringsfout nie, daarom werk dit steeds om die NAS te ping terwyl dit nie werk om daarheen te blaai nie.

Twee herstellings met verskillende omvang

Die nou herstelling hou die gestooide oplosser en verander wat Samba toegelaat word om hom te vra. Voeg twee reëls by die Samba-konfigurasie wat die daemon werklik lees, en herbegin dan die diens:

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

Sonder host in daardie lys is DNS uit die pad vir deelopsoeke, en enkel-etiket-name bly op die plaaslike segment. Kantoorname los steeds normaal op vir elke ander program, want dit verander net Samba. Die koste is dat Samba glad nie meer DNS kan gebruik nie, so 'n deel wat deur 'n volkwalifiseerde kantoornaam geadresseer word, word 'n probleem.

Die breë herstelling verwyder die oorsaak: hou op om 'n oplosser te stoot wat name antwoord wat hy nie besit nie, of stoot 'n split-DNS-beleid sodat net kantoor-agtervoegsels die kantoor-oplosser bereik. Dit is die beter langtermyn-antwoord op 'n bestuurde netwerk, want dit beskerm die blaaier en die pakketbestuurder ook, maar dit vereis administratiewe toegang aan die bedienerkant en 'n kliënt wat die gestooide instellings gehoorsaam.

Kies een doelbewus. 'n Oplosser-verandering verander naambepaling vir elke toepassing gelyktydig, wat 'n veranderingsrekord is, nie 'n wysiging vir 'n ondersteuningsoproep nie.

Die agtervoegsel kan alles verklaar

As die kliënt ook 'n soek-agtervoegsel stoot, word 'n kort plaaslike naam herskryf na die kantoor se domein voordat dit nagevra word. Dan lieg die oplosser glad nie: hy is 'n billike vraag oor 'n kantoornaam gevra en het 'n korrekte antwoord gegee. Lees die nagevraagde naam in die oplosser-uitset om dit van die advertensie-adres-geval te onderskei, want die twee foute lyk identies in die lêerbestuurder.

Die oplossing hier is óf om die volkwalifiseerde plaaslike naam te gebruik óf om 'n split-DNS-reël by te voeg wat die plaaslike agtervoegsel besit. Nie een vereis om aan Samba te raak nie.

Bewys dit ná 'n herverbinding

Toets drie name in een sessie: die plaaslike deel by kort naam, 'n kantoor-gasheer by naam, en 'n gewone webwerf. As die eerste werk en die tweede breek, het die herstelling die fout verskuif eerder as om dit te verwyder. As die derde breek, het die oplosser-verandering verder gegaan as bedoel en elke opsoek is nou verdag.

Koppel dan die tonnel los en weer vas en herhaal al drie. Gestooide opsies word by elke verbinding weer toegepas, so 'n herstelling wat net tydens looptyd bestaan het, kan verdwyn sonder dat 'n konfigurasielêer verander. Teken die oplosser aan wat elke agtervoegsel besit en die opsoekorde wat geld, en noteer die datum, want die volgende kliënt-opdatering is die voor die hand liggende verdagte wanneer dit terugkeer.

As die deel steeds misluk ná al vyf kontroles, vang die presiese navraag en die presiese antwoord op voordat jy enigiets anders verander. Daardie paar reëls onderskei 'n oplosser-fout van 'n naam wat werklik nie bestaan nie, en dit is die vinnigste oordragnota wat jy kan skryf.