Samba sur VPN-adreso: kial la aŭskultanto malaperas

La kunhavo funkcias la tutan matenon, la tunelo rekonektiĝas tagmeze, kaj la sama UNC-vojo nun finiĝas per tempolimo dum ping al la servilo ankoraŭ respondas. Nenio ŝanĝiĝis en la difino de la kunhavo kaj la VPN estas aktiva. Kio ŝanĝiĝis estas la loka adreso al kiu Samba estis ligita, kaj ĝi ne plu ekzistas post kiam la interfaco estis kreita denove. Tiu fiaskmaniero estas problemo de la vivociklo de aŭskultanto, ne problemo de permesoj.

La kunhavo funkcias ĝis la tunelo restartiĝas

Ligi servon al adreso alligas ĝian soketon al la vivodaŭro de tiu adreso. Kiam la tunela interfaco estas detruita kaj rekonstruita, la malnova adreso malaperas kaj la soketo ligita al ĝi foriras kun ĝi. La servo daŭre funkcias, sed nenio aŭskultas tie, kien la klientoj estas direktataj.

Ping ankoraŭ povas sukcesi se la nova adreso respondas al ICMP, kaj tial atingeblo aspektas bone dum la kunhavo estas morta. Ĝuste tiu sola misgvida sukceso sendas homojn al la fajroŝirmilo.

Atingeblo ne estas liga adreso

Ĉi tie miksiĝas tri decidoj. La vojo decidas ĉu klienta paketo alvenas. La aŭskultanta soketo decidas ĉu io akceptas ĝin ĉe la loka adreso. La agordo de la kunhavo kaj la permesoj de la dosiersistemo decidas kio okazas poste. Nur la dua rompiĝas kiam la interfaco estas kreita denove.

Ankaŭ adreso el la VPN-pool ne aŭtomate estas loka liga adreso. Ĝi apartenas al kliento, ne al la dosier-servilo. Ping estas malbona testo por dosier-servo.

Tenu tiujn posedantojn apartaj ankaŭ en la dokumentaro. Estonta ŝanĝo en la VPN-pool ne devus postuli redakti Samban, kaj ŝanĝo de kunhavaj permesoj ne devus postuli restarigi la tunelon.

Anstataŭe ligu al stabila adreso

La pli stabila dezajno tenas Samban sur konstanta adreso kaj lasas la VPN porti klientojn al ĝi. La servila adreso ne ŝanĝiĝas kiam la tunelo flirtas, do la aŭskultanto neniam devas sekvi interfacon. Enirpermeson tiam devigas la VPN-vojo kaj la gastiga fajroŝirmilo, kiuj estas konstruitaj por tiu tasko.

Se vi nepre devas ligi al la tunelo, komprenu la kontrakton de la instalita eldono. La parametroj interfaces kaj bind interfaces only ne estas la sama afero, kaj la dokumentaro pri ligado avertas pri intermitaj interfacoj. Dinamika administrado de aŭskultanto ekzistas sur iuj platformoj, sed tio estas kapablo kontrolenda, ne supozenda. Legu la tabelon antaŭ kaj post flirtado kaj komparu la du eligojn.

ss -ltnp | grep ':445'

Testu la rekonekton, ne la verdan lumon

Kontrolu la aŭskultanton post rekonekto, ne nur post servo-startigo. Kreu la tunelon denove, poste legu la aŭskultan tabelon kaj konfirmu ke la soketo ekzistas sur la adreso kien klientoj estas direktataj. Verda tunela indikilo kaj sukcesa agorda kontrolo pruvas nek unu nek la alian.

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

Poste plenumu unu permesitan operacion kaj unu rifuzitan vojon el kliento, kaj ripetu post dua rekonekto. Se la kunhavo funkcias nur ĝis la unua flirtado, la ligo ankoraŭ estas ligita al la vivodaŭro de la interfaco kaj la dezajno ne estas riparita. Ŝanĝu la ligon aŭ la servan adreson, kaj la simptomo ĉesas reveni.