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

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

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

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

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

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

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

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

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