Samba na naslovu VPN: zakaj poslušalec izgine

Skupna raba deluje vse dopoldne, tunel se opoldne znova poveže in ista pot UNC zdaj poteče, medtem ko ping na strežnik še odgovarja. V opredelitvi skupne rabe se ni nič spremenilo in VPN deluje. Spremenil se je lokalni naslov, na katerega je bila Samba vezana, in po ponovnem ustvarjanju vmesnika ne obstaja več. Tak način odpovedi je težava življenjskega cikla poslušalca, ne težava dovoljenj.

Skupna raba deluje do ponovnega zagona tunela

Vezava storitve na naslov priveže njeno vtičnico na življenjsko dobo tega naslova. Ko se vmesnik tunela uniči in znova zgradi, stari naslov izgine in vtičnica, vezana nanj, izgine z njim. Storitev še naprej deluje, vendar nič ne posluša tam, kamor so usmerjeni odjemalci.

Ping lahko še uspe, če se novi naslov odzove na ICMP, zato je dostopnost videti v redu, medtem ko je skupna raba mrtva. Prav ta edini zavajajoči uspeh pošlje ljudi k požarnemu zidu.

Dostopnost ni naslov vezave

Tu se premešajo tri odločitve. Pot odloča, ali paket odjemalca prispe. Poslušajoča vtičnica odloča, ali kaj sprejme na lokalnem naslovu. Nastavitev skupne rabe in dovoljenja datotečnega sistema odločajo, kaj se zgodi potem. Ob ponovnem ustvarjanju vmesnika se pokvari le druga.

Tudi naslov iz nabora VPN ni samodejno lokalni naslov vezave. Pripada odjemalcu, ne datotečnemu strežniku. Ping je slab preizkus za datotečno storitev.

Te lastnike ločujte tudi v dokumentaciji. Prihodnja sprememba nabora VPN ne bi smela zahtevati urejanja Sambe, sprememba dovoljenj skupne rabe pa ne bi smela zahtevati ponovnega zagona tunela.

Namesto tega se vežite na stabilen naslov

Stabilnejša zasnova drži Sambu na stalnem naslovu in pusti VPN, da pripelje odjemalce do njega. Naslov strežnika se ob zatikanju tunela ne spremeni, zato poslušalcu nikoli ni treba slediti vmesniku. Sprejem takrat uveljavljata pot VPN in požarni zid gostitelja, ki sta zgrajena za to nalogo.

Če se morate vezati na tunel, razumite pogodbo nameščene izdaje. Parametra interfaces in bind interfaces only nista isto, dokumentacija o vezavi pa opozarja na prekinjene vmesnike. Dinamično upravljanje poslušalca obstaja na nekaterih platformah, vendar je to zmožnost, ki jo je treba preveriti, ne predpostaviti. Preberite tabelo pred zatikanjem in po njem ter primerjajte oba izpisa.

ss -ltnp | grep ':445'

Preizkusite ponovno povezavo, ne zelene lučke

Preverite poslušalca po ponovni povezavi, ne le po zagonu storitve. Znova ustvarite tunel, nato preberite tabelo poslušanja in potrdite, da vtičnica obstaja na naslovu, kamor so usmerjeni odjemalci. Zelena lučka tunela in uspešno preverjanje konfiguracije ne dokazujeta niti enega.

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

Nato izvedite eno dovoljeno operacijo in eno zavrnjeno pot z odjemalca ter ponovite po drugi ponovni povezavi. Če skupna raba deluje le do prvega zatikanja, je vezava še vedno povezana z življenjsko dobo vmesnika in zasnova ni popravljena. Spremenite vezavo ali naslov storitve in simptom se preneha vračati.