VPN prevzal DNS a rozbil miestne názvy: opravte zoznam

Tunel sa zdvihne, intranet sa načíta a názov tlačiarne sa prestane rozkladať. Alebo naopak: miestne názvy stále fungujú, kým všetko v podnikovej sieti vyprší. Oba príznaky pochádzajú z toho istého miesta, zo zoznamu resolverov, ktorý klient VPN pri pripojení prepísal.

Opravte zoznam zámerne a potom sa samostatne venujte mechanizmu push. Trasy sú tretia téma a nie to, čo sa tu opravuje.

Ktorý zoznam aplikácie skutočne používajú

Windows rozkladá cez nastavenia na úrovni rozhrania, nie cez to, čo ukazuje nejaký dialóg, takže začnite efektívnymi zoznamami pre každé rozhranie. Alias je dôležitejší než zobrazený názov, pretože každý príkaz nižšie oslovuje rozhranie. Pomýlite si alias a oprava pristane na nesprávnom adaptéri. Bude to vyzerať, že funguje, až do ďalšieho pripojenia, keď sa vráti vlastný záznam tunela.

Otázkou je, ktoré servery sa dostali dopredu a či prišli ako statické záznamy alebo ako DHCP lease. Obe skutočnosti určujú, ktorá oprava je vám k dispozícii.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Prečítajte výstup pre adaptér tunela a pre fyzický adaptér a poznačte každú adresu na každom z nich. Statický záznam možno odstrániť politikou alebo skriptom; záznam od DHCP je viazaný na lease a vráti sa, čo mení opravu, ktorú by ste mali zvoliť. Názvy vo vzdialenej sieti rozkladá inzerovaný resolver, názvy v miestnej LAN fyzický adaptér a dopyt ide na zoznam, ktorý sa prezerá prvý.

Odstráňte pretlačené servery alebo ich zaraďte nižšie

Zmažte pretlačené servery, keď ich nič v tuneli nepotrebuje, pretože vlastné resolvery fyzického adaptéra znova preberajú. Ponechajte ich len ak vzdialená sieť vlastní zóny, na ktoré dokážu odpovedať iba jej servery, a v takom prípade postavte pred ne miestny resolver. Dva príkazy nižšie pokrývajú obe možnosti, takže vyberte ten, ktorý zodpovedá situácii, namiesto spúšťania oboch.

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

Index 1 sa prezerá prvý, takže pretlačené adresy zostávajú dostupné, ale prestávajú byť predvolenou odpoveďou na každý dopyt. Prepínač validate=no preskakuje test dostupnosti, ktorý často zlyháva, kým sa tunel ešte usadzuje, takže výsledok potvrďte príkazom show a nie dôverou v návratový kód.

Predtým, než sa na to spoľahnete, stojí za to poznať dve obmedzenia. Windows nezmaže servery, ktoré prišli cez DHCP pomocou netsh, a tieto hodnoty pretrvávajú ako DhcpNameServer pod kľúčom registra rozhrania, takže úprava registra je posledná možnosť, ktorú treba po ďalšom lease znova skontrolovať. Ani poradie viazania adaptérov nie je spoľahlivý mechanizmus radenia, pretože klient VPN môže vložiť svoj vlastný záznam na začiatok zoznamu.

Kde sa dá push filtrovať

Lepšia oprava odstráni možnosť skôr, než sa použije. Klient Community OpenVPN dokáže filtrovať pretlačenú direktívu podľa názvu, čo necháva konfiguráciu servera nedotknutú.

pull-filter ignore "dhcp-option DNS "

Záverečná medzera patrí zhode a filter pomenúva možnosť, nie adresu servera. Ak profil obsahuje aj direktívu block-outside-dns, jej odstránenie mení ochranu pred únikom a nie rozkladanie názvov, takže o tom rozhodnite samostatne namiesto spájania dvoch úprav.

Pre jedno tvrdohlavé meno hostiteľa je jeden riadok v súbore hosts Windows stabilnejší než preskupovanie resolverov pre celý stroj. Je tiež neviditeľný pre ďalšieho človeka, takže ho zaznamenajte tam, kde sa dokumentuje konfigurácia stroja.

Nechajte opravu prežiť opätovné pripojenie

Rozkladanie názvov treba otestovať dvakrát, raz proti zvolenému serveru a raz v podobe, ktorú používa aplikácia. Táto dvojica oddeľuje problém poradia resolverov od servera, ktorý vôbec neodpovedá. Preskočenie prvého testu nechá obe príčiny spletené.

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

Znova pripojte tunel a zopakujte oba príkazy. Čokoľvek ste zmenili ručne, vydrží len do ďalšieho pripojenia, pretože klient pri zdvíhaní adaptéra znova zostavuje stav resolverov. Vložte riadky netsh do podporovaného skriptu pripojenia vášho klienta, nechajte skript úspešne skončiť a pred jeho spustením pridajte krátke čakanie. Klient, ktorý aplikuje DNS po skripte, výsledok tak či tak prepíše.

Ak sa verejné názvy rozkladajú a vnútorné po oprave stále zlyhávajú, zoznam resolverov už nie je podozrivý. Dopyt sa pravdepodobne vôbec nedostane na server, čo ukazuje na smerovanie alebo pravidlo firewallu a nie na ďalšie nastavenie DNS. Poznačte si alias rozhrania a adresy, na ktorých ste sa zastavili, pretože obe sa medzi strojmi líšia a ani jedno neprežije prestavbu samo.