Вашиот VPN домен во dnsmasq не е пренос на зона

Ја барате корпоративната зона во конфигурацијата на dnsmasq на клиентот, не ја наоѓате и заклучувате дека VPN не го пратил својот домен. Она што е пратено е навестување за рутирање, а не зона. Клиентот го запишува доменот и резолверот што треба да одговара за него, а управуваниот бекенд тоа го претвора во условно препраќање. Барањето на погрешно место дава уверена и целосно лажна дијагноза.

Она што клиентот го прифатил не е она што го понудил gateway-от

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

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

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

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

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

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

Кога се користи локален кеширачки резолвер, системската датотека покажува на loopback адресата и ништо друго. Тој запис го означува локалниот слушател, а не горните сервери што му ги предал менаџерот. Корпоративната адреса законски ќе недостасува во датотеката.

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

Не мешајте ги бекендовите

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

Утврдете кој бекенд менаџерот е конфигуриран да го користи, потоа читајте ја генерираната конфигурација на тој бекенд наместо дистрибуциска датотека што случајно постои. Менаџерот пишува сопствена конфигурација на примерокот и поддржува прилагодени опции за тој примерок, па уредувањето на неповрзана глобална датотека не менува ништо и изгледа како промена без ефект. Стартувањето втор демон на портата 53 е полошо од бескорисно, бидејќи сега две програми не се согласуваат чија е портата. Прво утврдете го сопственикот, потоа уредувајте таму каде што тој сопственик чита.

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

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

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