EAP através de um gateway VPN: quem termina o método

Os tíquetes descrevem um login VPN falhado e uma política RADIUS que exige um método mais forte como se fossem o mesmo problema, e não são. O gateway aceita credenciais e encaminha-as, ou transporta uma conversa EAP entre o cliente e o servidor de autenticação. Qual das duas coisas acontece decide se uma alteração do lado do servidor pode corrigir alguma coisa. Leia a troca antes de editar o grupo de servidores.

Dois percursos de autenticação que parecem iguais num registo

No primeiro percurso, o gateway VPN recolhe um nome de utilizador e uma palavra-passe e envia um RADIUS Access-Request com um atributo de palavra-passe. O servidor de autenticação compara-o com o seu armazém e responde aceitar ou rejeitar. O cliente nunca executa um método EAP porque nada lho pediu.

No segundo percurso, o cliente e o servidor de autenticação executam o método EAP de ponta a ponta, e o gateway encaminha atributos EAP-Message entre eles. O gateway continua a terminar a conversa RADIUS exterior, mas a lógica do método vive nos dois extremos.

Ambos os percursos produzem uma linha no registo a dizer que a autenticação falhou. Só o segundo pode ser afetado pelo método EAP preferido do servidor, e só o primeiro pela forma como o gateway lê a palavra-passe. Tratá-los como intercambiáveis é como as equipas passam um dia a mudar grupos de servidores para um cliente que nunca ia falar PEAP.

Onde o método é realmente executado

RFC 3579 define o esquema de passagem: o NAS transporta pacotes EAP em atributos RADIUS e não precisa de código específico para cada tipo de EAP. Por isso um gateway pode suportar PEAP e EAP-TLS sem implementar nenhum dos dois.

Um gateway que submete uma palavra-passe não transporta PEAP, mesmo que o backend aceitasse PEAP de outro cliente. Ativar PEAP na política do servidor não acrescenta um método a um cliente que nunca ofereceu um.

As definições de autenticação PPP pertencem ao serviço PPP. Não reconfiguram silenciosamente cada percurso IPsec ou XAuth antigo que usa o mesmo servidor AAA, por isso uma alteração que funciona para um tipo de acesso pode deixar o outro intacto.

O que o NAS tem de suportar

A passagem desloca o requisito do código do método para o suporte do transporte. O gateway tem de conseguir transportar EAP sobre o seu protocolo VPN, e o cliente RADIUS nele tem de conseguir enviar e receber atributos EAP-Message dos tamanhos em causa.

Em IKEv2, o EAP faz parte de um fluxo de autenticação definido, e as verificações de identidade e confiança do servidor vêm desse fluxo. Uma etiqueta PEAP emprestada de uma implementação 802.1X não se transfere automaticamente porque a negociação à sua volta é diferente.

O lado do cliente também tem requisitos. Tem de estar configurado para o método, confiar no certificado do servidor que o método apresenta e ter credenciais que o método possa usar. Um método baseado em certificados sem certificado de cliente falha antes de o RADIUS ver alguma coisa, e isso é um problema de aprovisionamento e não de política do servidor.

Leia uma tentativa antes de mudar a política

Capture uma única tentativa aprovada no gateway e no servidor de autenticação. Procure atributos EAP-Message no pedido RADIUS. A presença deles diz que o percurso de passagem está a ser usado; a ausência aponta para uma troca de credenciais.

Num gateway Linux, uma captura na porta RADIUS mostra que atributos estão no cabo:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Depois compare o ponto de rejeição. Uma falha no gateway antes de qualquer pacote RADIUS significa que o cliente e o gateway não concordaram sobre o método. Uma rejeição RADIUS com atributos EAP significa que os extremos executaram o método e um deles recusou o resultado.

Planeie a migração como uma única alteração de ponta a ponta

Mudar de método significa mudar em conjunto a configuração do cliente, o suporte do transporte no gateway, a política do método no servidor e o armazém de credenciais. Faça-o nessa ordem e mantenha um percurso funcional até o novo estar provado. Uma alteração só do lado do servidor é um palpite e normalmente quebra os clientes que funcionavam. Prepare a alteração numa identidade de teste antes de tocar no grupo.

Anote a combinação que funciona: protocolo VPN, transporte EAP, método do par, método do servidor, tipo de credencial e verificação de identidade do servidor.

Mantenha o AAA de início de sessão administrativo separado da autenticação VPN, a menos que a tarefa inclua explicitamente ambos. Uma alteração pensada para o acesso remoto não deve retirar-lhe a capacidade de gerir o equipamento que a termina.