Ponte Linux não responde aos pacotes arp

3

Estou tentando configurar um cenário de teste com relação a pontes Linux para as quais eu preciso de uma pilha IP virtual completa. Basicamente, gostaria de simular a rede entre uma VM (ou container) e seu host, sem uma VM, ou seja, a camada de virtualização.

O lado do host é uma ponte ( br0 ) com um endereço IP configurado (o padrão gw da VM simulada), como visto em outras configurações de KVM em funcionamento. Eu tentei simular o lado da VM da conexão da seguinte forma:

  • usando uma interface tap (conexão OpenVPN com outro servidor, ping de lá)
  • um par veth com uma extremidade configurada com um endereço IP e a outra anexada à ponte
  • um segundo bridge com um endereço IP conectado à ponte principal via veth par

Em nenhuma dessas configurações, consegui fazer ping na bridge de host (o gw padrão das VMs). Em todas as configurações, o problema era o mesmo: a interface da bridge não respondia aos pacotes ARP.

configuração (local veth):

    +-----+
    | br0 |
    |     | +------+    +------+
    |     ==| vip1 |<-->| vip2 |
    +-----| +------+    +------+

    br0:  type=bridge, UP, 172.16.1.1/24
    vip1: type=veth, UP
    vip2: type=veth peer, UP, 172.16.1.2/24

    # brctl addbr br0
    # ifconfig br0 172.16.1.1 netmask 255.255.255.0 up
    # ip link add vip1 type veth peer name vip2
    # ifconfig vip2 172.16.1.2 netmask 255.255.255.0 up
    # brctl addif br0 vip1
    # ifconfig vip1 up

Agora estou tentando ping o br0 de vip2 :

    # [root@host ~]# ping -I vip2 172.16.1.1
    # PING 172.16.1.1 (172.16.1.1) from 172.16.1.2 vip2: 56(84) bytes of data.
    # ^C
    # --- 172.16.1.1 ping statistics ---
    # 2 packets transmitted, 0 received, 100% packet loss, time 1493ms

tcpdump na ponte:

    # [root@host ~]# tcpdump -i br0
    # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    # listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
    # 23:14:02.367624 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
    # 23:14:03.367657 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
    # 23:14:04.367345 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
    # ...

O que é bastante estranho, já que a interface br0 na qual esses pacotes chegam é UP e deve responder às solicitações ARP.

    # [root@host ~]# ifconfig br0
    # br0       Link encap:Ethernet  HWaddr F6:F3:5A:A7:A2:5B
    #           inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
    #           inet6 addr: fe80::f4f3:5aff:fea7:a25b/64 Scope:Link
    #           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    #           RX packets:53 errors:0 dropped:0 overruns:0 frame:0
    #           TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
    #           collisions:0 txqueuelen:0
    #           RX bytes:1580 (1.5 KiB)  TX bytes:360 (360.0 b)

Eu tentei:

  • Interface de toque OpenVPN (ping de outro host através do OpenVPN para que o pacote chegue à interface de toque vs. interface veth)
  • outra ponte ( br1 ), usando um par veth para conectar as duas pontes
  • definindo net.ipv4.conf.all.arp_filter e outros, mas nada parece ter efeito
  • iptables e ebtables estão vazios e ACEITAM tudo.

Por isso, estou tentando descobrir por que isso não está funcionando e qual é a diferença para as soluções de contêiner ou virtualização. Qualquer ajuda é muito apreciada!

Obrigado!

    
por grasbueschel 27.12.2014 / 00:26

0 respostas