Kohalik Samba jagamine kadus pärast seda, kui OpenVPN lükkas DNS-i

Samba kaotab kohalikud jagamised hetkel, mil OpenVPN ühendus luuakse, ja tunnel pole peaaegu kunagi põhjus. Ühenduspunkt on korras, NAS töötab ja tunneli paigaldatud resolver vastab küsimustele nime kohta, mida ta pole kunagi näinud. Samba küsib seda resolverit oma otsingujärjekorra alguses, usub vastust ja ühendub aadressiga, kus miski ei kuula. Jagamise parandamine tähendab vastuse parandamist, mitte ühenduspunkti.

Viis kontrolli selles järjekorras, mis välistab iga sammuga kõige rohkem võimalusi.

Kes vastab lühikese nime eest

Küsige operatsioonisüsteemilt, mitte failihaldurilt. resolvectl status kuvab igale lingile kinnitatud DNS-serverid ja märgib, milline link on vaikimisi marsruut, ning lühikese nime päring teatab serveri, mis vastas. Käivitage see üks kord NAS-i nime jaoks ja üks kord nime jaoks, mis teate, et see on kontori domeenis olemas. Kui kaks vastust tulevad erinevatelt serveritelt, olete lõhe leidnud.

Kontrollige, kas vastuseks oli eitav vastus või aadress. Eitav vastus tähendab, et Samba oleks pidanud liikuma edasi teise mehhanismi juurde, ja rike on mujal. Aadress tähendab, et Samba ühendus tõelise kohaga ja ei saanud midagi tagasi.

Miks Samba usub vale vastust

Samba lahendab nimesid fikseeritud järjestuse kaudu, mille määrab name resolve order. Enamikus distributsioonides sisaldab vaikeväärtus host, mis tähendab DNS-i, ja see töötab enne ainult kohtvõrgule mõeldud mehhanisme nagu NetBIOS-i ringhääling. Seega saab resolverit lükkav tunnel iga jagamise nime puhul esimese keeldumise õiguse, sealhulgas ühe sildiga nimede puhul, mis ei pidanud kunagi hoonest lahkuma.

Tavaliselt tagastab tundmatu nimi eitava vastuse ja järgmine mehhanism saab järje. Mõned resolverid, eriti tarbija-ISP-de ja avalikud, vastavad tundmatutele nimedele hoopis otsingulehe või reklaamaadressiga. See vastus näib resolveri teegile õnnestumisena, nii et Samba lõpetab otsimise ja valib aadressi, millel pole teie võrguga mingit seost.

Tulemuseks on jagamine, mis kaob ilma veadialoogita. Miski selles järjestuses pole VPN-i marsruutimise rike, seepärast toimib NAS-i pingimine endiselt, samas kui sellele sirvimine ei toimi.

Kaks erineva ulatusega parandust

Kitsas parandus säilitab läbisurutud resolveri ja muudab seda, mida Samba tohib sellelt küsida. Lisage kaks rida Samba konfiguratsiooni, mida deemon tegelikult loeb, ja taaskäivitage teenus:

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

Ilma host-ta selles loendis on DNS jagamise otsingute teelt väljas ja ühe sildiga nimed jäävad kohalikku segmenti. Kontori nimed lahenevad endiselt tavaliselt iga teise programmi jaoks, sest see muudab ainult Sambat. Hind on see, et Samba ei saa enam üldse DNS-i kasutada, nii et täielikult kvalifitseeritud kontori nimega adresseeritud jagamine muutub probleemiks.

Lai parandus kõrvaldab põhjuse: lõpetage resolveri lükkamine, mis vastab nimedele, mida ta ei oma, või lükake jaotatud DNS-i poliitika, nii et kontori resolverini jõuavad ainult kontori sufiksid. See on hallatavas võrgus parem pikaajaline vastus, sest kaitseb ka brauserit ja paketihaldurit, kuid nõuab administratiivset juurdepääsu serveri poolel ja klienti, kes järgib läbisurutud seadeid.

Valige üks teadlikult. Resolveri muudatus muudab nimelahendust kõigi rakenduste jaoks korraga, mis on muudatuse kirje, mitte tugikõne jaoks tehtud redigeerimine.

Sufiks võib kõike selgitada

Kui klient lükkab ka otsingusufiksi, kirjutatakse lühike kohalik nimi enne päringut kontori domeeni ümber. Siis ei valeta resolver üldse: temalt küsiti ausat küsimust kontori nime kohta ja ta andis õige vastuse. Lugege küsitud nimi resolveri väljundist, et seda reklaamaadressi juhtumist eristada, sest failihalduris näevad mõlemad rikked ühesugused välja.

Parandus on siin kas kasutada täielikult kvalifitseeritud kohalikku nime või lisada jaotatud DNS-i reegel, mis omab kohalikku sufiksit. Kumbki ei nõua Samba puudutamist.

Tõestage seda pärast uuesti ühendamist

Testige ühes seansis kolme nime: kohalikku jagamist lühikese nimega, kontori hosti nimega ja tavalist veebisaiti. Kui esimene töötab ja teine katkeb, on parandus vea kohale liigutanud, mitte selle kõrvaldanud. Kui kolmas katkeb, läks resolveri muudatus kavatsetust kaugemale ja iga otsing on nüüd kahtlane.

Seejärel lahutage tunnel ja ühendage uuesti ning korrake kõiki kolme. Läbisurutud valikud rakendatakse igal ühendamisel uuesti, nii et ainult tööajal eksisteerinud parandus võib kaduda, ilma et konfiguratsioonifail muutuks. Registreerige resolver, mis omab iga sufiksit, ja kehtiv otsingujärjekord, ning märkige kuupäev, sest järgmine kliendi uuendus on ilmne kahtlusalune, kui see naaseb.

Kui jagamine ebaõnnestub pärast kõiki viit kontrolli endiselt, fikseerige täpne päring ja täpne vastus enne muu muutmist. See ridade paar eristab resolveri riket nimest, mida tõesti ei eksisteeri, ja see on kiireim üleandmismärkus, mille saate kirjutada.