Pacotes não recebidos ao executar o IPv6 através de uma ponte

Question

Eu tenho uma configuração com duas interfaces de rede: eth0 e tap0 , vinculadas por br0

bridge name     bridge id               STP enabled     interfaces
br0             8000.************       no              eth0
                                                        tap0

Nem eth0 nem tap0 têm um endereço IP além do IPv6 local de eth0 :

2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet6 fe80::XXXX:XXXX:XXXX:XXXX/64 scope link 
       valid_lft forever preferred_lft forever
41: tap0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc fq_codel master br0 state DOWN group default qlen 100
    link/ether YY:YY:YY:YY:YY:YY brd ff:ff:ff:ff:ff:ff

A ponte, no entanto, tem um endereço IPv4 estático e um endereço IPv6 configurado sem estado. Como preciso que esse endereço IPv6 sem estado seja configurado se fosse para eth0 , configurei o MAC de tap0 para ser maior que o de eth0 (assim, o brctl escolherá eth0 MAC como br0 MAC). Como resultado, o endereço IP que br0 atribui a si mesmo é o mesmo que eth0 escolheria sem outras interfaces.

Observe que as extensões de privacidade estão desativadas (em all e em qualquer interface específica).

Portanto, br0 é assim:

42: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet 192.168.X.Y/24 brd 192.168.X.255 scope global br0
        valid_lft forever preferred_lft forever
    inet6 ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ/64 scope global 
        valid_lft 7123sec preferred_lft 3523sec
    inet6 fe80::ZZZZ:ZZZZ:ZZZZ:ZZZZ/64 scope link 
       valid_lft forever preferred_lft forever

Portanto, há um endereço IPv6 público e um local e o público corresponde ao MAC (como é escolhido pelo stateless). Quando eu agora envio pacotes ICMPv6, eu não recebo uma resposta:

PING google.com(2a00:1450:4001:80e::1008) 56 data bytes
^C
--- google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

No entanto, ao verificar com o tcpdump, vejo pacotes sendo enviados e respostas chegando entre o servidor e meu IP, ou seja, eu realmente vejo a resposta no dump de pacote e ele é endereçado ao endereço IPv6 de br0 . Eu tentei especificar cada interface com ping6 -I <interface> sem sucesso.

Então, agora estou sem idéias: envio pacotes, recebo uma resposta sobre o endereço correto, mas ainda assim o sistema parece estar soltando-o em vez de aceitá-lo. Por que isso é descartado? Isso pode ser depurado?

Editar : tenho rotas IPv6 executando ip -6 route yields:

XXXX:XXX:XXXX:XXXX::/64 dev br0  proto kernel  metric 256  expires 6997sec
fe80::/64 dev br0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via fe80::XXX:XXXX:XXXX:XXXX dev br0  proto ra  metric 1024  expires 1597sec

A primeira linha é o prefixo atribuído pelo ISP, conforme relatado no meu roteador (Fritz Box) e que parece correto, pois esta deve ser a minha rede local (estou correto?), então não preciso de um gateway. Os outros dois são endereços de link local tão bons novamente.

A última rota agora é o que deveria ser interessante, certo? O IP que eu acho lá parece para coincidir com o meu roteador. Eu posso pingar, mas apenas se especificar a interface, ou seja, executando ping6 <ip> yields:

connect: Invalid argument

Mas ping6 -I br0 <ip> funciona:

PING <ip>(<ip>) from <myip> br0: 56 data bytes
64 bytes from <ip> icmp_seq=1 ttl=64 time=0.534 ms
64 bytes from <ip> icmp_seq=2 ttl=64 time=0.393 ms
64 bytes from <ip> icmp_seq=3 ttl=64 time=0.350 ms
64 bytes from <ip> icmp_seq=4 ttl=64 time=0.369 ms
^C
--- <ip> ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.350/0.411/0.534/0.075 ms

É claro que <ip> é o IP dos roteadores, ou seja, o endereço fe80::... acima. Não consigo encontrar o ponto em minha configuração de roteadores, onde ele me diz esse endereço, no entanto, eu encontro seu ULA (Unique Local Address) e começa com fd80:: , mas além disso é idêntico, então estou confiante de que são meus roteadores Endereço IPv6.

No entanto : posso procurar os IPs dos meus routers com nslookup -query=AAAA fritz.box , o que gera duas respostas: O ULA ( fd00::... ) e o endereço IPv6 atribuído pelo ISP no prefixo ( 2a02:... ) com o mesmo sufixo (suponho que ele escolhe isso usando o SLAAC com seu MAC). O que não aparece aqui é o IP que começa com fe00:... , que é inserido na rota.

Talvez alguém tenha uma explicação para esse comportamento estranho ...

    

Answer 1

Eu não posso dizer que eu poderia rastrear o problema até suas raízes, mas pelo menos eu encontrei um "hack" para fazê-lo funcionar. Eu tive que ter certeza que minha bridge realmente pegou o MAC da minha interface eth0 e não o tap0 MAC atribuído aleatoriamente. Para garantir que isso aconteça, você só precisa garantir que o endereço tap0 seja maior que o de eth0 :

/usr/bin/openvpn --mktun --dev tap0
ip link set dev tap0 down
ip link set dev tap0 address 5a:c0:02:9e:ae:3c
ip link set dev tap0 up

Agora, a criação da ponte escolherá o MAC de eth0 , que será configurado corretamente para o SLAAC. Eu não exatamente recebo porque funciona dessa maneira, mas agora mesmo o encaminhamento de porta funciona bem e tudo parece bem.

As rotas agora parecem configuradas corretamente, assim como posso acessar sistemas externos e internos.

    

Answer 2

Você se lembrou de ativar o encaminhamento de ipv6 em /etc/sysctl.conf?

Altere a linha

 #net.ipv6.conf.all.forwarding=1

para

 net.ipv6.conf.all.forwarding=1

que, no entanto, desativa a autoconfiguração sem estado.