DNS в AWS Client VPN: используйте resolver VPC, а не подсеть
Resolver конечной точки AWS Client VPN — это основной диапазон 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 неверен» от «зона не связана» и от «клиент проигнорировал настройку». У каждого своё исправление, и ни одно не является проблемой пропускной способности.
Успешный поиск ничего не говорит об устойчивой скорости передачи, поэтому держите эти два разговора раздельно, когда отчитываетесь.