Samba na adrese VPN: prečo poslucháč mizne

Zdieľanie funguje celé dopoludnie, tunel sa na obed znovu pripojí a tá istá cesta UNC teraz vyprší, zatiaľ čo ping na server stále odpovedá. V definícii zdieľania sa nič nezmenilo a VPN beží. Zmenila sa miestna adresa, na ktorú bola Samba naviazaná, a po opätovnom vytvorení rozhrania už neexistuje. Taký spôsob zlyhania je problém životného cyklu poslucháča, nie problém oprávnení.

Zdieľanie funguje, kým sa tunel reštartuje

Naviazanie služby na adresu pripúta jej socket k životnosti tejto adresy. Keď sa rozhranie tunela zničí a znova vytvorí, stará adresa zmizne a socket naviazaný na ňu zmizne s ňou. Služba beží ďalej, ale nič nepočúva tam, kam sú klienti smerovaní.

Ping môže stále uspieť, ak nová adresa odpovedá na ICMP, a preto dostupnosť vyzerá dobre, kým je zdieľanie mŕtve. Práve tento jediný zavádzajúci úspech posiela ľudí k firewallu.

Dostupnosť nie je adresa naviazania

Miešajú sa tu tri rozhodnutia. Trasa rozhoduje, či paket klienta dorazí. Počúvajúci socket rozhoduje, či ho niečo na miestnej adrese prijme. Konfigurácia zdieľania a oprávnenia súborového systému rozhodujú, čo sa stane potom. Pri opätovnom vytvorení rozhrania sa pokazí iba druhé.

Ani adresa z fondu VPN nie je automaticky miestnou adresou naviazania. Patrí klientovi, nie súborovému serveru. Ping je pre súborovú službu slabý test.

Držte týchto vlastníkov oddelene aj v dokumentácii. Budúca zmena fondu VPN by nemala vyžadovať úpravu Samby a zmena oprávnení zdieľania by nemala vyžadovať reštart tunela.

Naväzte sa radšej na stabilnú adresu

Stabilnejší návrh drží Sambu na trvalej adrese a necháva VPN, aby k nej priviedla klientov. Adresa servera sa pri zakolísaní tunela nemení, takže poslucháč nikdy nemusí sledovať rozhranie. Prístup potom vynucuje cesta VPN a firewall hostiteľa, ktoré sú na túto úlohu stavané.

Ak sa na tunel naviazať musíte, pochopte zmluvu nainštalovanej verzie. Parametre interfaces a bind interfaces only nie sú to isté a dokumentácia k naväzovaniu varuje pred prerušovanými rozhraniami. Dynamická správa poslucháča existuje na niektorých platformách, ale je to schopnosť na overenie, nie na predpoklad. Prečítajte tabuľku pred zakolísaním a po ňom a porovnajte oba výstupy.

ss -ltnp | grep ':445'

Testujte opätovné pripojenie, nie zelenú kontrolku

Overte poslucháča po opätovnom pripojení, nielen po spustení služby. Znova vytvorte tunel, potom prečítajte tabuľku počúvania a potvrďte, že socket existuje na adrese, kam sú klienti smerovaní. Zelený indikátor tunela a úspešná kontrola konfigurácie nepreukazujú ani jedno.

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

Potom spustite jednu povolenú operáciu a jednu zakázanú cestu z klienta a zopakujte to po druhom opätovnom pripojení. Ak zdieľanie funguje len do prvého zakolísania, naviazanie je stále zviazané so životnosťou rozhrania a návrh nie je opravený. Zmeňte naviazanie alebo adresu služby a symptóm sa prestane vracať.