VPN pravilo za domenu puca kad CDN promijeni svoje adrese

Kopirate adresu iz jednog upita u svoje pravilo usmjeravanja, stranica radi, a tjedan kasnije više ne. Ništa se u pravilu nije promijenilo. Usluga se preselila na drugu rubnu adresu, klijent je razriješio drugo ime hosta ili je sesija prešla na IPv6. Odluka je pred vama: je li pravilo prema imenu ili eksplicitni raspon pravi alat za ovu uslugu, i tri uvjeta 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 razrješivač, regiju i trenutak. Pitajte dvaput iz različitih mreža i možete dobiti različite odgovore. Pitajte jednom i tretirajte odgovor kao popis adresa usluge, i pravilo koje napišete je snimka, 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 promet često koriste odvojena imena. Pravilo izgrađeno od imena hosta u adresnoj traci može pokriti stranicu i promašiti video, što se čita kao djelomičan neuspjeh, a ne kao pogreška usmjeravanja.

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

Tri uvjeta koja odlučuju pravilo domene ili raspone

Prvo, objavljuje li usluga stabilan skup prefiksa koje možete posjedovati i dokumentirati? Ako da, eksplicitni rasponi su iskreni i jeftini. Ako ne, pravilo domene jedini je 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 snimka s boljim brendiranjem. Treće, pokriva li mehanizam poddomene i obje obitelji adresa ili samo imena koja ste upisali?

Odgovorite na ta tri i izbor je obično očit. 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, prenesite 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 doista kontaktira, a ne što stranica prikazuje:

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

Držite razrješivač vidljivim tijekom usporedbe, jer pravilo koje radi s jednog razrješivača i pada s drugog govori vam o odgovoru CDN-a, ne o tunelu. Kratak TTL također znači da odgovor koji ste zabilježili ima rok valjanosti.

Što svaki mehanizam zapravo pokriva

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

Ruta adrese u kernelu uspoređuje prefikse. Ona nema pojma što je ime hosta, pa ne može slijediti uslugu koja mijenja adrese. Pravilo domene razrješava imena i usmjerava rezultat; slijedi uslugu, ali ovisi o razrješivaču, ponašanju osvježavanja i klijentovu rukovanju poddomenama, pa se pravilo koje slijedi imena mora testirati s razrješivačem koji klijent doista koristi.

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

Ponovno provjerite nakon promjene usluge

Nakon ažuriranja klijenta ili promjene usluge ponovno izvedite isti test sesije. Popis adresa koji je prije radio dokaz je o tom razdoblju, a ne trajni inventar infrastrukture usluge.

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

Ta bilješka razlika je između pravila koje možete braniti i pravila koje se nitko ne usuđuje dotaknuti. Ako usluga objavljuje vlastiti popis prefiksa, upotrijebite ga i navedite datum. Ako ne, recite to i držite pravilo domene s njegovim ponašanjem osvježavanja zapisanim pokraj.