Ваша VPN домена у dnsmasq-у није пренос зоне

Тражите корпоративну зону у dnsmasq конфигурацији клијента, не налазите је и закључујете да VPN није послао своју домену. Оно што је послато је смерница за рутирање, а не зона. Клијент бележи домену и resolver који на њу треба да одговори, а управљани backend то претвара у условљено прослеђивање. Тражење на погрешном месту даје сигурну и потпуно лажну дијагнозу.

Оно што је клијент прихватио није оно што је gateway понудио

Gateway може понудити resolver, домену и руту потребну да се до тог resolver-а стигне, а клијент може прихватити сва три или ниједно од њих. Увезени профил, помоћна скрипта или правило које игнорише послате опције могу оставити прихваћени скуп празним док страна сервера изгледа исправно. Почните од забележеног стања клијента, а не од конфигурације сервера, јер то стање је оно што resolver заиста прима. Ако прихваћена домена недостаје, ништа даље низ ланац неће бити важно. Проверите DNS својства везе пре него што прегледате било који cache.

Та разлика објашњава већину извештаја о домени која никада није стигла. Била је понуђена и није примењена.

Две врсте уноса домене

Веза може носити обичне домене за претрагу и домене само за рутирање, а друга врста почиње тилдом. Домена за претрагу и усмерава упите и дозвољава ширење кратких имена, што је згодно на радној станици и изненађујуће на серверу. Домена само за рутирање каже да упити за тај суфикс треба да иду на одређене сервере без промене начина на који се кратка имена решавају. Писање исте домене на оба начина није сувишно, јер два уноса обављају различите послове.

За приватни простор имена облик само за рутирање је обично онај који желите. Он држи корпоративни суфикс усмерен на корпоративни resolver и оставља све остало на миру.

localhost у resolv.conf није грешка

Када се користи локални кеширајући resolver, системска датотека показује на loopback адресу и ништа друго. Тај унос означава локалног слушаоца, а не узводне сервере које му је управљач предао. Корпоративна адреса ће оправдано недостајати у датотеци.

Замена тог уноса јавним resolver-ом класична је погрешна поправка. Она враћа јавно разрешавање имена и одбацује условљено правило у истој измени.

Не мешајте backend-ове

Управљана dnsmasq инстанца и системски resolver различити су програми са различитом конфигурацијом и различитим приказима статуса. Статусна наредба за један не говори ништа корисно о другом.

Утврдите који је backend управљач конфигурисан да користи, па прочитајте генерисану конфигурацију тог backend-а уместо дистрибуцијске датотеке која случајно постоји. Управљач пише сопствену конфигурацију инстанце и подржава прилагођене опције за ту инстанцу, па уређивање неповезане глобалне датотеке не мења ништа и изгледа као промена без учинка. Покретање другог daemon-а на порту 53 горе је од бескорисног, јер се сада два програма не слажу око тога коме припада порт. Прво утврдите власника, а затим уређујте тамо где тај власник чита.

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

Упитајте једно дозвољено приватно име и једно јавно контролно име кроз уобичајени пут апликације. Директан упит према корпоративном серверу доказује да запис постоји; не доказује да је клијент изабрао тај сервер. Други упит је онај који тестира правило.

Затим поновите након поновног повезивања и након прекида везе. Повезивање треба да прати животни циклус везе, а приватна имена треба да престану да се решавају када тунел нестане, уместо да се враћају на јавни resolver који одговара за исти суфикс. Ако се ипак враћају, пронашли сте цурење, што је друга грешка од поквареног претраживања. Запишите који је backend радио, које су домене примењене и шта је сваки упит вратио.