Planear o acesso privado IKEv2 de pilha dupla com strongSwan

Um túnel de pilha dupla não é uma decisão mas três, e podem ser respondidas de forma diferente. Por que família circula o túnel exterior, que famílias o cliente recebe lá dentro e em que famílias os serviços protegidos respondem realmente. Um desenho que as trata como uma única escolha ou transporta IPv6 que nunca foi necessário, ou distribui endereços que nada consegue encaminhar de volta. Separe as três e o resto da configuração torna-se quase mecânico.

Três tipos de endereço, decididos separadamente

O endereço exterior é como os dois gateways se alcançam, e pode ser IPv4 enquanto o tráfego interior transporta ambas as famílias. O endereço virtual interior é a identidade do cliente dentro do túnel, e cada família precisa do seu próprio conjunto. Os prefixos protegidos são aquilo a que o cliente pode chegar, e pertencem aos serviços e não ao túnel. Confundir o terceiro com o segundo causa a maioria dos erros de planeamento, porque ambos parecem intervalos privados.

Transporte exterior apenas IPv4 com tráfego interior de pilha dupla é uma disposição normal e bem suportada.

Decida cada uma explicitamente e registe as decisões. Se o caminho exterior for apenas IPv4, diga-o e deixe de se preocupar com a alcançabilidade dos pontos finais IPv6. Se uma família for atribuída lá dentro mas nada responder nela, ou a retire do plano ou torne esses serviços realmente de pilha dupla.

Atribua um endereço virtual em cada família

Numa configuração swanctl o cliente pede endereços virtuais, e um carácter universal em cada família pede ao respondente que atribua um de cada. O respondente retira-os de conjuntos, e os conjuntos são objetos separados das redes atrás do gateway. Mantenha-os separados também no plano, porque um conjunto que se sobrepõe a um prefixo de serviço produz encaminhamento que parece correto até ao momento em que o tráfego aterra num local não pretendido.

Peça ambas as famílias quando precisa das duas, e uma quando não precisa, porque um endereço não usado é superfície de política sem benefício. Um pedido específico é um pedido e não uma reserva, e o respondente pode devolver outro valor segundo a sua própria política. Esse detalhe importa onde um endereço está codificado numa regra de firewall ou numa verificação de monitorização. Refira os conjuntos pelo nome na ligação e mantenha as redes de serviços fora deles.

vips = 0.0.0.0, ::

Gere o seu próprio prefixo local único para o conjunto IPv6 em vez de adotar um valor de exemplo curto. O exemplo mostra a forma da definição, não um valor predefinido a herdar.

Descreva os destinos à parte dos conjuntos

Os seletores de tráfego descrevem o que cada lado espera trocar, pelo que os seletores locais do gateway devem nomear prefixos de serviços protegidos e não conjuntos de clientes. Os seletores remotos do cliente refletem essa intenção. Quando as duas listas descrevem objetos diferentes, o túnel pode subir e mesmo assim não transportar nada de útil.

Esses mesmos prefixos precisam de rotas de retorno e de encaminhamento permitido dentro da rede do gateway, para cada família que ativar.

É aqui que um plano IPv6 privado deixa de ser suficiente. O endereçamento local único compra alcançabilidade privada e não cria saída IPv6 pública, pelo que um desenho que assume que a família sem numeração seguirá simplesmente as regras de mascaramento IPv4 desiludirá os seus utilizadores. Se o acesso IPv6 público faz parte do requisito, precisa de um plano encaminhado e de um upstream que concorde com ele. Caso contrário, diga claramente que o lado IPv6 é apenas privado, o que é uma fronteira honesta e não uma limitação a esconder.

Torne o DNS e os caminhos de retorno intencionais

A resolução de nomes não segue o transporte. Um resolvedor pode devolver registos A e AAAA através de um túnel apenas IPv4, e o cliente tentará então uma família que nunca planeou. Decida que nomes de serviço devem transportar respostas de pilha dupla utilizáveis e torne ambos os caminhos intencionais. Um nome que resolve para uma família sem caminho funcional produz uma paragem em vez de um erro limpo, e as paragens são muito mais difíceis de diagnosticar.

Documente a alcançabilidade do ponto final exterior em separado, incluindo se há alguma travessia NAT em jogo e que família utiliza.

Depois escreva o plano em seis linhas: ponto final exterior, conjunto IPv4, conjunto IPv6, prefixo de serviço IPv4, prefixo de serviço IPv6 e o router que possui as respostas de cada um. Um plano com essa forma responde às perguntas que um operador faz realmente às três da manhã. Qualquer coisa mais curta deixa a pilha dupla como um segundo endereço aparafusado a uma política apenas IPv4, e é assim que costuma acabar a funcionar a meio.