EAP a través dunha pasarela VPN: quen remata o método
Unha pasarela VPN ou ben remata as credenciais ou ben reenvía EAP a RADIUS. Cal das dúas usa o seu cliente decide se un cambio de política do servidor pode axudar.
Os tíckets describen un inicio de sesión VPN fallido e unha política RADIUS que esixe un método máis forte como se fosen o mesmo problema, e non o son. A pasarela acepta unhas credenciais e reenvíaas, ou ben leva unha conversa EAP entre o cliente e o servidor de autenticación. Cal das dúas cousas ocorre decide se un cambio no servidor pode arranxar algo. Lea o intercambio antes de editar o grupo de servidores.
Dous camiños de autenticación que se parecen nun rexistro
No primeiro camiño, a pasarela VPN recolle un usuario e un contrasinal e envía unha RADIUS Access-Request cun atributo de contrasinal. O servidor de autenticación compáraa co seu almacén e responde aceptar ou rexeitar. O cliente nunca executa un método EAP porque nada llo pediu.
No segundo camiño, o cliente e o servidor de autenticación executan o método EAP de extremo a extremo, e a pasarela reenvía atributos EAP-Message entre eles. A pasarela segue rematando a conversa RADIUS externa, pero a lóxica do método vive nos dous extremos.
Ambos camiños producen unha liña no rexistro que di que a autenticación fallou. Só o segundo pode verse afectado polo método EAP que prefire o servidor, e só o primeiro por como le a pasarela o contrasinal. Tratalos como intercambiables é como os equipos pasan un día cambiando grupos de servidores para un cliente que nunca ía falar PEAP.
Onde se executa realmente o método
RFC 3579 define o esquema de paso: o NAS leva paquetes EAP en atributos RADIUS e non necesita código específico para cada tipo de EAP. Por iso unha pasarela pode admitir PEAP e EAP-TLS sen implementar ningún.
Unha pasarela que envía un contrasinal non leva PEAP, aínda que o backend aceptase PEAP doutro cliente. Activar PEAP na política do servidor non engade un método a un cliente que nunca ofreceu un.
Os axustes de autenticación PPP pertencen ao servizo PPP. Non reconfiguran en silencio cada camiño IPsec ou XAuth antigo que usa o mesmo servidor AAA, así que un cambio que funciona para un tipo de acceso pode deixar intacto o outro.
O que o NAS debe admitir
O paso traslada o requisito do código do método ao soporte do portador. A pasarela debe poder levar EAP polo seu protocolo VPN, e o cliente RADIUS que corre nela debe poder enviar e recibir atributos EAP-Message dos tamaños implicados.
En IKEv2, EAP forma parte dun fluxo de autenticación definido, e as comprobacións de identidade e confianza do servidor veñen dese fluxo. Unha etiqueta PEAP tomada dun despregamento 802.1X non se traslada automaticamente porque a negociación ao seu redor é distinta.
O lado do cliente tamén ten requisitos. Debe estar configurado para o método, confiar no certificado do servidor que presenta o método e ter credenciais que o método poida usar. Un método baseado en certificados sen certificado de cliente falla antes de que RADIUS vexa nada, o que é un problema de aprovisionamento e non de política do servidor.
Lea un intento antes de cambiar a política
Capture un único intento aprobado na pasarela e no servidor de autenticación. Busque atributos EAP-Message na petición RADIUS. A súa presenza indica que se usa o camiño de paso; a súa ausencia apunta a un intercambio de credenciais.
Nunha pasarela Linux, unha captura no porto RADIUS mostra que atributos hai no cable:
sudo tcpdump -ni any -X 'udp port 1812' -c 20
Despois compare o punto de rexeitamento. Un fallo na pasarela antes de calquera paquete RADIUS significa que o cliente e a pasarela non se puxeron de acordo sobre o método. Un rexeitamento RADIUS con atributos EAP significa que os extremos executaron o método e un deles rexeitou o resultado.
Planifique a migración como un só cambio de extremo a extremo
Cambiar o método significa cambiar á vez a configuración do cliente, o soporte do portador na pasarela, a política do método no servidor e o almacén de credenciais. Fágao nesa orde e manteña un camiño funcional ata que o novo quede probado. Un cambio só no servidor é unha conxectura e normalmente rompe os clientes que funcionaban. Prepare o cambio nunha identidade de proba antes de tocar o grupo.
Anote a combinación que funciona: protocolo VPN, portador EAP, método do par, método do servidor, tipo de credencial e comprobación de identidade do servidor.
Manteña o AAA de inicio de sesión administrativo separado da autenticación VPN, salvo que a tarefa inclúa ambos explicitamente. Un cambio pensado para o acceso remoto non debe quitarlle a capacidade de xestionar o dispositivo que o remata.