Alcance o contêiner LXC de um guest virtualbox no mesmo host

Question

Contexto

• Eu desenvolvo sites no meu laptop Ubuntu (Ubuntu 13.04 64b).
• Cada site é executado em um contêiner LXC dedicado¹ na rede 10.0.3.x
• Às vezes, preciso acessar esses sites a partir de um convidado de uma caixa virtual executando o Windows²

Ele costumava funcionar "fora da caixa", mas há algumas semanas, ele simplesmente parou. Eu acho que depois de uma atualização do Ubuntu, mas era um LXC ou um Virtualbox ou até mesmo uma atualização de "coisas de rede"? Eu não posso dizer desde que eu não corro esses testes todos os dias.

¹ Para falsificar plataformas diversas e complexas e usar apenas recursos que realmente preciso.

² Para testá-los em navegadores do Windows.

A pergunta:

Como devo configurar minhas configurações de rede Virtualbox / LXC / host para acessar os sites nos contêineres LXC do convidado do Virtualbox?

O que eu fiz até agora

Minha configuração atual de virtualbox é ter duas placas de rede.

• Uma ponte sobre wlan0 (para acessar a Internet)
• Uma ponte no cartão virtual LXC lxcbr0 (para acessar os contêineres)

A Weird thing : I can ping LXC containers from the Windows VM, but I can't access them in HTTP (browsers or telnet on port 80).

Only actually started containers responds to ping.

Eu tentei um monte de outras configurações, mas estou mais "adivinhando" do que entendendo o que está acontecendo.

Meu trabalho atual

Eu configurei uma porta para a frente no meu host com o iptables, como eu faria para tornar um contêiner acessível em toda a rede (na verdade é o que ele faz).

Quando faço isso, posso alcançar o contêiner encaminhado da VM do Windows.

Mas isso definitivamente não é uma solução limpa:

• só posso acessar um contêiner no momento (ou preciso usar portas diferentes)
• Eu preciso reconfigurar iptables toda vez que eu alternar o projeto
• Eu realmente dou acesso ao contêiner para o mundo exterior
• Eu preciso ter uma conexão LAN ou WAN ativa
• Eu mal posso mais usar nomes de domínio (eu tenho um arquivo host no ip do contêiner correspondente do Windows)

Answer 1

Seguindo a sugestão do user228273, encontrei a configuração que resolveu o problema: Primeiro, criei uma interface de toque chamada tap0 e apresentei:

ip tuntap add mode tap tap0
ip link set tap0 up

se um dos comandos anteriores falhar, provavelmente é porque você já tem uma interface tap0 . Use o comando

ip link show

para avaliar a situação e, eventualmente, alterar o nome da interface. Agora você pode adicionar a interface tap0 à ponte padrão que, no Ubuntu, tem o nome lxcbr0 .

brctl addif lxcbr0 tap0

Em seguida, configurei meu VirtualBox para usar um "Adaptador em ponte" na interface tap0 , conforme mostrado abaixo:

EainstânciadoVirtualBoxeosLXCspodem"ver" uns aos outros.

N.B. Todos os comandos anteriores devem ser executados como administrador.

    

Answer 2

Tive exatamente o mesmo problema. Quase certamente a "falha" do VirtualBox, que parece fazer uma ponte de rede é o seu próprio caminho, provavelmente para permanecer consistente em várias plataformas (Mac, Solaris e aquele outro). Evidências:

• Interfaces de rede em ponte VBox não aparecem em "brctl show" (como o LXC veth's)
A documentação
• possui: "O VirtualBox usa um driver de dispositivo em seu sistema host que filtra dados de seu adaptador de rede físico"

Realmente estranho que o ICMP esteja passando, mas o TCP (e provavelmente outros) não é ...

No entanto, a documentação também tem "você ainda pode usar interfaces TAP para determinadas configurações avançadas", então eu investiguei a anexação de um novo TAP à minha ponte:

# ip tuntap add mode tap
# brctl addif brY tapX
# ip link set tapX up

Em seguida, ajustei as configurações de rede VBox para usar tapX em vez de brY e tudo veio bem (depois de reiniciar o convidado).

Experimentou dois convidados compartilhando o mesmo tapX, não tendo certeza de que funcionou tão bem. Provavelmente, é mais seguro usar um toque para cada convidado da VBox.

    

Answer 3

Se você puder fazer ping no alvo, mas não puder acessar os aplicativos lá, então é um problema do iptables, quase certo.

Meu palpite é que durante o processo de atualização você tem o sinalizador do sistema "net.bridge.bridge-nf-call-iptables = 1" marcado como ON em /etc/systcl.conf .

Se assim for, eu não a deixaria OFF, mas revise a configuração do iptables.