Приватный DNS работает в VPC, но не через VPN
Приватное имя, которое разрешается внутри EC2, но не через VPN, — это проблема пути резолвера. Прочитайте форму отказа, прежде чем править запись зоны.
Приватное имя разрешается с инстанции EC2, но не с ноутбука, подключённого через VPN, а зона в консоли выглядит правильно. Первый порыв — отредактировать запись, и это почти никогда не является проблемой. Запись кому-то отвечает; просто не отвечает вашему ноутбуку. Разница между двумя вызывающими в том, какой резолвер они спрашивают и есть ли у этого резолвера поддерживаемый путь в DNS-представление VPC.
Я начинаю с доказательства, что запись существует, а остальное время трачу на путь запроса. Это разные системы, и отказывают они по-разному.
Прочитайте форму отказа, прежде чем что-то менять
Три исхода означают три разные вещи, и один запрос их различает: запустите dig для имени против резолвера, который клиент действительно использует.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
Тайм-аут — это утверждение о сети. NXDOMAIN — это утверждение о DNS-представлении. Публичный ответ — это утверждение о политике. Правка записи зоны при тайм-ауте выбрасывает единственное полезное доказательство в деле.
Почему адрес плюс два в VPC не является удалённым резолвером
Адрес CIDR плюс два — это локальная служба для ресурсов внутри VPC. AWS документирует, что пересылка запросов из локальных сетей или с DNS-серверов другого VPC напрямую на этот адрес не поддерживается и может давать нестабильные результаты.
Это не значит, что эксперимент никогда не выглядит работающим. Это значит, что поведение не является контрактом, который можно вписать в скрипт поддержки. Поддерживаемое направление — входящая конечная точка Resolver: пара адресов внутри вашего VPC, доступная из сети, которую вы контролируете, принимающая запросы, приходящие извне AWS.
Стройте путь в том порядке, в котором он отказывает чисто
Должны существовать три перехода, и у каждого свой способ отказа.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesПересыльщику нужен маршрут к адресам конечной точки через VPN, и обратный путь тоже должен работать. Для обычного DNS на порту 53 конечная точка отвечает по UDP и TCP, поэтому оба протокола должны быть разрешены и оба должны пережить любую проверку состояния по пути.
Затем проверьте DNS-представление отдельно. Приватная размещённая зона видна только тем VPC, с которыми она связана, или через намеренную договорённость об общем доступе. Доступная конечная точка сама по себе не делает каждую приватную зону разрешимой в её контексте разрешения.
Исходящая конечная точка обслуживает противоположное направление и не ответит на запрос, приходящий с вашего ноутбука.
Проверьте с обеих сторон
Опрашивайте с клиента к пересыльщику, затем с пересыльщика к конечной точке. Если клиент отказывает, а пересыльщик работает, разрыв между этими двумя.
Если отказывают оба, посмотрите на политику безопасности конечной точки и на адрес источника, который она действительно видит. Пересыльщик за NAT предъявляет адрес NAT вместо VPN-адреса ноутбука, и одной этой разницы достаточно, чтобы запрос отбросили. Если оба работают, а приложение всё равно отказывает, возможно, приложение использует другой резолвер, не тот, который вы тестировали.
Держите публичное и приватное пространства имён намеренно раздельно. Split DNS — это политика, которую вы настраиваете, а не побочный эффект того, что один запрос случайно вернул данные.
Чего я не стал бы делать
Я не стал бы добавлять правило NAT, которое заставило работать один запрос, и называть это проектом.
Я не стал бы направлять каждого удалённого клиента на адрес плюс два только потому, что один тест однажды вернул запись. И я не стал бы расширять политику безопасности конечной точки на весь пул VPN, когда доступ нужен одному пересыльщику. Если организация уже держит одобренный пересыльщик внутри VPC, сначала прочитайте этот проект, потому что вторая конечная точка, которую вы добавите, — та, которую никто не документирует.