ip netns exec и DNS: защо имената не работят в пространството от имена

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

Това е проблем с избора на файл, а не проблем с маршрутизацията, и точно затова цифровият адрес все още работи.

Проверете изгледа на преобразувателя, който процесът действително получава

Не приемайте, че обвивката, която сте използвали, е еквивалентна на процеса, който отстранявате. Графично приложение, systemd unit и контейнер могат всеки да влезе в различен контекст на монтиране или на мрежа. Изпълнете заявката през същия път за стартиране и отпечатайте файла на преобразувателя отвътре.

За пространство от имена, създадено с ip netns add, проверката само за четене е кратка:

ip netns exec vpn cat /etc/resolv.conf

Отбележете дали резултатът посочва достъпен адрес, loopback stub или символна връзка, която сочи към място с различна достъпност.

Какво всъщност монтира помощникът exec

Инструментът ip-netns документира конфигурация за всяко пространство от имена под /etc/netns/NAME/. Когато стартира процес, помощникът създава пространство за монтиране и монтира тези файлове върху обичайните им пътища, така че процесът вижда копието, специфично за пространството от имена. Това е удобство на точно този стартер. Влизането в мрежово пространство от имена по друг начин, например чрез unshare или среда за изпълнение на контейнери, не възпроизвежда това автоматично.

Преобразувателят на loopback е капанът тук: 127.0.0.53 означава собствения loopback на пространството от имена, а не stub на хоста. Stub, който слуша само в пространството от имена на хоста, не става услуга в новото.

Изберете преобразувател, до който пространството от имена има достъп

Който и сървър да посочва файлът, той все още се нуждае от маршрут от това пространство от имена. Публичният преобразувател може да отговаря за публични имена и пак да се проваля за вътрешна зона, защото частната услуга е достъпна само през тунела. Проверявайте маршрута едновременно с адреса, а не след като заявката вече се е провалила.

Приложенията със собствен преобразувател, например такова, което използва DNS over HTTPS, може напълно да пренебрегнат файла. Ако инструментът има собствена настройка за DNS, промяната на resolv.conf няма да му повлияе и пространството от имена никога не е било проблемът.

Запишете файла на правилното място

Създайте файла за пространството от имена под /etc/netns/NAME/resolv.conf и оставете стартерът да го представи. Дръжте го минимален: един или два достъпни сървъра и домейните за търсене, които задачата изисква. Не редактирайте генерирания файл на преобразувателя на хоста, за да поправите изглед, предназначен за една група процеси, защото това променя всяко приложение на машината. Ако хостът използва мениджър на преобразувателя, конфигурирайте пътя на пространството от имена през този мениджър, вместо да се борите с него.

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

Тествайте отново целия път

Тествайте вътре в пространството от имена с цифров адрес, вътрешно име и публично име. Тази последователност разделя достъпността от преобразуването и разделя вътрешните зони от публичните. След това пресъздайте пространството от имена и повторете, защото файл, който съществува само в работещ екземпляр, изчезва с него.

Уверете се, че файлът получава процесът, а не обвивката. Заявка, която работи от интерактивна обвивка и се проваля от услуга, е находка за контекста на монтиране и си струва да бъде записана преди следващия инцидент, вместо да се преоткрива от нулата.