AWS Client VPN DNS: subnet емес, VPC resolver-ін қолданыңыз

Endpoint 10.0.8.0/24 ішінде, сондықтан resolver 10.0.8.2 болуы керек. Бұл ең жиі еститін пайымдау, және ол екі рет қате. Route 53 Resolver VPC-нің негізгі IPv4 диапазонында плюс екі мекенжайында жауап береді, бұл 10.0.0.0/16 VPC үшін 10.0.0.2, endpoint қай subnet-ті қолданса да. Екінші қате байсалдырақ: endpoint-ке дұрыс мекенжайды қою клиенттің операциялық жүйесі одан бірдеңе сұрайды дегенді білдірмейді. Екі қате де бір симптом береді: атауларды шешу кейбір клиенттерде жұмыс істейді, басқаларында сәтсіз аяқталады.

Миф subnet байланысынан басталады

Байланыс клиент қосылымдарының серпімді желілік интерфейстері қайда орналасқаны туралы, қандай resolver мекенжайы бар екені туралы емес. Endpoint-тің subnet-тері клиенттерге VPC ішінде мекенжай береді, және олардың әрқайсысы өз resolver-ін алып жүрмейді.

Осы екі идеяны бөлгенде, арифметика құпия болудан қалады, ал ақаулықты іздеу клиентке ауысады, бұл істердің көбісі шын мәнінде сонда аяқталады.

Мекенжайды VPC-нің негізгі диапазонынан есептеңіз

VPC-нің негізгі IPv4 CIDR-ін алып, желілік мекенжайға екі қосыңыз. 10.0.0.0/16 10.0.0.2 береді, 172.31.0.0/16 172.31.0.2 береді, ал қосымша диапазоны бар VPC resolver-ді негізгіде ұстайды. Сол VPC ішіндегі 10.0.8.0/24 subnet оны жылжытпайды. Endpoint-ке тимес бұрын мекенжайды VPC ID қасына жазып қойыңыз, өйткені бұл сан VPC-нің қасиеті, қосылымның емес.

VPC link-local 169.254.169.253 мекенжайында да жауап береді. Бұл мекенжай VPC ішінен қолжетімді, бірақ туннельдің арғы жағындағы ноутбук үшін жалпы маршрутталатын мақсат емес.

Сонымен екі жарамды resolver мекенжайы бар, және олардың ешқайсысы subnet плюс екі емес.

Endpoint параметрі не істейді, не істемейді

Client VPN endpoint-інде DNS сервер өрістері бар, ал консоль VPC resolver опциясын ұсынған жерде сол идеяны толтырады. Оларды орнату қосылым орнатылған кезде қызметтің клиенттерге не беретінін өзгертеді. Бұл басқарылмайтын OpenVPN клиентінің осы мәнмен не істейтінін өзгертпейді, өйткені клиент оны операциялық жүйеге қолдануы керек. «Менің Mac-імде жұмыс істейді, Linux машинасында істемейді» деген сөз осы алшақтықтан шығады.

Linux-та resolver интеграциясы қосылым менеджеріне тиесілі, қолданушыға емес. /etc/resolv.conf файлын қолмен өңдеу мекенжайдың бір сессия үшін жұмыс істейтінін дәлелдейді, содан кейін қайта қосылғанда жоғалады — сондықтан түзетілген істердің көбісі келесі таңда қайтады.

Қосылғаннан кейін клиенттегі белсенді resolver-ді тексеріңіз, endpoint-тің конфигурация бетін емес.

Split tunneling дұрыс resolver-ді жеңе алады

Split tunneling кезінде тек туннельге итерілген маршруттар қолданылады. Егер resolver мекенжайы маршрутпен қамтылмаса, сұрау жергілікті интерфейстен шығады және үйдегі роутеріңіз жауап береді. Endpoint-тегі мекенжай әлі дұрыс, іздеу әлі сәтсіз. Resolver үшін маршрут қосып, қайта сынаңыз.

Қабаттасатын жергілікті диапазондар бірдей нәтижені жағымсыз түрде береді: сұрауға жауап келеді, тек қате серверден.

Amazon DNS мекенжайы үшін security group ашпаңыз

Іздеу уақыты біткенде инстинкт resolver мекенжайына UDP 53 рұқсат ететін ереже қосуға итермелейді. AWS құжаттайды: security group-тар мен желілік ACL-дар Amazon DNS трафигін өз DNS инстансына баратын трафик сияқты сүзбейді. Бұл ережелерді ашу VPC resolver үшін ештеңе өзгертпейді және шекараны себепсіз кеңейтеді. Өзіңіз жүргізетін resolver басқа жағдай және шынымен өз ережелерін қажет етеді.

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

Жолды тексеріңіз, сосын басқаны өлшеңіз

Жалпыға ашық атауды шешіңіз, VPC-ге байланысты жеке хостинг аймағында тіркелген жеке атауды шешіңіз және екеуінің арасында клиенттің белсенді resolver-ін оқыңыз. Бұл реттілік «resolver мекенжайы қате» дегенді «аймақ байланыспаған» және «клиент параметрді елемеді» дегеннен ажыратады. Әрқайсысының түзетуі бөлек, және ешқайсысы өткізу қабілетінің мәселесі емес.

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