A helyi Samba megosztás eltűnt, miután az OpenVPN DNS-t tolt

A Samba abban a pillanatban elveszíti a helyi megosztásokat, amikor OpenVPN csatlakozik, és az alagút szinte soha nem az ok. A csatolás rendben van, a NAS működik, és az alagút által telepített feloldó olyan névre válaszol, amelyet soha nem látott. A Samba korán kérdezi ezt a feloldót a keresési sorrendjében, hisz a válasznak, és olyan címre csatlakozik, ahol semmi nem figyel. A megosztás javítása a válasz javítását jelenti, nem a csatolásét.

Öt ellenőrzés, abban a sorrendben, amely lépésenként a legtöbb lehetőséget zárja ki.

Ki válaszol a rövid névre

Kérdezze az operációs rendszert, ne a fájlkezelőt. A resolvectl status kiírja az egyes kapcsolatokhoz rendelt DNS-kiszolgálókat, és megjelöli, melyik kapcsolat az alapértelmezett útvonal, a rövid név lekérdezése pedig jelenti a válaszoló kiszolgálót. Futtassa egyszer a NAS nevére, egyszer pedig egy olyan névre, amelyről tudja, hogy létezik az irodai tartományban. Ha a két válasz különböző kiszolgálóktól érkezik, megtalálta a szakadást.

Ellenőrizze, hogy a válasz negatív válasz vagy cím volt-e. A negatív válasz azt jelenti, hogy a Sambának tovább kellett volna lépnie egy másik mechanizmusra, és a hiba máshol van. A cím azt jelenti, hogy a Samba valódi helyre csatlakozott, és semmit nem kapott vissza.

Miért hisz a Samba egy hibás válasznak

A Samba a neveket a name resolve order által meghatározott rögzített sorrenden keresztül oldja fel. A legtöbb disztribúcióban az alapértelmezés tartalmazza a host bejegyzést, ami DNS-t jelent, és ez a csak helyi hálózatra szolgáló mechanizmusok, például a NetBIOS-sugárzás előtt fut. Ezért az a feloldót tolt alagút minden megosztásnév esetében megkapja az első elutasítás jogát, beleértve az egyszerű címkéjű neveket is, amelyeknek soha nem kellett volna elhagyniuk az épületet.

Általában az ismeretlen név negatív választ ad vissza, és a következő mechanizmus kap sort. Egyes feloldók, különösen a fogyasztói internetszolgáltatók és a nyilvános feloldók, az ismeretlen nevekre keresőlappal vagy reklámcímmel válaszolnak. Ez a válasz a feloldó könyvtárának sikernek tűnik, ezért a Samba abbahagyja a keresést, és olyan címet tárcsáz, amelynek semmi köze a hálózatához.

Az eredmény egy megosztás, amely hibaablak nélkül eltűnik. Ebben a sorrendben semmi nem VPN-útválasztási hiba, ezért a NAS pingelése továbbra is működik, míg a rá való böngészés nem.

Két különböző hatókörű javítás

A szűk javítás megtartja a betoltott feloldót, és megváltoztatja, mit kérdezhet tőle a Samba. Adjon hozzá két sort ahhoz a Samba-konfigurációhoz, amelyet a démon valóban olvas, majd indítsa újra a szolgáltatást:

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

Ha ebben a listában nincs host, a DNS kikerül a megosztáskeresés útjából, és az egyszerű címkéjű nevek a helyi szegmensen maradnak. Az irodai nevek továbbra is normálisan feloldódnak minden más program számára, mert ez csak a Sambát változtatja meg. Az ár az, hogy a Samba egyáltalán nem használhat DNS-t, így a teljesen minősített irodai névvel címzett megosztás problémává válik.

A széles javítás megszünteti az okot: ne toljon olyan feloldót, amely nem az övéihez tartozó nevekre válaszol, vagy toljon osztott DNS-szabályzatot, hogy csak az irodai utótagok érjék el az irodai feloldót. Ez a jobb hosszú távú válasz felügyelt hálózaton, mert a böngészőt és a csomagkezelőt is védi, de rendszergazdai hozzáférést igényel a kiszolgáló oldalán és egy olyan klienst, amely engedelmeskedik a betoltott beállításoknak.

Válasszon egyet szándékosan. A feloldó módosítása egyszerre változtatja meg a névfeloldást minden alkalmazás számára, ami változási rekord, nem támogatási híváshoz készült szerkesztés.

Az utótag mindent megmagyarázhat

Ha a kliens keresési utótagot is tol, a rövid helyi név még a lekérdezés előtt átíródik az irodai tartományba. Akkor a feloldó egyáltalán nem hazudik: tisztességes kérdést tettek fel neki egy irodai névről, és helyes választ adott. Olvassa el a lekérdezett nevet a feloldó kimenetében, hogy ezt megkülönböztesse a reklámcím esetétől, mert a két hiba a fájlkezelőben azonosnak látszik.

A megoldás itt vagy a teljesen minősített helyi név használata, vagy egy osztott DNS-szabály hozzáadása, amely a helyi utótag tulajdonosa. Egyik sem igényli a Samba érintését.

Bizonyítsa újracsatlakozás után

Teszteljen három nevet egy munkamenetben: a helyi megosztást rövid névvel, egy irodai gazdagépet névvel és egy közönséges webhelyet. Ha az első működik, a második pedig elromlik, a javítás áthelyezte a hibát ahelyett, hogy megszüntette volna. Ha a harmadik romlik el, a feloldó módosítása tovább ment a szándékoltnál, és minden keresés gyanús most.

Ezután bontsa és csatlakoztassa újra az alagutat, és ismételje meg mindhármat. A betoltott beállítások minden csatlakozáskor újra érvénybe lépnek, ezért egy csak futásidőben létező javítás eltűnhet anélkül, hogy konfigurációs fájl változna. Jegyezze fel a feloldót, amely az egyes utótagok tulajdonosa, és az érvényben lévő keresési sorrendet, és írja fel a dátumot, mert a következő kliensfrissítés a nyilvánvaló gyanúsított, amikor ez visszatér.

Ha a megosztás mind az öt ellenőrzés után is meghiúsul, rögzítse a pontos lekérdezést és a pontos választ, mielőtt bármi mást megváltoztatna. Ez a két sor megkülönbözteti a feloldó hibáját egy olyan névtől, amely valóban nem létezik, és ez a leggyorsabb átadási jegyzet, amit írhat.