Ein VPN-domeneregel bryt saman når eit CDN byter adresser

Du kopierer adressa frå eitt oppslag inn i ruteringsregelen din, nettstaden verkar, og ei veke seinare gjer han det ikkje. Ingenting ved regelen er endra. Tenesta flytta til ei anna kantadresse, klienten slo opp eit anna vertsnamn, eller økta bytte til IPv6. Avgjerda framfor deg er om ein navnebasert regel eller eit eksplisitt intervall er det rette verktøyet for denne tenesta, og tre vilkår avgjer det. Det følgjande skil namnet frå adressa, fordi berre éin av dei er stabil.

Kvifor eitt oppslag ikkje er ein fortegnelse

Eit innhaldsleveringsnettverk svarar med ei adresse som er vald for resolvaren, regionen og augeblinken. Spør to gonger frå ulike nettverk, og du kan få ulike svar. Spør éin gong og handsam svaret som adresselista til tenesta, og regelen du skriv er eit augeblinksbilete, ikkje ein regel. Det er heile problemet med å handsame eit DNS-svar som konfigurasjon.

Det finst eit andre hol. Eitt synleg vertsnamn dekkjer sjeldan heile applikasjonen, fordi innlogging, medium og API-trafikk ofte brukar separate namn. Ein regel bygd frå vertsnamnet i adressefeltet kan dekkje sida og bomme på videoen, noko som blir lese som ein delvis feil og ikkje som ein ruteringsfeil.

Det tredje holet er adressefamilien. Ein regel berre for v4 seier ingenting om AAAA-posten klienten kanskje føretrekkjer.

Tre vilkår som avgjer domeneregel eller intervall

For det første, publiserer tenesta eit stabilt sett med prefiks du kan eige og dokumentere? Viss ja, er eksplisitte intervall ærlege og billege. Viss nei, er ein domeneregel den einaste mekanismen som kan følgje tenesta.

For det andre, blir domenemekanismen til klienten din oppdatert? Ein regel som blir løyst éin gong ved tilkopling og aldri igjen, er eit augeblinksbilete med betre merkevare. For det tredje, dekkjer mekanismen underdomene og begge adressefamiliane, eller berre namna du skreiv inn?

Svar på dei tre, og valet er vanlegvis openbert. Gjetting gir ein regel som verkar i test og sviktar i produksjon.

Test ei økt, ikkje ei side

Last sida, og utfør deretter operasjonen som betyr noko: logg inn, start avspeling, last opp ei fil. Kvar av dei kan nå ein annan vert, og den som sviktar er den regelen din bomma på.

List opp kva økta faktisk kontaktar, i staden for kva sida viser:

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

Hald resolvaren synleg under samanlikninga, fordi ein regel som verkar frå éin resolvar og sviktar frå ein annan, fortel deg om svaret til CDN, ikkje om tunnelen. Ein kort TTL tyder òg at svaret du noterte har haldbarheitstid.

Kva kvar mekanisme faktisk dekkjer

Dei to mekanismane ser utbytbart ut på ei innstillingsside og oppfører seg ulikt under overflata.

Ei kjerneadresserute matchar prefiks. Ho anar ikkje kva eit vertsnamn er, så ho kan ikkje følgje ei teneste som byter adresser. Ein domeneregel løyser namn og ruter resultatet; han følgjer tenesta, men er avhengig av resolvaren, oppdateringsåtferda og handsaminga til klienten av underdomene, så ein regel som følgjer namn, må testast med resolvaren klienten faktisk brukar.

Ingen av dei er ei overmengd av den andre, og difor skapar blanding utan eit notat forvirring seinare.

Sjekk på nytt etter at tenesta endrar seg

Etter ein klientoppdatering eller tenesteendring, køyr den same økttesten igjen. Ei adresseliste som tidlegare verka, er prov om den perioden, ikkje ein permanent fortegnelse over infrastrukturen til tenesta.

Skriv ned kva mekanisme som dekkjer kva vertsnamn, og datoen du sist stadfesta det.

Det notatet er skilnaden mellom ein regel du kan forsvare og ein regel ingen tør å røre. Viss tenesta publiserer si eiga prefiksliste, bruk ho og oppgi datoen. Viss ikkje, seie det, og hald domeneregelen med oppdateringsåtferda si skriven ved sida av.