A VPN átvette a DNS-t és elrontotta a helyi neveket: javítsa a listát

A tunnell feljön, az intranet betöltődik, és a nyomtató neve feloldhatatlanná válik. Vagy fordítva: a helyi nevek továbbra is működnek, miközben minden, ami a vállalati hálózaton belül van, időtúllépésbe fut. Mindkét tünet ugyanabból ered, egy feloldólistából, amelyet a VPN-kliens csatlakozáskor újraírt.

Javítsa a listát szándékosan, majd a push-mechanizmust külön kezelje. Az útvonalak harmadik téma, és nem ez az, amit itt javítunk.

Melyik listát használják valójában az alkalmazások

A Windows interfészszintű beállításokon keresztül old fel, nem azon keresztül, amit egy párbeszédablak mutat, ezért kezdje az interfészenkénti tényleges listákkal. Az alias fontosabb, mint a megjelenített név, mert minden alábbi parancs egy interfészt szólít meg. Ha eltéveszti az aliast, a javítás a rossz adapterre kerül. Úgy tűnik majd, hogy működik, egészen a következő újracsatlakozásig, amikor a tunnell saját bejegyzése visszatér.

A kérdés az, mely szerverek kerültek előre, és hogy statikus bejegyzésként vagy DHCP-bérletként érkeztek-e. Mindkét tény eldönti, melyik javítás áll rendelkezésére.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Olvassa ki a tunnell-adapter és a fizikai adapter kimenetét, és jegyezze fel az összes címet mindkettőn. A statikus bejegyzést házirend vagy szkript távolíthatja el; a DHCP-től kapott bejegyzés a bérlethez kötött, és visszatér, ami megváltoztatja a választandó javítást. A távoli hálózat neveit a hirdetett feloldó oldja fel, a helyi LAN neveit a fizikai adapter, és a lekérdezés ahhoz a listához megy, amelyet először néznek meg.

Távolítsa el a betolt szervereket, vagy sorolja őket hátrébb

Törölje a betolt szervereket, ha a tunnellen belül semminek nincs rájuk szüksége, mert a fizikai adapter saját feloldói ismét átveszik a szerepet. Csak akkor tartsa meg őket, ha a távoli hálózatnak olyan zónái vannak, amelyekre csak a saját szerverei tudnak válaszolni, és ebben az esetben tegyen eléjük helyi feloldót. Az alábbi két parancs mindkét választást lefedi, ezért a helyzethez illőt válassza ahelyett, hogy mindkettőt futtatná.

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

Az 1-es indexet nézik meg először, így a betolt címek elérhetők maradnak, de megszűnnek minden lekérdezés alapértelmezett válasza lenni. A validate=no kapcsoló kihagy egy elérhetőségi próbát, amely gyakran meghiúsul, miközben a tunnell még beáll, ezért a show paranccsal erősítse meg az eredményt, ne a kilépési kódban bízzon.

Két korlátot érdemes tudni, mielőtt erre támaszkodik. A Windows nem törli azokat a szervereket, amelyek DHCP-n keresztül, a netsh segítségével érkeztek, és ezek az értékek DhcpNameServer néven megmaradnak az interfész bejegyzéskulcsa alatt, így a bejegyzés szerkesztése az utolsó lehetőség, amelyet a következő bérlet után újra ellenőrizni kell. Az adapterek kötési sorrendje sem megbízható rangsorolási mechanizmus, mert egy VPN-kliens beillesztheti a saját bejegyzését a lista elejére.

Hol szűrhető a push

Egy jobb javítás még az alkalmazás előtt eltávolítja a lehetőséget. A Community OpenVPN kliens név szerint szűrhet egy betolt direktívát, ami érintetlenül hagyja a szerver konfigurációját.

pull-filter ignore "dhcp-option DNS "

A záró szóköz az egyeztetéshez tartozik, és a szűrő a lehetőséget nevezi meg, nem egy kiszolgálócímet. Ha a profil block-outside-dns direktívát is tartalmaz, annak eltávolítása a szivárgásvédelmet változtatja meg, nem a névfeloldást, ezért ezt külön döntse el, ahelyett hogy a két módosítást összevonná.

Egyetlen makacs hosztnévhez egy sor a Windows hosts fájljában stabilabb, mint az egész gép feloldóinak átrendezése. Ez a következő ember számára is láthatatlan, ezért jegyezze fel ott, ahol a gép konfigurációját dokumentálják.

Tegye a javítást újracsatlakozás-állóvá

A feloldást kétszer kell tesztelni, egyszer egy kiválasztott szerverrel szemben, egyszer pedig abban a formában, ahogy egy alkalmazás használja. Ez a pár szétválasztja a feloldósorrend-problémát attól a szervertől, amely egyáltalán nem válaszol. Az első teszt kihagyása összekuszálva hagyja a két okot.

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

Csatlakozzon újra a tunnellhez, és ismételje meg mindkét parancsot. Amit kézzel módosított, csak a következő kapcsolatig tart, mert a kliens az adapter felemelése közben újraépíti a feloldóállapotát. Tegye a netsh sorokat az ügyfél támogatott csatlakozási szkriptjébe, hagyja, hogy a szkript sikeresen befejeződjön, és adjon hozzá rövid várakozást, mielőtt lefut. Az a kliens, amely a szkript után alkalmazza a DNS-t, így is felülírja az eredményt.

Ha a nyilvános nevek feloldódnak, a belsők pedig a javítás után is meghiúsulnak, a feloldólista már nem gyanús. A lekérdezés valószínűleg egyáltalán nem ér el a szerverig, ami az útvonalválasztásra vagy egy tűzfalszabályra utal, nem egy újabb DNS-beállításra. Jegyezze fel az interfész aliasát és azokat a címeket, amelyekre jutott, mert mindkettő gépenként eltér, és egyik sem éli túl egyedül az újraépítést.