Identidade IKE ou endereço do endpoint: não os confunda

Leia um campo rotulado como identidade FQDN como uma string literal, não como uma solicitação do nome DNS reverso do seu endereço público. No analisador do strongSwan é exatamente isso, uma string, e lê-la nunca a resolve para um endpoint. Esse fato, por si só, elimina a distração mais comum quando você escolhe identificadores para um peer. As verificações abaixo impedem que os três valores envolvidos se fundam em um só.

Um rótulo não é uma consulta

As interfaces dos fornecedores usam palavras como FQDN e hostname com frouxidão, e o rótulo numa caixa não diz nada sobre a codificação por trás dele. Um equipamento que chama um campo de Client FQDN pode enviar um FQDN, uma string em forma de e-mail ou um endereço nu. Trate o texto e o tipo como duas decisões separadas e registre ambos.

Nada numa identidade literal exige DNS. É uma afirmação que o outro lado verifica, não um nome que a rede tenha de resolver.

Três valores separados, escritos separadamente

Três tarefas estão por trás de uma única tela de configuração, e fundi-las é o erro caro. Um valor é o endereço do endpoint, que decide para onde vão os pacotes. Outro é a identidade local que este peer apresenta, e o terceiro é a identidade que você espera do outro extremo antes de autenticá-lo. Escreva-os como três linhas no ticket de mudança, porque qualquer coisa menos que isso descreve uma VPN e não uma relação.

As identidades de exemplo precisam ser escolhidas e autorizadas como parte da implantação. São afirmações que a autenticação verifica, não credenciais que tornem qualquer peer confiável, então uma string de aparência plausível não autoriza nada.

O tipo faz parte do valor

A referência de identidades do strongSwan separa FQDN, valores em forma de e-mail, endereços IP e outras codificações, então a codificação importa tanto quanto os caracteres. Dois dispositivos podem aceitar o mesmo texto sob tipos diferentes e ainda assim recusarem-se um ao outro. Uma nota que registra o valor sem o seu tipo é meia configuração.

Pergunte ao fornecedor qual tipo o equipamento realmente envia, e confirme com uma decodificação em vez do rótulo da interface. Um tipo adivinhado é uma divergência à espera da próxima mudança.

Cada lado tem de satisfazer o outro

A identidade local de cada lado tem de passar pela política de autenticação do outro lado. Isso não é o mesmo que colar uma string em cada caixa de identidade nos dois dispositivos, que é o atalho que produz uma configuração que ninguém consegue depurar.

A autenticação por certificado acrescenta requisitos próprios, porque a identidade do certificado e as condições de confiança ficam ao lado da identidade IKE que você digitou. Uma correspondência de identidade IKE sozinha não autoriza um peer com certificado.

Onde o DNS importa e o que a sua versão impõe

Um hostname de gateway usado para descoberta precisa mesmo de DNS a funcionar, e esse requisito pertence a encontrar o endpoint e não a qualquer pesquisa reversa de uma identidade digitada. Mantenha os dois separados no ticket, porque uma falha de descoberta e uma divergência de identidade leem-se de forma semelhante num log de cliente e são reparadas em lugares diferentes.

Leia o analisador do produto e da versão que você realmente executa antes de copiar sintaxe que impõe um tipo, porque versões antigas do strongSwan comportavam-se de forma diferente e outros fornecedores acrescentam restrições próprias. Quando comparar os dois extremos, mantenha quatro coisas juntas: identidade esperada, identidade apresentada, tipo e o erro de autenticação. Esse conjunto transforma uma divergência em evidência em vez de opinião.