Правило домена VPN ломается, когда CDN меняет свои адреса

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

Почему один запрос — не инвентарь

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

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

Третий пробел — семейство адресов. Правило только для v4 ничего не говорит о записи AAAA, которую клиент может предпочесть.

Три условия, решающие правило домена или диапазоны

Во-первых, публикует ли сервис стабильный набор префиксов, которым вы можете владеть и которые можете документировать? Если да, явные диапазоны честны и дешевы. Если нет, правило домена — единственный механизм, способный следовать за сервисом.

Во-вторых, обновляется ли механизм домена вашего клиента? Правило, которое разрешается один раз при подключении и больше никогда, — это снимок с лучшим брендингом. В-третьих, покрывает ли механизм поддомены и оба семейства адресов, или только имена, которые вы ввели?

Ответьте на эти три, и выбор обычно очевиден. Догадки дают правило, которое работает в тесте и отказывает в продакшене.

Проверяйте сеанс, а не страницу

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

Перечислите, с чем сеанс действительно связывается, а не то, что показывает страница:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Держите резолвер на виду во время сравнения, потому что правило, которое работает с одного резолвера и отказывает с другого, говорит вам об ответе CDN, а не о туннеле. Короткий TTL также означает, что записанный вами ответ имеет срок годности.

Что на самом деле покрывает каждый механизм

Два механизма выглядят взаимозаменяемыми на странице настроек и ведут себя по-разному внутри.

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

Ни одно не является надмножеством другого, и поэтому их смешивание без пометки позже создаёт путаницу.

Перепроверьте после изменения сервиса

После обновления клиента или изменения сервиса запустите тот же тест сеанса снова. Список адресов, который работал раньше, — это свидетельство о том периоде, а не постоянный инвентарь инфраструктуры сервиса.

Запишите, какой механизм покрывает какое имя хоста, и дату последней проверки.

Эта пометка — разница между правилом, которое вы можете защитить, и правилом, которое никто не смеет трогать. Если сервис публикует свой список префиксов, используйте его и укажите дату. Если нет, скажите об этом и держите правило домена с его поведением обновления записанным рядом.