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 alice

Ezutá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.

Kapcsolódó cikkek