Правіла дамена 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 таксама азначае, што запісаны вамі адказ мае тэрмін прыдатнасці.

Што насамрэч пакрывае кожны механізм

Два механізмы выглядаюць узаемазаменнымі на старонцы налад і паводзяць сябе па-рознаму ўнутры.

Маршрут адраса ў ядры супастаўляе прэфіксы. Ён не ведае, што такое імя хоста, таму не можа ісці за сэрвісам, які змяняе адрасы. Правіла дамена вызначае імёны і маршрутызуе вынік; яно ідзе за сэрвісам, але залежыць ад рэзалвера, паводзін абнаўлення і апрацоўкі субдаменаў кліентам, таму правіла, якое ідзе за імёнамі, трэба тэставаць з тым рэзалверам, які кліент фактычна выкарыстоўвае.

Ні адно не з’яўляецца надмноствам іншага, таму змешванне іх без нататкі пазней стварае блытаніну.

Пераправерце пасля змены сэрвісу

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

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

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