Como un inicio de sesión VPN chega a RADIUS e ao teu provedor de identidade

A semana pasada un usuario puido iniciar sesión na VPN e aínda así acabou nunha rede onde non se resolvía nada. O cliente dicía conectado, o rexistro da pasarela dicía Access-Accept e o equipo de identidade dicía que a conta estaba ben. O inicio de sesión funcionara; a autorización que había detrás, non. Cando falla un inicio de sesión VPN, percorro o camiño que realmente segue a solicitude — cliente, pasarela, servidor RADIUS, provedor de identidade — e deteño me no primeiro salto cuxa resposta non concorda coa seguinte.

O cliente nunca fala RADIUS

Diga o que diga a aplicación do portátil, o seu primeiro salto é o protocolo VPN: IKEv2, OpenVPN, WireGuard ou un cliente baseado en TLS. RADIUS non aparece nese intercambio. O cliente autentícase ante a pasarela cun certificado, un nome de usuario e un contrasinal, ou un método EAP transportado dentro da configuración do túnel.

Iso importa cando se len rexistros, porque o erro xenérico de autenticación que ve o usuario prodúceo a pasarela despois de falar xa con outra cousa. Se o cliente nunca chega á pasarela, non existe ningunha solicitude RADIUS que depurar e unha hora dedicada ao servidor RADIUS é tempo perdido. Confirma que o túnel se levantou antes de tocar o backend.

A pasarela é o cliente RADIUS

En canto a configuración do túnel chega ao punto no que hai que comprobar as credenciais, a pasarela convértese nun servidor de acceso á rede. Constrúe unha Access-Request: User-Name, un contrasinal ou carga EAP, NAS-IP-Address ou NAS-Identifier, e un Message-Authenticator cando o método o esixe. A solicitude vai a UDP 1812 por defecto, e a contabilidade a 1813. As instalacións máis antigas aínda usan 1645 e 1646, así que unha regra de cortalumes escrita para un par explica moitas fallas silenciosas.

Ambos os lados comparten un segredo, e non é unha credencial de usuario. Asina o intercambio e cada resposta vérifícase contra el. Configura o segredo de forma distinta nos dous lados e o servidor non responde cun segredo incorrecto: descarta a solicitude ou a resposta non supera a verificación, de modo que a pasarela informa dun tempo de espera. Un segredo incorrecto e un servidor morto parecen idénticos desde a pasarela, por iso probo o salto cunha ferramenta de cliente antes de culpar o directorio.

O protocolo é pequeno e antigo — RFC 2865 define o intercambio de autenticación —, pero os atributos que transporta son a base sobre a que se constrúe a maior parte da política VPN.

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

O servidor RADIUS pode ser só a fachada do provedor de identidade

A xente fala de RADIUS e do provedor de identidade como se fosen a mesma caixa. A miúdo non o son. O servidor RADIUS recibe a Access-Request e logo pregunta a outra cousa — Active Directory por LDAP ou Kerberos, un ficheiro de usuarios local ou un servizo externo — antes de responder. FreeRADIUS co módulo LDAP ou krb5, Windows NPS e Cisco ISE ocupan todos esta posición.

A distinción decide onde mirar. Un contrasinal rexeitado é unha resposta do provedor de identidade retransmitida por RADIUS. Un tempo de espera adoita ser o tramo RADIUS-directorio: unha conta de enlace caducada, un directorio inalcanzable ou unha solicitude encamiñada ao backend equivocado. Se o nome de usuario leva un sufixo de dominio, o servidor pode encamiñar por el, e a mesma conta enviada como CORP\alice e [email protected] pode acabar en lugares distintos. En Windows NPS, o rexistro Security anota 6272 para unha concesión e 6273 para unha denegación, o que di se a decisión veu de NPS.

Le o fallo no salto que o produciu

Unha soa mensaxe de non se pode conectar cobre catro fallos distintos. Antes de cambiar nada, empareja o síntoma co salto que o produciu.

A última fila é a que envía á xente ao equipo equivocado. Access-Accept significa que as credenciais se aceptaron; non significa que a pasarela colocase o usuario no grupo correcto nin empuxase rutas. Os atributos de grupo só importan se a política da pasarela os le. Vin un inicio de sesión correcto caer nun grupo de convidados porque o mapeo de grupos estaba configurado no lado RADIUS para un atributo distinto do que inspecciona a pasarela.

Segue un inicio de sesión de principio a fin

Escolle unha soa conta de proba e unha pasarela, e observa o mesmo intento nos catro puntos. Inicia unha execución de depuración no lado RADIUS — freeradius -X imprime a solicitude e cada módulo que toca —, segue o rexistro de autenticación da pasarela e executa tcpdump para o intercambio UDP. Conéctate unha vez e le as catro trazas en orde.

O que queres ver é acordo: a pasarela preguntou polo usuario que esperabas, o servidor RADIUS escolleu o backend que esperabas, ese backend devolveu unha decisión e os atributos da resposta coinciden coa política que aplica a pasarela. O primeiro lugar onde as trazas non coinciden é a túa liña de fallo. Se a resposta non leva atributo de grupo, o problema está no lado RADIUS, non no perfil VPN; se o atributo está e a pasarela o ignora, o problema é a política da pasarela.

Unha nota de seguridade mentres estás aí. O segredo compartido protexe o intercambio, pero non cifra a maioría dos atributos. Se a pasarela e o servidor RADIUS están en segmentos distintos, pon ese salto en RADIUS sobre TLS ou nunha ruta privada. Un túnel de usuario cifrado non di nada sobre a ligazón do backend.

Antes de pechar o tícket, confirma catro cousas. A pasarela pode alcanzar o servidor RADIUS no porto para o que está realmente configurada. O segredo compartido coincide en ambos os lados. O servidor RADIUS resolve a forma exacta do nome de usuario que envía a pasarela. A aceptación leva os atributos que necesita a política da pasarela. Cando se cumpren as catro, un inicio de sesión que segue fallando é un problema de política da pasarela, non de autenticación.