VPN-domajna regulo rompiĝas, kiam CDN ŝanĝas siajn adresojn

Vi kopias la adreson el unu serĉo en vian enkursigan regulon, la retejo funkcias, kaj semajnon poste ĝi ne plu funkcias. Nenio en la regulo ŝanĝiĝis. La servo transloĝiĝis al alia randa adreso, la kliento solvis alian gastigantnomon, aŭ la sesio transiris al IPv6. La decido antaŭ vi estas, ĉu nom-bazita regulo aŭ eksplicita intervalo estas la ĝusta ilo por ĉi tiu servo, kaj tri kondiĉoj decidas tion. Tio, kio sekvas, apartigas la nomon de la adreso, ĉar nur unu el ili estas stabila.

Kial unu serĉo ne estas inventaro

Enhava livera reto respondas per adreso elektita por la solvilo, la regiono kaj la momento. Demandu dufoje el malsamaj retoj kaj vi povas ricevi malsamajn respondojn. Demandu unufoje kaj traktu la respondon kiel la adresliston de la servo, kaj la regulo, kiun vi skribas, estas momentfoto, ne regulo. Tio estas la tuta problemo pri trakti DNS-respondon kiel agordon.

Ekzistas dua manko. Unu videbla gastigantnomo malofte kovras la tutan aplikaĵon, ĉar ensaluto, amaskomunikiloj kaj API-trafiko ofte uzas apartajn nomojn. Regulo konstruita el la gastigantnomo en la adresobreto povas kovri la paĝon kaj maltrafi la videon, kio legiĝas kiel parta fiasko, ne kiel enkursiga eraro.

La tria manko estas la adresfamilio. Regulo nur por v4 diras nenion pri la AAAA-rikordo, kiun la kliento eble preferas.

Tri kondiĉoj, kiuj decidas domajnan regulon aŭ intervalojn

Unue, ĉu la servo publikigas stabilan aron da prefiksoj, kiujn vi povas posedi kaj dokumenti? Se jes, eksplicitaj intervaloj estas honestaj kaj malmultekostaj. Se ne, domajna regulo estas la sola mekanismo, kiu povas sekvi la servon.

Due, ĉu la domajna mekanismo de via kliento refreŝiĝas? Regulo, kiu solviĝas unufoje ĉe konekto kaj neniam plu, estas momentfoto kun pli bona markado. Trie, ĉu la mekanismo kovras subdomajnojn kaj ambaŭ adresfamiliojn, aŭ nur la nomojn, kiujn vi tajpis?

Respondu al tiuj tri kaj la elekto kutime estas evidenta. Divenado produktas regulon, kiu funkcias en testado kaj fiaskas en produktado.

Testu sesion, ne paĝon

Ŝargu la paĝon, poste plenumu la operacion, kiu gravas: ensalutu, komencu ludadon, alŝutu dosieron. Ĉiu el ili povas atingi alian gastiganton, kaj tiu, kiu fiaskas, estas tiu, kiun via regulo maltrafis.

Listigu, kion la sesio efektive kontaktas, anstataŭ kion la paĝo montras:

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

Tenu la solvilon videbla dum la komparo, ĉar regulo, kiu funkcias el unu solvilo kaj fiaskas el alia, parolas al vi pri la respondo de la CDN, ne pri la tunelo. Mallonga TTL ankaŭ signifas, ke la respondo, kiun vi notis, havas limdaton.

Kion ĉiu mekanismo efektive kovras

La du mekanismoj aspektas interŝanĝeblaj en agorda paĝo kaj kondutas malsame sube.

Kerna adresa itinero kongruas prefiksojn. Ĝi havas nenian ideon, kio estas gastigantnomo, do ĝi ne povas sekvi servon, kiu ŝanĝas adresojn. Domajna regulo solvas nomojn kaj enkursigas la rezulton; ĝi sekvas la servon sed dependas de la solvilo, de la refreŝiga konduto kaj de la traktado de subdomajnoj fare de la kliento, do regulo, kiu sekvas nomojn, devas esti testata kun la solvilo, kiun la kliento efektive uzas.

Neniu estas superaro de la alia, kaj tial ilia miksado sen noto poste kreas konfuzon.

Rekontrolu post kiam la servo ŝanĝiĝas

Post klienta ĝisdatigo aŭ serva ŝanĝo, rulu la saman sesian teston denove. Adreslisto, kiu antaŭe funkciis, estas pruvo pri tiu periodo, ne daŭra inventaro de la infrastrukturo de la servo.

Notu, kiu mekanismo kovras kiun gastigantnomon, kaj la daton de via lasta kontrolo.

Tiu noto estas la diferenco inter regulo, kiun vi povas defendi, kaj regulo, kiun neniu kuraĝas tuŝi. Se la servo publikigas sian propran prefiksliston, uzu ĝin kaj citi la daton. Se ne, diru tion, kaj tenu la domajnan regulon kun ĝia refreŝiga konduto skribita apude.