Ter rede em ponte para contêineres lxc na Amazon ec2

Question

Estou tentando configurar contêineres LXC no topo da Amazon. Eu sou muito novo para Amazon e VPC especialmente. Na verdade, criei o VPC pela primeira vez para experimentar o lxc.

Minha meta : meu objetivo é ter contêineres lxc em instâncias da Amazon e tê-los na rede de tipo de ponte. Isso significa que eu deveria ser capaz de atribuir ips públicos ou ips privados a outros contêineres amazon instances / lxc, como na LAN física. Para isso eu tenho tentado virsh (libvirt) com rede de bridge. Com isso, nunca consegui o que queria.

O que eu fiz : criei uma VPC com sub-rede única (pública). Lançou uma instância debian nela. Instalou o LXC e conseguiu atingir o modo nat e o modo de rota. Mas isso me deu 192.168.122.0 (padrão lxc) endereços IP. Mas consegui colocar a internet nos contêineres com algumas regras de iptable. Depois de tentar com o libvirt, manualmente criando bridge usando bridge-utils, não tive sorte em atribuir um IP ao container. Minha suposição é que o contêiner deve obter uma concessão de DHCP do serviço DHCP da Amazon. Por fim, associei outro IP elástico à instância debian e memorizei seu ip privado nado. Depois disso, criei uma ponte simples e adicionei eth0 à ponte no host. Em seguida, criei uma rede host-bridge simples usando o libvirt. E na configuração lxc codificado no ip nated i memorizado. Então eu comecei o contêiner lxc. O contêiner poderia obter o ip nado nele. Eu poderia ssh para ele do host. Mas eu não estou recebendo internet nesse contêiner.

/ etc / network / interfaces (host)     auto lo     iface lo inet loopback     auto eth0     iface eth0 inet manual

auto br0
iface br0 inet dhcp
    bridge_ports eth0
    bridge_fd 0
    bridge_maxwait 0

host-bridge virsh net-dumpxml

 <network>
 <name>host-bridge</name>
 <uuid>7c41e4ce-311c-c78f-5ea3-a03a224e4a3c</uuid>
 <forward mode='bridge'/>
 <bridge name='br0' />
 </network>

arquivo de configuração lxc

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
#lxc.network.name = eth0
lxc.network.ipv4 = 10.0.0.207/24(natted memorized ip)

arquivo de interfaces do contêiner     auto lo     iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.0.0.207
netmask 255.255.255.0
gateway 10.0.0.1

Minhas perguntas :

1. Qual VPC devo escolher para esse cenário?
2. Qual modo de rede facilita meu trabalho?
3. No mínimo, com o que consegui, como posso acessar a Internet ao contêiner?
4. Sem o Elastic IP, não posso ter um IP privado na mesma sub-rede que pode ser acessado por outras instâncias e contêineres?

Answer 1

A Amazon não suporta endereços IP dinâmicos para servidores dentro do VPC. O único endereço IP que é atribuído quando um servidor é iniciado é o único que você pode enviar com e receber da rede. Apenas adicionando dinamicamente os servidores de contêineres do LXC a uma instância e assumindo que a interligação em rede pode fazer com que ela funcione, isso não acontecerá. A rede IP da Amazon é uma rede para fins especiais para roteamento entre instâncias e não imita uma sub-rede ethernet comum - a maioria dos recursos que você esperaria de uma não funciona.

Se você precisar desses recursos, existe a possibilidade de configurar uma sub-rede de rede virtual sobre os endereços IP da Amazon - usando algo como o tunelamento GRE, VDE (virtual distributed ethernet) ou OpenVPN.

No entanto, se você fizer isso exclusivamente com o Amazon Network, tentarei explicar suas opções.

Os endereços IP elásticos funcionam para que o endereço IP privado permaneça o mesmo, mas há um NAT um para um acontecendo com o endereço IP elástico se (e somente se) o endereço for roteado para o gateway da Internet.

Há também a possibilidade de remover a verificação de origem e destino da interface de rede da instância, que geralmente é feita para roteadores. É possível que o uso dele permita que vários servidores residam em uma instância, mas parece duvidoso, pois não acredito que a Amazon roteasse as solicitações ARP para o servidor, mesmo nesse caso.

Atualmente, o Amazon VPC oferece suporte a várias interfaces por instância (até 2) e vários endereços IP por instância (até 8). Isso é algo que você pode usar se estiver disposto a configurar a instância toda vez que adicionar um servidor. Os endereços são simplesmente endereços adicionais, a comunicação é permitida como na interface virtual da instância. Não há suporte DHCP para eles, portanto, você precisa configurar manualmente os endereços IP depois de adicioná-los ao seu servidor a partir do console de gerenciamento. A maneira normal de usá-los é simplesmente usar "ip addr add" para adicionar vários endereços IP à mesma interface, mas não vejo nenhuma razão aparente para que usar a ponte e passar os endereços para diferentes interfaces não funcionasse tão bem. / p>     

Answer 2

Eu tenho a mesma necessidade e posso encontrar uma maneira de fazer isso.

Minha configuração é:

Cartão eth1 adicional com HWaddr 02:5f:fc:b3:0b:b9 e vários IPs 10.2.132.61 para '10 .2.132.64 '

Eu quero usar o bridging e compartilhar o mesmo NIC para dar a cada um dos meus contêineres um dos IPs configurados para essa interface.

Minha primeira tentativa foi criar um br0 on eth1 e depois usar essa configuração

lxc.network.type = veth                
lxc.network.hwaddr = 02:5f:fc:b3:0b:b9 
lxc.network.flags = up                 
lxc.network.link = br0

O problema aqui é que quando você inicia o container, o dhcp receberá pacotes de 02:5f:fc:b3:0b:b9 (a ponte externa) indo para sua interface que tem o mesmo HDaddr, e ele irá reclamar com:

 kernel: [16809131.333956] br0: received packet on vethVIAEYB with own address as source address

A solução que encontrei é alterar o MAC da interface externa ( br0 e eth1 no host) para um aleatório. Desta forma, iniciando o contêiner é capaz de obter as informações DHCP imediatamente!

Então eu fiz

sudo ifconfig eth1 down
sudo ifconfig eth1 hw ether 00:80:48:BA:d1:30
sudo ifconfig br0  hw ether 00:80:48:BA:d1:30
sudo ifconfig eth1 up

Em seguida, reiniciar o contêiner fez o truque!

Agora está trabalhando com o DHCP. Para usar os outros IPs registrados para essa interface, obviamente, terei que confiar na configuração estática do IP no arquivo CONTAINER / config.