OpenVZ várias redes em CTs

5

Eu tenho o Hardware Node (HN), que tem duas interfaces físicas (eth0, eth1). Estou jogando com o OpenVZ e quero deixar meus contêineres (CTs) terem acesso a ambas as interfaces. Estou usando configuração básica - venet. CTs são bons para acessar eth0 (interface pública). Mas não consigo obter CTs para obter acesso a eth1 (rede privada). Eu tentei:

# on HN
vzctl set 101 --ipadd 192.168.1.101 --save
vzctl enter 101
ping 192.168.1.2 # no response here
ifconfig # on CT returns lo (127.0.0.1), venet0 (127.0.0.1), venet0:0 (95.168.xxx.xxx), venet0:1 (192.168.1.101)

Eu acredito que o principal problema é que todos os pacotes fluem através de eth0 no HN (descoberto usando o tcpdump). Então, o problema pode estar nas rotas em HN.

Ou minha lógica está errada? Eu só preciso acessar ambas as interfaces (redes) em HN de CTs. Nada complicado.

    
por user6733 18.04.2010 / 19:15

4 respostas

3

Mesmo problema, mas solução diferente. As duas portas não estavam conectadas à mesma rede e precisavam aparecer do endereço IP da máquina virtual, portanto, o mascaramento não funcionava.

A questão principal aqui é que o contêiner openvz configura a sub-rede de todos os ips na venet para 255.255.255.255. Não há preferência de uma interface. Não há preferência em qual roteador ele deve passar, por isso, às vezes, usa eth0 e, às vezes, usa eth1. O resultado foi uma falha aleatória de determinados endereços IP quando a solicitação foi finalizada na interface errada.

Uma solução foi adicionar uma rota que especificava a fonte assim:

ip route add 10.20.0.0/16 dev venet0 src 10.20.0.xxx
ip route add a.b.c.241/24 dev venet0 src a.b.c.xxx

Descobri que a solução mais simples, por enquanto, era configurar as sub-redes logo depois de terem sido criadas (em um contêiner do ubuntu / debian em /etc/network/if-up.d):

#!/bin/sh
if [ "$IFACE" = "venet0:1" ]; then
        ifconfig venet0:1 netmask 255.255.0.0 up
fi
if [ "$IFACE" = "venet0:0" ]; then
        ifconfig venet0:0 netmask 255.255.255.0 up
fi
exit 0

Ambas as soluções devem ter o mesmo efeito. Ambas as soluções me preocupam um pouco que, ao acessar a Internet (para atualizar ou para o DNS), ele possa inadvertidamente usar o endereço 10.x.x.x que não tem rota para a Internet. A rota padrão é default via 192.0.2.1 dev venet0 , então não tenho certeza de como ela chega lá, mas parece funcionar como planejado após várias reinicializações do contêiner e do host.

UPDATE Para uma solução mais robusta: usei o bash para verificar o IP e descobrir em qual sub-rede adicioná-lo.

Ubuntu / Debian (/etc/network/if-up.d):

#!/bin/bash
if [ "${IF_ADDRESS:0:6}" = "xx.yy." ]; then
        echo "AlReece45: $IFACE, IP Address $IF_ADDRESS marked as internal"
        ifconfig "$IFACE" netmask 255.255.0.0 up
fi
if [ "${IF_ADDRESS:0:11}" = "xxx.yy.zzz." ]; then
        echo "AlReece45: $IFACE, IP address $IF_ADDRESS marked as external"
        ifconfig "$IFACE" netmask 255.255.255.0 up
fi
exit 0

CentOS / Redhat (/ sbin / ifup-local):

#!/bin/bash
IFACE="$1"
IF_ADDRESS=$(ifconfig $IFACE | grep "inet addr" | awk '{print $2}' | cut -d':' -f2);
if [ "${IF_ADDRESS:0:6}" = "xx.yy." ]; then
        echo "AlReece45: $1, IP Address $IF_ADDRESS marked as internal"
        ifconfig "$1" netmask 255.255.0.0 up
fi
if [ "${IF_ADDRESS:0:11}" = "xxx.yy.zzz." ]; then
        echo "AlReece45: $1, IP address $IF_ADDRESS marked as external"
        ifconfig "$1" netmask 255.255.255.0 up
fi
exit 0
    
por 26.05.2010 / 20:15
2

O problema estava entre a cadeira e o teclado. Eu não definiu o mascaramento no outro dispositivo. Então, para todos com o mesmo problema: tente definir o baile de máscaras em todas as interfaces da HN.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE # I forgot this line

Eu percebi isso graças a: Wiki do OpenVZ

    
por 18.04.2010 / 19:44
1

Recentemente, configurei um servidor OpenVZ com dois adaptadores de rede Ethernet, cada um em sua própria sub-rede, mascarando-se no HN.

Descoberto o seguinte: Se um CT tiver dois IPs em diferentes sub-redes, o primeiro IP a ser configurado no arquivo vzid.conf deve ser aquele que compartilha o gateway padrão com o HN. Mudar a ordem dos IPs e reiniciar o CT resolveu o problema de roteamento para mim.

    
por 24.02.2011 / 16:07
0

Eu tenho a mesma configuração, com duas sub-redes diferentes em dois nic diferentes no meu HN.

Eu tenho observado que cada primeiro venet0 funciona bem, mas se o segundo venet0:1 puder receber, eles parecem ter dificuldade em encontrar uma rota para a minha segunda sub-rede.

O engraçado: eu poderia ssh para o meu host virtual, a partir da segunda sub-rede (comming desktop 10.24.14.21 formulário para o meu host virtual: 10.24.14.24), mas isso não vai funcionar:

 # ping ${SSH_CONNECTION%% *} 
 PING 10.24.14.21 (10.24.14.21) 56(84) bytes of data.

Ok, eu preciso fazer algo sobre venet0:1 , algo assim parece fazer o trabalho:

 # vzctl exec 777 ip address delete 10.24.14.24/32 dev venet0 label venet0:1
 # vzctl exec 777 ip address add    10.24.14.24/24 dev venet0 label venet0:1

Bem, de lá eu escrevi este litte workaround-venet-netmask.sh :

#!/bin/bash

(
    export NEWMASK=24      # 255.255.255.0
    export IFACE=venet0:1
    export IP1
    while IP1=$(
        ip address show dev ${IFACE%*} label $IFACE |
            sed -ne "s/^.*inet \([0-9.]\+\)\/32 .*$IFACE//p"
      ); ! [ "$IP1" ] ;do
        sleep 1
      done
    ip address delete $IP1/32 dev ${IFACE%*} label $IFACE
    ip address add $IP1/$NEWMASK dev ${IFACE%*} label $IFACE
) </dev/null >/dev/null 2>&1 &

Do que eu fiz um symlink para este script, para cada VE.start necessário (por enquanto, este script está localizado em /etc/vz/conf/workaround-venet-netmask.sh .):

# ln -s workaround-venet-netmask.sh 777.start
# ln -s workaround-venet-netmask.sh 10001.start
# ln -s workaround-venet-netmask.sh 10012.start

Por enquanto, isso parece funcionar bem, para mim. Na esperança de que isso possa ajudá-lo.

    
por 01.11.2012 / 11:07