Delegação de prefixo IPv6 numa VPN site a site: lista de verificação

Levantar o túnel é a metade fácil. Já vi um link site a site ficar estabelecido por dias enquanto todos os hosts da LAN remota recebiam apenas silêncio, porque o prefixo delegado atrás desse gateway estava configurado numa interface mas nunca foi encaminhado para o túnel. Os endereços do túnel respondiam a pings o tempo todo, e é exatamente por isso que ninguém olhou para o prefixo. Esta é a ordem que verifico quando um prefixo IPv6 delegado tem de atravessar uma VPN de site: o mapa de prefixos, os seletores de tráfego, o encaminhamento e a firewall, e depois o caminho de retorno.

Escreve o mapa de prefixos antes de tocares no túnel

A delegação de prefixo entrega um bloco ao router que o pediu. Não instala uma rota no par, não estende esse bloco on-link e não diz ao gateway remoto o que está atrás do router requerente. Estas três coisas são tuas para configurar, e pertencem a um plano de endereçamento antes de qualquer ficheiro de configuração mudar.

Para cada site, regista o prefixo delegado, o /64 realmente em uso na LAN, os endereços do túnel e o dono de cada rota. O fornecedor delega 2001:db8:a1::/56 ao site A, que serve 2001:db8:a1:10::/64 na sua LAN; o site B mantém 2001:db8:b2::/64. Se o site A serve apenas esse /64, ambas as pontas devem indicar 2001:db8:a1:10::/64 em vez do /56 inteiro.

Dois erros aparecem quase sempre. Um é tratar o prefixo remoto como on-link, fazendo bridge ou colocando-o na interface do túnel, para que o gateway responda à solicitação de vizinhos por hosts que não consegue alcançar. O outro é anunciar o /56 inteiro quando só um /64 está configurado: a tabela de rotas afirma que o bloco é alcançável e a maioria dos endereços cai num buraco negro.

Alinha os seletores de tráfego das duas pontas com as rotas

O IKEv2 e o WireGuard recusam ambos tráfego incompatível, de forma suficientemente silenciosa para o túnel continuar a parecer saudável.

No strongSwan os seletores são explícitos. No site A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

A conn do site B espelha as duas sub-redes. Quando não concordam, o respondedor rejeita o CHILD_SA com TS_UNACCEPTABLE, pelo que o child SA nunca sobe mesmo que o IKE_SA tenha subido. Em ambos os lados a sub-rede configurada tem de ser igual ao que o kernel local encaminha para o túnel.

O WireGuard transporta a mesma informação em AllowedIPs, com uma particularidade: AllowedIPs é um filtro de origem ao receber e uma rota ao enviar. Se a entrada de peer do site B para o site A omitir 2001:db8:a1:10::/64, os pacotes do site A chegam com um handshake válido e são descartados como não permitidos. Isso produz o padrão familiar de um handshake que se renova sem parar enquanto nenhuma resposta sai. Compara as duas pontas com wg show wg0 allowed-ips. Verifica de novo essa lista sempre que a delegação mudar; um /64 desatualizado mantém a sessão viva e o novo prefixo inalcançável.

Exclui primeiro o encaminhamento, a firewall e a MTU

Antes de leres mais uma linha de log, confirma que os gateways encaminham de todo. sysctl net.ipv6.conf.all.forwarding tem de devolver 1 em ambos, aplicado também às interfaces do túnel e da LAN. Vem agarrada uma armadilha: com o encaminhamento ligado, uma interface com accept_ra=1 deixa de aceitar anúncios de router do fornecedor, pelo que a máquina pode perder a rota predefinida ascendente mesmo encaminhando perfeitamente dentro do túnel. Define accept_ra=2 onde ainda é preciso o RA do fornecedor.

As regras da firewall têm então de permitir o prefixo nos dois sentidos, e o ICMPv6 tem de sobreviver: descoberta de vizinhos, packet-too-big e destination-unreachable não são opcionais. Se os descartares, a descoberta de MTU do caminho quebra e ficas com ligações que abrem e depois param na primeira resposta grande. Um par mínimo de regras é assim:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

A MTU está por trás disto. Um túnel encolhe a MTU utilizável para baixo de 1500, e o IPv6 exige que cada ligação transporte pelo menos 1280. Pings pequenos passam, uma sessão SSH congela num grande surto, e /proc/net/snmp6 mostra mensagens packet-too-big que nunca voltam. Define a MTU do túnel explicitamente, ou limita o MSS TCP na tabela mangle, e deixa o ICMPv6 que comunica a MTU menor voltar.

Testa o caminho de retorno, não o endereço do túnel

A falha que custa mais tempo é o encaminhamento unidirecional. Cada gateway encaminha o prefixo remoto para o túnel, mas os hosts respondem pelo seu próprio gateway predefinido porque é lá que vive o seu /64. Levar um pacote ao destino é metade do caminho.

Dois comandos resolvem a maior parte. No site A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 mostra que interface usaria uma resposta daquela origem; corre a verificação espelhada no site B. Depois gera tráfego a partir de um host e não do gateway, e compara os contadores nas duas pontas.

Se a solicitação de vizinhos para o prefixo remoto aparecer no túnel, esse prefixo está on-link num sítio onde não devia; corrige isso antes de ajustar rotas. O proxy NDP cobre os casos em que a bridge é realmente necessária, não substitui uma rota.

Planeia a mudança do prefixo debaixo de ti

A delegação de prefixo é um aluguer entre o router delegante e o requerente, e uma renovação pode devolver um bloco diferente: outro /56 após uma migração do fornecedor, ou um aluguer mais curto do que o tempo em que o túnel está de pé. Todos os sítios que nomeiam o prefixo antigo ficam desatualizados ao mesmo tempo: rotas, seletores, AllowedIPs, regras de firewall, registos DNS e qualquer monitorização que codifique endereços literais. O fluxo de mensagens está no RFC 8415.

Onde se espera que o prefixo se mova, mantém um plano de endereçamento interno que não dependa dele e traduz na fronteira. O NPTv6 é a opção sem estado e mantém a política interna legível, mas é tradução de prefixo, não uma camada mágica: as fronteiras /64 têm de alinhar-se, as somas de verificação são ajustadas, e as aplicações que incorporam endereços literais continuam a quebrar. Se mantiveres os endereços do fornecedor de ponta a ponta, regista o comportamento do aluguer e um procedimento de mudança no plano de endereçamento.

Termina com um teste que resista ao tempo: um host permitido em cada LAN alcança um serviço na outra LAN, a resposta volta pelo túnel, e o mesmo par continua a funcionar depois de um reinício do túnel e de uma renovação da delegação. Se a última parte falhar, o desenho depende de estado que não sobreviverá à semana.