VPN домен ережесі CDN өз мекенжайларын өзгерткенде бұзылады

Бір сұраудан мекенжайды өз маршруттау ережеңізге көшіресіз, сайт жұмыс істейді, ал бір аптадан кейін істемейді. Ережеде ештеңе өзгерген жоқ. Қызмет басқа шеткі мекенжайға көшті, клиент басқа хост атын шешті немесе сессия IPv6-ға ауысты. Алдыңыздағы шешім — атауға негізделген ереже ме, әлде нақты диапазон ба осы қызмет үшін дұрыс құрал, және оны үш шарт шешеді. Төмендегі атауды мекенжайдан ажыратады, өйткені олардың тек біреуі ғана тұрақты.

Неге бір сұрау түгендеу емес

Мазмұнды жеткізу желісі шешушіге, аймаққа және сәтке таңдалған мекенжаймен жауап береді. Әртүрлі желілерден екі рет сұраңыз, әртүрлі жауап алуыңыз мүмкін. Бір рет сұрап, жауапты қызметтің мекенжайлар тізімі деп қабылдаңыз, сонда жазған ережеңіз ереже емес, сурет болады. DNS жауабын конфигурация ретінде қараудың бүкіл мәселесі осында.

Екінші олқылық бар. Бір көрінетін хост аты бүкіл қолданбаны сирек қамтиды, өйткені кіру, медиа және API трафигі жиі бөлек аттарды пайдаланады. Мекенжай жолағындағы хост атынан құрылған ереже бетті қамтып, бейнені өткізіп жіберуі мүмкін, бұл маршруттау қатесі емес, ішінара істен шығу ретінде оқылады.

Үшінші олқылық — мекенжайлар отбасы. Тек v4-ке арналған ереже клиент таңдауы мүмкін AAAA жазбасы туралы ештеңе айтпайды.

Домен ережесін немесе диапазондарды шешетін үш шарт

Біріншіден, қызмет сіз иеленіп, құжаттай алатын тұрақты префикстер жиынын жариялай ма? Егер жарияласа, нақты диапазондар адал және арзан. Егер жарияламаса, домен ережесі қызметті ғана қуалай алатын жалғыз механизм.

Екіншіден, клиентіңіздің домен механизмі жаңара ма? Қосылу кезінде бір рет шешіліп, басқа ешқашан жаңармайтын ереже — жақсырақ брендингі бар сурет. Үшіншіден, механизм субдомендерді және екі мекенжай отбасын қамти ма, әлде тек сіз терген аттарды ма?

Осы үшеуіне жауап беріңіз, таңдау әдетте айқын болады. Болжау сынақта жұмыс істеп, өндірісте сәтсіздікке ұшырайтын ереже жасайды.

Сессияны сынаңыз, бетті емес

Бетті жүктеңіз, содан кейін маңызды әрекетті орындаңыз: кіріңіз, ойнатуды бастаңыз, файл жүктеңіз. Олардың әрқайсысы басқа хостқа жете алады, ал сәтсіз болатыны — ережеңіз өткізіп жіберген.

Бет көрсететін нәрсені емес, сессия шын мәнінде немен байланысатынын тізімдеңіз:

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

Салыстыру кезінде шешушіні көрінетін күйде ұстаңыз, өйткені бір шешушіден жұмыс істеп, екіншісінен сәтсіз болатын ереже сізге CDN жауабы туралы айтады, туннель туралы емес. Қысқа TTL де жазып алған жауабыңыздың жарамдылық мерзімі бар екенін білдіреді.

Әр механизм шын мәнінде нені қамтиды

Екі механизм параметрлер бетінде алмастырылатын көрінеді, ал ішінде басқаша әрекет етеді.

Ядродағы мекенжай маршруты префикстерді сәйкестендіреді. Ол хост атының не екенін білмейді, сондықтан мекенжайларын өзгертетін қызметті қуалай алмайды. Домен ережесі аттарды шешіп, нәтижені маршруттайды; ол қызметті қуалайды, бірақ шешушіге, жаңару тәртібіне және клиенттің субдомендерді өңдеуіне тәуелді, сондықтан аттарды қуалайтын ережені клиент шын мәнінде пайдаланатын шешушімен сынау керек.

Ешқайсысы екіншісінің қамтитын жиыны емес, сондықтан оларды жазбасыз араластыру кейін шатасушылық тудырады.

Қызмет өзгергеннен кейін қайта тексеріңіз

Клиент жаңартылғаннан немесе қызмет өзгергеннен кейін сол сессия сынағын қайта іске қосыңыз. Бұрын жұмыс істеген мекенжайлар тізімі сол кезең туралы дәлел, қызмет инфрақұрылымының тұрақты түгендеуі емес.

Қай механизм қай хост атын қамтитынын және соңғы тексеру күнін жазып қойыңыз.

Бұл жазба — қорғай алатын ереже мен ешкім тиісуге батылы бармайтын ереженің айырмашылығы. Егер қызмет өзінің префикс тізімін жарияласа, оны пайдаланып, күнін көрсетіңіз. Егер жоқ болса, соны айтыңыз және домен ережесін оның жаңару тәртібімен қатар жазып ұстаңыз.