Configuração de DNS separada em cada namespace de rede

Solução

Você pode usar ip netns execwith bashem vez de usar nsenter, ou seja:

ip netns exec [namespace name] bash

Isso permitirá que você entre em uma sessão de shell interativa onde os arquivos de configuração de rede específicos do namespace são automaticamente montados em seus locais padrão (globais) (sem afetar outras sessões).

Explicação

O seguinte é retirado da ip netnspágina de manual :

Para aplicativos que estão cientes de namespaces de rede, a convenção é procurar arquivos de configuração de rede global primeiro em **/etc/netns/**NAME/ e depois em /etc/ . Por exemplo, se você quiser uma versão diferente de /etc/resolv.conf para um namespace de rede usado para isolar sua vpn, você deve nomeá-la como /etc/netns/myvpn/resolv.conf .

O ip netns exec automatiza o manuseio dessa configuração, convenção de arquivo para aplicativos que não reconhecem o namespace da rede, criando um namespace de montagem e vinculando a montagem de todos os arquivos de configuração do namespace por rede em seu local tradicional em /etc.

Observe em particular a distinção entre aplicativos com reconhecimento de namespace de rede e aplicativos sem reconhecimento de namespace de rede .

As nsenterman pages , por outro lado, parecem não mencionar essa distinção (em particular, procurei pelas strings "aware", "resolv", ".conf" e "/etc" e não encontrei resultados). Isso parece sugerir que o nsenterutilitário não executa o mesmo tipo de manipulação automática de aplicativos que não reconhecem namespace.

Comentários adicionais

Além de Network Namespaces , você também pode querer olhar para User Namespaces e Mount Namespaces . E se você deseja mais isolamento além do DNS, também pode considerar a conteinerização, por exemplo, LXC Containers , Docker ou até mesmo uma VM completa.

Basta olhar para o que está fazendo ip netns exec test ...na sua situação, usando strace.

Excerto:

# strace  -f ip netns exec test sleep 1 2>&1|egrep '/etc/|clone|mount|unshare'|egrep -vw '/etc/ld.so|access'
unshare(CLONE_NEWNS)                    = 0
mount("", "/", 0x55f2f4c2584f, MS_REC|MS_SLAVE, NULL) = 0
umount2("/sys", MNT_DETACH)             = 0
mount("test", "/sys", "sysfs", 0, NULL) = 0
open("/etc/netns/test", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
mount("/etc/netns/test/resolv.conf", "/etc/resolv.conf", 0x55f2f4c2584f, MS_BIND, NULL) = 0

então, para reproduzir (parcialmente, por exemplo, /sysnão é tratado aqui) o que ip netns exec test ...está fazendo:

~# ip netns id

~# head -1 /etc/resolv.conf 
# Generated by NetworkManager

~# nsenter --net=/var/run/netns/test unshare --mount sh -c 'mount --bind /etc/netns/test/resolv.conf /etc/resolv.conf; exec bash'

~# ip netns id
test
~# head -1 /etc/resolv.conf 
# For namespace test
~#

Então está certo. nsentersozinho não é suficiente. unsharetem que ser usado, para mudar para um namespace de montagem recém-criado (baseando este novo em uma cópia do anterior) e alterá-lo, e não apenas usando textualmente um já existente, uma vez que ainda não existe nenhum que se encaixe. Isso é o que está fazendo o syscall com o mesmo nome que está dizendo strace.

As duas primeiras respostas fornecem boas informações e respostas, mas tentarei responder de um ângulo ligeiramente diferente.

Um namespace de rede fornece um local para colocar interfaces de rede, rotas e regras de roteamento de rede e entradas de filtro de rede.

Um namespace de montagem fornece um local para colocar arquivos. Esses arquivos podem estar relacionados à rede e podem ser usados ​​em um namespace de rede específico, mas no final são apenas arquivos.

A criação de um novo namespace de rede (por exemplo, com “ ip netns add newnetns”) não fornece automaticamente um novo namespace de montagem.

Se você usar o ip netns exec newnetns somecomandcomando “ ” então você criará um novo processo (somecommand) usando o novo namespace de rede (newnetns que você criou anteriormente) e também obterá um novo namespace de montagem criado para este processo. Você também obterá determinados arquivos vinculados montados nesse novo namespace de montagem (por exemplo , /etc/netns/newnetns/resolv.confem /etc/resolv.conf). Agora, ao usar “ ip netns exec” esses arquivos geralmente são relacionados à rede, como resolv.conf. No entanto, mesmo que esses arquivos estejam relacionados à rede e você provavelmente os tenha criado para usar com seu novo namespace de rede, eles não farão parte de seu novo namespace de rede. Quando seu processo (somecommand) terminar, o namespace de montagem que foi criado para ele também desaparecerá (a menos que por outros meios você tenha anexado outro processo ao mesmo namespace de montagem), mas o namespace de rede permanecerá.

Quando você usa o nsentercomando, ele coloca seu comando no namespace de rede de sua escolha, mas nsenternão cria um novo namespace de montagem como “ ip netns exec” faz.

Digno de nota é que “ ip netns add newnetns” cria um novo namespace de rede que está basicamente vazio. Você precisa adicionar interfaces ou rotas a esse novo namespace de rede. “ ip netns exec” que coloca um processo nesse namespace de rede, cria um novo namespace de montagem que é basicamente uma cópia do namespace de montagem principal (provavelmente mostrando seu sistema de arquivos principal), com apenas algumas montagens de ligação adicionadas a ele.

Também digno de nota é que a ip-netnspágina do manual menciona a convenção de arquivo que será usada em nome de aplicativos que não reconhecem o namespace da rede. Isso pode dar a impressão de que há um monte de aplicativos com reconhecimento de rede que usam a convenção de arquivo. /etc/netns/nsname/... Até onde sei, esse não é o caso. De cara, não consigo pensar em nenhum outro aplicativo que use os arquivos em /etc/netns/nsname/..., mas talvez haja.