strongSwan EAP: a identidade IKE contra o nome AAA esperado

A autenticação EAP sobre IKEv2 pode pedir a um cliente que valide dois nomes de servidor diferentes numa única ligação. O gateway que termina o IKE apresenta uma identidade, e o backend EAP que termina a troca TLS interna pode apresentar outra. No strongSwan vivem em blocos de configuração diferentes, e pôr um nome no bloco errado produz uma falha que parece um problema de certificado. É a leitura de qual validação falhou que indica qual bloco editar.

Uma ligação, duas identidades de servidor

A primeira identidade pertence à troca IKE. O cliente marca um endereço e espera que o par prove uma identidade concreta, normalmente o nome no certificado do gateway.

A segunda pertence ao EAP. Com PEAP ou TTLS, o cliente constrói um túnel TLS até ao servidor de autenticação dentro da IKE SA, e esse servidor interno apresenta o seu próprio certificado. Quando o backend é um anfitrião separado, o nome difere do do gateway. Um cliente que só verifica o primeiro nome aceita o que o segundo afirmar. E um cliente configurado com um único nome nos dois sítios falha assim que os dois diferem de facto.

Ambos os nomes vêm da configuração do operador, não do certificado que faz desaparecer o erro. Perguntar ao operador pelos detalhes da implementação é mais rápido do que adivinhar dois nomes de anfitrião.

Que campo pertence a que camada

No swanctl, o endereço e a identidade IKE são definições separadas, e a identidade EAP é uma terceira.

O endereço remoto escolhe para onde vão os pacotes, e a identidade remota indica o que o par tem de provar. A expectativa EAP é escrita sob o bloco local, porque descreve a troca EAP deste cliente e não o comportamento IKE do par. É precisamente esta colocação que é mal lida. O nome está na configuração do cliente enquanto descreve um servidor, e é exatamente por isso que parece fora de lugar.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

Esse fragmento não é uma ligação completa; material de confiança, credenciais e políticas das ligações filhas ainda têm de estar presentes. Copiá-lo à letra para um ficheiro de trabalho substituiria definições de que ainda precisa.

Porque é que aaa_id vive sob local

O bloco local descreve o que este extremo faz durante a autenticação, incluindo o método que vai usar e a identidade que espera que o outro extremo apresente para esse método. Nada nele afirma que o servidor AAA corre na mesma máquina.

O valor predefinido torna a armadilha mais afiada. Quando não está definido um valor explícito, a identidade AAA esperada segue a identidade remota, pelo que uma implementação com um só nome funciona e esconde a distinção. Um valor explícito só importa quando a implementação EAP termina realmente noutro sítio. Defini-lo para um nome diferente sem esse motivo cria uma falha que o operador não consegue reproduzir. Leia a implementação antes de inventar um segundo nome.

Mantenha o valor idêntico ao que o certificado do backend afirma realmente, incluindo a forma do nome. Um ponto final ou um curinga que não cubra o anfitrião basta para a verificação falhar.

Interfaces que não conseguem exprimir a separação

Um perfil do NetworkManager não é a mesma interface de configuração que o swanctl. O plugin por trás expõe um conjunto mais estreito de controlos de identidade, e quais existem depende da versão instalada.

Isso importa quando a implementação precisa mesmo de dois nomes. Um campo rotulado como identidade do servidor pode configurar uma camada e não a outra, pelo que um perfil pode parecer correto e falhar na verificação interna. Verifique o que o plugin instalado suporta antes de assumir que o perfil consegue exprimir essa disposição. Se não conseguir, a escolha é do operador: um caminho de aprovisionamento diferente ou um desenho corrigido da identidade do servidor. Enfraquecer o PEAP ou aceitar qualquer nome muda a política de autenticação em vez de a corrigir.

A alternativa não é algo a inventar no cliente. Peça a disposição suportada por escrito e guarde essa resposta com o perfil.

Distinga uma discrepância de identidade de um certificado expirado

Uma discrepância de nome e um certificado expirado são falhas diferentes, e o registo distingue-as. Leia a mensagem antes de decidir que campo alterar.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

Definir a identidade AAA pretendida não renova um certificado nem estabelece confiança no seu emissor, e renovar um certificado não corrige um nome esperado errado. Leia qual validação falhou antes de editar outro campo de identidade. Depois recarregue a configuração e confirme que a ligação carregada mostra o valor definido, porque um ficheiro editado que nunca foi carregado não muda nada. Escreva ambos os nomes e as suas camadas nas notas de implementação.