Каманда дасягае 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. Інакш наступны чалавек праверыць распазнавальнік хоста, убачыць працуючы адказ і зробіць выснову, што з прасторай імёнаў усё добра.

Пераправерце ўвесь шлях

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

Пераканайцеся, што файл атрымлівае працэс, а не абалонка. Запыт, які працуе з інтэрактыўнай абалонкі і зрываецца з сэрвісу, — гэта знаходка пра мантажны кантэкст, і яе варта запісаць да наступнага інцыдэнту, а не адкрываць нанова.

Падобныя артыкулы