VPN domēna noteikums salūzt, kad CDN maina savas adreses

Jūs nokopējat adresi no viena vaicājuma savā maršrutēšanas noteikumā, vietne strādā, un nedēļu vēlāk vairs nestrādā. Noteikumā nekas nav mainījies. Pakalpojums pārcēlās uz citu malas adresi, klients atrisināja citu resursdatora nosaukumu, vai sesija pārgāja uz IPv6. Lēmums jūsu priekšā ir, vai uz vārdu balstīts noteikums vai skaidrs diapazons ir pareizais instruments šim pakalpojumam, un trīs nosacījumi to izšķir. Turpmākais atdala vārdu no adreses, jo tikai viens no tiem ir stabils.

Kāpēc viens vaicājums nav inventārs

Satura piegādes tīkls atbild ar adresi, kas izvēlēta atrisinātājam, reģionam un brīdim. Jautājiet divreiz no dažādiem tīkliem, un jūs varat saņemt dažādas atbildes. Jautājiet vienreiz un uzskatiet atbildi par pakalpojuma adrešu sarakstu, un jūsu rakstītais noteikums ir momentuzņēmums, nevis noteikums. Tā ir visa problēma ar DNS atbildes uztveršanu kā konfigurāciju.

Ir otra plaisa. Viens redzams resursdatora nosaukums reti aptver visu lietojumprogrammu, jo pieteikšanās, mediji un API plūsma bieži izmanto atsevišķus nosaukumus. Noteikums, kas veidots no adreses joslas resursdatora nosaukuma, var aptvert lapu un palaist garām video, ko lasa kā daļēju kļūmi, nevis maršrutēšanas kļūdu.

Trešā plaisa ir adrešu saime. Noteikums tikai v4 neko nepasaka par AAAA ierakstu, kam klients var dot priekšroku.

Trīs nosacījumi, kas izšķir domēna noteikumu vai diapazonus

Pirmkārt, vai pakalpojums publicē stabilu prefiksu kopu, kuru jūs varat piederēt un dokumentēt? Ja jā, skaidri diapazoni ir godīgi un lēti. Ja nē, domēna noteikums ir vienīgais mehānisms, kas var sekot pakalpojumam.

Otrkārt, vai jūsu klienta domēna mehānisms atjaunojas? Noteikums, kas atrisinās vienreiz pieslēgšanās laikā un nekad vairs, ir momentuzņēmums ar labāku zīmolu. Treškārt, vai mehānisms aptver apakšdomēnus un abas adrešu saimes, vai tikai nosaukumus, ko ierakstījāt?

Atbildiet uz šiem trim, un izvēle parasti ir acīmredzama. Minēšana rada noteikumu, kas strādā testā un neizdodas ražošanā.

Pārbaudiet sesiju, nevis lapu

Ielādējiet lapu, pēc tam veiciet svarīgo darbību: piesakieties, sāciet atskaņošanu, augšupielādējiet failu. Katrs no tiem var sasniegt citu resursdatoru, un tas, kas neizdodas, ir tas, ko jūsu noteikums palaida garām.

Uzskaitiet, ar ko sesija patiešām sazinās, nevis ko rāda lapa:

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

Turiet atrisinātāju redzamu salīdzināšanas laikā, jo noteikums, kas strādā no viena atrisinātāja un neizdodas no cita, stāsta par CDN atbildi, nevis par tuneli. Īss TTL arī nozīmē, ka pierakstītajai atbildei ir derīguma termiņš.

Ko katrs mehānisms patiešām aptver

Abi mehānismi iestatījumu lapā izskatās aizstājami, bet iekšpusē uzvedas citādi.

Kodola adreses maršruts saskaņo prefiksus. Tam nav ne jausmas, kas ir resursdatora nosaukums, tāpēc tas nevar sekot pakalpojumam, kas maina adreses. Domēna noteikums atrisina nosaukumus un maršrutē rezultātu; tas seko pakalpojumam, bet ir atkarīgs no atrisinātāja, atjaunināšanas uzvedības un klienta apakšdomēnu apstrādes, tāpēc noteikums, kas seko nosaukumiem, ir jāpārbauda ar atrisinātāju, ko klients patiešām izmanto.

Neviens nav otra virskopa, tāpēc to sajaukšana bez piezīmes vēlāk rada apjukumu.

Pārbaudiet vēlreiz pēc pakalpojuma maiņas

Pēc klienta atjaunināšanas vai pakalpojuma maiņas vēlreiz palaidiet to pašu sesijas testu. Iepriekš strādājošs adrešu saraksts ir pierādījums par to periodu, nevis pastāvīgs pakalpojuma infrastruktūras inventārs.

Pierakstiet, kurš mehānisms aptver kuru resursdatora nosaukumu, un pēdējās pārbaudes datumu.

Šī piezīme ir atšķirība starp noteikumu, ko varat aizstāvēt, un noteikumu, kam neviens neuzdrošinās pieskarties. Ja pakalpojums publicē savu prefiksu sarakstu, izmantojiet to un norādiet datumu. Ja nē, sakiet to, un turiet domēna noteikumu ar tā atjaunināšanas uzvedību blakus pierakstītu.