Pravidlo domény VPN prestane platiť, keď CDN zmení svoje adresy

Skopírujete adresu z jedného dotazu do svojho pravidla smerovania, web funguje a o týždeň už nie. Na pravidle sa nič nezmenilo. Služba sa presunula na inú okrajovú adresu, klient preložil iné meno hostiteľa alebo relácia prešla na IPv6. Rozhodnutie pred vami je, či je pravidlo podľa názvu, alebo explicitný rozsah správny nástroj pre túto službu, a tri podmienky to rozhodnú. Nasledujúce oddeľuje názov od adresy, pretože stabilný je len jeden z nich.

Prečo jeden dotaz nie je inventár

Sieť na doručovanie obsahu odpovedá adresou zvolenou pre resolver, oblasť a okamih. Spýtajte sa dvakrát z rôznych sietí a môžete dostať rôzne odpovede. Spýtajte sa raz a berte odpoveď ako zoznam adries služby, a pravidlo, ktoré napíšete, je snímka, nie pravidlo. To je celý problém s tým, keď sa s odpoveďou DNS zaobchádza ako s konfiguráciou.

Existuje druhá medzera. Jedno viditeľné meno hostiteľa málokedy pokryje celú aplikáciu, pretože prihlásenie, médiá a prevádzka API často používajú samostatné mená. Pravidlo postavené na mene hostiteľa z adresného riadka môže pokryť stránku a minúť video, čo sa číta ako čiastočné zlyhanie, nie ako chyba smerovania.

Treťou medzerou je rodina adries. Pravidlo len pre v4 nehovorí nič o zázname AAAA, ktorému môže klient dať prednosť.

Tri podmienky, ktoré rozhodnú pravidlo domény alebo rozsahy

Po prvé, zverejňuje služba stabilnú sadu prefixov, ktorú môžete vlastniť a dokumentovať? Ak áno, explicitné rozsahy sú poctivé a lacné. Ak nie, pravidlo domény je jediný mechanizmus, ktorý môže službu sledovať.

Po druhé, obnovuje sa mechanizmus domény vášho klienta? Pravidlo, ktoré sa preloží raz pri pripojení a už nikdy, je snímka s lepším brandingom. Po tretie, pokrýva mechanizmus subdomény a obe rodiny adries, alebo len názvy, ktoré ste zadali?

Odpovedzte na tie tri a voľba je zvyčajne jasná. Hádanie vytvorí pravidlo, ktoré funguje pri teste a zlyhá v prevádzke.

Testujte reláciu, nie stránku

Načítajte stránku a potom vykonajte operáciu, na ktorej záleží: prihláste sa, spustite prehrávanie, nahrajte súbor. Každá z nich môže dosiahnuť iného hostiteľa a tá, ktorá zlyhá, je tá, ktorú vaše pravidlo minulo.

Vypíšte, s čím relácia skutočne komunikuje, nie čo zobrazuje stránka:

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

Udržujte resolver počas porovnania na očiach, pretože pravidlo, ktoré funguje z jedného resolvera a zlyhá z iného, vám hovorí o odpovedi CDN, nie o tuneli. Krátke TTL tiež znamená, že zaznamenaná odpoveď má dobu použiteľnosti.

Čo každý mechanizmus skutočne pokrýva

Oba mechanizmy vyzerajú na stránke nastavení zameniteľne a vnútri sa správajú inak.

Jadrová trasa adresy porovnáva prefixy. Nemá poňatia, čo je meno hostiteľa, takže nemôže sledovať službu, ktorá mení adresy. Pravidlo domény prekladá názvy a smeruje výsledok; sleduje službu, ale závisí od resolvera, správania obnovy a od toho, ako klient zvláda subdomény, takže pravidlo, ktoré sleduje názvy, sa musí testovať s resolverom, ktorý klient skutočne používa.

Ani jedno nie je nadmnožinou druhého, a preto ich miešanie bez poznámky neskôr vytvára zmätok.

Po zmene služby skontrolujte znova

Po aktualizácii klienta alebo zmene služby spustite ten istý test relácie znova. Zoznam adries, ktorý predtým fungoval, je dôkazom o tom období, nie trvalým inventárom infraštruktúry služby.

Zapíšte, ktorý mechanizmus pokrýva ktoré meno hostiteľa, a dátum posledného overenia.

Táto poznámka je rozdiel medzi pravidlom, ktoré dokážete obhájiť, a pravidlom, na ktoré si nikto netrúfne siahnuť. Ak služba zverejňuje vlastný zoznam prefixov, použite ho a uveďte dátum. Ak nie, povedzte to a držte pravidlo domény s jeho správaním obnovy zapísaným vedľa.