Спільне використання мережі контейнера VPN: що відбувається з DNS

Спільне використання мережевого простору імен контейнера VPN дає застосунку інтерфейси й маршрути тунелю. Воно не дає йому резолвер тунелю, ні об’єднану копію будь-чого іншого на хості. Ця прогалина породжує дуже конкретну відмову: публічні імена розв’язуються, внутрішні ні, а застосунок, що падає, виглядає так, ніби використовує неправильний DNS-сервер, бо так і є. Виправлення зазвичай менше, ніж припускає діагностика.

Крок 1: Перевіряйте із застосунку, а не з хоста

Виконайте пошук усередині контейнера, який має проблему, а не на хості й не в браузері. docker exec app-container getent hosts db.internal відповідає на єдине важливе питання: що повертає резолвер цього процесу.

Якщо хост розв’язує ім’я, а контейнер ні, ви знайшли несправність. Усе подальше — вибір підтримуваного способу її виправити.

Крок 2: Прочитайте підтримувану модель середовища виконання

Документація Docker щодо мереж фіксує обмеження на прапорці DNS для контейнерів, які спільно використовують мережевий режим іншого контейнера. У Compose network_mode: service:vpn прив’язує застосунок до простору імен контейнера VPN, а для кожної служби dns налаштування поводяться не так, як у звичайній службі. Рішення, яке ви отримуєте, — це те, що має спільний простір імен.

Визначені користувачем мостові мережі також використовують вбудований DNS Docker інакше, ніж типовий міст. Тому dns блок, скопійований із робочого прикладу моста, може взагалі нічого не робити в спільному стеку. Перевірте схему, перш ніж копіювати блок.

Адреса петлі завжди стосується відповідного мережевого контексту. Усередині спільного простору імен 127.0.0.1 не є резолвером хоста.

Крок 3: Простежте запит до його отримувача

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

Сторінка перевірки IP у браузері не може сказати, куди пішли запити імен. Вона каже, куди пішло одне HTTP-з’єднання.

Крок 4: Виправляйте два класи відмов по-різному

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

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

Крок 5: Повторно перевірте після перестворення

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

Запишіть власника резолвера й очікуваний простір імен поряд із визначенням спільної мережі. Наступній людині знадобиться і те, і те.