As respostas ping para IPs flutuantes não alcançam o roteador (iptables / nat)

3

Estou executando o OpenStack e estou com problemas para acessar minhas instâncias a partir de IPs flutuantes, de qualquer lugar, exceto do nó do controlador de rede.

Eu tenho uma implantação do Folsom com o FlatDHCP, não executando multi-host, rodando no Ubuntu 12.04.

Como exemplo, aqui está uma instância em execução com um IP fixo de 10.40.0.2 e um IP flutuante de 10.20.0.3:

$ nova list
+-------+---------+--------+------------------------------+
| ID    | Name    | Status | Networks                     |
+-------+---------+--------+------------------------------+
| 3d292 | quantal | ACTIVE | private=10.40.0.2, 10.20.0.3 |
+-------+---------+--------+------------------------------+

Se eu estiver conectado ao controlador, posso fazer ping e ssh na instância da VM a partir de qualquer um dos IPs. No entanto, não consigo fazer ping ou ssh para a instância de uma máquina externa.

Se eu tentar fazer ping do meu laptop (192.168.3.8), e fizer um tcpdump na interface pública (eth3), posso ver a solicitação e responder:

# tcpdump -i eth3 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 65535 bytes
17:26:54.004746 IP 192.168.3.8 > 10.20.0.3: ICMP echo request, id 47116, seq 0, length 64
17:26:54.005383 IP 10.20.0.3 > 192.168.3.8: ICMP echo reply, id 47116, seq 0, length 64

No entanto, os pacotes de resposta do ICMP não retornam ao meu laptop. Na verdade, se eu fizer login no roteador / firewall (Cisco ASA 5500), ele não verá os pacotes de resposta do ICMP se eu fizer uma captura de pacote. No entanto, não parece estar filtrando os pacotes. É como se eles simplesmente não alcançassem o ASA. Eu também não consigo pingar a interface 10.20.0.3 do ASA.

O controlador está conectado diretamente ao ASA, portanto, o problema parece estar no nó do controlador ou no ASA.

Mesmo que o tcpdump mostre os pacotes de resposta saindo, é possível que eles estejam sendo descartados em vez de deixar o controlador? Se sim, isso seria por causa do iptables, ou devido a alguma outra coisa?

A saída do iptables-save está em um githubist.

$ ip addr show eth3
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 33:44:55:66:77:88 brd ff:ff:ff:ff:ff:ff
    inet 10.20.0.2/24 brd 10.20.0.255 scope global eth3
    inet 10.20.0.3/32 scope global eth3
    inet 10.20.0.4/32 scope global eth3
    inet 10.20.0.5/32 scope global eth3
    inet6 fe80::6273:5cff:fe68:b4b7/64 scope link
       valid_lft forever preferred_lft forever
    
por Lorin Hochstein 02.04.2013 / 23:34

1 resposta

2

Pode ser necessário configurar algumas regras de segurança conforme descrito [aqui] ( link }.

You must configure security group rules depending on the type of plugin you are using. If you are using a plugin that:

Implements OpenStack Networking security groups, you can configure security group rules directly by using neutron security-group-rule-create. The following example allows ping and ssh access to your VMs.

 $ neutron security-group-rule-create --protocol icmp --direction ingress default
 $ neutron security-group-rule-create --protocol tcp --port-range-min 22 --port-range-max 22 --direction ingress default

Does not implement OpenStack Networking security groups, you can configure security group rules by using the nova secgroup-add-rule or euca-authorize command. The following nova commands allow ping and ssh access to your VMs.

$ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
$ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0

Você também pode configurar as regras por meio da interface da Web do Horizon.

    
por 26.08.2013 / 02:06