Вашият VPN домейн в dnsmasq не е прехвърляне на зона

Търсите корпоративната зона в конфигурацията на dnsmasq на клиента, не я намирате и заключавате, че VPN не е изпратил своя домейн. Това, което е изпратено, е подсказка за маршрутизиране, а не зона. Клиентът записва домейна и резолвера, който трябва да отговаря за него, а управляваният бекенд превръща това в условно препращане. Търсенето на грешното място дава уверена и напълно погрешна диагноза.

Това, което клиентът е приел, не е това, което шлюзът е предложил

Шлюзът може да предложи резолвер, домейн и маршрута, необходими за достигане до този резолвер, а клиентът може да приеме и трите, или нито едно от тях. Импортиран профил, помощен скрипт или политика, която игнорира изпратените опции, могат да оставят приетия набор празен, докато сървърната страна изглежда правилна. Започнете от записаното състояние на клиента, а не от конфигурацията на сървъра, защото това състояние е това, което резолверът действително получава. Ако приетият домейн липсва, нищо по-нататък няма да има значение. Проверете свойствата на DNS на връзката, преди да прегледате който и да е кеш.

Това разграничение обяснява повечето съобщения за домейн, който така и не пристигна. Беше предложен и не беше приложен.

Два вида записи за домейн

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

За частно пространство от имена формата само за маршрутизиране обикновено е тази, която искате. Тя държи корпоративния суфикс насочен към корпоративния резолвер и оставя всичко останало на мира.

localhost в resolv.conf не е грешка

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

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

Не бъркайте бекендовете

Управляван екземпляр на dnsmasq и системен резолвер са различни програми с различна конфигурация и различни изгледи на състоянието. Команда за състояние за единия не казва нищо полезно за другия.

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

Тествайте пространството от имена, не само отговора

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

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