VPN го презеде DNS и ги скрши локалните имиња: поправете ја листата

Тунелот се крева, интранетот се вчитува, а името на печатачот престанува да се решава. Или обратно: локалните имиња уште работат, додека сето во корпоративната мрежа истекува. Двата симптома доаѓаат од исто место, листа на резолвери што VPN клиентот ја препишал кога се поврзал.

Поправете ја листата намерно, потоа зафатете се со push механизмот одделно. Рутите се трета тема и не се тоа што се поправа овде.

Која листа апликациите навистина ја користат

Windows решава преку поставки на ниво на интерфејс, а не преку тоа што го покажува некој дијалог, затоа почнете со ефективните листи по интерфејс. Алијасот е поважен од прикажаното име, бидејќи секоја команда подолу се обраќа на интерфејс. Ако го згрешите алијасот, поправката ќе слета на погрешен адаптер. Ќе изгледа дека работи до следното повторно поврзување, кога ќе се врати сопствениот запис на тунелот.

Прашањето е кои сервери завршија напред и дали дојдоа како статични записи или како DHCP закуп. Двата факти одлучуваат која поправка ви е достапна.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Прочитајте го излезот за адаптерот на тунелот и за физичкиот, и запишете ја секоја адреса на секој од нив. Статичен запис може да се отстрани со политика или скрипта; запис даден од DHCP е врзан за закупот и ќе се врати, што ја менува поправката што треба да ја изберете. Имињата во далечната мрежа ги решава објавениот резолвер, имињата на локалниот LAN физичкиот адаптер, а барањето оди до листата што се разгледува прва.

Отстранете ги турканите сервери или поставете ги пониско

Избришете ги турканите сервери кога ништо во тунелот не ги потребува, бидејќи сопствените резолвери на физичкиот адаптер повторно преземаат. Задржете ги само ако далечната мрежа има зони на кои можат да одговорат само нејзините сервери, и во тој случај ставете локален резолвер пред нив. Двете команди подолу ги покриваат двете избори, затоа изберете ја што одговара на состојбата наместо да ги извршите двете.

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

Индексот 1 се разгледува прв, така што турканите адреси остануваат достапни но престануваат да бидат стандардниот одговор на секое барање. Знамето validate=no прескокнува тест за достапност што често паѓа додека тунелот уште се стабилизира, затоа потврдете го резултатот со командата show наместо да му верувате на излезниот код.

Вреди да се знаат две граници пред да се потпрете на ова. Windows нема да ги избрише серверите што дојдоа преку DHCP преку netsh, и тие вредности остануваат како DhcpNameServer под клучот за регистрација на интерфејсот, затоа уредувањето на регистрацијата е последно средство што мора повторно да се провери по следниот закуп. И редот на врзување на адаптерите не е сигурен механизам за рангирање, бидејќи VPN клиентот може да го вметне својот запис на врвот од листата.

Каде може да се филтрира push

Подобра поправка ја отстранува опцијата пред да се примени. Клиентот Community OpenVPN може да филтрира туркана директива по име, што ја остава конфигурацијата на серверот недопрена.

pull-filter ignore "dhcp-option DNS "

Завршното празно место припаѓа на совпаѓањето и филтерот ја именува опцијата, а не адреса на сервер. Ако профилот содржи и директива block-outside-dns, нејзиното отстранување ја менува заштитата од истекување, а не решавањето на имиња, затоа одлучете за тоа одделно наместо да ги споите двете измени.

За едно тврдоглаво име на домаќин, една линија во датотеката hosts на Windows е постабилна од прередување на резолвери за целата машина. Таа е и невидлива за следниот човек, затоа запишете ја таму каде што се документира конфигурацијата на машината.

Направете поправката да го преживее повторното поврзување

Решавањето на имиња мора да се тестира двапати, еднаш против избран сервер и еднаш во формата што ја користи апликација. Овој пар го одвојува проблемот со редот на резолвери од сервер што воопшто не одговара. Ако се прескокне првиот тест, двете причини остануваат заплеткани.

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

Поврзете го тунелот повторно и повторете ги двете команди. Она што сте го смениле рачно важи само до следното поврзување, бидејќи клиентот ја обновува состојбата на резолверите додека го крева адаптерот. Ставете ги линиите netsh во поддржаната скрипта за поврзување на вашиот клиент, оставете ја скриптата успешно да заврши и додајте кратко чекање пред да се изврши. Клиент што применува DNS по скриптата сепак ќе го препише резултатот.

Ако јавните имиња се решаваат, а внатрешните по поправката уште не успеваат, листата на резолвери повеќе не е сомнителна. Барањето веројатно воопшто не стигнува до серверот, што укажува на рутирање или правило на огнен ѕид, а не на друга DNS поставка. Запишете го алијасот на интерфејсот и адресите на кои застанавте, бидејќи двете се разликуваат меѓу машини и ниту едно не преживува преуредување само.