Eu configurei uma infraestrutura de rede única com vários nós e OpenStack Folsom (2012.2). Tudo corre bem, as instâncias estão funcionando bem em qualquer nó de computação, a rede privada funciona como um encanto e todas as instâncias podem ser acessadas via IPs flutuantes do lado de fora e podem alcançar o exterior.
Mas, ao tentar executar uma solicitação de rede de uma VM para si mesmo por meio do IP flutuante, ela falha.
Nem o ping nem o ssh estão funcionando.
Os grupos de segurança estão todos abertos.
O ping funciona por meio de IPs flutuantes de uma VM para outra, mas o SSH não é .
Alguns dados para um exemplo
Entradas iptables (referentes a 10.1.100.4/10.0.0.13) no controlador (todos os serviços, incluindo rede):
-A nova-network-2.7-OUTPUT -d 10.1.100.4/32 -j DNAT --to-destination 10.0.0.13
-A nova-network-2.7-PREROUTING -d 10.1.100.4/32 -j DNAT --to-destination 10.0.0.13
-A nova-network-2.7-float-snat -s 10.0.0.13/32 -o eth0 -j SNAT --to-source 10.1.100.4
Entradas do iptables no nó de cálculo:
em relação a 10.1.100.4/10.0.0.13:
-A nova-compute-2.7-local -d 10.0.0.13/32 -j nova-compute-2.7-inst-143
sobre nova-compute-2.7-inst-143:
-N nova-compute-2.7-inst-143
-A nova-compute-2.7-inst-143 -m state --state INVALID -j DROP
-A nova-compute-2.7-inst-143 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A nova-compute-2.7-inst-143 -j nova-compute-2.7-provider
-A nova-compute-2.7-inst-143 -s 10.0.0.1/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A nova-compute-2.7-inst-143 -s 10.0.0.0/24 -j ACCEPT
-A nova-compute-2.7-inst-143 -p tcp -m tcp --dport 22 -j ACCEPT
-A nova-compute-2.7-inst-143 -p tcp -m tcp --dport 3389 -j ACCEPT
-A nova-compute-2.7-inst-143 -p tcp -m multiport --dports 1:65535 -j ACCEPT
-A nova-compute-2.7-inst-143 -p udp -m multiport --dports 1:65535 -j ACCEPT
-A nova-compute-2.7-inst-143 -p icmp -j ACCEPT
-A nova-compute-2.7-inst-143 -j nova-compute-2.7-sg-fallback
Qualquer sugestão de onde procurar o problema é bem-vinda. Claro que vou fornecer todos os dados necessários para resolver o problema. Atualmente, não tenho certeza de quais dados ajudariam.
Tilo,
Isso é capturado muito bem no link , e os patches estão em andamento para a nova ( link a partir de hoje (7 de janeiro de 2013).
A correção completa também inclui o bug 1096987 ( link ) e 1096985 ( link ) para cobrir os cenários de implantação mais comuns nos quais você está usando um gateway externo predefinido ou aproveitando os novos linux / iptables da nova rede configuração de ponte pública de rede.
Ok, eu encontrei o problema:
Todos os pacotes para Floating IPs (10.1.100.0/24 no meu caso) são DNATed para o destino da rede privada (10.0.0.0/24 no meu caso). Os pacotes ssh circulam pelo controlador e voltam para a VM. O servidor ssh responde, mas envia o pacote com seu endereço privado como fonte (é claro - não tem outro). Então o cliente ssh recebe um pacote de 10.0.0.13 como resposta a um pedido para 10.1.100.4 que ele ignora.
Bem, então ao enviar pacotes de Private para Floating IPs, não apenas o destino tem que ser NAT, mas também a fonte. Mas isso não é direto porque o DNAT está no PREROUTE enquanto o SNAT está no POSTROUTE. Isso pode ser feito usando o módulo de rastreamento de conexão:
iptables -t nat -A nova-network-2.7-float-snat -s 10.0.0.13/32 -d 10.0.0.0/24 -j SNAT --to-source 10.1.100.4 -m conntrack --ctstate DNAT
Isso fez o truque para mim (para cada IP flutuante, é claro). Ele manipula cada pacote de particular para privado que já estava DNATed (então deve ir para IP Flutuante), para fazer com que pareça vir de um IP Flutuante.
No meu cenário ssh agora acontece o seguinte:
Isso funciona também para ping e também para tráfego entre diferentes VMs.
Parece que tenho que corrigir o código da nova rede e enviá-lo para o projeto openstack: - /.