DNS кінцевої точки AWS Client VPN: чому закріплення розв'язаної IP не працює
Замініть ім'я кінцевої точки AWS Client VPN адресою, яку ви розв'язали, і тунель згодом перестане працювати. Збережіть експортоване ім'я та його випадковий префікс.
Минулого тижня dig +short дав одну адресу для імені кінцевої точки у вашому профілі AWS Client VPN, і тунель підключився. Цього тижня той самий профіль стоїть на 'Connecting' на вашому ноутбуці, тоді як недоторкана копія колеги ще працює. Нічого не блокували, і сертифікат не закінчився. Хтось замінив ім'я хоста кінцевої точки цією розв'язаною адресою, і сервіс там більше не відповідає. Експортоване ім'я — це частина, побудована так, щоб пережити цю зміну.
Ім'я у вашому профілі може бути не тим ім'ям, яке запитується
Профілі, експортовані з Client VPN, зазвичай містять remote-random-hostname. Коли ця опція ввімкнена, клієнт створює одноразову мітку, приєднує її до імені кінцевої точки через точку і розв'язує складене ім'я. Запис wildcard у зоні кінцевої точки відповідає на будь-яку мітку, тому вигаданий префікс теж розв'язується і тому цей трюк залишається непомітним, коли ви намагаєтеся відтворити запит вручну.
Тож коли ви вставляєте ім'я кінцевої точки в термінал і отримуєте відповідь, ви розв'язали інше ім'я, ніж те, яке клієнт використовує під час підключення. Ця розбіжність не є дефектом, який треба виправляти в профілі. Мітка створюється заново навмисно: опція не дає кешам тримати застарілу відповідь і ніколи не ідентифікує вашу машину чи сеанс.
Мені траплявся випадок сумісності, коли клієнт повністю ігнорує опцію. AWS документує обхід: збережіть справжнє ім'я кінцевої точки і додайте попереду випадковий рядок плюс точку, розглядаючи це як схему найменування, а не як значення для вставки. Застосувати це до старого клієнта розумно; жорстко закріплювати рядок із префіксом як кінцеву точку — ні.
Чому збережена відповідь не може залишатися правильною
Адресами кінцевих точок Client VPN керує AWS, і вони змінюються з часом, про що документація з найкращих практик каже прямо. Захоплена відповідь — це знімок одного розв'язання. Профіль, який його жорстко кодує, стає профілем, націленим на виведений з експлуатації хост, щойно сервіс переміститься, а збій рідко виглядає як DNS: ви отримуєте тайм-аут підключення або завислий handshake, тому люди ганяються за маршрутизацією та сертифікатами.
Та сама відповідь у /etc/hosts успадковує той самий термін із додатковою проблемою. Запис hosts переживає перезавантаження, повторні експорти й виправлення 'перевстановіть клієнт', тому збій повертається щоразу, коли адреса переміщується. Я бачив, як один тижнями лежав нешкідливо, а потім вивів з ладу кожну машину, яка його несла, тоді як свіжі інсталяції підключалися нормально. Цей поділ, одна група збоїть, а інша в порядку на тому самому акаунті, — найдешевша підказка, яку ви отримаєте.
Правильно обмежте область рандомізації. Вона відбувається на кожну спробу підключення. Встановлений тунель не розв'язує свою кінцеву точку заново, не змінює сервер посеред сеансу, і окремі запити застосунків не обирають кожен новий хост VPN. Лише наступна спроба розв'язує знову, тому сеанс, що працює цілий день, нічого не каже про завтрашній ранок.
Що перевіряє сервіс, коли тунель піднімається
Client VPN вимагає, щоб адреса, до якої ви підключені, збігалася з адресою, розв'язаною для DNS-імені кінцевої точки. Ця одна вимога пояснює кілька збоїв, які виглядають не пов'язаними: власний DNS-запис, що вказує в інше місце, власний frontend, що переадресовує на справжню адресу кінцевої точки, і профіль, переписаний на сиру адресу. AWS документує схему 'власний запис плюс переадресація' як збій із новими клієнтами від AWS. Перевірка вузька; це не вирок, що кожен псевдонім заборонений.
Це не загальне правило про протоколи VPN. Числовий remote цілком припустимий у звичайному розгортанні OpenVPN, і багато хто так працює. Обмеження походить від керованої схеми, а не від протоколу під нею.
Що робить послаблення перевірки сертифікатів неправильним рефлексом. Якщо профіль збоїть після заміни адреси, вимкнення перевірки сервера переносить помилку замість того, щоб виправити розв'язання або вимогу збігу адреси, і залишає клієнт, який довірятиме будь-чому. Зберігайте експортований CA, перевірку сервера й налаштування взаємної автентифікації точно такими, якими вони прийшли.
Списки дозволів, вихідний трафік і приватний DNS — три окремі проблеми
Правило брандмауера, яке має дозволити призначення до підключення ноутбука, стосується зовнішнього слухача. Дайте власнику мережі ім'я кінцевої точки, транспорт і налаштований порт, а потім запитайте, чи може їхній контроль слідувати за поведінкою DNS сервісу. Правило, що тримає одну захоплену адресу, — це знімок із невиписаним терміном. Якщо контроль приймає лише незмінні призначення, закрийте цю прогалину до розгортання, а не закріплюйте відповідь мовчки.
Партнеру, якому потрібна фіксована адреса джерела для запитів після підняття тунелю, потрібне інше: вихідний трафік. Те, що бачить сайт, залежить від маршруту застосунку й політики розділеного тунелю, а не від адреси, до якої підключився клієнт. Трафік розділеного тунелю може взагалі не торкатися AWS.
Приватний DNS усередині тунелю — третій шар. Резолвер, який видають клієнтам, відповідає на внутрішні імена після підключення; він не може розв'язати публічну кінцеву точку до появи тунелю. Збій розв'язання кінцевої точки й збій розв'язання внутрішнього застосунку трапляються на різних етапах, і їх змішування веде вас не до того журналу.
Сімейство адрес належить до того самого списку. Відповідь IPv4 нічого не каже про дозволений шлях кінцевої точки IPv6 або з подвійним стеком, тому знімок, зроблений в одному сімействі, не є доказом для іншого.
Перевірте з'єднання, нічого не закріплюючи
Почніть із профілю в тому вигляді, в якому його експортовано, і прочитайте, що він насправді вимагає:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'Потім порівняйте три речі: ім'я кінцевої точки, яке тримає профіль, адресу, яку клієнт повідомляє для нової спроби, і те, у що ім'я розв'язується зараз. Ім'я, що розв'язується, доводить лише те, що запис відповідає; транспорт і автентифікація окремі, і кінцева точка не зобов'язана відповідати на ping. Власний журнал клієнта — єдине джерело для середнього пункту, тому зафіксуйте його під час спроби, а не після.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
Адреса, що відповідає сьогодні, — доказ про сьогодні; ім'я — те, що сервіс підтримує чинним. Запишіть спостереження, надішліть його власнику кінцевої точки й залиште профіль націленим на ім'я.
Дві звички, від яких варто відмовитися: вимикати перевірки сертифікатів, щоб пройти завислий handshake, і нагромаджувати мітки перед іменем кінцевої точки в надії, що одна зачепиться. Мітка розв'язується через запис wildcard, або проблема в іншому місці. Якщо правильно налаштований профіль усе одно збоїть, надішліть точний запит і подію підключення, а не довше ім'я хоста.
Перш ніж закрити питання: профіль усе ще несе експортоване ім'я кінцевої точки, жоден файл hosts не закріплює адресу, remote у журналі клієнта відповідає поточному розв'язанню, а правило брандмауера називає кінцеву точку, а не адресу. Це також стан, який треба передати наступній людині.