Políticas de interfaz

Autenticación de puerto de servidor 802.1X

IEEE 802.1X es un estándar IEEE para el control de acceso de red basado en puertos de red. Forma parte del grupo de protocolos de red IEEE 802.1. Proporciona un mecanismo de autenticación a los dispositivos que desean conectarse a una LAN.

IEEE 802.1X define la encapsulación del Protocolo de autenticación extensible (EAP) sobre IEEE 802, que se conoce como "EAP sobre LAN" o EAPOL.

La autenticación 802.1X involucra a tres partes: un suplicante, un autenticador y un servidor de autenticación. El suplicante es un dispositivo cliente (como un servidor) que desea conectar a la LAN. El término "suplicante" también se utiliza indistintamente para referirse al software que se ejecuta en el cliente que proporciona credenciales al autenticador. El autenticador es un dispositivo de red que proporciona un vínculo de datos entre el cliente y la red y puede permitir o bloquear el tráfico de red entre ambos, como un conmutador Ethernet o un punto de acceso inalámbrico; y el servidor de autenticación suele ser un servidor de confianza que puede recibir y responder a solicitudes de acceso de red, y puede indicar al autenticador si se va a permitir la conexión, y varias configuraciones que se deben aplicar a la conexión o configuración de ese cliente. Los servidores de autenticación suelen ejecutar software compatible con los protocolos RADIUS y EAP. En algunos casos, el software del servidor de autenticación se puede estar ejecutando en el hardware del autenticador.

El autenticador actúa como guardia de seguridad de una red protegida. El suplicante (es decir, el dispositivo del cliente) no puede acceder a través del autenticador al lado protegido de la red hasta que la identidad del suplicante haya sido validada y autorizada. Con la autenticación basada en puertos 802.1X, el suplicante debe proporcionar inicialmente las credenciales requeridas al autenticador; estas habrán sido especificadas de antemano por el administrador de la red y podrían incluir un nombre de usuario/contraseña o un certificado digital permitido. El autenticador reenvía estas credenciales al servidor de autenticación para decidir si se va a conceder el acceso. Si el servidor de autenticación determina que las credenciales son válidas, informa al autenticador, lo que a su vez permite que el suplicante (dispositivo cliente) acceda a los recursos ubicados en el lado protegido de la red.

Las extensiones de 802.1X también pueden permitir que el servidor de autenticación pase las opciones de configuración de puerto al autenticador. Un ejemplo es usar atributos de par de valor RADIUS para pasar un ID de VLAN, lo que permite el acceso suplicante a una de varias VLAN.

(Fuente: Wikipedia, revisada por Apstra)

Puede administrar la configuración 802.1X en dispositivos de red con autenticación de puerto de servidor 802.1X, una colección de configuraciones de política de interfaz.

La política de interfaz 802.1X solo se admite en Junos (como vista previa técnica) y en los dispositivos de red física arista EOS. Juniper Evolved no admite esta función por el momento.

Nota:

La política de interfaz 802.1X en Junos se ha clasificado como una función Juniper Apstra Technology Preview. Estas funciones son "tal como están" y de uso voluntario. El soporte de Juniper intentará resolver cualquier problema que los clientes experimenten al usar estas funciones y creará informes de errores en nombre de los casos de soporte. Sin embargo, Es posible que Juniper no proporcione servicios de soporte integrales a las funciones de vista previa técnica.

Para obtener más información, consulte la página De vista previa de la tecnología Apstra de Juniper o póngase en contacto con el soporte de Juniper.

Esta configuración de política permite que la red requiera servidores L2 en un plano para autenticarse en un servidor RADIUS antes de que se le proporcione acceso a la red.

El operador de red puede requerir que los clientes se autentifiquen mediante EAP-TLS, certificados, nombre de usuario y contraseña simples o omisión de autenticación MAC.

Nota:

La compatibilidad con protocolos de cifrado, certificados, EAP, se negocia entre el suplicante RADIUS y el servidor RADIUS, y el conmutador no lo controla.

Después de que se produzca la autenticación, un servidor RADIUS opcionalmente puede establecer un atributo de ID de VLAN en tiempo de autenticación para mover el suplicante a una VLAN definida, conocida por un ID de VLAN específico de leaf.

En esta sección se describen las tareas necesarias para crear políticas de interfaz que se usarán con la autenticación del puerto de servidor del servidor 802.1X y la asignación dinámica de VLAN.

Escenarios comunes

A continuación, se presentan algunos escenarios comunes para la autenticación de puerto 802.1X.

• El dispositivo es compatible con 802.1X, las credenciales y la VLAN se configuran en Radius
• El dispositivo es compatible con 802.1X, pero las credenciales no están configuradas en Radius
• El dispositivo no es compatible con 802.1X, pero la dirección MAC del dispositivo está configurada en Radius
• El dispositivo no es compatible con 802.1X y la dirección MAC del dispositivo no está configurada en Radius

Flujo de trabajo de la política de interfaz 802.1X

1. Crear redes virtuales (por ejemplo, VLAN de datos, VLAN de reserva, VLAN dinámica)
2. Crear servidores AAA
3. Crear política de interfaz 802.1X
4. Asignar puertos y VLAN de reserva

Crear redes virtuales para interfaces

Cree redes virtuales para la política de interfaz según la tabla a continuación. Sugerimos crear estas redes virtuales con un ID de VLAN coherente entre todos los dispositivos leaf (en lugar de usar un conjunto de recursos). Para obtener más información acerca de cómo crear redes VLAN, consulte Redes virtuales.

Descripción	de parámetros
VLAN de datos (asignada a los puertos)	Las interfaces tendrán configuración 802.1X si se asigna al menos una VLAN al puerto. Si un puerto no tiene asignadas redes VLAN, la configuración 802.1X no se representará en la interfaz. La interfaz se configurará como un puerto enrutado.
VLAN dinámica (opcional, asignada a dispositivos leaf, no a puertos)	Opcionalmente, el servidor RADIUS elige el ID de VLAN dinámicamente cuando el usuario (suplicante) está autenticado y autorizado. El software Apstra no tiene control sobre la asignación dinámica de VLAN. Esta decisión la toma la configuración radius, no la configuración del conmutador.
VLAN de reserva (opcional, asignada a dispositivos leaf, no a puertos)	La VLAN de reserva se puede asignar al usuario (suplicante) en caso de error de autenticación. En caso de reserva, la VLAN se controla mediante la configuración del conmutador. Debe existir una VLAN dinámica RADIUS o una VLAN de reserva en el conmutador, pero no es necesario enlazar puntos de conexión a esa VLAN. Solo tiene que existir en el conmutador.

Crear servidor AAA para la política de interfaz

Cree el servidor AAA. Para obtener más información, consulte Servidores AAA (Plano).

Crear política de interfaz 802.1x

Debe crear la política antes de poder asignarle interfaces o VLAN de reserva.

1. Desde el plano, vaya a Políticas de > por etapas > políticas de interfaz y haga clic en Crear política de interfaz.
2. Ingrese un nombre y seleccione 802.1x en la lista desplegable.
3. Seleccione el control de puerto.
   • dot1x habilitado : requiere puertos para autenticar EAPOL antes de tener acceso a la red.
   • Denegar acceso : bloquea completamente el puerto; no se permite ningún acceso a la red. No se necesitan otros parámetros. Ejemplo: como una configuración de cuarentena para desactivar rápidamente los puertos que pueden estar infectados.
4. Seleccione el modo host.
   • Multi-host** (predeterminado): permite que todas las direcciones MAC del puerto se autentiquen después de la primera autorización correcta. Después de que el primer host se desautorice, todas las MAC del puerto se des autentifican.
   • Un solo host : permite que un solo host se autentique; no se permiten todos los demás MAC.
5. Si desea habilitar Auth Bypass de MAC en Arista EOS, active la casilla Habilitado? La habilitación de la omisión de autenticación MAC permite que un conmutador envíe la dirección MAC al servidor RADIUS si el puerto no se autentica dentro del tiempo de espera de autenticación. Las solicitudes de omisión de autenticación mac (MAB) solo se envían si el cliente no responde a las solicitudes RADIUS o si el cliente falla la autenticación.
   Nota:

   La omisión de la autenticación MAC se debe configurar junto con el control de puerto 802.1X.

   PRECAUCIÓN:

   El comportamiento de falla de auth bypass de MAC puede ser diferente entre los proveedores de conmutadores y los principales modelos de conmutadores.

6. Escriba tiempo de espera de re-autenticación (opcional) para configurar un período de tiempo (segundos). El tiempo de espera de la reententificación hace que el conmutador solicite a cualquier cliente que vuelva a autenticarse en la red después de que expire el tiempo de espera. Esto también vuelve a activar la omisión de mac Auth.

   Si el tiempo de espera de reententificación no está configurado, no se representa ninguna configuración relacionada en el conmutador. Esto significa que el puerto de conmutación será cualquiera que sea el sistema operativo por defecto del proveedor. Si se configura un valor, se habilitará la re autentificación 802.1X en el puerto y se configurará un valor de tiempo.

7. Haga clic en Crear para crear la política de interfaz y volver a la vista de tabla.

Asignar puertos y VN de reserva a la política de interfaz

En estos pasos, se agregan interfaces o redes VLAN dinámicas a la política de interfaz.

1. Desde el plano, vaya a Políticas de > escenarios > políticas de interfaz y desplácese hacia abajo hasta la sección Asignar a.
2. Asigne puertos e interfaces:Haga clic en nombres de hoja para expandir interfaces y, a continuación, haga clic en puertos e interfaces para asignarlos. Tenga en cuenta que no puede asignar puertos asignados a políticas en conflicto.
3. Asignar VN de reserva:La asignación de la red virtual de reserva es específica de la hoja. Para volver a usar la reserva en varios dispositivos leaf, debe asignarla a cada leaf. Cualquier VN que se asigne al leaf se puede usar como red virtual de reserva; no hay restricciones.
4. Después de configurar la política, las opciones ya están visibles, incluidas las interfaces a las que se aplica la configuración.
   Nota:

   Las configuraciones de interfaz AAA, Dot1x y Dot1x ahora se insertan en los dispositivos leaf. La siguiente es una parte de la configuración de ejemplo que se representa para el conmutador EOS Arista.