Правило за домейн на 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 също означава, че записаният отговор има срок на годност.

Какво всъщност покрива всеки механизъм

Двата механизма изглеждат взаимозаменяеми на страница с настройки и се държат различно под повърхността.

Маршрутът на адрес в ядрото съпоставя префикси. Той няма представа какво е име на хост, затова не може да следва услуга, която сменя адреси. Правилото за домейн резолвва имена и маршрутизира резултата; то следва услугата, но зависи от резолвъра, поведението при обновяване и обработката на поддомейни от клиента, затова правило, което следва имена, трябва да се тества с резолвъра, който клиентът реално използва.

Нито едно не е надмножество на другото, затова смесването им без бележка по-късно създава объркване.

Проверете отново след промяна на услугата

След актуализация на клиента или промяна на услугата изпълнете същия тест на сесията отново. Списък с адреси, който преди е работел, е доказателство за онзи период, а не постоянен инвентар на инфраструктурата на услугата.

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

Тази бележка е разликата между правило, което можете да защитите, и правило, което никой не смее да пипне. Ако услугата публикува собствен списък с префикси, използвайте го и посочете датата. Ако не, кажете го и дръжте правилото за домейн с поведението му при обновяване, записано до него.