Configurando um túnel IPv6 do Hurricane Electric sem ser o gateway padrão

Question

Eu tenho tentado descobrir se é possível configurar um túnel IPv6 do Hurricane Electric para ser configurado em um servidor CentOS VPS, mas não torná-lo o gateway padrão para todo o tráfego IPv6, mas também ser capaz de utilizar o / 64 sub-rede delegada através do túnel.

Usando o exemplo do CentOS 7 com algumas modificações neste guia (é um Linode VPS):

link

O motivo para o túnel não ser o gateway padrão é que já tenho IPv6 nativo via SLAAC e um / 64 delegado, mas esperava adicionar o túnel IPv6 como um cenário de failover / rota de rede IPv6 adicional para serviços executando neste servidor.

Todas as configurações que vi em relação à configuração de uma interface "he-ipv6", basicamente assumem o gateway padrão, o que torna meu espaço de endereço IPv6 nativo não mais passível de ping para o lado da WAN, mas conectividade como ping e traceroute funciona dentro do servidor em ambas as interfaces, testado especificando a interface específica nos testes.

traceroute -6 -i eth0 ipv6.google.com

traceroute to ipv6.google.com (2a00:1450:400b:801::200e), 30 hops max, 80 byte packets
 1  2a01:7e00::xxxx:xxxx:xxxx:xxxx (2a01:7e00::8678:acff:fe5a:1a41)  0.919 ms  1.358 ms  1.425 ms
 2  2a01:7e00:7777:6::1 (2a01:7e00:7777:6::1)  0.832 ms 2a01:7e00:7777:1::1 (2a01:7e00:7777:1::1)  0.893 ms 2a01:7e00:7777:3::1 (2a01:7e00:7777:3::1)  2.858 ms
 3  2001:7f8:4::3b41:1 (2001:7f8:4::3b41:1)  1.489 ms  1.489 ms  1.470 ms
 4  2001:4860:0:1102::2 (2001:4860:0:1102::2)  1.768 ms 2001:4860:0:1103::3 (2001:4860:0:1103::3)  2.129 ms  2.306 ms
 5  2607:f8b0:e000:8000::6 (2607:f8b0:e000:8000::6)  11.461 ms 2001:4860::c:4000:dd7a (2001:4860::c:4000:dd7a)  30.924 ms  30.940 ms
 6  2001:4860::1:0:b04f (2001:4860::1:0:b04f)  12.182 ms  14.449 ms  13.446 ms
 7  2001:4860:0:1::1223 (2001:4860:0:1::1223)  10.631 ms  10.818 ms  11.042 ms
 8  dub08s01-in-x0e.1e100.net (2a00:1450:400b:801::200e)  11.695 ms  12.338 ms  11.674 ms

traceroute -6 -i he-ipv6 ipv6.google.com

traceroute to ipv6.google.com (2a00:1450:400b:c00::8b), 30 hops max, 80 byte pac                 kets
 1  jamesnetworks-3.tunnel.tserv1.lon2.ipv6.he.net (2001:470:1f1c:xxx::1)  5.321                  ms  8.443 ms  11.440 ms
 2  ge3-20.core1.lon2.he.net (2001:470:0:320::1)  11.657 ms  11.635 ms  11.610 m                 s
 3  2001:7f8:4::3b41:1 (2001:7f8:4::3b41:1)  12.799 ms  12.776 ms  12.745 ms
 4  2001:4860:0:1::2484 (2001:4860:0:1::2484)  12.380 ms 2001:4860:0:1103::3 (20                 01:4860:0:1103::3)  13.500 ms 2001:4860:0:1103::2 (2001:4860:0:1103::2)  12.769                  ms
 5  2001:4860::c:4000:dd7a (2001:4860::c:4000:dd7a)  12.871 ms 2607:f8b0:e000:80                 00::6 (2607:f8b0:e000:8000::6)  22.566 ms 2001:4860::c:4000:dd7a (2001:4860::c:4                 000:dd7a)  13.663 ms
 6  2001:4860::1:0:af90 (2001:4860::1:0:af90)  20.897 ms  11.010 ms  12.375 ms
 7  2001:4860::2:0:b051 (2001:4860::2:0:b051)  12.114 ms  22.411 ms  11.200 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  dg-in-x8b.1e100.net (2a00:1450:400b:c00::8b)  11.499 ms  11.035 ms  11.800 ms

Configurei o túnel e confirmo que funciona, mas meus dois / 64 espaços de endereço IPv6 não funcionam quando ambos estão ativados. Estou procurando orientação adicional sobre qual configuração de roteamento eu preciso ter para que isso funcione, possivelmente um pouco fora do escopo abordado nos documentos acima.

O gateway padrão no dispositivo eth0 configurado como:

default via fe80::1 dev eth0 proto ra metric 1024 expires 1796sec

Ao ativar a interface he-ipv6 , isso é adicionado além do acima:

default via 2001:470:1fxx:xx::1 dev he-ipv6 metric 1

A métrica é mais alta, todo o tráfego tenta passar pela interface he-ipv6 , que não é o que eu quero. Igualmente, ter duas rotas "padrão" parece ser uma má idéia.

O que eu estou tentando fazer é manter a conectividade IPv6 nativa funcionando, enquanto tendo o he-ipv6 ativo e disponível para o tráfego ser roteado para os endereços IPv6 configurados no meu roteado / 64 através do túnel, além do existente / 64 do Linode.

Acredito que vou precisar fazer um roteamento estático aqui, mas não tenho certeza de como resolvê-lo.

Até agora, com a capacidade de controlar a métrica adequadamente, conforme a orientação abaixo, é assim que a tabela de roteamento IPv6 se parece:

unreachable ::/96 dev lo metric 1024 error -113
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -113
# Additional route added by he-ipv6
2001:470:1f1c:xxx::/64 dev he-ipv6 proto kernel metric 256
# Adding any IPv6 in the HE routed /64 to eth0 adds the route below
2001:470:1f1d:xxx::/64 dev eth0 proto kernel metric 256
unreachable 2002:a00::/24 dev lo metric 1024 error -113
unreachable 2002:7f00::/24 dev lo metric 1024 error -113
unreachable 2002:a9fe::/32 dev lo metric 1024 error -113
unreachable 2002:ac10::/28 dev lo metric 1024 error -113
unreachable 2002:c0a8::/32 dev lo metric 1024 error -113
unreachable 2002:e000::/19 dev lo metric 1024 error -113
# Linode SLAAC IPv6
2a01:7e00::/64 dev eth0 proto kernel metric 256 expires 14395sec
2a01:7e00:xxxx:xxx::/64 dev eth0 proto kernel metric 256
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -113
# Having fe80::/64 for both interfaces seems wrong?
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev he-ipv6 proto kernel metric 256
# eth0 (Linode IPv4/IPv6)
default via fe80::1 dev eth0 proto ra metric 1024 expires 1795sec hoplimit 64
# he-ipv6
default via 2001:470:1f1c:xxx::1 dev he-ipv6 metric 1025

As duas referências para fe80::/64 não parecem bem aqui, eu não acho que o he-ipv6 precisaria deste conjunto neste caso e possivelmente eu preciso de rotas estáticas adicionais para permitir que os endereços roteados / 64 sejam externamente acessível.

Qualquer conselho ou solução seria apreciado para que isso funcionasse!

    

Answer 1

Não há problema em ter duas rotas padrão, mas, como ressalta Ron nos comentários, você quase certamente desejará que elas tenham métricas diferentes, de modo que normalmente uma (presumivelmente a interface ethernet) será normalmente preferida.

Você desejará editar o script ifup adicionado para a interface he-ipv6 e adicionar METRIC=100 à parte inferior. Quando a interface de túnel é ativada, isso deve resultar em duas rotas padrão, a existente com uma métrica de 1 e a nova com uma métrica de 100. Se a rota padrão através da porta Ethernet desaparecer, o tráfego da v6 começará a fluir através do túnel.

Lembre-se de que você também pode adicionar algumas rotas estáticas v6 adicionais por meio da interface de túnel com base no que deseja alcançar por meio do HE.

EDITAR: O Redhat / CentOS não implementa / honra o valor de METRIC consistentemente nos vários scripts de interface. Você poderia certamente modificar esses scripts para incluir esse valor, mas isso pode não ser desejável do ponto de vista da operabilidade, já que você precisaria rastrear todas as alterações feitas no envio para esses scripts de estoque.

Então ... você pode fazer isso a partir do CLI facilmente:

sudo ip -6 delete default via 2001:470:1fxx:xx::1 dev he-ipv6 sudo ip -6 add default via 2001:470:1fxx:xx::1 dev he-ipv6 metric 100

Você também pode adicionar isso para ser executado automaticamente, criando um script chamado /sbin/ifup-local que seria parecido com isto:

#!/bin/sh if [[ "$1" == "he-ipv6" ]] then sudo ip -6 delete default via 2001:470:1fxx:xx::1 dev he-ipv6 sudo ip -6 add default via 2001:470:1fxx:xx::1 dev he-ipv6 metric 100 else #DO_NOTHING fi

Isso deve ser chamado automaticamente pelo CentOS depois que cada interface é ativada, mas só fará qualquer coisa se a interface em questão for literalmente "he-ipv6".