DNS на AWS Client VPN: користите VPC resolver, не подмрежу

Endpoint се налази у 10.0.8.0/24, па resolver мора бити 10.0.8.2. То је резоновање које најчешће чујем и погрешно је двапут. Route 53 Resolver одговара на примарном IPv4 опсегу VPC-а плус два, што је за VPC 10.0.0.0/16 адреса 10.0.0.2, без обзира на то коју подмрежу endpoint користи. Друга грешка је тиша: стављање исправне адресе у endpoint не значи да ће је оперативни систем клијента икада питати било шта. Обе грешке дају исти симптом: разрешавање имена ради код неких клијената, а код других не.

Мит почиње код асоцијације подмреже

Асоцијација се односи на то где живе еластични мрежни интерфејси за клијентске везе, а не на то која адреса resolver-а постоји. Подмреже endpoint-а дају клијентима адресу унутар VPC-а и ниједна од њих не носи сопствени resolver.

Када раздвојите те две идеје, аритметика престаје да буде мистериозна, а отклањање проблема прелази на клијента, где већина ових случајева заиста заврши.

Израчунајте адресу из примарног VPC опсега

Узмите примарни IPv4 CIDR VPC-а и додајте два на мрежну адресу. 10.0.0.0/16 даје 10.0.0.2, 172.31.0.0/16 даје 172.31.0.2, а VPC са секундарним опсегом задржава resolver на примарном. Подмрежа 10.0.8.0/24 унутар тог VPC-а то не помера. Запишите адресу поред ID-а VPC-а пре него што дирнете endpoint, јер је број својство VPC-а, а не везе.

VPC одговара и на link-local адреси 169.254.169.253. Та адреса је доступна унутар VPC-а, али није општа рутирана дестинација за лаптоп на другој страни тунела.

Дакле, постоје две важеће адресе resolver-а и ниједна од њих није подмрежа плус два.

Шта поставка endpoint-а ради, а шта не

Endpoint Client VPN има поља за DNS сервер, а где конзола нуди опцију VPC resolver-а, она попуњава исту идеју. Њихово постављање мења оно што сервис предаје клијентима током успоставе везе. То не мења оно што неуправљани OpenVPN клијент ради с том вредношћу, јер клијент је још мора применити на оперативни систем. Из тог јаза долази «ради на мом Mac-у, али не на Linux машини».

На Linux-у интеграцијом resolver-а управља менаџер веза, а не корисник. Ручно уређивање /etc/resolv.conf доказује да адреса ради за једну сесију, а затим нестаје при поновном повезивању — зато се толико поправљених случајева враћа следећег јутра.

Проверите активни resolver на клијенту након повезивања, а не страницу конфигурације endpoint-а.

Split tunneling може да победи исправан resolver

Уз split tunneling користе се само руте гурнуте у тунел. Ако адреса resolver-а није покривена рутом, упит излази кроз локални интерфејс и на њега одговара ваш кућни рутер. Адреса у endpoint-у је и даље исправна, а претрага и даље не успева. Додајте руту за resolver, па тестирајте поново.

Преклапајући локални опсези дају исти резултат на гори начин: упит добије одговор, само од погрешног сервера.

Не отварајте сигурносне групе за адресу Amazon DNS

Инстинкт када претраге истекну је да се дода правило које допушта UDP 53 на адресу resolver-а. AWS документује да сигурносне групе и мрежни ACL-ови не филтрирају Amazon DNS саобраћај онако како филтрирају саобраћај према сопственој DNS инстанци. Отварање тих правила не мења ништа за VPC resolver и шири границу без разлога. Resolver који сами водите је други случај и заиста му требају сопствена правила.

Ако се оба појављују у вашем дизајну, проверите на које је клијент заиста усмерен пре него што уредите било које правило.

Проверите пут, па измерите нешто друго

Разрешите јавно име, разрешите приватно име регистровано у приватној хостованој зони повезаној са VPC-ом и прочитајте активни resolver клијента између то двоје. Тај след одваја «адреса resolver-а је погрешна» од «зона није повезана» и од «клијент је игнорисао поставку». Сваки има другачије решење и ниједан није проблем пропусности.

Успешна претрага не говори ништа о трајној брзини преноса, зато држите та два разговора одвојено када извештавате.