DNS при AWS Client VPN: използвайте resolver на VPC, а не на подмрежата

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 сървър и където конзолата предлага опция за resolver на VPC, тя попълва същата идея. Задаването им променя какво услугата подава на клиентите при установяване на връзката. Не променя какво прави неконтролиран клиент OpenVPN с тази стойност, защото клиентът все още трябва да я приложи към операционната система. От тази разлика идва «работи на моя Mac, но не на Linux машината».

В Linux интеграцията с resolver се притежава от мениджъра на връзки, а не от потребителя. Ръчното редактиране на /etc/resolv.conf доказва, че адресът работи за една сесия и след това изчезва при повторно свързване — затова толкова поправени случаи се връщат на следващата сутрин.

Проверете активния resolver на клиента след свързване, а не страницата с конфигурация на endpoint.

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

При split tunneling се използват само маршрутите, избутани в тунела. Ако адресът на resolver не е покрит от маршрут, заявката излиза през локалния интерфейс и домашният ви рутер отговаря. Адресът в endpoint е все още правилен и търсенето все още се проваля. Добавете маршрута за resolver и тествайте отново.

Припокриващи се локални диапазони дават същия резултат по-неприятно: заявката получава отговор, само че от грешен сървър.

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

Инстинктът при изтичащи търсения е да добавите правило, позволяващо UDP 53 към адреса на resolver. AWS документира, че security групите и мрежовите ACL не филтрират трафика към Amazon DNS така, както филтрират трафика към собствен DNS инстанс. Отварянето на тези правила не променя нищо за resolver на VPC и разширява границата без причина. Resolver, който поддържате сами, е друг случай и наистина се нуждае от собствени правила.

Ако и двете присъстват в дизайна ви, проверете към кое е насочен клиентът, преди да редактирате правило.

Проверете пътя, после измерете нещо друго

Разрешете публично име, разрешете частно име, регистрирано в частна хоствана зона, асоциирана с VPC, и прочетете активния resolver на клиента между двете. Тази последователност отделя «адресът на resolver е грешен» от «зоната не е асоциирана» и от «клиентът е игнорирал настройката». Всяко има различно решение и нито едно не е проблем с пропускателната способност.

Успешното търсене не казва нищо за устойчива скорост на трансфер, затова дръжте тези два разговора отделно, когато докладвате.