DNS серверот на VPN постојано завршува под оној на LAN, а уредувањето на /etc/resolv.conf го поправа тоа за неколку минути. Таа датотека се генерира, па поправката никогаш не останува. Во resolvconf на Debian влезот за редоследот е /etc/resolvconf/interface-order и тој ги сортира имињата на записите, а не DNS адресите. Потврдете кој стек на resolver е навистина задолжен пред да допрете која било од двете датотеки.

Потврдете дека resolvconf го поседува излезот

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

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

Ако решената патека не води во работниот директориум на resolvconf, застанете тука: ова упатство припаѓа на друг стек.

Дури по таа проверка вреди да се набројат записите што resolvconf моментално ги држи.

Прочитајте ги записите пред да пишувате шеми

interface-order се совпаѓа со имињата на записите на добавувачот, не со адреси и не со имиња на интерфејси на јадрото. Набројте што е регистрирано за вашите шеми да се однесуваат на постоечки записи.

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

Името на записот обично носи наставка што го идентификува неговиот добавувач, па записот за тунел и записот за DHCP може да делат префикс на интерфејс и сепак да се сортираат поинаку. Копирајте ги точните имиња од списокот на директориумот. Не изведувајте име од името на интерфејсот, зашто интеграцијата на клиентот одлучува што ќе се регистрира. Измисленото име никогаш нема да се совпадне, а записот ќе падне во шемата што фаќа сè, без никаква порака за грешка.

Напишете го редоследот како шеми за прво совпаѓање

Датотеката е список на shell glob шеми, една по ред. Записот ја зазема позицијата на првата шема со која се совпаѓа, па широка шема над конкретна ја прави конкретната линија недостапна.

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

Ставете ја конкретната шема за тунелот над шемата што фаќа сè и над шемата на физичкиот интерфејс.

Задржете ги другите линии што датотеката веќе ги имаше. Замената на целата политика со пример е начинот на кој неповрзани добавувачи тивко се преместуваат; сменете една линија, генерирајте повторно и споредете. Шемите не можат да содржат празни места, коси црти или почетна точка или тилда, а празните линии и коментарите со хеш се игнорираат.

Генерирајте повторно и проверете го резултатот

Редоследот се применува кога скриптите за ажурирање ја преградуваат датотеката. Стартувајте ја поддржаната патека за ажурирање наместо да го уредувате генерираниот излез, потоа прочитајте што resolver-от навистина примил.

resolvconf -u
cat /etc/resolv.conf

Проверете две барања, не едно: приватно име што треба да се реши преку тунелот и јавно контролно име. Ако приватното име сè уште не успева додека редоследот изгледа точен, проблемот е во рутирањето на именскиот простор, а не во приоритетот на записите, и никакво прередување нема да го поправи. Споредете го секој одговор со серверот што го вратил, не само со успехот. Приватно име одговорено од погрешен resolver е сè уште неуспех, а за корисникот изгледа како прекин на DNS.

Повлечете го застарениот запис од употреба наместо да го намалувате

Застарен VPN запис што продолжува да се појавува по исклучувањето е грешка во животниот циклус на интеграцијата со клиентот. Преместувањето на дното го крие симптомот и остава мртов resolver на списокот.

Повлечете го преку компонентата што го регистрира, потоа потврдете дека директориумот на записи повеќе не го наведува.

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

Поврзани статии