Географиялық DNS және эникаст: алынатын VPN кіреберісін тексеру

Географиялық DNS және эникаст кіреберіс нүктелерін түрлі ережелермен таңдайды. Жауап қай шешушіні бейнелейтінін, содан кейін сессия түйін ауысуына шыдайтынын тексеріңіз.

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

Шешуші шын мәнінде кімнің орнын хабарлайтынын тексеріңіз

Топологияға сезімтал сұранысқа жауап беретін өкілетті сервер әдетте сұраған рекурсивті шешушінің мекенжайын көреді, атауды терген адамның мекенжайын емес. Орталықтандырылған шешуші өзі қызмет ететін клиенттерден алыс болуы мүмкін, және жауап солардың орнына шешушіні бейнелейді. Бұл ақау емес; қосымша ақпарат берілмесе, хаттама осылай әрекет етеді. EDNS клиенттік қосымша желісінің спецификациясы шектеуді де, қосымша шешімді де сипаттайды.

EDNS клиенттік қосымша желісі әр қатысушы оны қолдап, қосқанда бастапқы желі туралы ақпаратты тасымалдай алады. Ол қосымша, оның құпиялылық пен кэшке салдары бар және кез келген жария шешуші пайдаланушының нақты орнын хабарлайды деп болжауға рұқсат емес. Оның айналасында жобалау алдында шешуші операторларынан сұраңыз.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Эникаст маршруттауы нені шешкенін тексеріңіз

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

Қызмет орнын қызмет жағынан немесе оны атайтын жауаптан растаңыз, тек DNS жауабынан емес. traceroute -n 198.51.100.20 жүрген жолыңызды көрсетеді және оның соңындағы хостты әлі атамайды, сондықтан оны жауап емес, жол ретінде оқыңыз.

Сессияның түйін ауысуына шыдайтынын тексеріңіз

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

Жылжуды болжаудың орнына бақылаңыз. sudo tcpdump -ni any -c 20 esp жол өзгерген сайын сыртқы пакеттерді көрсетеді, ал серіктес мекенжайының кенет өзгеруі сол жылжудың өзі. Іске асыруыңыз үшін көзделген мінез-құлықты анық көрсетіңіз, содан кейін жолды өзгертуге мәжбүрлеп оны сынаңыз. Егер жобалау сессия репликациясын болжаса, механизмді атаңыз және ол жаппайтын сәтсіздікті атаңыз.

Сәйкестіктің әлі де сай келетінін тексеріңіз

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

Мұны әдеттен тыс түйінге жеткен клиенттен тексеріңіз, өйткені түйін сайынғы сертификат көрінетін жағдай дәл осы. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com тізбекті және атауларды басып шығарады, ал клиент дәл соны салыстырады. Содан кейін профильді тарылту керек пе, әлде сертификат моделін өзгерту керек пе, соны шешіңіз.

Жазбаны тексеріңіз, тек бірінші жауапты емес

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

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Сценарийлерді тек кеңседен емес, өкілдік қолжетімділік желілерінен іске қосыңыз, өйткені бүкіл сұрақ әртүрлі клиенттер шын мәнінде қай кіреберіске жететінінде. Бір желі — бір нұсқаның үлгісі.

Қатысты мақалалар