IKEv2 endereço do servidor versus identidade: o que o cliente realmente verifica

Um gateway que muda de endereço pode continuar funcionando enquanto o mesmo gateway por trás de um novo certificado para, e o inverso também acontece. O endereço informa ao cliente para onde enviar pacotes; a identidade autenticada informa ao cliente se o par que responde é aquele em quem ele deve confiar. IKEv2 os mantém como dois campos separados, o que é útil quando você para de tratá-los como uma string. Eles também são configurados em locais diferentes, então um pode estar correto enquanto o outro está errado.

Verifique-os nesta ordem e pare na primeira incompatibilidade, porque as verificações posteriores assumem que as anteriores foram aprovadas.

Primeiro, qual valor é o endereço

O endereço de conexão é o que o cliente disca: um IP, um nome DNS que resolve para um ou um front-end com balanceamento de carga. Isso são informações de transporte e nada mais. A identidade viaja na carga útil do ID IKEv2 e é então comparada com o certificado do par. Um nome DNS na caixa de endereço não se torna a identidade esperada, e um IP bruto não se torna a identidade apenas porque o soquete está conectado a ele.

Em termos strongSwan, o endereço é right ou left, e a identidade esperada é rightid ou leftid, e é isso que a documentação de configuração IKEv2 descreve. Se você editou apenas o endereço, você configurou metade do par.

Em segundo lugar, o que o certificado pode provar

A identidade possui um tipo e o certificado deve conter um nome correspondente. Uma identidade DNS é satisfeita por uma entrada dNSName na extensão de nome alternativo do sujeito; uma identidade IP precisa de uma entrada iPAddress. Um certificado emitido para vpn.example.com não prova nada sobre o endereço literal 203.0.113.10, e um certificado emitido para esse endereço não prova nada sobre o nome. A reemissão para um nome diferente, portanto, não é uma substituição imediata, mesmo quando a mesma chave e CA são reutilizados.

Os clientes modernos ignoram o nome comum quando existe um nome alternativo de assunto, e muitos o ignoram completamente. Se a lista SAN não contém o valor que o cliente verifica, o handshake falha depois que o certificado já foi aceito como confiável, e é por isso que o log é lido como um erro de identidade em vez de um erro de confiança.

Terceiro, como cada cliente declara a expectativa

Windows pega o nome ou endereço do servidor que você digitou e exige que o certificado corresponda a ele, portanto, digitar um IP cria uma expectativa de IP. O cliente IKEv2 de Android se comporta da mesma maneira e ambos rejeitam um certificado válido e publicamente confiável que nomeia um host diferente. Um perfil pode começar a falhar simplesmente porque alguém substituiu o nome do host pelo seu endereço durante uma migração. Veja o que o cliente pediu antes de ver o que o certificado contém.

Em strongSwan a expectativa é explícita: defina rightid para a identidade que o servidor realmente apresenta, que pode ser diferente da correta. Definir como %any aceita tudo o que o par oferece e remove exatamente a verificação que você está tentando manter.

Quarto, separe o login do usuário da identidade do par

A autenticação EAP e a identidade do servidor respondem a questões diferentes. Uma identidade EAP como [email protected] diz quem é o usuário, depois que o cliente decide que o servidor é o correto. A rotação dessa senha não pode corrigir uma incompatibilidade de identidade de peer, porque a conexão nunca atinge o estágio de login do usuário.

Um relatório limpo deve nomear ambos: a identidade que o cliente esperava, a identidade que o servidor apresentou e as entradas SAN do certificado.

Quinto, mude através de um canal verificado

Quando o gateway se mover legitimamente, atualize o endereço primeiro e deixe a identidade em paz, porque esse é o caso que IKEv2 lida bem. Quando a própria identidade mudar, trate-a como um evento de confiança e obtenha o novo valor de uma fonte em que você já confia, e não do endpoint que está falhando no momento. Uma mensagem entregue pela conexão que você está tentando validar não é uma evidência dessa conexão.

Registre o endereço final, a identidade e a lista SAN juntos nas notas do perfil. A próxima pessoa que tocar no certificado verá qual dos três tem permissão para se mover.