ip netns exec і DNS: чому імена не працюють усередині простору імен

Команда досягає 10.8.0.5 усередині простору імен VPN без жодної скарги, а та сама команда відмовляє тієї миті, коли використовує ім’я хоста. Простір імен має власні інтерфейси, маршрути й сокети; власного файлу розпізнавача в нього немає. Якщо щось не покладе один туди, процес усередині читає /etc/resolv.conf хоста й запитує сервер, який може бути недоступним із цього мережевого стеку.

Це проблема вибору файлу, а не проблема маршрутизації, і саме тому числова адреса призначення досі працює.

Перевірте подання розпізнавача, яке процес справді отримує

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

Для простору імен, створеного за допомогою ip netns add, перевірка лише для читання коротка:

ip netns exec vpn cat /etc/resolv.conf

Зверніть увагу, чи називає результат доступну адресу, заглушку loopback або символьне посилання, що вказує на місце з іншою доступністю.

Що насправді монтує помічник exec

Інструмент ip-netns документує конфігурацію для кожного простору імен під /etc/netns/NAME/. Коли він запускає процес, помічник створює простір імен монтування й монтує ці файли поверх їхніх звичайних шляхів, тож процес бачить копію, специфічну для простору імен. Це зручність саме цього засобу запуску. Вхід у мережевий простір імен іншим шляхом, наприклад через unshare або середовище виконання контейнерів, не відтворює цього автоматично.

Тут пастка — розпізнавач на loopback: 127.0.0.53 означає власний loopback простору імен, а не заглушку хоста. Заглушка, що слухає лише в просторі імен хоста, не стає службою в новому.

Виберіть розпізнавач, до якого простір імен може дістатися

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

Застосунки з власним розпізнавачем, як-от той, що використовує DNS over HTTPS, можуть цілком ігнорувати файл. Якщо інструмент має власне налаштування DNS, зміна resolv.conf на нього не вплине, і простір імен ніколи не був проблемою.

Запишіть файл у правильне місце

Створіть файл для простору імен під /etc/netns/NAME/resolv.conf і дозвольте засобу запуску його подати. Тримайте його мінімальним: один або два доступні сервери й домени пошуку, потрібні завданню. Не редагуйте згенерований файл розпізнавача хоста, щоб виправити подання, призначене для однієї групи процесів, бо це змінює кожен застосунок на машині. Якщо хост використовує менеджер розпізнавача, налаштуйте шлях простору імен через цей менеджер, а не боріться з ним.

Запишіть вміст файлу в runbook. Інакше наступна людина перевірить розпізнавач хоста, побачить робочу відповідь і дійде висновку, що простір імен у порядку.

Перевірте весь шлях заново

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

Переконайтеся, що файл отримує процес, а не оболонка. Запит, який працює з інтерактивної оболонки й відмовляє зі служби, — це знахідка про контекст монтування, і її варто записати до наступного інциденту, а не відкривати заново з нуля.