Pravidlo domény VPN přestane platit, když CDN změní své adresy

Zkopírujete adresu z jednoho dotazu do svého pravidla směrování, web funguje a o týden později už ne. Na pravidle se nic nezměnilo. Služba se přesunula na jinou okrajovou adresu, klient přeložil jiné jméno hostitele nebo relace přešla na IPv6. Rozhodnutí před vámi je, zda je pravidlo podle názvu, nebo explicitní rozsah správný nástroj pro tuto službu, a tři podmínky to rozhodnou. Následující text odděluje název od adresy, protože stabilní je jen jeden z nich.

Proč jeden dotaz není inventář

Síť pro doručování obsahu odpovídá adresou zvolenou pro resolver, oblast a okamžik. Zeptejte se dvakrát z různých sítí a můžete dostat různé odpovědi. Zeptejte se jednou a berte odpověď jako seznam adres služby, a pravidlo, které napíšete, je snímek, ne pravidlo. To je celý problém s tím, když se s odpovědí DNS zachází jako s konfigurací.

Existuje druhá mezera. Jedno viditelné jméno hostitele málokdy pokryje celou aplikaci, protože přihlášení, média a provoz API často používají samostatná jména. Pravidlo postavené na jménu hostitele z adresního řádku může pokrýt stránku a minout video, což se čte jako částečné selhání, ne jako chyba směrování.

Třetí mezerou je rodina adres. Pravidlo jen pro v4 neříká nic o záznamu AAAA, kterému může klient dát přednost.

Tři podmínky, které rozhodnou pravidlo domény, nebo rozsahy

Za prvé, zveřejňuje služba stabilní sadu prefixů, kterou můžete vlastnit a dokumentovat? Pokud ano, explicitní rozsahy jsou poctivé a levné. Pokud ne, pravidlo domény je jediný mechanismus, který může službu sledovat.

Za druhé, obnovuje se mechanismus domény vašeho klienta? Pravidlo, které se přeloží jednou při připojení a už nikdy, je snímek s lepším brandingem. Za třetí, pokrývá mechanismus subdomény a obě rodiny adres, nebo jen názvy, které jste napsali?

Odpovězte na ty tři a volba je obvykle jasná. Hádání vytvoří pravidlo, které funguje při testu a selže v provozu.

Testujte relaci, ne stránku

Načtěte stránku a pak proveďte operaci, na které záleží: přihlaste se, spusťte přehrávání, nahrajte soubor. Každá z nich může dosáhnout jiného hostitele a ta, která selže, je ta, kterou vaše pravidlo minulo.

Vypište, s čím relace skutečně komunikuje, ne co zobrazuje stránka:

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

Udržujte resolver po celou dobu srovnání na očích, protože pravidlo, které funguje z jednoho resolveru a selže z jiného, vám říká o odpovědi CDN, ne o tunelu. Krátké TTL také znamená, že zaznamenaná odpověď má dobu použitelnosti.

Co každý mechanismus skutečně pokrývá

Oba mechanismy vypadají na stránce nastavení zaměnitelně a uvnitř se chovají jinak.

Jádrová trasa adresy porovnává prefixy. Nemá ponětí, co je jméno hostitele, takže nemůže sledovat službu, která mění adresy. Pravidlo domény překládá názvy a směruje výsledek; sleduje službu, ale závisí na resolveru, chování obnovy a na tom, jak klient zvládá subdomény, takže pravidlo, které sleduje názvy, se musí testovat s resolverem, který klient skutečně používá.

Ani jedno není nadmnožinou druhého, a proto jejich míchání bez poznámky později vytváří zmatek.

Po změně služby zkontrolujte znovu

Po aktualizaci klienta nebo změně služby spusťte stejný test relace znovu. Seznam adres, který dříve fungoval, je dokladem o onom období, ne trvalým inventářem infrastruktury služby.

Zapište, který mechanismus pokrývá které jméno hostitele, a datum posledního ověření.

Tato poznámka je rozdíl mezi pravidlem, které umíte obhájit, a pravidlem, na které si nikdo netroufne sáhnout. Pokud služba zveřejňuje vlastní seznam prefixů, použijte ho a uveďte datum. Pokud ne, řekněte to a držte pravidlo domény s jeho chováním obnovy zapsaným vedle.