Удаление устаревшей записи VPN из базы данных resolvconf

Внутреннее имя по-прежнему разрешается в сервер VPN спустя сутки после закрытия туннеля, и файл резолвера снова и снова возвращается с этой записью. Там, где состоянием владеет Debian resolvconf, этот файл собирается из записей поставщиков, и одна из них — остаток. Удаление записи занимает минуту; доказательство того, что её безопасно удалить, — настоящая работа. Эти шлюзы выполняются по порядку, и неудачный шлюз завершает процедуру, а не отправляет вас к следующему шагу.

Убедитесь, что состоянием владеет resolvconf

Сначала определите владельца, потому что тот же симптом под systemd-resolved требует других команд и другого ремонта. Пакет resolvconf держит базу данных в /run/resolvconf и направляет /etc/resolv.conf на файл, который собирает из этой базы. Два чтения решают вопрос: цель символической ссылки и то, установлен ли пакет и активен ли он. Цель в /run/systemd/resolve означает другую конструкцию, где ничего из нижнего не действует.

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

Если ссылка указывает в другое место или пакета нет, остановитесь здесь. Обёртка совместимости, занявшая имя и поставляемая другим менеджером резолвера, не владеет этой базой данных.

База данных хранит входы, а не ответ

База данных хранит входы, а файл — это выход, поэтому перечисление входов — единственный способ увидеть, какая программа установила запись, от которой вы хотите избавиться. Записи короткие, а их ключи — это ручки, которые понадобятся позже. Прочитайте их, прежде чем решать, какая устарела, потому что имя, похожее на интерфейс VPN, может принадлежать другому клиенту. Держите частные адреса и внутренние домены поиска вне общих диагностик; сам ключ обычно идентифицирует запись.

sudo resolvconf --list
sudo resolvconf -i

Первая команда печатает переданные записи без их обработки, а вторая перечисляет интерфейсы, которые сейчас предоставляют конфигурацию DNS. Ключи обычно строятся из имени интерфейса и программы-поставщика. Руководство resolvconf описывает базу данных, к которой относятся эти ключи.

Скопируйте ключ из вывода вместо того, чтобы строить его заново. Запись называется tun0 не только потому, что старый скрипт использовал это имя.

Докажите, что у записи нет владельца

Запись безопасно удалять, когда её не устанавливало ни одно живое соединение. Сопоставьте ключ с соединением, которое его создало, затем подтвердите, что это соединение исчезло. Именно это сопоставление и есть весь шлюз, и это шаг, который чаще всего пропускают на пути к команде удаления. Если доказательства неоднозначны, считайте запись живой и остановитесь.

Имена процессов — слабое доказательство. OpenConnect вызывает vpnc-script, поэтому проверка процесса vpnc ничего не говорит о том, какая запись текущая. Новое соединение может также повторно использовать имя интерфейса, оставленное старым, из-за чего ключ выглядит старше, чем есть. Сравните адрес сервера внутри записи с адресами ещё поднятых туннелей и остановитесь, если они совпадают.

Обычное отключение через менеджер-владелец — первое средство. Оно отзывает то, что установило это соединение, и не трогает других поставщиков.

Проверьте удаление и перезапись

Когда запись подтверждена как устаревшая, удалите её по точному ключу и затем прочитайте результат, а не предполагайте его. Команда меняет состояние резолвера для каждого приложения на хосте, поэтому запускайте её в окне, которое контролируете. Заключите ключ в кавычки, потому что в нём есть символы, которые оболочка иначе раскрыла бы. Заполнитель в блоке означает ключ, скопированный из списка, а не буквальную строку.

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

Удаление запускает скрипты обновления, когда обновление включено; при отключённых обновлениях оно откладывает обновление, поэтому удалённая запись и перезаписанный файл — два отдельных события. Перечитайте список и убедитесь, что ключ исчез, прежде чем смотреть на файл. Затем запросите одно имя, которое должно по-прежнему разрешаться через оставшихся поставщиков, и одно публичное имя, и сравните оба с тем, что видели до изменения. Если частное имя полностью перестаёт разрешаться, эта запись всё ещё его несла.

resolvconf -u запускает только эти скрипты обновления. Он никогда не выявляет и не удаляет устаревшую запись, а пересборка из устаревших входов воспроизводит тот же нежелательный файл.

Убитый хук отключения оставляет запись

Разовая очистка восстанавливает сегодняшнее состояние, а следующее прерванное выключение возвращает запись. Пройдите путь демонтажа: хук отключения клиента, помощник, который этот хук вызывает, и что происходит, когда любой из них убит. Прерванное выключение — обычный источник, потому что хук вообще не запускался. Запишите код выхода хука один раз, и вы узнаете, не сбоит ли он тихо.

Держите настройку и очистку под одним владельцем. Второй скрипт, угадывающий имена интерфейсов, в конце концов удалит запись другого соединения, что хуже устаревшей записи, с которой вы начали. Владелец должен решать и когда запись устарела, потому что знает, какое соединение её установило.

Затем проверьте жизненный цикл: подключитесь, отключитесь, снова перечислите записи. Самостоятельное исчезновение записи — единственное доказательство, что ремонт держится.