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 stub или симболичка врска што покажува кон место со поинаква достапност.

Што всушност монтира exec помошникот

Алатката ip-netns документира конфигурација по простор на имиња под /etc/netns/NAME/. Кога стартува процес, помошникот создава простор на имиња за монтирање и ги монтира тие датотеки врз нивните вообичаени патеки, па процесот ја гледа копијата специфична за просторот на имиња. Тоа е погодност на овој конкретен стартер. Влегувањето во мрежен простор на имиња по друг пат, како unshare или контејнерски runtime, не го репродуцира тоа автоматски.

Разрешувачот на loopback е стапицата овде: 127.0.0.53 значи сопствениот loopback на просторот на имиња, а не stub на домаќинот. Stub што слуша само во просторот на имиња на домаќинот не станува услуга во новиот.

Изберете разрешувач до кој просторот на имиња може да стигне

Кој и да е серверот што го наведува датотеката, на него и понатаму му треба рута од тој простор на имиња. Јавниот разрешувач може да одговара на јавни имиња, а сепак да не успее за внатрешна зона, зашто приватната услуга е достапна само преку тунелот. Проверете ја рутата истовремено со адресата, а не откако пребарувањето веќе не успеало.

Апликациите со сопствен разрешувач, како онаа што користи DNS over HTTPS, можат целосно да ја игнорираат датотеката. Ако алатката има сопствено DNS поставување, менувањето на resolv.conf нема да влијае на неа, а просторот на имиња никогаш не бил проблемот.

Запишете ја датотеката на правилното место

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

Запишете ја содржината на датотеката во runbook. Инаку следната личност ќе го тестира разрешувачот на домаќинот, ќе види одговор што работи и ќе заклучи дека просторот на имиња е во ред.

Тестирајте ја целата патека повторно

Тестирајте во просторот на имиња со нумеричка адреса, внатрешно име и јавно име. Таа секвенца ја одделува достапноста од разрешувањето и ги одделува внатрешните зони од јавните. Потоа пресоздајте го просторот на имиња и повторете, зашто датотека што постои само во инстанца што работи исчезнува со неа.

Потврдете дека датотеката ја прима процесот, а не лушпата. Пребарување што работи од интерактивна лушпа и не успева од услуга е наод за контекстот на монтирање, и вреди да се запише пред следниот инцидент наместо да се открива одново од нула.