Een VPN-domeinregel breekt wanneer een CDN zijn adressen wijzigt

Je kopieert het adres uit één lookup in je routeringsregel, de site werkt, en een week later niet meer. Niets aan de regel is veranderd. De dienst is naar een ander edge-adres verhuisd, de client heeft een andere hostnaam opgelost, of de sessie is overgestapt op IPv6. De beslissing voor je is of een op naam gebaseerde regel of een expliciet bereik het juiste instrument is voor deze dienst, en drie voorwaarden beslechten dat. Wat volgt scheidt de naam van het adres, omdat alleen één van beide stabiel is.

Waarom één lookup geen inventaris is

Een contentdeliverynetwerk antwoordt met een adres dat gekozen is voor de resolver, de regio en het moment. Vraag twee keer vanuit verschillende netwerken en je kunt verschillende antwoorden krijgen. Vraag één keer en behandel het antwoord als de adressenlijst van de dienst, en de regel die je schrijft is een momentopname, geen regel. Dat is het hele probleem met een DNS-antwoord als configuratie behandelen.

Er is een tweede gat. Eén zichtbare hostnaam dekt zelden de hele applicatie, omdat inloggen, media en API-verkeer vaak aparte namen gebruiken. Een regel op basis van de hostnaam in de adresbalk kan de pagina dekken en de video missen, wat als een gedeeltelijke storing en niet als een routeringsfout wordt gelezen.

Het derde gat is de adresfamilie. Een regel alleen voor v4 zegt niets over het AAAA-record dat de client misschien verkiest.

Drie voorwaarden die domeinregel of bereiken beslissen

Ten eerste, publiceert de dienst een stabiele set prefixen die je kunt bezitten en documenteren? Zo ja, dan zijn expliciete bereiken eerlijk en goedkoop. Zo nee, dan is een domeinregel het enige mechanisme dat de dienst kan volgen.

Ten tweede, wordt het domeinmechanisme van je client vernieuwd? Een regel die één keer bij het verbinden oplost en daarna nooit meer, is een momentopname met betere branding. Ten derde, dekt het mechanisme subdomeinen en beide adresfamilies, of alleen de namen die je hebt getypt?

Beantwoord die drie en de keuze is meestal duidelijk. Gissen levert een regel op die in tests werkt en in productie faalt.

Test een sessie, geen pagina

Laad de pagina en voer daarna de handeling uit die ertoe doet: inloggen, afspelen starten, een bestand uploaden. Elk daarvan kan een andere host bereiken, en degene die faalt is degene die je regel heeft gemist.

Som op waar de sessie echt contact mee maakt in plaats van wat de pagina toont:

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

Houd de resolver zichtbaar tijdens de vergelijking, want een regel die vanaf de ene resolver werkt en vanaf een andere faalt, vertelt je iets over het antwoord van het CDN, niet over de tunnel. Een korte TTL betekent ook dat het antwoord dat je noteerde een houdbaarheidsdatum heeft.

Wat elk mechanisme werkelijk dekt

De twee mechanismen lijken op een instellingenpagina uitwisselbaar en gedragen zich eronder anders.

Een kerneladresroute matcht prefixen. Die weet niet wat een hostnaam is, dus kan geen dienst volgen die adressen wijzigt. Een domeinregel lost namen op en routeert het resultaat; die volgt de dienst, maar hangt af van de resolver, het vernieuwingsgedrag en de omgang van de client met subdomeinen, dus een regel die namen volgt moet worden getest met de resolver die de client echt gebruikt.

Geen van beide is een superset van de andere, en daarom veroorzaakt mengen zonder notitie later verwarring.

Controleer opnieuw nadat de dienst verandert

Na een clientupdate of een dienstwijziging voer je dezelfde sessietest opnieuw uit. Een adressenlijst die eerder werkte is bewijs over die periode, geen permanente inventaris van de infrastructuur van de dienst.

Schrijf op welk mechanisme welke hostnaam dekt, en de datum waarop je dat voor het laatst hebt geverifieerd.

Die notitie is het verschil tussen een regel die je kunt verdedigen en een regel die niemand durft aan te raken. Als de dienst zijn eigen prefixlijst publiceert, gebruik die en vermeld de datum. Zo niet, zeg dat, en houd de domeinregel met zijn vernieuwingsgedrag ernaast geschreven.