Вътрешните имена не се резолвват през VPN, а публичните сайтове работят

Един потребител съобщава, че името на хоста от вътрешната мрежа не се резолвва през VPN. Втори доклад, от същия лаптоп, казва, че тест за изтичане все още показва заявки, на които отговаря локалният резолвер. Звучат като един проблем, а са два, с различни доказателства, и обичайната поправка за първия влошава втория. Разделете ги, преди да пипате каквато и да е настройка.

Два симптома, които не са една повреда

Неуспехът да се резолвне вътрешно име означава, че въпросът е отишъл някъде, където няма отговор за него. Заявките, които излизат от тунела, означават, че въпросът е отишъл на грешното място дори когато отговорът е бил наличен. Това са противоположни повреди: едната е липсващ отговор, другата е излишна дестинация.

Капанът е, че добавянето на офисния резолвер навсякъде поправя първата и гарантира втората. Добавянето на публичен резолвер навсякъде прави обратното.

Запишете двете наблюдения с времева марка, след което минете през четирите проверки по-долу по ред.

Кой резолвер на адаптера получава въпроса

В Windows DNS клиентът избира сървъри според реда на обвързване на адаптерите, а тунелният адаптер не е автоматично пръв. Отворете разширените настройки на адаптера и преместете връзката за отдалечен достъп над физическия адаптер, след което се свържете отново, за да влезе промяната в сила в нова сесия.

Редът на обвързване е само първата половина. Клиентът трябва да знае и кои имена принадлежат на този адаптер, а това е въпрос на суфикс, не на ред.

Поставете изхода от ipconfig /all на работещата машина до този на лаптопа, и двата снет при вдигнат тунел. Работещата машина ще покаже DNS суфикс, специфичен за връзката, на офисния си адаптер, а лаптопът може да не покаже нищо на тунела. Тази разлика обяснява цял клас доклади от вида сървърът е точно там, а името пак не се резолвва, защото без суфикс краткото име никога не се допълва до зоната, която обслужва офисният резолвер.

Краткото име има нужда от суфикс преди нужда от маршрут

Въвеждането на неквалифицирано име на хост кара резолвера да отгатне домейн. Отгатването идва от списъка със суфикси, прикачен към връзката, и ако този списък е празен, заявката излиза като един етикет, с който няма да съвпадне нито една частна зона.

Копирайте суфикса от работещата машина в свойствата на IPv4 на VPN адаптера в раздела DNS, след което се свържете отново. В Linux еквивалентът е домейнът за търсене на тунелната връзка, който systemd-resolved показва за всяка връзка, а не глобално.

Дръжте двете настройки отделно в бележките си. Суфиксът променя какво се пита; адресът на резолвера променя кого се пита. Поправянето на едното, докато другото е грешно, дава резултат, който изглежда случаен.

Питайте резолвера директно, после името

Директна заявка към офисния резолвер отделя проблем с име от проблем с път, защото заобикаля изцяло избора на резолвер от клиента.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Първата команда пита конкретен сървър за напълно квалифицирано име. Ако отговори, резолверът и маршрутът до него са наред и повредата е в избора или суфикса. Ако изтече времето, адресът е грешен или недостъпен и проблемът е в маршрутизацията, не в DNS. Втората команда показва какво става с краткото име, а третата отпечатва конфигурацията на резолвера за всяка връзка на хост със systemd.

Следете за отговори-шаблони, които някои мрежи връщат за непознати имена. Правдоподобният отговор не е доказателство, че е отговорил желаният сървър, затова сравнете върнатия адрес с този, който вътрешната услуга наистина използва. Ако адресът принадлежи на паркираща страница или прокси, резолверът е отговорил, но отговорът никога не е бил ваш. Това разграничение спестява час гонене на тунел, който е работил през цялото време.

В Linux VPN клиент, който презаписва /etc/resolv.conf, заменя локалните резолвери изцяло. vpnc предлага DNSUpdate no, за да спре това, а systemd-resolved може да насочва към тунелната връзка само изброените домейни. И двата подхода оставят публичните имена на локалния резолвер и изпращат вътрешните имена в офиса.

Изтичанията са правило, не отметка

Резолвването на имена е UDP обмен към порт 53, така че тунел, който носи уеб трафик, но не UDP, оставя заявката на физическия път. Докажете го, като снимате трафик на физическата мрежова карта, докато се резолвва публично име. Заявка, видима на този интерфейс в четима форма, означава, че тунелът не я носи.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Ако заявката се появи на този интерфейс в четима форма, тунелът не я носи. Поправката е правило, което разрешава порт 53 само към резолвера, изпратен от VPN, и изхвърля другите дестинации, плюс конфигурация на клиента, която не изхвърля тихо изпратената опция.

Тази последна част е по-важна, отколкото изглежда. Стартирайте OpenVPN с route-nopull и изпратената DNS опция изчезва заедно с маршрутите, освен ако филтърът за изтегляне не бъде разширен, за да я запази. А клиент, който игнорира dhcp-option DNS, ще продължи да използва каквото е имал преди. Всяка промяна от страна на сървъра изисква нова сесия, защото списъкът с резолвери се доставя при вдигане на тунела, а стара сесия продължава да показва старото състояние.

Запишете коя повреда наистина сте наблюдавали, преди да затворите заявката. Липсващ вътрешен отговор и заявка, избягала от тунела, изискват различни поправки, а промяна на суфикса, която оправя първата, може тихо да влоши втората. Който поеме заявката след вас, ще се довери на етикета, затова направете етикета точен.