Pools VPN de pilha dupla: endereçar as duas famílias no strongSwan

Os pools IPv4 e IPv6 internos, os prefixos protegidos e a família do túnel externo são três decisões separadas. Planeje cada uma antes de chamar isso de pilha dupla.

Um gateway pode entregar a um usuário nômade tanto um endereço virtual IPv4 quanto um IPv6, enquanto o túnel externo ainda viaja sobre IPv4. São decisões independentes, e tratá-las como uma só é onde os planos de pilha dupla geralmente se desfazem. As famílias internas do cliente, os prefixos protegidos que ele pode alcançar e o transporte que carrega a encapsulação são três escolhas separadas.

A maior parte da confusão vem de aplicar a expressão pilha dupla a um desenho que é de pilha dupla em apenas um lugar. Um serviço pode ser de pilha dupla internamente, de pilha única no seu endereço externo, e ainda assim funcionar perfeitamente bem para os clientes. O que ele não pode é funcionar por acaso.

Duas famílias por dentro, um caminho por fora

A conexão externa é IKE sobre UDP, e ela precisa de uma família de endereços alcançável de onde quer que o cliente esteja. Um endereço IPv6 interno não exige um provedor com IPv6, porque o pacote interno é carga útil dentro do externo. Muitas implantações que funcionam transportam prefixos IPv6 por um enlace ascendente só IPv4.

O que o caminho externo realmente limita é a alcançabilidade e a travessia de NAT. Se o gateway anuncia apenas um endereço IPv4, um cliente numa rede só IPv6 não consegue conectar-se de forma alguma, por mais pools que você tenha configurado. Decida a família externa pela sua população de clientes, não pelo plano de endereços interno.

Dê ao cliente um endereço em cada família

Pedir as duas famílias é uma linha do lado do cliente, desde que o gateway tenha o que distribuir. Os pools nomeados mantêm as fontes separadas das redes de serviço, e é essa propriedade que torna as regras de firewall legíveis seis meses depois.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

O vips valor pede um endereço de cada família, e a lista de pools decide de onde vêm esses endereços. A documentação do strongSwan sobre IP virtual abrange várias solicitações e a atribuição de pools, incluindo o ponto de que um cliente que pede um endereço específico expressa apenas uma preferência que o respondedor pode anular. Não construa uma regra de acesso que presuma que o cliente sempre recebe o mesmo valor.

Gere o seu próprio prefixo local único em vez de copiar o do exemplo. Duas organizações que ambas fd42::/16 o implantarem descobrirão a colisão na primeira vez que se interligarem, e diagnosticar isso não é agradável.

Os seletores descrevem destinos, não fontes

Os seletores de tráfego locais da SA filha dizem quais redes protegidas estão atrás do gateway, e os seletores remotos descrevem o que o cliente pode usar como fonte. Um endereço de pool virtual pertence ao lado de origem dessa política; colocá-lo na lista de destinos é uma leitura errada comum da configuração.

As duas famílias precisam de rotas de retorno e encaminhamento permitido no gateway. Adicionar um prefixo a um seletor sem uma rota de volta ao pool produz um túnel que se estabelece, passa uma direção do tráfego e descarta a resposta em silêncio. O seletor é política, não encaminhamento.

Mantenha os pools e os prefixos de serviço em blocos separados do seu plano de endereços. Quando se sobrepõem, uma rota que deveria chegar a um host protegido pode coincidir com um endereço de pool e desaparecer dentro do túnel.

O DNS e o caminho de resposta decidem se parece terminado

As respostas do resolvedor são independentes do transporte usado para chegar até ele. Um nome pode devolver um registro A, um registro AAAA ou ambos, e o cliente escolhe segundo as suas próprias regras de preferência. Se um serviço interno publica um registro AAAA mas nada encaminha esse prefixo, os clientes em redes de pilha dupla vão tentar o caminho IPv6 primeiro e ficar lá até ele falhar. Nada na configuração do túnel parece errado enquanto isso acontece.

Portanto decida por nome quais famílias devem ser utilizáveis e depois verifique se o prefixo correspondente está no seletor e tem uma rota de retorno. É uma decisão serviço a serviço. Publicar os dois tipos de registro sem distinção é como um serviço que funciona só com IPv4 começa a estourar o tempo para metade dos seus usuários.

Verifique as duas famílias antes de dar isso por concluído

Uma configuração que carrega não é uma configuração que funciona. Leia o estado que o daemon relata, confirme as atribuições de pool e depois olhe as rotas que o cliente realmente instalou.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Os dois primeiros comandos mostram as SA filhas estabelecidas e quais pools ainda têm endereços disponíveis, de modo que um plano que funciona para o primeiro cliente e falha para o décimo torna-se visível. Os dois últimos mostram se o cliente recebeu um endereço IPv6 global do pool e para onde o tráfego a um prefixo protegido realmente iria. Compare o endereço atribuído com o pool que configurou, não com o endereço que esperava. Se o respondedor escolheu um valor diferente segundo a sua política, as rotas e as regras de firewall ainda devem bater com o que ele escolheu.

Depois teste um host protegido por família, e teste um nome que resolva para as duas. Um teste de uma só família não lhe diz nada sobre a metade do plano que não exercitou, e é nessa metade que costuma estar a rota em falta.

Artigos relacionados