Samba na adrese VPN: proč posluchač mizí

Sdílení funguje celé dopoledne, tunel se v poledne znovu připojí a stejná cesta UNC nyní vyprší, zatímco ping na server stále odpovídá. V definici sdílení se nic nezměnilo a VPN běží. Změnila se místní adresa, na kterou byla Samba navázaná, a ta po opětovném vytvoření rozhraní už neexistuje. Tento způsob selhání je problém životního cyklu posluchače, ne problém oprávnění.

Sdílení funguje, dokud se tunel restartuje

Navázání služby na adresu připoutá její socket k životnosti této adresy. Když se rozhraní tunelu zničí a znovu vytvoří, stará adresa zmizí a socket na ni navázaný zmizí s ní. Služba běží dál, ale nic neposlouchá tam, kam jsou klienti směrováni.

Ping může stále uspět, pokud nová adresa odpovídá na ICMP, a proto dostupnost vypadá dobře, i když je sdílení mrtvé. Právě tento jediný zavádějící úspěch posílá lidi k firewallu.

Dostupnost není adresa pro navázání

Míchají se zde tři rozhodnutí. Trasa rozhoduje, zda paket klienta dorazí. Poslouchající socket rozhoduje, zda jej něco na místní adrese přijme. Konfigurace sdílení a oprávnění souborového systému rozhodují, co se stane potom. Při opětovném vytvoření rozhraní se rozbije jen to druhé.

Ani adresa z fondu VPN není automaticky místní adresou pro navázání. Patří klientovi, ne souborovému serveru. Ping je pro souborovou službu špatný test.

Držte tyto vlastníky oddělené i v dokumentaci. Budoucí změna fondu VPN by neměla vyžadovat úpravu Samby a změna oprávnění sdílení by neměla vyžadovat restart tunelu.

Navazujte raději na stabilní adresu

Stabilnější návrh drží Sambu na trvalé adrese a nechává VPN, aby k ní klienty přiváděla. Adresa serveru se při zakolísání tunelu nemění, takže posluchač nikdy nemusí sledovat rozhraní. Vstup se pak vynucuje cestou VPN a firewallem hostitele, které jsou pro tento úkol stavěné.

Pokud se na tunel navázat musíte, pochopte smlouvu nainstalované verze. Parametry interfaces a bind interfaces only nejsou totéž a dokumentace k navazování varuje před přerušovanými rozhraními. Dynamická správa posluchače existuje na některých platformách, ale je to schopnost k ověření, ne k předpokladu. Přečtěte tabulku před zakolísáním a po něm a porovnejte oba výstupy.

ss -ltnp | grep ':445'

Testujte opětovné připojení, ne zelenou kontrolku

Ověřte posluchače po opětovném připojení, ne jen po spuštění služby. Znovu vytvořte tunel, potom přečtěte tabulku naslouchání a potvrďte, že socket existuje na adrese, kam jsou klienti směrováni. Zelený indikátor tunelu a úspěšná kontrola konfigurace neprokazují ani jedno.

smbclient -L //files.corp.example -U alice

Pak spusťte jednu povolenou operaci a jednu zakázanou cestu z klienta a zopakujte to po druhém opětovném připojení. Pokud sdílení funguje jen do prvního zakolísání, je navázání stále svázané s životností rozhraní a návrh není opravený. Změňte navázání nebo adresu služby a symptom se přestane vracet.