Samba egy VPN-címen: miért tűnik el a figyelő
A megosztás addig működik, amíg az alagút újraindul, aztán időtúllépésbe fut, miközben a ping még válaszol. Az eltűnt címhez kötött figyelő magyarázza az egész mintát.
A megosztás egész délelőtt működik, az alagút délben újracsatlakozik, és ugyanaz az UNC-útvonal most időtúllépésbe fut, miközben a ping a kiszolgálóhoz még válaszol. A megosztás definíciójában semmi sem változott, és a VPN fut. Ami változott, az a helyi cím, amelyhez a Samba kötve volt, és amely az interfész újralétrehozása után már nem létezik. Ez a hibamód a figyelő életciklusának problémája, nem jogosultsági probléma.
A megosztás addig működik, amíg az alagút újraindul
Egy szolgáltatás címhez kötése a socketjét az adott cím élettartamához rögzíti. Amikor az alagút interfésze megsemmisül és újraépül, a régi cím eltűnik, és a hozzá kötött socket is vele tűnik el. A szolgáltatás tovább fut, de semmi sem figyel ott, ahová az ügyfeleket irányítják.
A ping még sikerülhet, ha az új cím válaszol ICMP-re, és ezért az elérhetőség jónak látszik, miközben a megosztás halott. Pont ez az egyetlen félrevezető siker küldi az embereket a tűzfalhoz.
Az elérhetőség nem kötési cím
Itt három döntés keveredik. Az útvonal dönti el, hogy megérkezik-e egy ügyfélcsomag. A figyelő socket dönti el, hogy valami fogadja-e a helyi címen. A megosztás konfigurációja és a fájlrendszer jogosultságai döntik el, mi történik utána. Az interfész újralétrehozásakor csak a második törik meg.
A VPN-készletből származó cím sem helyi kötési cím automatikusan. Az egy ügyfélhez tartozik, nem a fájlkiszolgálóhoz. A ping rossz teszt egy fájlszolgáltatás számára.
Tartsa ezeket a tulajdonosokat a dokumentációban is külön. A VPN-készlet jövőbeli változása ne igényelje a Samba szerkesztését, és a megosztási jogosultságok változása ne igényelje az alagút újraindítását.
Inkább stabil címhez kössön
A stabilabb kialakítás a Sambát állandó címen tartja, és a VPN-re bízza, hogy az ügyfeleket odavigye. A kiszolgáló címe nem változik, amikor az alagút remeg, így a figyelőnek soha nem kell interfészt követnie. A beengedést ekkor a VPN-útvonal és a gazdagép tűzfala kényszeríti ki, amelyeket erre a feladatra építettek.
Ha mindenképpen az alagúthoz kell kötnie, értse meg a telepített kiadás szerződését. A interfaces és a bind interfaces only paraméter nem ugyanaz, és a kötésről szóló dokumentáció figyelmeztet a szakaszos interfészekre. A dinamikus figyelőkezelés néhány platformon létezik, de ez ellenőrizendő képesség, nem feltételezendő. Olvassa el a táblázatot remegés előtt és után, és hasonlítsa össze a két kimenetet.
ss -ltnp | grep ':445'Az újracsatlakozást tesztelje, ne a zöld lámpát
Ellenőrizze a figyelőt újracsatlakozás után, ne csak a szolgáltatás indítása után. Hozza létre újra az alagutat, majd olvassa el a figyelési táblázatot, és erősítse meg, hogy a socket létezik azon a címen, ahová az ügyfeleket irányítják. A zöld alagútjelző és a sikeres konfigurációellenőrzés egyiket sem bizonyítja.
smbclient -L //files.corp.example -U aliceEzután hajtson végre egy engedélyezett műveletet és egy megtagadott útvonalat egy ügyfélről, és ismételje meg egy második újracsatlakozás után. Ha a megosztás csak az első remegésig működik, a kötés továbbra is az interfész élettartamához kötődik, és a kialakítás nincs rendben. Változtassa meg a kötést vagy a szolgáltatás címét, és a tünet nem tér vissza.