Samba sa isang address ng VPN: bakit nawawala ang tagapakinig

Gumagana ang share buong umaga, muling kumokonekta ang tunnel sa tanghali, at ang parehong landas ng UNC ay nag-time out na ngayon habang sumasagot pa ang ping sa server. Walang nagbago sa depinisyon ng share at naka-on ang VPN. Ang nagbago ay ang lokal na address na nakatali sa Samba, at wala na ito pagkatapos muling gawin ang interface. Ang ganoong paraan ng pagpalya ay problema sa lifecycle ng tagapakinig, hindi problema sa pahintulot.

Gumagana ang share hanggang sa mag-restart ang tunnel

Ang pagtali ng serbisyo sa isang address ay nagtatali ng socket nito sa buhay ng address na iyon. Kapag winasak at muling itinayo ang interface ng tunnel, nawawala ang lumang address at kasama nitong nawawala ang socket na nakatali rito. Patuloy na tumatakbo ang serbisyo, ngunit walang nakikinig sa lugar kung saan dinadala ang mga kliyente.

Maaari pa ring magtagumpay ang ping kung sumasagot ang bagong address sa ICMP, at iyon ang dahilan kung bakit mukhang maayos ang pag-abot habang patay ang share. Ang nag-iisang nakalilinlang na tagumpay na iyon ang nagpapadala ng mga tao sa firewall.

Ang pag-abot ay hindi address ng pagtali

Tatlong desisyon ang naghahalo dito. Itinatakda ng ruta kung darating ang packet ng kliyente. Itinatakda ng socket na nakikinig kung may tumatanggap nito sa lokal na address. Itinatakda ng configuration ng share at mga pahintulot ng filesystem kung ano ang susunod na mangyayari. Kapag muling ginawa ang interface, ang pangalawa lang ang nasisira.

Ang address mula sa pool ng VPN ay hindi rin awtomatikong lokal na address ng pagtali. Pag-aari ito ng kliyente, hindi ng file server. Mahinang pagsubok ang ping para sa serbisyo ng file.

Panatilihing hiwalay ang mga may-ari na iyon sa dokumentasyon. Ang susunod na pagbabago sa pool ng VPN ay hindi dapat mangailangan ng pag-edit ng Samba, at ang pagbabago sa pahintulot ng share ay hindi dapat mangailangan ng restart ng tunnel.

Sa halip, itali sa isang matatag na address

Pinapanatili ng mas matatag na disenyo ang Samba sa isang permanenteng address at hinahayaang dalhin ng VPN ang mga kliyente doon. Hindi nagbabago ang address ng server kapag kumakalog ang tunnel, kaya hindi kailangang sumunod ng tagapakinig sa isang interface. Ang pagtanggap ay ipinapatupad noon ng landas ng VPN at ng firewall ng host, na ginawa para sa gawaing iyon.

Kung kailangan mong itali sa tunnel, unawain ang kontrata ng naka-install na release. Ang mga parameter na interfaces at bind interfaces only ay hindi pareho, at nagbabala ang dokumentasyon ng pagtali tungkol sa pana-panahong interfaces. May dynamic na paghawak ng tagapakinig sa ilang platform, ngunit kakayahang dapat i-verify iyon, hindi ipagpalagay. Basahin ang talahanayan bago at pagkatapos ng pagkalog at ihambing ang dalawang output.

ss -ltnp | grep ':445'

Subukan ang muling pagkonekta, hindi ang berdeng ilaw

I-verify ang tagapakinig pagkatapos ng muling pagkonekta, hindi lamang pagkatapos ng pagsisimula ng serbisyo. Muling gawin ang tunnel, pagkatapos ay basahin ang talahanayan ng pakikinig at kumpirmahing umiiral ang socket sa address kung saan dinadala ang mga kliyente. Hindi pinapatunayan ng berdeng tagapagpahiwatig ng tunnel at ng pumasa na pagsusuri ng configuration ang alinman sa dalawa.

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

Pagkatapos ay magpatakbo ng isang pinapayagang operasyon at isang tinanggihang landas mula sa kliyente, at ulitin pagkatapos ng ikalawang muling pagkonekta. Kung gumagana lamang ang share hanggang sa unang pagkalog, nakatali pa rin ang pagtali sa buhay ng interface at hindi pa naayos ang disenyo. Baguhin ang pagtali o ang address ng serbisyo, at hindi na babalik ang sintomas.