Estou tentando resolver um problema estranho de roteamento. Tenho meu roteador configurado (Turris, rodando OpenWRT customizado), com conexão IPv6 de tunelamento Strongswan. Isso funciona bem para o roteador em si, pois a conectividade ipv6 está funcionando bem (através do túnel, meu provedor não oferece ipv6 nativo).
TL;DR: As rotas não são escolhidas como eu esperava, pois a mais genérica, ::/0 parece ser sempre preferida, embora uma correspondência /64 esteja disponível.
Mas quando tentei estender isso para minha rede doméstica, me deparei com um problema e não consegui encontrar a causa.
Embora o ipsec funcione, recebo uma interface ipsec0 e estas rotas:
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::/0 :: U 1024 0 2 ipsec0
2a01:490:19:42::/64 :: U 1024 0 0 br-lan
Aqui, 2a01:490:19:42::/64 é uma classificação que dediquei para minha rede local, 2a01:490:19:42::1 é o endereço IP do roteador nessa rede.
Aqui estão algumas observações:
1) Quando faço ping em 2a01:490:19:42::1 de um computador na minha rede local, o roteador responde, mas envia a resposta para a interface ipsec0. Eu não tenho ideia do porquê. O prefixo mais específico, 2a01:490:19:42::/64, em br-lan não deveria ser preferido? Parece escolher corretamente o endereço IP de origem 2a01:490:19:42::1.
2) A mesma coisa acontece quando tento enviar um pacote da minha rede local para algum outro site, digamos ping6 stackexchange.com. Os pacotes chegam ao roteador, são encaminhados, o servidor envia a resposta, o roteador recebe... e envia de volta para a interface ipsec0.
3) Não existem políticas xfrm. ip xfrm polnão retorna nada. Mas o Strongswan está concorrendo e tive a impressão de que o Strongswan sempre cria algumas políticas. Na minha configuração anterior, tive que adicionar alguns para permitir a passagem de pacotes para o túnel, mas estou um pouco confuso sobre o fato de a lista de políticas estar vazia.
Tudo bem, então o que há de errado? Por que a rota mais genérica, ::/0, é preferida para meus pacotes IPv6?
Obrigado!
Responder1
O problema foi que o ipsec inseriu suas regras em diferentes tabelas de roteamento (table 220) e criou uma política para direcionar o tráfego para lá:
root@turris:/etc/config# ip rule list
0: from all lookup local
220: from all lookup 220
32766: from all lookup main
32767: from all lookup default
Mas a tabela 220continha apenas a rota padrão para o túnel ipsec, e não para a rede local:
root@turris:/etc/config# ip -6 r show table 220
default dev ipsec0 proto static src 2a01:490:19:42::1 metric 1024
O que inevitavelmente fez com que todos os pacotes fossem encaminhados para o túnel.
A rede do próprio roteador funcionou apenas porque foi aceita e não roteada.
Corrigi isso instruindo o Strongswan a inserir regras de roteamento na tabela principal, definindo charon.routing_table = 254(o id de main, como visto em /etc/iproute2/rt_tables). Meu strongswan.confagora está assim:
charon {
# load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
routing_table = 254 # main
}