Pravilo domene VPN se zlomi, ko CDN spremeni svoje naslove

Kopirate naslov iz ene poizvedbe v svoje pravilo usmerjanja, spletno mesto deluje, teden dni kasneje pa ne več. V pravilu se ni nič spremenilo. Storitev se je preselila na drug robni naslov, odjemalec je razrešil drugo ime gostitelja ali seja je prešla na IPv6. Odločitev pred vami je, ali je pravilo na podlagi imena ali izrecen razpon pravo orodje za to storitev, in trije pogoji to odločijo. Naslednje ločuje ime od naslova, ker je stabilno le eno od obeh.

Zakaj ena poizvedba ni popis

Omrežje za dostavo vsebine odgovori z naslovom, izbranim za razreševalnik, regijo in trenutek. Vprašajte dvakrat iz različnih omrežij in lahko dobite različne odgovore. Vprašajte enkrat in odgovor obravnavajte kot seznam naslovov storitve, in pravilo, ki ga napišete, je posnetek, ne pravilo. To je vsa težava z obravnavanjem odgovora DNS kot konfiguracije.

Obstaja druga vrzel. Eno vidno ime gostitelja redko pokrije celotno aplikacijo, ker prijava, mediji in promet API pogosto uporabljajo ločena imena. Pravilo, zgrajeno iz imena gostitelja v naslovni vrstici, lahko pokrije stran in zgreši videoposnetek, kar se bere kot delna okvara, ne kot napaka usmerjanja.

Tretja vrzel je družina naslovov. Pravilo samo za v4 ne pove ničesar o zapisu AAAA, ki mu lahko odjemalec daje prednost.

Trije pogoji, ki odločijo pravilo domene ali razpone

Prvič, ali storitev objavlja stabilen nabor predpon, ki jih lahko imate in dokumentirate? Če da, so izrecni razponi pošteni in poceni. Če ne, je pravilo domene edini mehanizem, ki lahko sledi storitvi.

Drugič, ali se mehanizem domene vašega odjemalca osvežuje? Pravilo, ki se razreši enkrat ob povezavi in nikoli več, je posnetek z boljšo blagovno znamko. Tretjič, ali mehanizem pokriva poddomene in obe družini naslovov, ali le imena, ki ste jih vnesli?

Odgovorite na te tri in izbira je običajno očitna. Ugibanje ustvari pravilo, ki deluje pri preizkusu in odpove v produkciji.

Preizkusite sejo, ne strani

Naložite stran in nato izvedite dejanje, ki je pomembno: prijavite se, začnite predvajanje, naložite datoteko. Vsako od njih lahko doseže drugega gostitelja, in tisto, ki odpove, je tisto, ki ga je vaše pravilo zgrešilo.

Naštejte, s čim seja v resnici komunicira, namesto kaj prikazuje stran:

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

Med primerjavo imejte razreševalnik na očeh, ker pravilo, ki deluje z enega razreševalnika in odpove z drugega, vam govori o odgovoru CDN, ne o tunelu. Kratek TTL pomeni tudi, da ima zabeleženi odgovor rok uporabnosti.

Kaj vsak mehanizem v resnici pokriva

Oba mehanizma se na strani z nastavitvami zdita zamenljiva, znotraj pa se obnašata drugače.

Jedrna pot naslova ujema predpone. Nima pojma, kaj je ime gostitelja, zato ne more slediti storitvi, ki spreminja naslove. Pravilo domene razreši imena in usmeri rezultat; sledi storitvi, vendar je odvisno od razreševalnika, vedenja ob osvežitvi in od tega, kako odjemalec obravnava poddomene, zato je treba pravilo, ki sledi imenom, preizkusiti z razreševalnikom, ki ga odjemalec res uporablja.

Nobeno ni nadmnožica drugega, zato njuno mešanje brez opombe pozneje ustvari zmedo.

Znova preverite, ko se storitev spremeni

Po posodobitvi odjemalca ali spremembi storitve znova zaženite isti preizkus seje. Seznam naslovov, ki je prej deloval, je dokaz o tistem obdobju, ne trajen popis infrastrukture storitve.

Zapišite, kateri mehanizem pokriva katero ime gostitelja, in datum zadnjega preverjanja.

Ta opomba je razlika med pravilom, ki ga lahko branite, in pravilom, ki se ga nihče ne upa dotakniti. Če storitev objavi svoj seznam predpon, ga uporabite in navedite datum. Če ne, povejte to in imejte pravilo domene z njegovim vedenjem ob osvežitvi zapisano ob strani.