Правило 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 такође значи да одговор који сте забележили има рок важности.

Шта сваки механизам заиста покрива

Два механизма изгледају заменљиво на страници подешавања, а изнутра се понашају другачије.

Рута адресе у језгру подудара префиксе. Она нема појма шта је име домаћина, па не може да прати услугу која мења адресе. Правило домена решава имена и усмерава резултат; оно прати услугу, али зависи од резолвера, понашања при освежавању и руковању поддоменима од стране клијента, па правило које прати имена мора да се тестира са резолвером који клијент заиста користи.

Ниједно није надскуп другог, зато њихово мешање без белешке касније ствара забуну.

Проверите поново након промене услуге

Након ажурирања клијента или промене услуге, поново изведите исти тест сесије. Листа адреса која је раније радила доказ је о том периоду, не трајни инвентар инфраструктуре услуге.

Запишите који механизам покрива које име домаћина и датум последње провере.

Та белешка је разлика између правила које можете да браните и правила које нико не усуђује да дотакне. Ако услуга објављује сопствену листу префикса, користите је и наведите датум. Ако не, кажите то и држите правило домена са његовим понашањем при освежавању записаним поред.