Minha pergunta está relacionadaessepergunta, mas com pouca diferença:
Eu tenho um Ubuntu vps com um único IPv4 na interface principal. Eu gostaria de ter dois túneis IPv6 separados nesta máquina, provenientes de dois provedores diferentes com endereços de endpoint diferentes. Quando tento um deles sozinho. Tudo está bem. Mas quando adiciono o segundo túnel, o primeiro ainda funciona, mas o segundo não pode receber ping de fora. Ele pode executar ping em si mesmo e no gateway.
Eu adiciono estas linhas ao meu /etc/network/interfaces:
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:xxx:xxx:xxxx::2
netmask 64
endpoint xx.xx.xx.xx
local yy.yy.yyy.yy
ttl 255
gateway 2001:xxx:xxx:xxxx::1
auto sbtb-ipv6
iface sbtb-ipv6 inet6 v4tunnel
address 2a09:xxx:xxx:xxxx::2
netmask 64
endpoint zz.zz.zz.zz
local yy.yy.yyy.yy
ttl 255
gateway 2a09:xxx:xxx:xxxx::1
Alguém sabe onde está o problema ou como posso solucionar isso?
Responder1
Algumas observações
Para outras ferramentas de configuração de rede ifupdown, v4tunnelé realmente uma camada 3SENTARtúnel que pode ser criado dependendo de ferramentas usando o equivalente ip tunnel add FOO mode sit ...ou de ip link add name FOO type sit ....
As interfaces da camada 3 não possuem um endereço da camada 2 (sem endereço MAC Ethernet) e, portanto, não precisam resolver o endereço da camada 2 subjacente: ARP (IPv4) e NDP (IPv6) não acontecem com uma interface da camada 3 . Pela mesma razão, não há gateway para resolver: um gateway não é necessário para sua propriedade gateway, mas a sintaxe ainda pode permitir adivinhar a interface a ser usada ao criar uma entrada na tabela de roteamento sem especificar a interface e geralmente é isso que é feito, incluindo oexemplos de configuração do próprio agente de túnel. No final das contas, o uso da máscara de rede /64 e um gateway não são necessários em nenhum lugar para a configuração do OP. Mas essa resposta ainda seguirá essas configurações, então será mais fácil para o leitor adaptá-la a um túnel de interface da camada 2, onde todas essas configurações se tornarão obrigatórias. Da mesma forma, normalmente apenas são necessárias configurações sobre a interface não padrão (aqui sbtb-ipv6), mas de qualquer forma estou fornecendo uma configuração para as duas interfaces. A única diferença que resta é qual interface obtém a rota padrão na tabela de roteamento principal.
Multihoming e roteamento de política
Este é agora um caso desistema multihoming usando vários endereçoscada um com seu próprio caminho para acessar a Internet (IPv6). Os roteadores upstream certamente implementamEncaminhamento estrito de caminho reverso(SRPF) para anti-spoofing: cada endereço de origem deve transitar pelo seu caminho dedicado. Com roteamento simples, apenas uma rota padrão é usada (a primeira exibida). É possível adicionar uma segunda rota padrão com métrica mais longa, mas ela nunca será escolhida até que a rota com métrica mais curta desapareça.
Para superar isso, pode-se usarroteamento de política. Isso permite que o sistema escolha outras tabelas de roteamento (preenchidas com rotas diferentes) e regras de roteamento que escolherão essas tabelas de roteamento com seletores adicionais, em vez de apenas usar o destino para encontrar a rota. Aqui o que é útil é o endereço de origem (e em alguns casos também a interface de saída quando esta interface é forçada comSO_BINDTODEVICE).
Portanto, o objetivo é criar múltiplas tabelas de roteamento alternativas com uma visão parcial das rotas, com base nas entradas da tabela de roteamento principal: cada tabela de roteamento considerará que existe apenas um caminho para a Internet e terá sua própria rota padrão. Então, uma regra de roteamento baseada no endereço de origem selecionará a tabela de roteamento adequada para os pacotes de saída. No caso do OP, nada de especial é necessário para os pacotes recebidos, pois a tabela de roteamento local já trata desse caso.
Implementação
Primeiro, as interfacesconfigurações devem ser ajustadas adicionando um diferentemétricaem cada um, ou a sbtb-ipv6configuração provavelmente falhará porque não pode haver duas rotas padrão com a mesma métrica.
Então, manualmente, veja como fazer isso funcionar. Adicione duas tabelas de roteamento com valores (arbitrários) 2000 para HE e 2001 para SBTB e copie apenas as rotas relacionadas para cada uma. A métrica não importa aqui, pois não há conflito possível.
ip -6 route add 2001:xxx:xxx:xxxx::/64 dev he-ipv6 table 2000
ip -6 route add default via 2001:xxx:xxx:xxxx::1 dev he-ipv6 table 2000
ip -6 route add 2a09:xxx:xxx:xxxx::/64 dev sbtb-ipv6 table 2001
ip -6 route add default via 2a09:xxx:xxx:xxxx::1 dev sbtb-ipv6 table 2001
E selecione a rota adequada com base no endereço de origem com regras de roteamento (e para ser explícito, indique uma prioridade fixa e indique que é um pacote iniciado localmente com iif lo):
ip -6 rule add pref 20000 from 2001:xxx:xxx:xxxx::2 iif lo lookup 2000
ip -6 rule add pref 20010 from 2a09:xxx:xxx:xxxx::2 iif lo lookup 2001
Para o caso em que alguém se liga à interface (por exemplo, ping -I sbtb-ipv6 ...) em vez de "simplesmente" ao endereço da interface ( ping -I 2a09:xxx:xxx:xxxx::2), também use isso para obter resultados adequados (realmente útil para casos da camada 2 onde não existe uma segunda rota padrão na tabela de roteamento principal, não realmente necessário no caso de OP com interfaces de camada 3):
ip -6 rule add pref 20001 oif he-ipv6 lookup 2000
ip -6 rule add pref 20011 oif sbtb-ipv6 lookup 2001
A direção oposta (tráfego de entrada, também conhecido como ingresso) já é tratada corretamente na localtabela de roteamento quando os endereços são adicionados, portanto, não há nada especial a fazer para o ingresso.
Configuração final
Acima deve ser tentado manualmente primeiro, com um acesso de console remoto de backup (embora o IPv4 não seja afetado, o acesso IPv4 deve ser suficiente). Em seguida, ele pode ser integrado ao interfacesarquivo de configuração, usando comandos up/ sempre que não suportar o recurso (ou seja: todo o roteamento de políticas). Certifique-se de remover os testes anteriores manualmente, ou alguns comandos na configuração da interface entrarão em conflito com erros como e a configuração das interfaces falhará.downifupdownRTNETLINK answers: File exists
ATUALIZAÇÃO: isso também inclui a emissão de três pings para a extremidade remota do túnel SBTB, pois pelos comentários parece que este túnel deve ver o tráfego do servidor antes de poder aceitar o tráfego para o servidor. Se o endereço de peer SBTB (túnel) não for suficiente para acionar a aceitação de tráfego para o servidor, substitua-o por algum endereço IPv6 "bem conhecido". O mesmo poderia ser adicionado na interface HE, mas isso não parece necessário.
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:xxx:xxx:xxxx::2
netmask 64
endpoint xx.xx.xx.xx
local yy.yy.yyy.yy
ttl 255
gateway 2001:xxx:xxx:xxxx::1
metric 1000
up ip -6 route add 2001:xxx:xxx:xxxx::/64 dev he-ipv6 table 2000
up ip -6 route add default via 2001:xxx:xxx:xxxx::1 dev he-ipv6 table 2000
up ip -6 rule add pref 20000 from 2001:xxx:xxx:xxxx::2 iif lo lookup 2000
up ip -6 rule add pref 20001 oif he-ipv6 lookup 2000
down ip -6 rule del pref 20001
down ip -6 rule del pref 20000
auto sbtb-ipv6
iface sbtb-ipv6 inet6 v4tunnel
address 2a09:xxx:xxx:xxxx::2
netmask 64
endpoint zz.zz.zz.zz
local yy.yy.yyy.yy
ttl 255
gateway 2a09:xxx:xxx:xxxx::1
metric 1001
up ip -6 route add 2a09:xxx:xxx:xxxx::/64 dev sbtb-ipv6 table 2001
up ip -6 route add default via 2a09:xxx:xxx:xxxx::1 dev sbtb-ipv6 table 2001
up ip -6 rule add pref 20010 from 2a09:xxx:xxx:xxxx::2 iif lo lookup 2001
up ip -6 rule add pref 20011 oif sbtb-ipv6 lookup 2001
up ping -q -c3 -I sbtb-ipv6 2a09:xxx:xxx:xxxx::1
down ip -6 rule del pref 20011
down ip -6 rule del pref 20010
Como usar?
Agora pode-se abrir uma ou ambas as interfaces, ela sempre funcionará corretamente, com prioridade he-ipv6quando ambas estiverem ativas. Para usar a sbtb-ipv6interface quando ambas estiverem ativas, deve-se vincular ao seu endereço ou vincular à própria interface. Aqui estão exemplos para exibir a rota que o kernel deve usar:
# ip route get to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from :: via 2001:xxx:xxx:xxxx::1 dev he-ipv6 src 2001:xxx:xxx:xxxx::2 metric 1000 pref medium
# ip route get from 2001:xxx:xxx:xxxx::2 to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from 2001:xxx:xxx:xxxx::2 via 2001:xxx:xxx:xxxx::1 dev he-ipv6 table 2000 src 2001:xxx:xxx:xxxx::2 metric 1024 pref medium
# ip route get oif he-ipv6 to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from :: via 2001:xxx:xxx:xxxx::1 dev he-ipv6 table 2000 src 2001:xxx:xxx:xxxx::2 metric 1024 pref medium
# ip route get from 2a09:xxx:xxx:xxxx::2 to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from 2a09:xxx:xxx:xxxx::2 via 2a09:xxx:xxx:xxxx::1 dev sbtb-ipv6 table 2001 src 2a09:xxx:xxx:xxxx::2 metric 1024 pref medium
# ip route get oif sbtb-ipv6 to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from :: via 2a09:xxx:xxx:xxxx::1 dev sbtb-ipv6 table 2001 src 2a09:xxx:xxx:xxxx::2 metric 1024 pref medium
Vários comandos, daemons ou ferramentas requerem várias opções para vincular a outro endereço ou dispositivo de origem. Ex.: ping -I, traceroute -i, curl --interface, ssh -b/ ssh -B, etc.
Pode-se verificar comparando o resultado de um destes comandos:
curl -6 https://ifconfig.co
curl -6 --interface 2001:xxx:xxx:xxxx::2 https://ifconfig.co
curl -6 --interface he-ipv6 https://ifconfig.co
versus o resultado de um destes:
curl -6 --interface 2a09:xxx:xxx:xxxx::2 https://ifconfig.co
curl -6 --interface sbtb-ipv6 https://ifconfig.co