En VPN-domeneregel brytes når et CDN bytter adresser

Du kopierer adressen fra ett oppslag inn i ruteringsregelen din, nettstedet virker, og en uke senere gjør det ikke. Ingenting ved regelen er endret. Tjenesten flyttet til en annen kantadresse, klienten slo opp et annet vertsnavn, eller økten byttet til IPv6. Beslutningen foran deg er om en navnebasert regel eller et eksplisitt intervall er det riktige verktøyet for denne tjenesten, og tre betingelser avgjør det. Det følgende skiller navnet fra adressen, fordi bare én av dem er stabil.

Hvorfor ett oppslag ikke er en fortegnelse

Et innholdsleveringsnettverk svarer med en adresse som er valgt for resolveren, regionen og øyeblikket. Spør to ganger fra ulike nettverk, og du kan få ulike svar. Spør én gang og behandle svaret som tjenestens adresseliste, og regelen du skriver er et øyeblikksbilde, ikke en regel. Det er hele problemet med å behandle et DNS-svar som konfigurasjon.

Det finnes et andre hull. Ett synlig vertsnavn dekker sjelden hele applikasjonen, fordi innlogging, medier og API-trafikk ofte bruker separate navn. En regel bygget fra vertsnavnet i adressefeltet kan dekke siden og bomme på videoen, noe som leses som en delvis feil og ikke som en ruteringsfeil.

Det tredje hullet er adressefamilien. En regel bare for v4 sier ingenting om AAAA-posten klienten kanskje foretrekker.

Tre betingelser som avgjør domeneregel eller intervaller

For det første, publiserer tjenesten et stabilt sett med prefikser du kan eie og dokumentere? Hvis ja, er eksplisitte intervaller ærlige og billige. Hvis ikke, er en domeneregel den eneste mekanismen som kan følge tjenesten.

For det andre, oppdateres klientens domenemekanisme? En regel som løses én gang ved tilkobling og aldri igjen, er et øyeblikksbilde med bedre merkevare. For det tredje, dekker mekanismen underdomener og begge adressefamiliene, eller bare navnene du skrev inn?

Svar på de tre, og valget er vanligvis åpenbart. Gjetting gir en regel som virker i test og svikter i produksjon.

Test en økt, ikke en side

Last siden, og utfør deretter operasjonen som betyr noe: logg inn, start avspilling, last opp en fil. Hver av dem kan nå en annen vert, og den som svikter er den regelen din bommet på.

List opp hva økten faktisk kontakter, i stedet for hva siden viser:

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

Hold resolveren synlig under sammenligningen, fordi en regel som virker fra én resolver og svikter fra en annen, forteller deg om CDNs svar, ikke om tunnelen. En kort TTL betyr også at svaret du noterte har holdbarhetstid.

Hva hver mekanisme faktisk dekker

De to mekanismene ser utbyttbare ut på en innstillingsside og oppfører seg ulikt under overflaten.

En kjerneadresserute matcher prefikser. Den aner ikke hva et vertsnavn er, så den kan ikke følge en tjeneste som bytter adresser. En domeneregel løser navn og ruter resultatet; den følger tjenesten, men avhenger av resolveren, oppdateringsatferden og klientens håndtering av underdomener, så en regel som følger navn, må testes med resolveren klienten faktisk bruker.

Ingen av dem er en overmengde av den andre, og derfor skaper blanding uten et notat forvirring senere.

Sjekk på nytt etter at tjenesten endres

Etter en klientoppdatering eller tjenesteendring, kjør den samme økttesten igjen. En adresseliste som tidligere virket, er bevis om den perioden, ikke en permanent fortegnelse over tjenestens infrastruktur.

Skriv ned hvilken mekanisme som dekker hvilket vertsnavn, og datoen du sist verifiserte det.

Det notatet er forskjellen mellom en regel du kan forsvare og en regel ingen tør å røre. Hvis tjenesten publiserer sin egen prefiksliste, bruk den og oppgi datoen. Hvis ikke, si det, og hold domeneregelen med sin oppdateringsatferd skrevet ved siden av.