A VPN-domainszabály elromlik, amikor a CDN megváltoztatja a címeit

Egy lekérdezésből átmásolod a címet az útválasztási szabályba, az oldal működik, egy hét múlva pedig már nem. A szabályban semmi nem változott. A szolgáltatás másik peremcímre költözött, a kliens másik hosztnevet oldott fel, vagy a munkamenet IPv6-ra váltott. A döntés előtted az, hogy a névalapú szabály vagy egy explicit tartomány a megfelelő eszköz-e ehhez a szolgáltatáshoz, és három feltétel eldönti. A következők elválasztják a nevet a címtől, mert csak az egyikük stabil.

Miért nem leltár egyetlen lekérdezés

Egy tartalomelosztó hálózat a feloldóhoz, a régióhoz és a pillanathoz választott címmel válaszol. Kérdezz kétszer különböző hálózatokból, és különböző válaszokat kaphatsz. Kérdezz egyszer, és kezeld a választ a szolgáltatás címlistájaként, akkor az írt szabály pillanatkép lesz, nem szabály. Ez az egész probléma a DNS-válasz konfigurációként kezelésével.

Van egy második rés. Egy látható hosztnév ritkán fedi le a teljes alkalmazást, mert a bejelentkezés, a média és az API-forgalom gyakran külön neveket használ. A címsor hosztnevéből épített szabály lefedheti az oldalt, és elvéti a videót, ami részleges hibaként, nem útválasztási hibaként olvasható.

A harmadik rés a címcsalád. A csak v4-re vonatkozó szabály semmit nem mond az AAAA-rekordról, amelyet a kliens előnyben részesíthet.

Három feltétel, amely eldönti a domainszabályt vagy a tartományokat

Először, közzétesz-e a szolgáltatás stabil előtagkészletet, amelyet birtokolhatsz és dokumentálhatsz? Ha igen, az explicit tartományok őszinték és olcsók. Ha nem, a domainszabály az egyetlen mechanizmus, amely követni tudja a szolgáltatást.

Másodszor, frissül-e az ügyfeled domainmechanizmusa? Az a szabály, amely egyszer oldódik fel csatlakozáskor, és soha többé, jobb arculatú pillanatkép. Harmadszor, lefedi-e a mechanizmus az aldomaineket és mindkét címcsaládot, vagy csak a beírt neveket?

Válaszolj erre a háromra, és a választás általában nyilvánvaló. A találgatás olyan szabályt ad, amely a tesztben működik, az éles üzemben pedig elbukik.

Munkamenetet tesztelj, ne oldalt

Töltsd be az oldalt, majd hajtsd végre a fontos műveletet: jelentkezz be, indítsd el a lejátszást, tölts fel egy fájlt. Ezek mindegyike más hoszthoz juthat el, és amelyik elbukik, az az, amelyet a szabályod kihagyott.

Sorolj fel, hogy a munkamenet valójában mihez kapcsolódik, ne azt, amit az oldal mutat:

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

Tartsd láthatóan a feloldót az összehasonlítás alatt, mert az a szabály, amely egyik feloldótól működik és a másiktól elbukik, a CDN válaszáról beszél, nem az alagútról. A rövid TTL azt is jelenti, hogy a rögzített válasznak van szavatossági ideje.

Mit fed le valójában az egyes mechanizmusok

A két mechanizmus a beállítások oldalán felcserélhetőnek látszik, a felszín alatt másképp viselkedik.

A kernel címe-útvonal előtagokat párosít. Fogalma sincs, mi a hosztnév, ezért nem tud követni egy címet váltó szolgáltatást. A domainszabály neveket old fel, és az eredményt útválasztja; követi a szolgáltatást, de függ a feloldótól, a frissítési viselkedéstől és attól, hogyan kezeli a kliens az aldomaineket, ezért a neveket követő szabályt azzal a feloldóval kell tesztelni, amelyet a kliens valójában használ.

Egyik sem részhalmaza a másiknak, ezért a jegyzet nélküli keverésük később zavart okoz.

Ellenőrizd újra, miután a szolgáltatás megváltozott

Kliensfrissítés vagy szolgáltatásváltozás után futtasd újra ugyanazt a munkamenet-tesztet. A korábban működő címlista az akkori időszak bizonyítéka, nem a szolgáltatás infrastruktúrájának állandó leltára.

Írd le, melyik mechanizmus melyik hosztnevet fedi, és az utolsó ellenőrzés dátumát.

Ez a jegyzet a különbség az olyan szabály között, amelyet meg tudsz védeni, és az olyan között, amelyhez senki nem mer hozzányúlni. Ha a szolgáltatás közzéteszi a saját előtaglistáját, használd azt, és idézd a dátumot. Ha nem, mondd ki, és tartsd a domainszabályt a frissítési viselkedésével együtt mellette leírva.