Супольнае выкарыстанне сеткі кантэйнера 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 унутры кантэйнера знікае пры перастварэнні і пераканае вас, што выпраўленне спрацавала, калі яно не спрацавала.

Запішыце ўладальніка рэзалвера і чаканую прастору імёнаў побач з вызначэннем агульнай сеткі. Наступнаму чалавеку спатрэбяцца абодва.