Paikallinen Samba-jako katosi, kun OpenVPN työnsi DNS:n

Samba menettää paikalliset jaot heti, kun OpenVPN yhdistetään, eikä tunneli ole juuri koskaan syy. Liitos on kunnossa, NAS on käynnissä, ja tunnelin asentama resolver vastaa kysymyksiin nimestä, jota se ei ole koskaan nähnyt. Samba kysyy tältä resolverilta varhain hakujärjestyksessään, uskoo vastauksen ja yhdistää osoitteeseen, jossa mikään ei kuuntele. Jaon korjaaminen tarkoittaa vastauksen korjaamista, ei liitoksen.

Viisi tarkistusta siinä järjestyksessä, joka sulkee pois eniten mahdollisuuksia per vaihe.

Kuka vastaa lyhyestä nimestä

Kysy käyttöjärjestelmältä, älä tiedostonhallinnalta. resolvectl status tulostaa jokaiseen linkkiin liitetyt DNS-palvelimet ja merkitsee, mikä linkki on oletusreitti, ja lyhyen nimen kysely ilmoittaa palvelimen, joka vastasi. Aja se kerran NAS-nimelle ja kerran nimelle, jonka tiedät olevan olemassa toimiston verkkotunnuksessa. Jos kaksi vastausta tulevat eri palvelimilta, olet löytänyt jakautuman.

Tarkista, oliko vastaus kielteinen vastaus vai osoite. Kielteinen vastaus tarkoittaa, että Samban olisi pitänyt siirtyä toiseen mekanismiin, ja vika on muualla. Osoite tarkoittaa, että Samba yhdisti todelliseen paikkaan eikä saanut mitään takaisin.

Miksi Samba uskoo väärää vastausta

Samba ratkaisee nimiä kiinteällä järjestyksellä, jonka name resolve order asettaa. Useimmissa jakeluissa oletus sisältää host, eli DNS:n, ja se ajetaan ennen vain lähiverkolle tarkoitettuja mekanismeja kuten NetBIOS-lähetystä. Siksi tunneli, joka työntää resolverin, saa ensimmäisen kieltäytymisoikeuden jokaiseen jakonimeen, mukaan lukien yksiosaiset nimet, joiden ei koskaan pitänyt lähteä rakennuksesta.

Yleensä tuntematon nimi palauttaa kielteisen vastauksen ja seuraava mekanismi saa vuoron. Jotkin resolverit, etenkin kuluttaja-ISP:iden ja julkiset, vastaavat tuntemattomiin nimiin hakusivulla tai mainososoitteella. Tämä vastaus näyttää resolverin kirjastolle onnistumiselta, joten Samba lopettaa etsimisen ja valitsee osoitteen, jolla ei ole mitään tekemistä verkkosi kanssa.

Tuloksena on jako, joka katoaa ilman virheikkunaa. Mikään tuossa järjestyksessä ei ole VPN-reitityksen vika, siksi NASin pingaaminen toimii edelleen, mutta siihen selaaminen ei toimi.

Kaksi eri laajuista korjausta

Kapea korjaus säilyttää työnnetyn resolverin ja muuttaa sitä, mitä Samba saa siltä kysyä. Lisää kaksi riviä Samban asetukseen, jonka daemon todella lukee, ja käynnistä palvelu uudelleen:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

Ilman host-kohtaa tuossa luettelossa DNS on poissa jakohakujen polulta, ja yksiosaiset nimet pysyvät paikallisessa segmentissä. Toimiston nimet ratkeavat edelleen normaalisti kaikille muille ohjelmille, koska tämä muuttaa vain Sambaa. Hinta on, että Samba ei voi enää käyttää DNS:ää lainkaan, joten täysin kelvollisella toimiston nimellä osoitettu jako muuttuu ongelmaksi.

Laaja korjaus poistaa syyn: lopeta sellaisen resolverin työntäminen, joka vastaa nimille, joita se ei omista, tai työnnä jaetun DNS:n käytäntö, jotta vain toimiston suffiksit saavuttavat toimiston resolverin. Se on parempi pitkän aikavälin vastaus hallitussa verkossa, koska se suojaa myös selainta ja paketinhallintaa, mutta se vaatii hallinnollisen pääsyn palvelinpuolelle ja asiakkaan, joka noudattaa työnnettyjä asetuksia.

Valitse yksi tarkoituksella. Resolverin muutos muuttaa nimien ratkaisua kaikille sovelluksille kerralla, mikä on muutostietue, ei tukipuhelua varten tehty muokkaus.

Suffiksi voi selittää kaiken

Jos asiakas työntää myös hakusuffiksin, lyhyt paikallinen nimi kirjoitetaan toimiston verkkotunnukseksi ennen kyselyä. Silloin resolver ei valehtele lainkaan: siltä kysyttiin reilu kysymys toimiston nimestä ja se antoi oikean vastauksen. Lue kysytty nimi resolverin tulosteesta erottaaksesi tämän mainososoitetapauksesta, koska molemmat viat näyttävät samoilta tiedostonhallinnassa.

Korjaus on tässä joko käyttää täysin kelvollista paikallista nimeä tai lisätä jaetun DNS:n sääntö, joka omistaa paikallisen suffiksin. Kumpikaan ei vaadi Sambaan koskemista.

Todista se uudelleenyhdistämisen jälkeen

Testaa kolmea nimeä yhdessä istunnossa: paikallinen jako lyhyellä nimellä, toimiston isäntä nimellä ja tavallinen verkkosivusto. Jos ensimmäinen toimii ja toinen hajoaa, korjaus siirsi vian sen sijaan että olisi poistanut sen. Jos kolmas hajoaa, resolverin muutos meni pidemmälle kuin oli tarkoitettu ja jokainen haku on nyt epäilyttävä.

Irrota sitten tunneli ja yhdistä uudelleen ja toista kaikki kolme. Työnnetyt asetukset otetaan uudelleen käyttöön jokaisessa yhteydessä, joten vain ajonaikana ollut korjaus voi kadota ilman, että asetustiedosto muuttuu. Kirjaa resolver, joka omistaa kunkin suffiksin, ja voimassa oleva hakujärjestys, ja merkitse päivämäärä, koska seuraava asiakaspäivitys on ilmeinen epäilty, kun tämä palaa.

Jos jako epäonnistuu edelleen kaikkien viiden tarkistuksen jälkeen, tallenna tarkka kysely ja tarkka vastaus ennen kuin muutat mitään muuta. Tämä rivipari erottaa resolverin vian nimestä, jota todella ei ole olemassa, ja se on nopein kirjoittamasi luovutusmuistio.