Список дозволених кінцевих точок 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-хості, яким керує сайт, зберігайте власність і план відновлення сайту, а не копіюйте синтаксис таблиці імен хостів з іншої платформи з іншою поведінкою життєвого циклу.

Зі схваленим безпечним тестом порівняйте адресу, яку вибирає клієнт, з активним дозволеним набором до і після контрольованої зміни. Охопіть невдале розв'язання імені, видалення запису, який більше не є дійсним, і, де це підтримується, іншу родину адрес. Передбачений тунель має відновитися, а не пов'язаний прямий трафік — залишатися в межах політики. Успішне перше підключення доводить лише те, що початкове перетворення випадково було правильним.