VPN pravilo za domenu puca kada CDN promijeni svoje adrese

Prekopirate adresu iz jednog upita u svoje pravilo rutiranja, stranica radi, a sedmicu kasnije više ne. Ništa se u pravilu nije promijenilo. Usluga se preselila na drugu edge adresu, klijent je razriješio drugo ime hosta ili je sesija prešla na IPv6. Odluka pred vama je da li je pravilo zasnovano na imenu ili eksplicitni raspon pravi alat za ovu uslugu, i tri uslova to rješavaju. Ono što slijedi razdvaja ime od adrese, jer je samo jedno od njih stabilno.

Zašto jedan upit nije inventar

Mreža za dostavu sadržaja odgovara adresom odabranom za resolver, regiju i trenutak. Pitajte dvaput iz različitih mreža i možete dobiti različite odgovore. Pitajte jednom i tretirajte odgovor kao listu adresa usluge, i pravilo koje napišete je snimak, a ne pravilo. To je cijeli problem s tretiranjem DNS odgovora kao konfiguracije.

Postoji druga praznina. Jedno vidljivo ime hosta rijetko pokriva cijelu aplikaciju, jer prijava, mediji i API saobraćaj često koriste odvojena imena. Pravilo napravljeno od imena hosta u adresnoj traci može pokriti stranicu i promašiti video, što se čita kao djelimični neuspjeh, a ne kao greška rutiranja.

Treća praznina je porodica adresa. Pravilo samo za v4 ne govori ništa o AAAA zapisu koji klijent može preferirati.

Tri uslova koja odlučuju pravilo domene ili raspone

Prvo, objavljuje li usluga stabilan skup prefiksa koje možete posjedovati i dokumentovati? Ako da, eksplicitni rasponi su iskreni i jeftini. Ako ne, pravilo domene je jedini mehanizam koji može slijediti uslugu.

Drugo, osvježava li se mehanizam domene vašeg klijenta? Pravilo koje se razriješi jednom pri povezivanju i nikad više je snimak s boljim brendingom. Treće, pokriva li mehanizam poddomene i obje porodice adresa, ili samo imena koja ste otkucali?

Odgovorite na ta tri i izbor je obično očigledan. Nagađanje daje pravilo koje radi u testu i pada u produkciji.

Testirajte sesiju, ne stranicu

Učitajte stranicu, pa izvedite radnju koja je važna: prijavite se, pokrenite reprodukciju, otpremite datoteku. Svaka od njih može doći do drugog hosta, a ona koja padne je ona koju je vaše pravilo promašilo.

Popišite s čime sesija zaista kontaktira, a ne šta stranica prikazuje:

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

Držite resolver vidljivim tokom poređenja, jer pravilo koje radi s jednog resolvera i pada s drugog govori vam o odgovoru CDN-a, ne o tunelu. Kratak TTL takođe znači da odgovor koji ste zabilježili ima rok trajanja.

Šta svaki mehanizam zaista pokriva

Dva mehanizma izgledaju zamjenjivo na stranici postavki, a iznutra se ponašaju različito.

Kernel ruta adrese poklapa prefikse. Ona nema pojma šta je ime hosta, pa ne može slijediti uslugu koja mijenja adrese. Pravilo domene razrješava imena i rutira rezultat; ono slijedi uslugu, ali zavisi od resolvera, ponašanja osvježavanja i klijentovog rukovanja poddomenima, pa se pravilo koje slijedi imena mora testirati s resolverom koji klijent zaista koristi.

Nijedno nije nadskup drugog, zbog čega njihovo miješanje bez zabilješke kasnije stvara zbrku.

Provjerite ponovo nakon promjene usluge

Nakon ažuriranja klijenta ili promjene usluge, ponovo izvedite isti test sesije. Lista adresa koja je ranije radila dokaz je o tom periodu, ne trajni inventar infrastrukture usluge.

Zapišite koji mehanizam pokriva koje ime hosta i datum posljednje provjere.

Ta zabilješka je razlika između pravila koje možete braniti i pravila koje se niko ne usuđuje dirati. Ako usluga objavljuje vlastitu listu prefiksa, koristite je i navedite datum. Ako ne, recite to i držite pravilo domene s njegovim ponašanjem osvježavanja zapisanim pored njega.