Como a autenticação híbrida do IKEv1 se traduz na autenticação de utilizadores do IKEv2

Todo o perfil VPN legado que pede um certificado de servidor e depois um nome de utilizador transporta dois acontecimentos de autenticação num só intercâmbio, e essa forma sobrevive ao protocolo que a introduziu. O modo híbrido do IKEv1 foi criado exatamente para isto: o gateway prova a sua identidade com uma chave pública e o utilizador prova a dele mais tarde através do XAuth. O IKEv2 exprime a mesma ideia em dois passos com mecanismos diferentes, e é nessas diferenças que as migrações falham. Nenhum número de versão converte um no outro, e copiar os nomes de opção antigos para um perfil novo produz um cliente que negocia e depois não autentica nada.

O que o modo híbrido fazia dentro do IKEv1

Num perfil híbrido o responder assina o intercâmbio da fase um com o seu certificado enquanto o iniciador não apresenta nenhum de propósito. A prova de identidade é, por isso, assimétrica, e foi isso que permitiu a um gateway manter a sua PKI existente enquanto os utilizadores mantinham as palavras-passe do diretório. Assim que a fase um termina, o XAuth corre como um pedido e uma resposta que transportam os atributos de nome de utilizador e palavra-passe dentro do canal ISAKMP já cifrado.

Repare onde fica a confiança. O certificado responde a que gateway o cliente chegou; o XAuth responde a que utilizador quer acesso. Nenhum substitui o outro, e um cliente configurado para aceitar qualquer certificado de servidor descartou em silêncio a primeira resposta. O rótulo híbrido também é usado para o modo agressivo com chave pré-partilhada mais XAuth, uma disposição diferente com a mesma experiência de utilizador, por isso leia o perfil e não o nome. Ambas as variantes vêm de rascunhos que nunca se tornaram normas, e é por isso que dois fabricantes podem implementar o modo híbrido e não interoperar com nenhum.

Como o IKEv2 chega às mesmas duas provas

O IKEv2 divide o trabalho entre o IKE_SA_INIT e o IKE_AUTH. O primeiro intercâmbio acorda propostas e chaves sem qualquer identidade; o segundo transporta o IDi, o IDr e as cargas AUTH. Sob EAP a primeira carga AUTH do iniciador sai vazia, o responder autentica-se primeiro com o seu certificado e a sua assinatura, e a conversa EAP corre depois dentro das mensagens IKE_AUTH.

O mecanismo que torna isto seguro é o material de chaves. Um método EAP bem-sucedido exporta uma chave de sessão, e a carga AUTH final do iniciador é calculada a partir dela, de modo que a prova do utilizador e as chaves do túnel ficam ligadas. O XAuth não tem equivalente: os seus atributos chegam depois da fase um e não contribuem em nada para as chaves. É precisamente essa lacuna que a arquitetura do IKEv2 foi concebida para fechar, e é por isso que um início de sessão IKEv2 funcional valida o certificado do servidor antes de pedir seja o que for.

Esta ordem também é um diagnóstico útil. Quando um cliente se queixa das credenciais antes de lhe ter mostrado um certificado, não está a fazer um intercâmbio EAP do IKEv2 de todo.

Mantenha três identidades separadas

Uma migração corre mal quando três identidades colapsam num só campo. Há a identidade do gateway que o cliente valida, normalmente um nome DNS no sujeito ou no SAN do certificado. Há a identidade do utilizador apresentada no EAP, que pode ser um início de sessão de domínio, um endereço ou uma cadeia de identidade EAP explícita. E há a fonte de autorização que mapeia esse utilizador para redes e rotas.

A sintaxe swanctl do strongSwan torna a separação visível: a ligação define remote { auth = pubkey } para o gateway e local { auth = eap-mschapv2 } para o utilizador, com a identidade EAP transportada à parte.

Quando a identidade do utilizador no perfil novo difere dos atributos XAuth antigos, por exemplo um UPN em vez de um nome curto, o servidor de autenticação vê um utilizador desconhecido e a falha parece uma palavra-passe errada. Verifique a cadeia de identidade antes de verificar a credencial.

Mapeie as opções e conte com as armadilhas

O mapeamento é curto e cada linha tem uma armadilha que só aparece no momento da autenticação.

Nenhuma dessas linhas é uma mudança de nome. A carga de configuração entrega endereços e resolvedores através de uma lista de atributos tipados, enquanto o espaço de atributos do XAuth foi invenção própria; tratá-los como intermutáveis é como um perfil acaba a pedir uma definição que o gateway nunca enviará.

Os seletores de tráfego merecem o seu próprio aviso. O IKEv1 exprimia o tráfego interessante através de identificadores de proxy ligados a um intercâmbio de modo rápido, ao passo que o IKEv2 negocia os seletores durante o IKE_AUTH e o responder pode estreitá-los. Uma incompatibilidade produz uma IKE SA estabelecida sem SA filha, que alguns clientes mostram alegremente como ligada.

Trate a ligação antiga como uma fronteira

O RFC 9395 deprecia o IKEv1, por isso uma ligação híbrida legada é uma fronteira de compatibilidade com data, não um alicerce. Corra os dois perfis lado a lado durante a mudança, porque o teste que importa não é se o perfil novo arranca, mas se o mesmo utilizador no mesmo dispositivo chega aos mesmos recursos.

Mantenha a validação de certificados estrita do princípio ao fim. Assim que o cliente deixa de apresentar o seu próprio certificado, a tentação é relaxar a verificação do servidor até o handshake terminar, e isso troca a única prova que resta por um ícone verde.

Anote quatro coisas antes de retirar o perfil antigo: o método EAP, a cadeia de identidade, a fonte de autorização e a data em que o suporte termina.