Приватний 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, спершу прочитайте цей проєкт, бо друга кінцева точка, яку ви додасте, — та, яку ніхто не документує.