Em um servidor de gateway, o netNS pode limitar um proc apenas para ver as redes internas?

Question

Eu posso estar usando a ferramenta errada, mas os namespaces de rede parecem um ajuste quase ideal.

Eu tenho 3 programas que não têm a capacidade de especificar uma interface de escuta ou endereço (que ouve apenas em "0.0.0.0"). Eu quero colocar esses serviços em um netns onde eles só vêem os endereços internos (ou seja, 192.168.3.0/24), impedindo-os de ouvir o tráfego externo.

Eu criei um netns chamado 'Local' e criei um veth para dividir os ns principais e locais, como:

ip link add veth1 type veth peer name vpe1

Eu escravizei veth1 a uma ponte local (br0) junto com outras duas interfaces físicas. "brctl show br0" agora mostra 3 interfaces: eth0, eth5 e veth1.

Em seguida, defino o IP da vpe1 para "129" na rede local. Testes mostraram que eu era capaz de pingar de outros hosts e de um shell bash no Local-ns, eu era apenas capaz de fazer ping de hosts na rede local.

No entanto , os progs (um deles sendo xinetd) servem para atender chamadas no endereço de rede local do servidor (o addr de ponte de 192.168.3.1). Ter um IP diferente no namespace 'local-only' não funciona para que eles respondam aos serviços no 'servidor'.

Tentando algumas outras opções - primeiro tentei fornecer o mesmo nome de host para o IP para 'vpe1' dentro de seu namespace, depois tentei dar o mesmo IP ... nada funcionou ou teve um efeito.

Conceitualmente, pensei em ter um sub-netns duplicando o espaço do nome principal e, em seguida, descarte a interface externa a partir dela - deixando esses procs vendo apenas a interface local e as solicitações de serviço, como antes, quando viam todas as interfaces (e não estavam em um namespace).

Enquanto isso parece ser um local ideal para um espaço de nomes separado para dar uma visão lógica diferente das interfaces do servidor para um grupo de processos, eu não estou vendo como fazer com que os netns simplesmente forneçam "view" diferente (para usar 'bind / named-speak') para aqueles "clientes".

Isso é possível com namespaces de rede do linux? Ou o que eles estão perdendo que poderia permitir isso? Se este tipo de "seccionamento" não é fornecido por namespaces, é possível fornecê-lo sem muito roteamento de iptable para simular os client-progs no namespace principal?

Obrigado!     A ☆ a

    

Answer 1

Namespaces de rede Linux são, simplesmente, pilhas IP isoladas. Esquecendo-se de coisas virtuais como namespaces de rede, pergunte-se: como resolvo minha tarefa usando roteadores, hosts, caixas de pontes e cabos Ethernet? Se você tem sua configuração física, então ela se traduz quase naturalmente em seu gêmeo virtual. Mas não se esqueça das regras de filtragem de pacotes, elas podem ser fundamentais.

Eu não entendo totalmente qual é a sua tarefa realmente. Mas uma coisa chama minha atenção, porque pode não ser o que você quer: uma ponte na qual você conecta interfaces de rede físicas, assim como um cabo veth em outro namespace de rede (pilha de IP). Isso significa acesso total da camada 2 a qualquer pessoa, por causa da ponte. Endereços IP não são importantes neste nível. Você concede acesso total à rede direta a um namespace de rede separado. Isso não é errado em si (na verdade, eu pessoalmente conheço algumas situações extremamente úteis), mas é isso que você quer no seu caso?