Samba VPN adresu: kodėl klausytojas išnyksta

Bendrinys veikia visą rytą, tunelis po pietų vėl prisijungia, o tas pats UNC kelias dabar baigiasi laiku, nors ping į serverį dar atsako. Bendrinio apraše niekas nepasikeitė ir VPN veikia. Pasikeitė vietinis adresas, prie kurio Samba buvo pririštas, ir po sąsajos sukūrimo iš naujo jo nebėra. Toks gedimo būdas yra klausytojo gyvavimo ciklo problema, o ne teisių problema.

Bendrinys veikia iki tunelio paleidimo iš naujo

Paslaugos priskyrimas adresui pririša jos lizdą prie to adreso gyvavimo trukmės. Kai tunelio sąsaja sunaikinama ir sukuriama iš naujo, senasis adresas išnyksta, o prie jo pririštas lizdas išnyksta kartu. Paslauga toliau veikia, bet niekas nesiklauso ten, kur nukreipiami klientai.

Ping vis tiek gali pavykti, jei naujasis adresas atsako į ICMP, todėl pasiekiamumas atrodo gerai, nors bendrinys nebeveikia. Būtent ši viena klaidinanti sėkmė nukreipia žmones prie užkardos.

Pasiekiamumas nėra priskyrimo adresas

Čia sumaišomi trys sprendimai. Maršrutas nusprendžia, ar kliento paketas atvyks. Klausantis lizdas nusprendžia, ar kas nors jį priims vietiniu adresu. Bendrinio konfigūracija ir failų sistemos teisės nusprendžia, kas vyks toliau. Kai sąsaja sukuriama iš naujo, sugenda tik antrasis.

VPN telkinio adresas taip pat nėra automatiškai vietinis priskyrimo adresas. Jis priklauso klientui, o ne failų serveriui. Ping yra prastas failų paslaugos testas.

Laikykite tuos šeimininkus atskirai ir dokumentacijoje. Būsimas VPN telkinio pakeitimas neturėtų reikalauti redaguoti Samba, o bendrinio teisių pakeitimas neturėtų reikalauti paleisti tunelio iš naujo.

Pririškite prie stabilaus adreso

Stabilesnis sprendimas laiko Samba nuolatiniame adrese ir leidžia VPN atvesti klientus ten. Serverio adresas nesikeičia, kai tunelis svyruoja, todėl klausytojui niekada nereikia sekti sąsajos. Tuomet priėmimą užtikrina VPN kelias ir prieglobos užkarda, kurie tam darbui ir sukurti.

Jei vis dėlto turite pririšti prie tunelio, supraskite įdiegtos versijos sutartį. Parametrai interfaces ir bind interfaces only nėra tas pats, o pririšimo dokumentacija įspėja apie nutrūkstančias sąsajas. Dinaminis klausytojo apdorojimas egzistuoja kai kuriose platformose, bet tai galimybė, kurią reikia patikrinti, o ne numanyti. Perskaitykite lentelę prieš ir po svyravimo ir palyginkite abu išvedimus.

ss -ltnp | grep ':445'

Tikrinkite prisijungimą iš naujo, o ne žalią lemputę

Patikrinkite klausytoją po prisijungimo iš naujo, o ne tik po paslaugos paleidimo. Sukurkite tunelį iš naujo, tada perskaitykite klausymosi lentelę ir patvirtinkite, kad lizdas yra adrese, į kurį nukreipiami klientai. Žalias tunelio indikatorius ir sėkminga konfigūracijos patikra neįrodo nė vieno.

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

Tada atlikite vieną leistiną operaciją ir vieną draudžiamą kelią iš kliento ir pakartokite po antro prisijungimo iš naujo. Jei bendrinys veikia tik iki pirmo svyravimo, priskyrimas vis dar susietas su sąsajos gyvavimo trukme ir sprendimas nepataisytas. Pakeiskite priskyrimą arba paslaugos adresą, ir simptomas nebesugrįš.