Framed-IP-Address de RADIUS para un enderezo de cliente VPN estable

RADIUS pode responder cun enderezo para un usuario concreto; se o túnel o recibe de verdade depende da pasarela. É nesa fenda entre o devolto e o aplicado onde fallan a maioría dos plans de enderezo estable. Un atributo nunha resposta de proba demostra que o servidor pode envialo, non que o servizo de acceso remoto o aplique. A secuencia seguinte comproba as dúas metades antes de que o enderezo acabe nas regras da devasa.

Decide que capa é dona do enderezo

As pasarelas de acceso remoto adoitan ter un conxunto local, e moitas tamén poden aceptar un enderezo da resposta de autenticación. Cales dos dous gaña depende da plataforma, do protocolo e da configuración do servizo, así que le a regra de precedencia para a versión exacta en uso. Cando o conxunto local ten prioridade, o atributo é decoración e o cliente aterriza igualmente nun enderezo aleatorio. Anota a decisión, incluído se un valor devolto debe quedar dentro do rango do conxunto ou pode caer fóra del.

RFC 2865 define Framed-IP-Address como o enderezo que se debe configurar para o usuario, e non di nada sobre a disposición dunha pasarela concreta a respectalo. A documentación do fabricante é a autoridade sobre a precedencia, non a definición do atributo.

Envía unha solicitude de proba e le a resposta

Proba o servidor illado primeiro, para que un atributo ausente non se confunda cun problema da pasarela. radtest envía unha Access-Request e imprime os atributos que volven.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Busca Framed-IP-Address na Access-Accept e confirma que o valor é o desexado e non un enderezo do conxunto dunha regra de reserva. Cando o atributo falta, a entrada do usuario ou a política de autorización non coinciden, e o axuste da pasarela non pode fornecer o que o servidor nunca enviou. Repite a solicitude mentres o servidor está en modo de depuración se a resposta é difícil de rastrear ata unha regra concreta. Mantén o segredo compartido fóra do historial da consola e dos tickets, porque o marcador de arriba non é unha credencial.

Confirma que a pasarela aplicou o valor

Unha resposta correcta é só a metade do contrato. O enderezo que aparece na interface do túnel é a observación que importa, e lese no cliente en vez de deducirse da configuración da pasarela.

ip -4 addr show tun0

Compara ese enderezo co atributo da Access-Accept. Unha discrepancia significa que a pasarela ignorou ou reescribiu o valor, o que reabre a cuestión da precedencia da primeira sección. Reconecta unha vez máis, porque unha reserva que só funciona no primeiro intento adoita indicar unha sesión obsoleta ou unha concesión aínda en mans da conexión anterior. Anota a versión da pasarela e o protocolo xunto ao resultado, para que a seguinte persoa poida saber se o comportamento depende da versión.

Planifica a concorrencia e a revogación

Un nome de usuario en dous dispositivos non pode corresponder a un só enderezo a menos que a pasarela distinga as sesións por algo máis que o inicio de sesión. Decide se a asignación pertence a unha persoa, a un dispositivo rexistrado ou a unha identidade de certificado, e fai esa escolla explícita no almacén de políticas. Proba un segundo cliente simultáneo e compara os dous enderezos asignados, xa que unha colisión aquí reaparece despois como un fallo de encamiñamento. O mesmo coidado pertence ao plan de revogación, porque un enderezo reasignado mentres as vellas regras da devasa aínda o citan convértese nun erro de autorización.

O enderezo estable simplifica regras e rexistros, pero nunca demostra quen xerou un paquete. A autenticación e a autorización de destino seguen importando cando ese enderezo pase despois a outra sesión.