kubectl не може розв'язати API приватного кластера через OpenVPN

kubectl зазнає невдачі під час пошуку імені, хоча тунель піднято і приватна адреса API досі відповідає на ping. Маршрут гаразд; клієнт питає резолвер, який ніколи не чув про приватну зону кластера. Найчастіше застосовують дві правки: надіслати резолвер віртуальної мережі кожному клієнту VPN або закріпити ім'я локально записом у hosts чи умовним переспрямовувачем. Вони розв'язують той самий симптом із різною відповідальністю, і їхнє змішування призводить до того, що команди редагують файли hosts щоразу, коли кінцеву точку перебудовують.

Розв'язання та доступність зазнають невдачі на різних рівнях

Виконайте пошук самі, перш ніж щось змінювати. getent hosts у Linux або nslookup у Windows покаже, чи отримує клієнт відповідь узагалі; тайм-аут або NXDOMAIN вказують на резолвер, а відповідь із неправильною адресою — на застарілий запис або публічний прохід.

Далі підтвердьте, до якого сервера kubectl насправді підключається. Контекст kubeconfig зберігає URL, і маршрут VPN його не переписує: якщо контекст називає публічну кінцеву точку, DNS може бути бездоганним, а команда все одно не виконається.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

Третій сигнал — форма збою після пошуку. Ім'я, що розв'язується в приватну адресу, а потім отримує тайм-аут TCP, — це проблема міжмережевого екрана або авторизованої мережі. Ім'я, що розв'язується в публічну адресу, означає, що запит вийшов із приватної зони. Тримайте ці три результати окремо; кожен веде вас до іншого відповідального.

Варіант A: надіслати резолвер віртуальної мережі в тунель

Коли сервер VPN працює всередині віртуальної мережі, клієнти можуть використовувати той самий резолвер, що й хост сервера. У OpenVPN Community сервер надсилає опцію DNS; Access Server показує те саме налаштування в адміністративному інтерфейсі, і клієнтам потрібно завантажити профіль знову, бо директива DNS подорожує всередині нього.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

Рядок маршруту важливий у профілях split tunnel. Надіслати адресу резолвера — не те саме, що зробити її досяжною: якщо через тунель іде лише підмережа кластера, запит до 10.0.0.4 виходить через локальний LAN і гине. Надішліть маршрут хоста для резолвера або включіть його підмережу в тунель.

У боку, що приймає, теж є політика. Резолвер, доступний із діапазону адрес клієнта, все одно може відхиляти запити з нього, а приватна зона, пов'язана з віртуальною мережею, відповідає лише клієнтам, які приходять шляхом DNS цієї мережі. Якщо пошук вичерпується після надсилання, перегляньте власні журнали резолвера, перш ніж знову торкатися клієнта.

На клієнті перевірте, що застосовано: resolvectl status у Linux із systemd-resolved, scutil --dns у macOS, ipconfig /all у Windows. Надісланий сервер DNS, який так і не з'явився, означає, що профіль не перезавантажено.

Варіант B: записи hosts і умовне переспрямування

Запис hosts — найменша можлива правка і найкрихкіша. Вона зіставляє одне ім'я з однією адресою на одній машині, тому годиться для демонстрації і ламається, коли приватну кінцеву точку або її IP перебудовують. Вона також приховує реальну прогалину від решти команди.

Умовний переспрямовувач масштабується краще, не надсилаючи DNS кожному клієнту. dnsmasq може надіслати одну зону резолверу VNet і залишити все інше в спокої: server=/cluster.internal/10.0.0.4. DNS Windows має умовні переспрямовувачі, і клієнти Windows можуть використовувати правило NRPT для того самого поділу. Переспрямовувачу все ще потрібен маршрут до резолвера VNet.

Переспрямування зберігає звичайний перегляд локальним, що важливо в split tunnel. Воно також дає одне місце для журналювання запитів приватної зони і одне місце, яке ламається, коли хост переспрямовувача переїжджає.

Вибирайте за відповідальністю, а не за зручністю

Надішліть резолвер, якщо ви керуєте профілем VPN і хочете, щоб працювало кожне приватне ім'я, а не лише API. Виберіть переспрямовувач, якщо клієнти мають зберегти локальний DNS для всього іншого або якщо VPN керує інша команда, ніж кластер.

Записи hosts — це діагностика, а не розгортання. Використайте один, щоб довести доступність API, потім приберіть його і виправте шлях резолвера; якщо залишити його на місці, питання маршрутизації згодом перетвориться на пошук скарбів. Який би варіант ви не вибрали, запишіть зону, адресу резолвера і маршрут, що несе запит.

Перевіряйте кінцеву точку API, а не лише ім'я

Коли пошук успішний, отримайте кінцеву точку версії API з CA кластера. curl --cacert ca.crt https://api.internal.example:6443/version відокремлює збої TLS і авторизації від DNS. 403 означає, що ім'я та з'єднання працюють, а ідентичність — ні.

Перевірте також, чи дозволений діапазон адрес клієнта авторизованими мережами або міжмережевим екраном кластера. Приватні кластери часто приймають трафік API лише з VNet або peered-діапазонів, тому тунель, що видає адреси з іншого пулу, підключається на мережевому рівні і відкидається на API.

Запишіть чотири факти під час ескалації: резолвер, яким користувався клієнт, адресу, яку він повернув, URL сервера у вибраному контексті kubeconfig і першу невдалу операцію. Цей запис скаже наступному інженеру, чи змінювати DNS, маршрутизацію або політику міжмережевого екрана, і зупинить наступну правку файла hosts.

Почніть із пошуку, виберіть шлях резолвера, що відповідає власникові зони, потім перевірте кінцеву точку. Якщо всі три пройдуть, залишкова проблема — авторизація, а не розв'язання імен.