VPN võttis DNS-i üle ja rikkus kohalikud nimed: parandage nimekiri

Tunnel tõuseb, intranet laeb ja printeri nimi lakkab lahendamast. Või vastupidi: kohalikud nimed töötavad endiselt, samal ajal kui kõik ettevõtte võrgus sees aegub. Mõlemad sümptomid tulevad samast kohast, resolverite nimekirjast, mille VPN-klient ühendudes ümber kirjutas.

Parandage nimekiri teadlikult ja tegelege seejärel push-mehhanismiga eraldi. Marsruudid on kolmas teema, mitte see, mida siin parandatakse.

Millist nimekirja rakendused tegelikult kasutavad

Windows lahendab liidese tasandi seadete kaudu, mitte selle kaudu, mida mõni dialoog näitab, seega alustage iga liidese kehtivatest nimekirjadest. Alias on tähtsam kui kuvatav nimi, sest iga allolev käsk pöördub liidese poole. Kui ajate aliase segi, maandub parandus vale adapteri peale. See näib töötavat kuni järgmise taasühendamiseni, mil tunnelile oma kirje naaseb.

Küsimus on, millised serverid ette jõudsid ja kas need saabusid staatiliste kirjetena või DHCP-liisinguna. Mõlemad faktid otsustavad, milline parandus on teile saadaval.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Lugege väljundit tunneliadapteri ja füüsilise adapteri kohta ning kirjutage üles iga aadress mõlemal. Staatilise kirje saab eemaldada poliitika või skriptiga; DHCP kaudu saadud kirje on liisinguga seotud ja tuleb tagasi, mis muudab paranduse valikut. Kaugvõrgu nimed lahendab kuulutatud resolver, kohaliku LAN-i nimed füüsiline adapter ning päring läheb nimekirja, mida küsitakse esimesena.

Eemaldage peale surutud serverid või asetage need madalamale

Kustutage peale surutud serverid, kui tunnelis pole millelgi neid vaja, sest füüsilise adapteri enda resolverid võtavad taas üle. Hoidke neid ainult siis, kui kaugvõrgul on tsoonid, millele ainult tema serverid vastata oskavad, ja sel juhul asetage nende ette kohalik resolver. Kaks allolevat käsku katavad mõlemad valikud, seega valige see, mis olukorraga sobib, mitte ärge käivitage mõlemat.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Indeksit 1 küsitakse esimesena, seega peale surutud aadressid jäävad kättesaadavaks, kuid lakkavad olemast iga päringu vaikevastus. Lipp validate=no jätab vahele kättesaadavuse testi, mis sageli ebaõnnestub, kui tunnel alles sätib end paika, seega kinnitage tulemus show-käsuga, mitte ärge usaldage väljumiskoodi.

Enne sellele tuginemist tasub teada kahte piiri. Windows ei kustuta servereid, mis saabusid DHCP kaudu läbi netsh, ja need väärtused püsivad DhcpNameServer-na liidese registrivõtme all, seega registri muutmine on viimane abinõu, mida tuleb pärast järgmist liisingut uuesti kontrollida. Adapterite sidumise järjekord pole samuti usaldusväärne järjestusmehhanism, sest VPN-klient võib sisestada oma kirje nimekirja tippu.

Kus saab pushi filtreerida

Parem parandus eemaldab valiku enne, kui see rakendub. Community OpenVPN klient saab peale surutud direktiivi nime järgi filtreerida, mis jätab serveri konfiguratsiooni puutumata.

pull-filter ignore "dhcp-option DNS "

Lõplik tühik kuulub vastele ja filter nimetab valikut, mitte serveri aadressi. Kui profiil sisaldab ka direktiivi block-outside-dns, muudab selle eemaldamine lekketõrjet, mitte nimede lahendamist, seega otsustage see eraldi ja ärge siduge kahte muudatust kokku.

Ühe kangekaelse hostinime jaoks on üks rida Windowsi hosts-failis stabiilsem kui resolverite ümberjärjestamine kogu masina jaoks. See on ka järgmisele inimesele nähtamatu, seega kirjutage see üles sinna, kus masina konfiguratsioon on dokumenteeritud.

Tehke parandus taasühenduse üle elama

Lahendamist tuleb testida kaks korda, üks kord valitud serveri vastu ja üks kord sellisel kujul, nagu rakendus seda kasutab. See paar eraldab resolverite järjekorra probleemi serverist, mis ei vasta üldse. Esimese testi vahelejätmine jätab kaks põhjust läbipõimunuks.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Ühendage tunnel uuesti ja korrake mõlemat käsku. Kõik, mida käsitsi muutsite, püsib ainult järgmise ühenduseni, sest klient ehitab adapterit üles tõstes oma resolveri oleku uuesti. Pange read netsh oma kliendi toetatud ühendusskripti, laske sellel skriptil edukalt lõppeda ja lisage lühike ootus enne selle käivitumist. Klient, mis rakendab DNS-i pärast skripti, kirjutab tulemuse niikuinii üle.

Kui avalikud nimed lahenevad ja sisemised pärast parandust ikka ei, ei ole resolverite nimekiri enam kahtlusalune. Päring ei jõua tõenäoliselt serverini üldse, mis viitab marsruutimisele või tulemüürireeglile, mitte järgmisele DNS-seadele. Kirjutage üles liidese alias ja aadressid, mille juurde jäite, sest mõlemad erinevad masinate vahel ja kumbki ei ela ülesehitust üksi üle.