Samba op een VPN-adres: waarom de listener verdwijnt

De share werkt de hele ochtend, de tunnel verbindt rond de middag opnieuw, en hetzelfde UNC-pad loopt nu in een time-out terwijl ping naar de server nog antwoordt. Er is niets veranderd in de definitie van de share en de VPN is actief. Wat is veranderd, is het lokale adres waaraan Samba was gebonden, en dat na het opnieuw aanmaken van de interface niet meer bestaat. Die faalmodus is een probleem in de levenscyclus van de listener, geen rechtenprobleem.

De share werkt tot de tunnel opnieuw verbindt

Een dienst aan een adres binden koppelt zijn socket aan de levensduur van dat adres. Wanneer de tunnelinterface wordt vernietigd en opnieuw opgebouwd, verdwijnt het oude adres en de socket die eraan was gebonden, verdwijnt mee. De dienst blijft draaien, maar niets luistert waar de clients naartoe worden gerouteerd.

Ping kan nog slagen als het nieuwe adres op ICMP antwoordt, en daarom ziet de bereikbaarheid er goed uit terwijl de share dood is. Juist dat ene misleidende succes stuurt mensen naar de firewall.

Bereikbaarheid is geen bindadres

Hier lopen drie beslissingen door elkaar. De route bepaalt of een clientpakket aankomt. De luisterende socket bepaalt of iets het op het lokale adres aanneemt. De configuratie van de share en de bestandssysteemrechten bepalen wat daarna gebeurt. Alleen de tweede breekt wanneer de interface opnieuw wordt aangemaakt.

Een adres uit de VPN-pool is ook niet automatisch een lokaal bindadres. Het hoort bij een client, niet bij de fileserver. Ping is een slechte test voor een bestandsdienst.

Houd die eigenaren ook in de documentatie gescheiden. Een toekomstige wijziging in de VPN-pool zou geen bewerking van Samba mogen vereisen, en een wijziging van share-rechten zou geen herstart van de tunnel mogen vereisen.

Bind in plaats daarvan aan een stabiel adres

Het stabielere ontwerp houdt Samba op een permanent adres en laat de VPN clients daarheen brengen. Het serveradres verandert niet wanneer een tunnel flappert, dus de listener hoeft nooit een interface te volgen. De toelating wordt dan afgedwongen door het VPN-pad en de hostfirewall, die voor die taak zijn gebouwd.

Als u zich toch aan de tunnel moet binden, begrijp dan het contract van de geïnstalleerde release. De parameters interfaces en bind interfaces only zijn niet hetzelfde, en de documentatie over binden waarschuwt voor intermitterende interfaces. Dynamische listenerafhandeling bestaat op sommige platforms, maar dat is een vermogen om te verifiëren, niet om aan te nemen. Lees de tabel voor en na een flapper en vergelijk de twee uitvoer.

ss -ltnp | grep ':445'

Test de herverbinding, niet het groene lampje

Controleer de listener na een herverbinding, niet alleen na een dienststart. Maak de tunnel opnieuw aan, lees dan de luistertabel en bevestig dat de socket bestaat op het adres waar clients naartoe worden gerouteerd. Een groene tunnelindicator en een geslaagde configuratiecontrole bewijzen geen van beide.

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

Voer daarna één toegestane bewerking en één geweigerd pad vanaf een client uit, en herhaal dat na een tweede herverbinding. Als de share alleen tot de eerste flapper werkt, is de binding nog steeds aan de levensduur van de interface gekoppeld en is het ontwerp niet hersteld. Wijzig de binding of het dienstadres, en het symptoom komt niet meer terug.