Peer IPsec de entrada que não corresponde a nenhum perfil? Verifique quatro campos

O seu peer relata que o túnel está ativo, o seu lado não mostra qualquer associação de segurança e o ficheiro de configuração contém claramente um nome de conexão correspondente. As três afirmações podem ser verdadeiras ao mesmo tempo. Uma negociação de entrada é comparada com a configuração em execução, usando o endereço do peer, a identidade que apresenta e o tráfego que propõe. Um ficheiro no disco que nunca foi carregado, uma identidade que não corresponde ao valor esperado ou um par de seletores desviado num prefixo produzirão silêncio cada um. Percorra os quatro grupos de campos na ordem que o respondedor segue.

Comece pelo pacote, não pelo ficheiro

O respondedor recebe um pedido IKE, procura uma definição que possa aceitar este peer e depois continua com a autenticação e a seleção de tráfego. Se nenhuma definição carregada corresponder no primeiro passo, a negociação termina antes de qualquer erro útil chegar ao utilizador.

Por isso «a configuração parece correta» não é prova. A pergunta é o que o serviço em execução carregou e que entrada selecionou para esta tentativa. Uma listagem de estado responde a isso com um único comando, enquanto o buffer do editor responde a outra pergunta. Verifique a listagem antes de alterar o ficheiro novamente.

Primeiro grupo de campos: a definição que está realmente carregada

Verifique o estado em execução com a ferramenta que detém o daemon: um comando de estado que lista as conexões carregadas, não o buffer do editor. Confirme que a entrada esperada está presente, está ativada para o comportamento de arranque pretendido e foi carregada após a sua última alteração. Um ficheiro guardado que não foi recarregado é a causa mais comum de «corrigi e nada mudou».

Confirme também que ficheiro o serviço lê. As distribuições diferem, e uma conexão escrita na inclusão errada é ignorada em silêncio em vez de rejeitada. Se a listagem de estado não mostrar a sua entrada de todo, suspeite do caminho de inclusão antes da sintaxe.

Segundo grupo de campos: os extremos não são identidades

O endereço de onde o peer se liga e a identidade com que se autentica são campos separados. Um nome de anfitrião, um nome distinto, um identificador de chave e um endereço podem todos servir como identidade IKE consoante a configuração, e não têm de se parecer de modo algum com o endereço público.

A correspondência de extremos pode também envolver uma vista NAT: o endereço visto na rede pode diferir do endereço que o peer julga ter. No modelo de conexões do libreswan, left e right são etiquetas dos dois participantes e não uma ordem fixa de local e remoto, e é por isso que copiar uma configuração funcional de outro local trocando os endereços não é uma tradução fiável.

Anote a identidade esperada de cada lado e a credencial que a valida. Se essas duas linhas não concordarem, nenhuma quantidade de ajuste de endereços produzirá correspondência.

Terceiro grupo de campos: o tráfego protegido

Os seletores descrevem os intervalos internos de origem e destino, a sua família de endereços e qualquer restrição de protocolo ou porta. Uma proposta para o endereço de um único anfitrião não é o mesmo pedido que para uma sub-rede inteira, e um respondedor configurado para a sub-rede pode recusá-la ou estreitá-la.

Quando os dois extremos não concordam, compare o fluxo previsto de ambos os pontos de vista em vez de alargar cada seletor para que algo se ligue. Pergunte a cada administrador que fluxo julga estar a proteger e depois compare as duas respostas. A discrepância costuma ser um prefixo de anfitrião de um lado e uma sub-rede do outro. Um túnel que corresponde porque agora protege tudo é uma decisão de segurança diferente, e que ninguém aprovou.

Quarto grupo de campos: está a ler uma implementação

O Libreswan, o antigo Openswan e o strongSwan têm ferramentas de gestão diferentes, sintaxe de configuração diferente e ordem de correspondência diferente. Um exemplo funcional de um não diz nada preciso sobre a prioridade de seleção de perfil ou a formulação de erros de outro, por isso verifique com a documentação do daemon neste anfitrião.

Correlacione uma tentativa de ponta a ponta: o endereço de origem do iniciador, a identidade oferecida e os seletores propostos — contra a mensagem de seleção do respondedor e a entrada carregada que ela nomeia. Contadores de encapsulamento e desencapsulamento a zero dizem apenas que as associações observadas não transportaram esses pacotes; não nomeiam o extremo que rejeitou a proposta nem provam que existia uma entrada correspondente naquele momento.

Após uma correção coordenada, confirme o perfil e a associação selecionados e depois teste o serviço realmente permitido e o seu caminho de resposta. Uma correspondência de perfil permite a negociação, e a negociação não é a última verificação de acesso.