Samba VPN-aadressil: miks kuulaja kaob

Jagamine töötab kogu hommiku, tunnel ühendub lõunal uuesti ja sama UNC-teek lõpeb nüüd aegumisega, samal ajal kui ping serverile vastab endiselt. Jagamise definitsioonis pole midagi muutunud ja VPN on üleval. Muutus kohalik aadress, millega Samba oli seotud, ja pärast liidese uuesti loomist ei ole seda enam olemas. See rikkerežiim on kuulaja elutsükli probleem, mitte õiguste probleem.

Jagamine töötab kuni tunnel taaskäivitub

Teenuse sidumine aadressiga seob selle sokli selle aadressi elueaga. Kui tunneli liides hävitatakse ja ehitatakse uuesti, kaob vana aadress ja sellega seotud sokkel kaob koos sellega. Teenus töötab edasi, aga mitte miski ei kuula seal, kuhu kliente suunatakse.

Ping võib siiski õnnestuda, kui uus aadress vastab ICMP-le, ja seetõttu näeb kättesaadavus hea välja, samal ajal kui jagamine on surnud. Just see üks eksitav õnnestumine saadab inimesed tulemüüri juurde.

Kättesaadavus ei ole sidumisaadress

Siin segunevad kolm otsust. Marsruut otsustab, kas kliendi pakett kohale jõuab. Kuulav sokkel otsustab, kas miski võtab selle kohalikus aadressis vastu. Jagamise konfiguratsioon ja failisüsteemi õigused otsustavad, mis juhtub pärast seda. Liidese uuesti loomisel katkeb ainult teine.

Ka VPN-i basseini aadress ei ole automaatselt kohalik sidumisaadress. See kuulub kliendile, mitte failiserverile. Ping on failiteenuse jaoks halb test.

Hoidke need omanikud eraldi ka dokumentatsioonis. Tulevane muudatus VPN-i basseinis ei tohiks nõuda Samba muutmist ja jagamise õiguste muudatus ei tohiks nõuda tunneli taaskäivitamist.

Siduge selle asemel stabiilse aadressiga

Stabiilsem lahendus hoiab Samba alalisel aadressil ja laseb VPN-il kliendid sinna viia. Serveri aadress ei muutu, kui tunnel väreleb, seega ei pea kuulaja kunagi liidest järgima. Sissepääsu tagavad siis VPN-i teek ja hosti tulemüür, mis on selle töö jaoks ehitatud.

Kui peate tingimata tunneliga siduma, mõistke paigaldatud versiooni lepingut. Parameetrid interfaces ja bind interfaces only ei ole sama asi ning sidumise dokumentatsioon hoiatab katkendlike liideste eest. Dünaamiline kuulaja haldus on mõnel platvormil olemas, kuid see on võime, mida tuleb kontrollida, mitte eeldada. Lugege tabelit enne ja pärast värelemist ning võrrelge kahte väljundit.

ss -ltnp | grep ':445'

Testige taasühendust, mitte rohelist tuld

Kontrollige kuulajat pärast taasühendust, mitte ainult teenuse käivitamise järel. Looge tunnel uuesti, seejärel lugege kuulamise tabelit ja kinnitage, et sokkel on olemas aadressil, kuhu kliente suunatakse. Roheline tunninäidik ja läbitud konfiguratsioonikontroll ei tõesta kumbagi.

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

Seejärel sooritage kliendist üks lubatud toiming ja üks keelatud tee ning korrake pärast teist taasühendust. Kui jagamine töötab ainult kuni esimese värelemiseni, on sidumine endiselt liidese elueaga seotud ja lahendust ei ole parandatud. Muutke sidumist või teenuse aadressi ja sümptom lakkab tagasi tulemast.