Samba VPN-osoitteessa: miksi kuuntelija katoaa

Jakaminen toimii koko aamupäivän, tunneli yhdistää uudelleen keskipäivällä, ja sama UNC-polku aikakatkaisee nyt, vaikka ping palvelimeen yhä vastaa. Jakamisen määritelmässä ei muuttunut mikään ja VPN on päällä. Se mikä muuttui, on paikallinen osoite, johon Samba oli sidottu, eikä sitä ole enää olemassa, kun liitäntä luotiin uudelleen. Tämä vikatila on kuuntelijan elinkaaren ongelma, ei käyttöoikeusongelma.

Jakaminen toimii, kunnes tunneli käynnistyy uudelleen

Palvelun sitominen osoitteeseen kytkee sen pistokkeen osoitteen elinikään. Kun tunnelin liitäntä tuhotaan ja rakennetaan uudelleen, vanha osoite katoaa ja siihen sidottu pistoke katoaa sen mukana. Palvelu jatkaa toimintaansa, mutta mikään ei kuuntele siellä, minne asiakkaat ohjataan.

Ping voi silti onnistua, jos uusi osoite vastaa ICMP:hen, ja siksi tavoitettavuus näyttää hyvältä, vaikka jakaminen on kuollut. Juuri tuo yksi harhaanjohtava onnistuminen lähettää ihmiset palomuurin luo.

Tavoitettavuus ei ole sidontaosoite

Tässä sekoittuvat kolme päätöstä. Reitti päättää, saapuuko asiakkaan paketti. Kuunteleva pistoke päättää, ottaako jokin sen vastaan paikallisessa osoitteessa. Jakamisen kokoonpano ja tiedostojärjestelmän käyttöoikeudet päättävät, mitä sen jälkeen tapahtuu. Kun liitäntä luodaan uudelleen, vain toinen hajoaa.

Myöskään VPN-altaan osoite ei ole automaattisesti paikallinen sidontaosoite. Se kuuluu asiakkaalle, ei tiedostopalvelimelle. Ping on huono testi tiedostopalvelulle.

Pidä nämä omistajat erillään myös dokumentaatiossa. Tuleva muutos VPN-altaaseen ei saisi vaatia Samban muokkaamista, eikä jakamisen käyttöoikeuksien muutos saisi vaatia tunnelin uudelleenkäynnistystä.

Sido sen sijaan vakaaseen osoitteeseen

Vakaampi rakenne pitää Samban pysyvässä osoitteessa ja antaa VPN:n kuljettaa asiakkaat sinne. Palvelimen osoite ei muutu, kun tunneli väreilee, joten kuuntelijan ei koskaan tarvitse seurata liitäntää. Pääsyn valvovat silloin VPN-reitti ja isäntäkoneen palomuuri, jotka on rakennettu juuri siihen työhön.

Jos sinun on pakko sitoa tunneliin, ymmärrä asennetun version sopimus. Parametrit interfaces ja bind interfaces only eivät ole sama asia, ja sidonnan dokumentaatio varoittaa katkonaisista liitännöistä. Dynaaminen kuuntelijan käsittely on olemassa joillakin alustoilla, mutta se on kyky, joka on varmistettava eikä oletettava. Lue taulukko ennen väreilyä ja sen jälkeen ja vertaa kahta tulostetta.

ss -ltnp | grep ':445'

Testaa uudelleenyhdistäminen, älä vihreää valoa

Varmista kuuntelija uudelleenyhdistämisen jälkeen, älä vain palvelun käynnistyksen jälkeen. Luo tunneli uudelleen, lue sitten kuuntelutaulukko ja varmista, että pistoke on osoitteessa, jonne asiakkaat ohjataan. Vihreä tunnelin osoitin ja läpäisty kokoonpanotarkistus eivät todista kumpaakaan.

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

Aja sitten yksi sallittu toiminto ja yksi evätty polku asiakkaalta ja toista toisen uudelleenyhdistämisen jälkeen. Jos jakaminen toimii vain ensimmäiseen väreilyyn asti, sidonta on yhä kytketty liitännän elinikään eikä rakennetta ole korjattu. Muuta sidontaa tai palvelun osoitetta, niin oire lakkaa palaamasta.