Список разрешённых конечных точек VPN: обновление DNS, которое вы забыли

Ввод vpn.example.com в исключение брандмауэра ощущается как подписка на DNS. Обычно происходит преобразование при загрузке, после чего правило хранит адреса и ничто их не обновляет. Теперь две части делят работу: резолвер, который отвечает, и брандмауэр, который хранит. Большинство сбоев конечных точек начинается там, где эта передача никогда не проектировалась.

Имя хоста в правиле — не активная подписка

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

Правило, называющее правильный хост, всё равно может пропускать неверный адрес. Этот разрыв — миф, а не опечатка.

TTL кэша — не таймер вашего брандмауэра

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

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

dig +short vpn.example.com
resolvectl query vpn.example.com

Проектируйте обновление и сбой как единую политику

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

Выберите поведение при сбое осознанно. Сохранение старого адреса может сохранить сессию и оставить устаревшее разрешение; очистка набора может помешать восстановлению. Ни то, ни другое не должно быть случайным результатом неудачного разрешения имени. Запишите выбранное поведение в runbook, чтобы следующий оператор не импровизировал под давлением.

Держите узким и bootstrap DNS. Безусловное исключение для публичного резолвера — это прямой путь DNS для всего, что под него подходит, а не только для имени конечной точки.

Докажите изменение конечной точки, а не первое подключение

Используйте поддерживаемый менеджер клиента, если он уже координирует разрешение и блокировку. На PF-хосте, которым управляет сайт, сохраняйте принадлежность и план восстановления сайта, а не копируйте синтаксис таблицы имён хостов с другой платформы с иным поведением жизненного цикла.

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