Pacotes IPv6 injetados na interface tun vão para a pilha IPv4

Question

Eu tenho um problema sobre as interfaces do tun e o manuseio do IPv6 pelo kernel.

Estou tentando fornecer IPv6 para os usuários finais da minha rede em uma rede IPv4 pura. Resumindo (apenas uma teoria de fundo de encapsulamento), todos os pacotes IPv6 são colocados em pacotes IPv4 e enviados através do encapsulamento e, quando saem, esse cabeçalho IPv4 é removido e entregue ao sistema.

O cenário em que estou simulando tudo isso é o seguinte:

• Eu tenho apenas uma máquina, com duas interfaces virtuais IPv4, usadas para envie tráfego encapsulado entre ambos. Vamos chamá-los de "if4a" e "if4b". Essas interfaces são filhas da interface de gerenciamento.
• Esta máquina também possui duas interfaces tun IPv6, usadas para mascarar os endereços IPv6 dos usuários finais. Vamos chamá-los de "if6a" e "if6b". Cada interface tun anexou um programa manual para colocar / remover os cabeçalhos que eu preciso (GTP) antes de gravar / ler os pacotes de / para o túnel (if4a com fd00: fea: 2001 :: 1 address e if4b com fd00: fea: 2002: : 1 endereço).
• Eu tenho dois endereços IPv6 não definidos em qualquer lugar, os endereços de usuários finais na verdade (fd00: cafe: 2001 :: 1 representa um usuário de if6a e fd00: cafe: 2002 :: 1 um usuário da rede if6b). / li>
• A tabela de roteamento é configurada para enviar o tráfego de usuários finais para o "if6a" ou "if6b" (interfaces tun).
• Existe uma configuração NAT que altera os endereços IPv6 "fea" por endereços "cafe" para evitar que os pacotes sejam entregues à destionation if6x diretamente e forçar o tráfego IPv6 através das interfaces tun e, portanto, dos meus programas GTP.

A questão é:

• Eu envio um ICMPv6 de fd00: fea: 2001 :: 1 para fd00: cafe: 2002 :: 1 até if6a.
• A cadeia de pós-produção de NAT altera o endereço de origem por fd00: cafe: 2001 :: 1
• O programa escutando if6a lê o ICMPv6, adiciona cabeçalhos GTP e envia para if4b (usando IPv4)
• O pacote IPv6 encapsulado no GTP possui estes endereços: de fd00: cafe: 2001 :: 1 a fd00: cafe: 2002 :: 1
• O servidor recebe o pacote, remove o cabeçalho GTP e o injeta (pacote IPv6) na interface if6b.
• Aqui é onde tshark fareja o pacote e imprime o traço
• A cadeia de pré-codificação NAT altera o endereço de destino por fd00: fea: 2002 :: 1 e sobe o IP da pilha.
• O pacote é descartado porque sobe a pilha IPv4 em vez da pilha IPv6.

Alguns vestígios:

• tshark:

[root@vm062 ~]# tshark -i if6b'
 Running as user "root" and group "root". This could be dangerous
 Capturing on 'if6b'
 1   0.000000 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104 Echo
 (ping) request id=0x7383, seq=1, hop limit=0
 1   2   0.785373 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104
 Echo (ping) request id=0x7383, seq=2, hop limit=0
 2   3   1.782000 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104
 Echo (ping) request id=0x7383, seq=3, hop limit=0
 3   4   2.781968 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104
 Echo (ping) request id=0x7383, seq=4, hop limit=0...

• Dropped packets, como mostra o dropwatch:

 [ipv6test@vm062 ssh]$ echo start | dropwatch -l kas
 Initalizing kallsyms db
 dropwatch> start
 Enabling monitoring...
 Kernel monitoring activated.
 Issue Ctrl-C to stop monitoring
 1 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 1 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 ...

Se eu parar o ping6 as paradas param também.

Eu tenho pesquisado sobre a função ip_rcv e só funciona para o IPv4 pacotes, então eu suponho que meus pacotes IPv6 estão entrando através da pilha IPv4 em vez da pilha IPv6. Por que o kernel está fazendo isso?

Existe uma questão semelhante aqui .