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

Візьміть основний CIDR IPv4 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 groups для адреси Amazon DNS

Інстинкт, коли пошук вичерпує час, — додати правило, що дозволяє UDP 53 до адреси resolver. AWS документує, що security groups і мережеві ACL не фільтрують трафік Amazon DNS так, як фільтрують трафік до власного екземпляра DNS. Відкриття цих правил нічого не змінює для resolver VPC і без причини розширює межу. Resolver, який ви ведете самі, — інший випадок, і йому справді потрібні власні правила.

Якщо у вашому проєкті є і те, й інше, перевірте, на що клієнт насправді вказує, перш ніж редагувати будь-яке правило.

Перевірте шлях, а потім виміряйте інше

Розв’яжіть публічне ім’я, розв’яжіть приватне ім’я, зареєстроване в приватній розміщеній зоні, пов’язаній з VPC, і прочитайте між ними активний resolver клієнта. Ця послідовність відокремлює «адреса resolver неправильна» від «зона не пов’язана» та від «клієнт проігнорував налаштування». Кожен має власне виправлення, і жоден не є проблемою пропускної здатності.

Успішний пошук нічого не каже про сталу швидкість передачі, тож тримайте ці дві розмови окремо, коли звітуєте.