Capítulo 31:
Listas de control de acceso
Una de las habilidades más importantes que necesita
un administrador de redes es el dominio de las listas de control de acceso
(ACL). Las ACL proporcionan capacidades de filtrado de paquetes para controlar
el flujo de tráfico.
Los diseñadores de
red utilizan firewalls para proteger las redes del uso no autorizado. Los
firewalls son soluciones de hardware o de software que aplican las políticas de
seguridad de la red. Imagine una cerradura en la puerta de una habitación
dentro de un edificio. La cerradura permite que solo los usuarios autorizados
que poseen una llave o una tarjeta de acceso puedan entrar. De igual forma, un
firewall filtra los paquetes no autorizados o potencialmente peligrosos e
impide que ingresen a la red.
En un router Cisco,
puede configurar un firewall simple que proporcione capacidades básicas de
filtrado de tráfico mediante ACL. Los administradores utilizan las ACL para
filtrar el tráfico, permitiendo o bloqueando paquetes específicos en sus redes.
Este capítulo
comienza con una revisión de las ACL y de la configuración de ACL IPv4
estándar. Más adelante en este capítulo, se explica cómo configurar y
solucionar problemas en las ACL IPv4 extendidas y ACL IPv6 en un router Cisco
como parte de una solución de seguridad. Se incluyen consejos, consideraciones,
recomendaciones y pautas generales sobre cómo utilizar las ACL. Además, en este
capítulo se ofrece la oportunidad de desarrollar su dominio de las ACL con una
serie de lecciones, actividades y ejercicios de práctica de laboratorio.
Listas ACL y la
máscara de wildcard
Nota: Esta sección incluye un breve repaso del funcionamiento y de
la configuración de ACL IPv4 estándar. Si necesita un repaso adicional,
consulte el Capítulo 7, Listas de control de acceso en el curso Routing and
Switching Essentials v6 .
Una ACL es una lista secuencial de instrucciones permit
(permitir) o deny (denegar), conocidas como “entradas de control de acceso”
(ACE). Las ACE también se denominan comúnmente “instrucciones de ACL”. Cuando
el tráfico de la red atraviesa una interfaz configurada con una ACL, el router
compara la información dentro del paquete con cada ACE, en orden secuencial,
para determinar si el paquete coincide con una de las ACE.
Las ACE de IPv4 incluyen el uso de máscaras wildcard. Una
máscara wildcard es una cadena de 32 dígitos binarios que el router
utiliza para determinar qué bits de la dirección debe examinar para obtener una
coincidencia.
En la figura 1 se muestra cómo las diferentes máscaras wildcard
filtran las direcciones IPv4. Recuerde que, en el ejemplo, el valor
binario 0 indica un bit que debe coincidir y el valor binario 1
indica un bit que se puede ignorar.
La figura 2 muestra tres ejemplos de máscaras de wildcard
que coinciden con subredes.
En el primer ejemplo, la máscara wildcard estipula que cada bit
en la IPv4 192.168.1.1 debe coincidir con exactitud.
En el segundo ejemplo, la máscara wildcard estipula que no habrá
coincidencias.
En el tercer ejemplo, la máscara wildcard estipula que cualquier
host dentro de la red 192.168.1.0/24 tendrá una coincidencia.
Cómo aplicar
listas ACL a una interfaz
Las listas ACL se pueden configurar para aplicarse al tráfico
entrante o al tráfico saliente, como se muestra en la figura 1. La última
instrucción de una ACL es siempre una denegación implícita. Esta instrucción se
inserta automáticamente al final de cada ACL, aunque no se vea en la salida del
comando show.
Como se muestra en la figura 2, puede configurar una ACL por
protocolo, por sentido, por interfaz:
·
Una ACL por protocolo: para
controlar el flujo de tráfico en una interfaz, se debe definir una ACL para
cada protocolo habilitado en la interfaz.
·
Una ACL por sentido: las ACL
controlan el tráfico en una interfaz de a un sentido por vez. Se deben crear
dos ACL diferentes para controlar el tráfico entrante y saliente.
·
Una ACL por interfaz: las ACL
controlan el tráfico de una interfaz, por ejemplo, GigabitEthernet 0/0.
Una conversación
TCP
Los administradores pueden controlar el tráfico de red basándose
en varias características, incluido el puerto TCP que se solicita. Es más fácil
comprender cómo filtra el tráfico una ACL si se examina el diálogo que se
produce durante una conversación TCP, por ejemplo, cuando se solicita una
página web.
Cuando un cliente solicita datos a un servidor web, IP
administra la comunicación entre la computadora (origen) y el servidor
(destino). TCP administra la comunicación entre el navegador web (aplicación) y
el software del servidor de red.
En la animación que se muestra en la figura 1, se ilustra
cómo se lleva a cabo una conversación TCP/IP. Los segmentos TCP se marcan con
indicadores que denotan su objetivo: la sesión comienza (se sincroniza) con un
indicador SYN, el indicador ACK es un acuse de recibo de un segmento esperado,
y un indicador FIN finaliza la sesión. Un indicador SYN/ACK confirma que la
transferencia está sincronizada. Los segmentos de datos TCP incluyen el
protocolo del nivel más alto necesario para dirigir los datos de aplicación a
la aplicación correcta.
Los segmentos de datos TCP también identifican el puerto que
coincide con el servicio solicitado. En la figura 2, se muestran los
rangos de puertos UDP y TCP. La figura 3 muestra una lista de números de
puertos conocidos.
Filtrado de
paquetes con ACL
El filtrado de paquetes controla el acceso a una
red mediante el análisis de los paquetes entrantes y salientes y la
transferencia o el descarte de estos según criterios determinados. El filtrado
de paquetes se puede realizar en la capa 3 o en la capa 4. Las ACL
estándar filtran sólo en la Capa 3. Las ACL extendidas filtran en las
capas 3 y 4.
Por ejemplo, una
ACL se puede configurar para “permitir el acceso web a los usuarios de la
red A, pero denegar el resto de los servicios a los usuarios de esa red.
Denegar el acceso HTTP a los usuarios de la red B, pero permitir que los
usuarios de la red B tengan todo otro tipo de acceso”. Consulte la figura para
analizar la secuencia de decisiones que aplica el filtro de paquetes para
realizar esta tarea.
Para esta
situación, el filtro de paquetes examina cada paquete de la siguiente manera:
·
Si el paquete es un SYN de TCP de la
red A que utiliza el puerto 80, tiene permiso para pasar. El resto de
los tipos de acceso se deniega a esos usuarios.
·
Si el paquete es un SYN de TCP de la
red B que utiliza el puerto 80, se bloquea. Sin embargo, se permite
el resto de los tipos de acceso.
Este es solo un
ejemplo sencillo. Se pueden configurar varias reglas para permitir o denegar
otros servicios a usuarios específicos.
ACL IPv4
estándar y extendidas
Los dos tipos de ACL de IPv4 de Cisco son estándar
y extendida.
Las ACL estándar se
pueden utilizar para permitir o denegar el tráfico de direcciones IPv4 de
origen únicamente. El destino del paquete y los puertos involucrados no se
evalúan. En el ejemplo de la figura 1, se permite todo el tráfico de la
red 192.168.30.0/24. Debido a la instrucción implícita “deny any” al final,
todo el tráfico, excepto el tráfico proveniente de la red 192.168.30.0/24, se
bloquea con esta ACL. Las ACL estándar se crean en el modo de configuración
global.
Las ACL extendidas
filtran paquetes IPv4 según varios atributos:
·
Tipo de protocolo
·
Dirección IPv4 de origen
·
Dirección IPv4 de destino
·
Puertos TCP o UDP de origen
·
Puertos TCP o UDP de destino
·
Información optativa de tipo de
protocolo para un control más preciso
En la
figura 2, la ACL 103 permite el tráfico que se origina desde
cualquier dirección en la red 192.168.30.0/24 hasta cualquier red IPv4 si el
puerto de host de destino es 80 (HTTP). Las ACL extendidas se crean en el modo
de configuración global.
Nota: Se analizará la sintaxis del comando con más
detalle en este capítulo.
Listas ACL
denominada y numeradas
Las ACL estándar y extendidas se pueden crear con un número o un
nombre para identificar la ACL y su lista de instrucciones.
El uso de ACL numeradas es un método eficaz para determinar el
tipo de ACL en redes más pequeñas con tráfico definido de forma más homogénea.
Sin embargo, un número no proporciona información sobre el propósito de la ACL.
Por este motivo, se puede usar un nombre para identificar una ACL de Cisco.
En la ilustración, se resumen las reglas que se deben seguir
para designar las ACL numeradas y denominada.
Dónde ubicar
las ACL
Cada ACL se debe colocar donde tenga más impacto en
la eficiencia. Como se muestra en la ilustración, las reglas básicas son las
siguientes:
·
Listas ACL
extendidas: coloque las listas ACL
extendidas lo más cerca posible del origen del tráfico que se filtrará. De esta
manera, el tráfico no deseado se deniega cerca de la red de origen, sin que
cruce la infraestructura de red.
·
Listas ACL
estándar: debido a que en las listas ACL
estándar no se especifican las direcciones de destino, colóquelas tan cerca del
destino como sea posible. Si una ACL estándar se ubicara en el origen del
tráfico, la instrucción “permir” o “deny” se ejecutará según la dirección de
origen determinada independientemente de adónde se dirige el tráfico.
La colocación de la
ACL y, por lo tanto, el tipo de ACL que se utiliza también puede depender de
diversos factores:
·
Alcance del control
del administrador de la red: la colocación de
la ACL puede depender de si el administrador de red controla tanto la red de
origen como la de destino o no.
·
Ancho de banda de
las redes involucradas: el filtrado del
tráfico no deseado en el origen impide la transmisión de ese tráfico antes de
que consuma ancho de banda en la ruta hacia un destino. Esto es de especial
importancia en redes con un ancho de banda bajo.
·
Facilidad de
configuración: si un administrador de red desea
denegar el tráfico proveniente de varias redes, una opción es utilizar una
única ACL estándar en el router más cercano al destino. La desventaja es que el
tráfico de dichas redes utilizará ancho de banda de manera innecesaria. Se
puede utilizar una ACL extendida en cada router donde se origina tráfico. Esto
ahorra ancho de banda, ya que el tráfico se filtra en el origen, pero requiere
la creación de ACL extendidas en varios routers.
Nota: Para la certificación CCNA, la regla general es
que las ACL extendidas se coloquen lo más cerca posible del origen y que las
ACL estándar se coloquen lo más cerca posible del destino.
Ejemplo de
ubicación de una ACL estándar
En la ilustración, el administrador desea impedir
que el tráfico que se origina en la red 192.168.10.0/24 llegue a la red
192.168.30.0/24.
Si la ACL estándar
se coloca en la interfaz de salida del R1 (no se muestra en la figura), eso
evitaría que el tráfico de la red 192.168.10.0/24 alcance cualquier red a la
que se pueda llegar a través de la interfaz Serial 0/0/0 del R1.
De acuerdo con las
pautas básicas de colocación de ACL estándar cerca del destino, en la
ilustración se muestran dos interfaces posibles del R3 a las que aplicar la ACL
estándar:
·
Interfaz S0/0/1 del
R3: la aplicación de una ACL estándar
para impedir que el tráfico de 192.168.10.0/24 ingrese a la interfaz S0/0/1
evita que dicho tráfico llegue a 192.168.30.0/24 y al resto de las redes con
las que se puede comunicar R3. Esto incluye la red 192.168.31.0/24. Dado que el
objetivo de la ACL es filtrar el tráfico destinado solo a 192.168.30.0/24, no
se debe aplicar una ACL estándar a esta interfaz.
·
Interfaz G0/0 del
R3: al aplicar una ACL estándar al
tráfico que sale por la interfaz G0/0, se filtran los paquetes que van de
192.168.10.0/24 a 192.168.30.0/24. Esto no afecta a las otras redes con las que
se puede comunicar R3. Los paquetes de 192.168.10.0/24 aún pueden llegar a
192.168.31.0/24.
Ejemplo de
ubicación de una ACL extendida
La regla básica para la colocación de una ACL
extendida es colocarla lo más cerca posible del origen. Esto evita que el
tráfico no deseado se envíe a través de varias redes y luego sea denegado
cuando llegue a destino. Sin embargo, los administradores de red solo pueden
colocar las listas ACL en los dispositivos que controlan. Por lo tanto, la
colocación se debe determinar en el contexto de hasta dónde se extiende el control
del administrador de red.
En la figura, el
administrador de la empresa A, que incluye las redes 192.168.10.0/24 y
192.168.11.0/24 (conocidas como .10 y .11 en este ejemplo) desea controlar el
tráfico hacia la empresa B. Específicamente, el administrador desea denegar el
tráfico FTP y Telnet de la red .11 a la red 192.168.30.0/24 (.30, en este
ejemplo) de la empresa B. Al mismo tiempo, se debe permitir que el resto del
tráfico de la red .11 salga de la empresa A sin restricciones.
Existen varias formas
de lograr estos objetivos. Una ACL extendida en el R3 que bloquee Telnet y FTP
de la red .11 cumpliría el objetivo, pero el administrador no controla el
R3. Además, esta solución también permite que el tráfico no deseado cruce toda
la red y luego sea bloqueado en el destino. Esto afecta la eficacia general de
la red.
Una mejor solución
es colocar una ACL extendida en R1 que especifique tanto las direcciones de
origen como las de destino (red .11 y red .30, respectivamente) y que aplique
la regla “No se permite que el tráfico de Telnet y FTP de la red .11 vaya a la
red .30”. La figura muestra dos interfaces en R1 en las que sería posible
aplicar la ACL extendida:
·
Interfaz S0/0/0 del
R1 (de salida): una de las posibilidades es aplicar
una ACL extendida de salida en la interfaz S0/0/0. Debido a que la ACL
extendida puede examinar tanto la dirección de origen como la de destino, solo
se deniegan los paquetes FTP y Telnet de 192.168.11.0/24, y el R1 reenvía el
resto del tráfico de 192.168.11.0/24 y de otras redes. La desventaja de colocar
la ACL extendida en esta interfaz es que la ACL debe procesar todo el tráfico
que sale de S0/0/0, incluidos los paquetes de 192.168.10.0/24.
·
Interfaz G0/1 del
R1 (de entrada): la aplicación de una ACL extendida
al tráfico que ingresa a la interfaz G0/1 implica que solamente los paquetes de
la red 192.168.11.0/24 están sujetos al procesamiento de la ACL en R1. Debido a
que el filtro se debe limitar solo a aquellos paquetes que salen de la red
192.168.11.0/24, la aplicación de una ACL extendida a G0/1 es la mejor
solución.
Configurar la ACL
IPv4
La sintaxis completa del comando de ACL estándar es la
siguiente:
Router(config)# access-list número-acl
{ deny | permit | remark } origen [ wildcard-origen ][ log ]
En la figura 1, se explica detalladamente la sintaxis para
una ACL estándar.
Las ACE pueden permitir o denegar un solo host o un rango de
direcciones host. Para crear una ACL numerada 10, que permita un host específico
con la dirección IPv4 192.168.10.10, debe introducir lo siguiente:
R1(config)# access-list 10
permit host 192.168.10.10
Como se muestra en la figura 2, para crear una instrucción
que permita un rango de direcciones IPv4 en una ACL numerada 10 que
permite todas las direcciones IPv4 en la red 192.168.10.0/24, debe introducir
lo siguiente:
R1(config)# access-list 10
permit 192.168.10.0 0.0.0.255
Para eliminar la ACL, se utiliza el comando de configuración
global no access-list 10. La ejecución del comando show access-list
confirma que se eliminó la lista de acceso 10.
Como se muestra en la figura 3, se utiliza la palabra clave remark
en los documentos, que facilita mucho comprender las listas de acceso. Cuando
se revisa la ACL en la configuración mediante el comando show running-config,
también se muestra el comentario.
Aplicación de una
ACL IPv4 estándar
Después de que se configura una ACL estándar IPv4, se vincula a
una interfaz mediante el comando ip access-group en el modo de
configuración de interfaz:
Router(config-if)# ip
access-group { número-acl | nombre-acl } {
in | out }
Para eliminar una ACL de una interfaz, primero introduzca el
comando no ip access-group en la interfaz; luego, introduzca el comando
global no access-list para eliminar toda la ACL.
La figura 2 muestra un ejemplo de una ACL diseñada para permitir
una sola red. Solo el tráfico de la red 192.168.10.0/24 redes está permitido
desde la interfaz serial 0/0/0.
Listas ACL IPv4
estándar denominada
En la figura 1, se muestran los pasos necesarios para crear
una ACL estándar con nombre.
Paso 1: En el modo de configuración global, utilice el comando ip
access-list para crear una ACL denominada. Los nombres de las ACL son
alfanuméricos, distinguen mayúsculas de minúsculas y deben ser únicos. El
comando de nombre ip access-list standard se usa para crear una
con nombre estándar. Después de introducir el comando, el router se encuentra
en el modo de configuración estándar (std) ACL denominada (nacl) como lo indica
el segundo indicador en la Figura 1.
Paso 2. En el modo de configuración de ACL con nombre, utilice las
instrucciones permit o deny a fin de especificar una o más
condiciones para determinar si un paquete se reenvía o se descarta. Puede
utilizar remark para agregar un comentario a la ACL.
Paso 3. Aplique la ACL a una interfaz con el comando ip
access-group. nombre. Especifique si la ACL se debe aplicar a
los paquetes cuando ingresan por la interfaz (in) o cuando salen de la interfaz
(out).
La figura 2 muestra los comandos que se utilizan para configurar
una ACL estándar denominada en el router R1, en la que la interfaz G0/0 deniega
el acceso del host 192.168.11.10 a la red 192.168.10.0. La ACL se llama
NO_ACCESS.
Verificación de
listas ACL
Como se muestra en la figura 1, el comando show ip
interface se utiliza para verificar la ACL en la interfaz. El resultado de
este comando incluye el número o el nombre de la lista de acceso y el sentido
en el que se aplicó la ACL. El resultado muestra que la lista de acceso 1
se aplica a la interfaz de salida S0/0/0 del router R1 y que la lista de acceso
NO_ACCESS se aplica a la interfaz g0/0, también en sentido de salida.
En el ejemplo de la figura 2, se muestra el resultado de
emitir el comando show access-lists en el router R1. Para ver una lista
de acceso individual, utilice el comando show access-lists seguido del
número o el nombre de la lista de acceso. Es posible que las instrucciones de
NO_ACCESS se vean extrañas. Observe que el número de secuencia 15 se
muestra antes que el número de secuencia 10. Esto se debe al proceso
interno del router y se analizará más adelante en esta sección.
Listas ACL
extendidas
Prueba de paquetes con ACL extendidas
Para un control más preciso del filtrado del tráfico, se pueden
crear ACL de IPv4 extendidas. Las ACL extendidas se numeran del 100 al 199 y
del 2000 a 2699, lo que da un total de 799 ACL extendidas numeradas
posibles. Las ACL extendidas también pueden tener nombre.
Las ACL extendidas se utilizan con más frecuencia que las ACL
estándar, porque proporcionan un mayor grado de control. Como se muestra en la
figura, al igual que las ACL estándar, las ACL extendidas tienen la capacidad
para revisar las direcciones de origen de los paquetes, pero también pueden
revisar la dirección de destino, los protocolos y los números de puerto (o
servicios). Esto proporciona una gama de criterios más amplia sobre la cual
basar la ACL. Por ejemplo, una ACL extendida puede permitir el tráfico de
correo electrónico de una red a un destino específico y, simultáneamente,
denegar la transferencia de archivos y la navegación web.
Filtrado de
puertos y servicios
La capacidad de filtrar por protocolos y números de puerto
permite que los administradores de red creen ACL extendidas muy específicas. Se
puede especificar una aplicación mediante la configuración del número o el
nombre de un puerto bien conocido.
En la figura 1, se muestran algunos ejemplos de la forma en
que un administrador especifica un número de puerto TCP o UDP colocándolo al
final de la instrucción de la ACL extendida. Se pueden utilizar operaciones
lógicas, por ejemplo, igual que (eq), distinto de (neq), mayor que (gt) y menor
que (lt).
En la figura 2, se muestra cómo visualizar una lista de
números de puerto y de palabras clave que pueden utilizarse al generar una ACL
mediante el siguiente comando:
R1(config)# access-list 101
permit tcp any any eq ?
Configurar las
ACL extendidas
Los pasos del procedimiento para configurar ACL extendidas son
los mismos que para las ACL estándar. Primero se configura la ACL extendida y,
a continuación, se activa en una interfaz. Sin embargo, la sintaxis de los
comandos y los parámetros son más complejos, a fin de admitir las funciones
adicionales proporcionadas por las ACL extendidas.
Nota: La lógica interna aplicada al ordenamiento de las instrucciones
de las ACL estándar no se aplica a las ACL extendidas. El orden en que se
introducen las instrucciones durante la configuración es el orden en que se
muestran y se procesan.
En la figura 1, se muestra la sintaxis frecuente de los
comandos para las ACL de IPv4 extendidas. Observe que hay muchas palabras clave
y parámetros para las ACL extendidas. No es necesario utilizar todas las
palabras clave y todos los parámetros al configurar una ACL extendida. Recuerde
que puede usar ? para obtener ayuda al introducir comandos complejos.
En la figura 2, se muestra un ejemplo de una ACL extendida.
En este ejemplo, el administrador de red configuró las ACL para restringir el
acceso de red a fin de permitir la navegación de sitios web solo desde la LAN
conectada a la interfaz G0/0 a cualquier red externa. La ACL 103 permite
que el tráfico proveniente de cualquier dirección en la red 192.168.10.0 vaya a
cualquier destino, sujeto a la limitación de que el tráfico utilice solo los
puertos 80 (HTTP) y 443 (HTTPS).
La naturaleza de HTTP requiere que el tráfico fluya nuevamente
hacia la red desde los sitios web a los que se accede mediante clientes
internos. El administrador de red desea restringir ese tráfico de retorno a los
intercambios HTTP de los sitios web solicitados y denegar el resto del tráfico.
La ACL 104 logra esto mediante el bloqueo de todo el tráfico entrante,
excepto las conexiones establecidas previamente. La instrucción permit en la
ACL 104 permite el tráfico entrante con el parámetro established.
El parámetro established permite que solo las respuestas
al tráfico procedente de la red 192.168.10.0/24 vuelvan a esa red. Si el
segmento TCP que regresa tiene los bits ACK o de restablecimiento (RST)
establecidos, que indican que el paquete pertenece a una conexión existente, se
produce una coincidencia. Sin el parámetro established en la instrucción
de ACL, los clientes pueden enviar tráfico a un servidor web, pero no recibir
el tráfico que vuelve de dicho servidor.
Aplicación de ACL
extendidas a las interfaces
En el ejemplo anterior, el administrador de red configuró una
ACL para permitir que los usuarios de la red 192.168.10.0/24 exploren sitios
web seguros e inseguros. Aunque se configuró, la ACL no filtrará el tráfico
hasta que se aplique a una interfaz. Para aplicar una ACL a una interfaz,
primero debe considerar si el tráfico que se filtrará es entrante o saliente.
Cuando un usuario de la LAN interna accede a un sitio web en Internet, hay
tráfico que sale hacia Internet. Cuando un usuario interno recibe un correo
electrónico de Internet, el tráfico ingresa al router local. Sin embargo,
cuando se aplica una ACL a una interfaz, los términos “entrada” y “salida”
tienen otros significados. Desde el punto de vista de una ACL, la entrada y
salida son respecto de la interfaz del router.
En la topología de la ilustración, el R1 tiene tres interfaces:
una interfaz serial, S0/0/0, y dos interfaces Gigabit Ethernet, G0/0 y G0/1.
Recuerde que una ACL extendida comúnmente se debería aplicar cerca del origen.
En esta topología, la interfaz más cercana al origen del tráfico de destino es
la interfaz G0/0.
La solicitud de tráfico web de los usuarios en la LAN
192.168.10.0/24 entra a la interfaz G0/0. El tráfico de retorno de las
conexiones establecidas a los usuarios en la LAN sale de la interfaz G0/0. En
el ejemplo, se aplica la ACL a la interfaz G0/0 en ambos sentidos. La ACL de
entrada, 103, revisa el tipo de tráfico. La ACL de salida, 104, revisa si hay
tráfico de retorno de las conexiones establecidas. Esto restringe el acceso a
Internet desde 192.168.10.0 para permitir solamente la navegación de sitios
web.
Nota: las listas de acceso se podrían haber aplicado a la interfaz
S0/0/0, pero en ese caso el proceso de ACL del router tendría que examinar
todos los paquetes que ingresan al router y no solo el tráfico que va hacia
192.168.11.0 y que vuelve de esa red. Esto provocaría que el router realice un
procesamiento innecesario.
Filtrado de
tráfico con ACL extendidas
En el ejemplo que se muestra en la figura 1, se deniega el
tráfico FTP de la subred 192.168.11.0 que va a la subred 192.168.10.0, pero se
permite el resto del tráfico. Recuerde que FTP utiliza los puertos TCP 20 y 21,
por lo tanto, la ACL requiere ambas palabras claves de nombre de puerto ftp
y ftp-data o eq 20 y eq 21 para denegar el tráfico FTP.
Si se utilizan números de puerto en vez de nombres de puerto,
los comandos se deben escribir de la siguiente forma:
access-list 101 deny tcp
192.168.11.0 0.0.0.255 192.168.10.0 0.0.0.255 eq 20
access-list 101 deny tcp
192.168.11.0 0.0.0.255 192.168.10.0 0.0.0.255 eq 21
Para evitar que la instrucción deny any implícita al
final de la ACL bloquee todo el tráfico, se agrega la instrucción permit ip
any any. Si no hay por lo menos una instrucción permit en una ACL,
todo el tráfico en la interfaz donde se aplicó esa ACL se descarta. La ACL se
debe aplicar en sentido de entrada en la interfaz G0/1 para filtrar el tráfico
de la LAN 192.168.11.0/24 cuando ingresa a la interfaz del router.
En el ejemplo que se muestra en la figura 2, se deniega el
tráfico de Telnet de cualquier origen a la LAN 192.168.11.0/24, pero se permite
el resto del tráfico IP. Debido a que el tráfico destinado a la LAN
192.168.11.0/24 sale de la interfaz G0/1, la ACL se aplica a G0/1 con la
palabra clave out. Observe el uso de las palabras clave any en la
instrucción permit. Esta instrucción permit se agrega para asegurar que no se
bloquee ningún otro tipo de tráfico.
Nota: en ambos ejemplos en las figuras 1 y 2, se utiliza la
instrucción permit ip any any al final de la ACL. Para obtener mayor
seguridad, se puede utilizar el comando permit 192.168.11.0 0.0.0.255 any.
Creación de ACL
extendidas denominada
Las ACL extendidas denominada se crean esencialmente de la misma
forma que las ACL estándar denominada. Para crear una ACL extendida denominada,
realice los siguientes pasos:
Paso 1. Desde el modo de configuración global, utilice
el comando ip access-list extended se para definir un nombre para
la ACL extendida.
Paso 2. En el modo de configuración de ACL denominada,
especifique las condiciones para permit o deny.
Paso 3. Desde el modo de configuración de interfaces,
aplique la ACL denominada con el comando ip access-group [ in | out
] nombre .
Paso 4. Vuelva al modo EXEC con privilegios y
verifique la ACL con el comando show access-lists nombre .
Paso 5: Guarde las entradas en el archivo de
configuración mediante el comando copy running-config startup-config.
Para eliminar una ACL extendida denominada, utilice el comando
de configuración global no ip access-list extended se .
En la ilustración, se muestran las versiones denominada de las
ACL creadas en los ejemplos anteriores. La ACL denominada SURFING permite que
los usuarios en la LAN 192.168.10.0/24 accedan a sitios web. La ACL denominada
BROWSING permite el tráfico de retorno de las conexiones establecidas. Cuando
se utilizan las ACL denominada, las reglas se aplican en sentido de entrada y
de salida en la interfaz G0/0.
Verificación de
ACL extendidas
Después de configurar una ACL y aplicarla a una interfaz,
utilice los comandos show del IOS de Cisco para verificar la
configuración. En la ilustración, en el ejemplo de arriba se muestra el comando
del IOS de Cisco que se utiliza para mostrar el contenido de todas las ACL. En
el ejemplo de abajo, se muestra el resultado de emitir el comando show ip
interface g0/0 en el router R1.
A diferencia de las ACL estándar, las ACL extendidas no
implementan la misma lógica interna ni la misma función de hash. El resultado y
los números de secuencia que se muestran en el resultado del comando show
access-lists están en el orden en que se introdujeron las instrucciones.
Las entradas de host no se enumeran automáticamente antes de las entradas de
rango.
El comando show ip interface se utiliza para verificar la
ACL en la interfaz y el sentido en el que se aplicó. El resultado de este
comando incluye el número o el nombre de la lista de acceso y el sentido en el
que se aplicó la ACL. Los nombres de las ACL BROWSING y SURFING en mayúscula se
destacan en el resultado que se ve en la pantalla.
Después de verificar la configuración de una ACL, el siguiente
paso es confirmar que la ACL funcione según lo esperado, es decir, que bloquee
y permita el tráfico según se espera.
Las pautas analizadas anteriormente en esta sección sugieren que
las ACL se configuren en una red de prueba y después se implementen en la red
de producción.
Edición de ACL
extendidas
Una ACL extendida se puede editar de dos maneras:
·
Método 1: editor de
texto. Con este método, la ACL se copia y
pega en el editor de texto, donde se realizan los cambios. La lista de acceso
actual se elimina mediante el comando no access-list. Luego, la ACL
modificada se pega nuevamente en la configuración.
·
Método 2: números
de secuencia. Los números de secuencia se pueden
utilizar para eliminar o para insertar una instrucción de ACL. El comando ip
access-list extended se se utiliza para ingresar al modo de
configuración de ACL con nombre. Si la ACL es numerada en vez de tener un
nombre, se utiliza el número de la ACL en el parámetro se . Las ACE se
pueden insertar o eliminar.
En la ilustración,
se muestra que el administrador debe editar la ACL con nombre SURFING para
corregir una errata en la instrucción de la red de origen. Para ver los números
de secuencia actuales, se utiliza el comando show access-lists. La
instrucción que se edita se identifica como instrucción 10. La instrucción
original se elimina con el comando no número_secuencia . La
instrucción corregida se agrega y se reemplaza la instrucción original.
Tipos de ACL IPv6
Las ACL IPv6 son similares a las ACL IPv4 tanto en la
configuración como en el funcionamiento. Si ya está familiarizado con las
listas de acceso de IPv4, las ACL de IPv6 serán fáciles de comprender y
configurar.
Existen dos tipos de ACL en IPv4: las estándar y las extendidas.
Ambos tipos de ACL pueden ser numeradas o con nombre.
En cuanto a IPv6, hay solamente un tipo de ACL, que equivale a
la ACL de IPv4 extendida con nombre. No existen ACL numeradas en IPv6.
Una ACL de IPv4 y una ACL de IPv6 no pueden tener el mismo
nombre.
Comparación
entre ACL de IPv4 y de IPv6
Aunque las ACL IPv4 e IPv6 son muy similares, hay
tres diferencias fundamentales entre ellas:
·
La primera diferencia es el comando
que se utiliza para aplicar una ACL de IPv6 a una interfaz. IPv4 utiliza el
comando ip access-group para aplicar una ACL de IPv4 a una interfaz
IPv4. IPv6 utiliza el comando ipv6 traffic-filter para realizar la misma
función para las interfaces IPv6.
·
A diferencia de las ACL de IPv4, las
ACL de IPv6 no utilizan máscaras wildcard. En cambio, se utiliza la longitud de
prefijo para indicar cuánto de una dirección IPv6 de origen o destino debe
coincidir.
·
La última diferencia principal tiene
que ver con la inclusión de dos instrucciones permit implícitas al final de
cada lista de acceso de IPv6. Al final de todas las ACL IPv4 estándar o
extendidas, hay una instrucción deny any o deny ip any any
implícita. En IPv6 se incluye una instrucción deny ipv6 any any similar
al final de cada ACL de IPv6. La diferencia es que IPv6 también incluye dos
otras instrucciones implícitas de forma predeterminada: permit icmp any any
nd-na y permit icmp any any nd-ns.
Estas dos
instrucciones permiten que el router participe en el equivalente de ARP para
IPv4 en IPv6. Recuerde que ARP se utiliza en IPv4 para resolver las direcciones
de capa 3 a direcciones MAC de capa 2. Como se muestra en la
ilustración, en IPv6 se utilizan mensajes ICMP de descubrimiento de vecinos
(ND) para lograr el mismo propósito. ND utiliza mensajes de solicitud de vecino
(NS) y de anuncio de vecino (NA).
Los mensajes ND se
encapsulan en paquetes IPv6 y requieren los servicios de la capa de red IPv6,
mientras que ARP para IPv4 no utiliza la capa 3. Dado que IPv6 utiliza el
servicio de la capa 3 para el descubrimiento de vecinos, las ACL de IPv6
deben permitir implícitamente que los paquetes ND se envíen y reciban por una
interfaz. Específicamente, se permiten tanto los mensajes de descubrimiento de
vecinos-anuncio de vecino (nd-na) como los de descubrimiento de
vecinos-solicitud de vecino (nd-ns).
Configuración
de topología de IPv6
En la figura 1, se muestra la topología que se
utilizará para configurar las ACL de IPv6. Esta es similar a la topología de
IPv4 anterior, excepto por el esquema de direccionamiento IPv6. Existen tres
subredes 2001:DB8:CAFE::/64:
·
2001:DB8:CAFE:10::/64
·
2001:DB8:CAFE:11::/64
·
2001:DB8:CAFE:30::/64
Dos redes seriales
conectan los tres routers:
·
2001:DB8:FEED:1::/64
·
2001:DB8:FEED:2::/64
En las
figuras 2, 3 y 4, se muestra la configuración de la dirección IPv6 para
cada uno de los routers. El comando show ipv6 interface brief se utiliza
para verificar la dirección y el estado de la interfaz.
Nota: el comando no shutdown y el comando clock
rate no se muestran.
Configuración de
ACL de IPv6
En IPv6 solo hay ACL con nombre. La configuración es similar a
la de una ACL de IPv4 extendida con nombre.
En la figura 1, se muestra la sintaxis de los comandos para
las ACL de IPv6. La sintaxis es similar a la que se utiliza en ACL de IPv4
extendidas. Una diferencia importante es el uso de la longitud de prefijo IPv6
en lugar de una máscara wildcard IPv4.
Hay tres pasos básicos para configurar una ACL de IPv6:
Paso 1. En el modo de configuración global, se usa el
comando ipv6 access-list se para crear una ACL IPv6. Al igual que
las ACL de IPv4 con nombre, los nombres en IPv6 son alfanuméricos, distinguen
mayúsculas de minúsculas y deben ser únicos. A diferencia de IPv4, no hay
necesidad de una opción estándar o extendida.
Paso 2. En el modo de configuración de ACL con nombre,
utilice las instrucciones permit o deny para especificar una o
más condiciones para determinar si un paquete se debe reenviar o descartar.
Paso 3. Regrese al modo EXEC con privilegios con el
comando end.
En la figura 2, se muestran los pasos para crear una ACL de
IPv6 con un ejemplo simple basado en la topología anterior. La primera
instrucción da el nombre NO-R3-LAN-ACCESS a la lista de acceso de IPv6. Al
igual sucede que con las ACL de IPv4 con nombre, no es necesario el uso de
mayúsculas en los nombres de las ACL de IPv6, pero esto hace que se destaquen
cuando se observa el resultado de la configuración en ejecución.
La segunda instrucción deniega todos los paquetes 2001:DB8:CAFE:30::/64
destinados a cualquier red IPv6. La tercera instrucción permite el resto de los
paquetes IPv6.
En la figura 3, se muestra la ACL en contexto con la
topología.
Aplicación de una
ACL de IPv6 a una interfaz
Después de que se configura una ACL de IPv6, se la vincula a una
interfaz mediante el comando ipv6 traffic-filter:
Router(config-if)# ipv6 traffic-filter access-list-name { in | out }
En la ilustración, se muestra la ACL NO-R3-LAN-ACCESS
configurada anteriormente y los comandos utilizados para aplicar la ACL de IPv6
de entrada a la interfaz S0/0/0. Si se aplica la ACL a la interfaz S0/0/0 de
entrada, se denegarán los paquetes de 2001:DB8:CAFE:30::/64 en ambas LAN en el
R1.
Para eliminar una ACL de una interfaz, primero introduzca el
comando no ipv6 traffic-filter en la interfaz y, luego, introduzca el
comando global no ipv6 access-list para eliminar la lista de acceso.
Nota: Tanto en IPv4 como en IPv6 se utiliza el comando access-class
para aplicar una lista de acceso a los puertos VTY.
Ejemplos de ACL
de IPv6
Denegar FTP
La topología para los ejemplos se muestra en la figura 1.
En el primer ejemplo (figura 2), el router R1 está
configurado con una lista de acceso IPv6 para denegar el tráfico FTP a 2001:DB8:CAFE:11::/64.
Se deben bloquear los puertos para los datos FTP (puerto 20) y el control
FTP (puerto 21). Como se aplica un filtro entrante en la interfaz G0/0 de
R1, solo se denegará el tráfico de la red 2001:DB8:CAFE:10::/64.
Acceso restringido
En el segundo ejemplo (figura 3), se configura una ACL IPv6
para proporcionar a la red LAN en R3 acceso limitado a las redes LAN en R1. Se
agregan comentarios en la configuración para documentar la ACL. Se marcaron las
siguientes características en la ACL:
1. Las primeras dos instrucciones permit proporcionan acceso
desde cualquier dispositivo al servidor web en 2001:DB8:CAFE:10::10.
2. El resto de los dispositivos tienen denegado el acceso a la
red 2001:DB8:CAFE:10::/64.
3. A la PC3 en 2001:DB8:CAFE:30::12 se le permite el acceso por
Telnet a la PC2, que tiene la dirección IPv6 2001:DB8:CAFE:11::11.
4. El resto de los dispositivos tiene denegado el acceso por
Telnet a la PC2.
5. El resto del tráfico IPv6 se permite al resto de los
destinos.
6. La lista de acceso de IPv6 se aplica a la interfaz G0/0 en
sentido de entrada, por lo que solo la red 2001:DB8:CAFE:30::/64 se ve
afectada.
Verificación de
ACL de IPv6
Los comandos que se utilizan para verificar una lista de acceso
de IPv6 son similares a los que se utilizan para las ACL de IPv4. Con estos
comandos, se puede verificar la lista de acceso de IPv6 RESTRICTED-ACCESS que
se configuró anteriormente. En la figura 1, se muestra el resultado del
comando show ipv6 interface. El resultado confirma que la ACL RESTRICTED-ACCESS
está configurada en sentido de entrada en la interfaz G0/0.
Como se muestra en la figura 2, el comando show
access-lists muestra todas las listas de acceso en el router, incluidas las
ACL de IPv4 y de IPv6. Observe que, en las ACL de IPv6, los números de
secuencia se colocan al final de la instrucción y no al principio, como ocurre
en las listas de acceso de IPv4. Aunque las instrucciones aparecen en el orden
en que se introdujeron, no siempre se presentan en incrementos de 10. Esto se
debe a que las instrucciones remark que se introdujeron utilizan un número de
secuencia, pero no se muestran en el resultado del comando show access-lists.
Al igual que las ACL extendidas para IPv4, las listas de acceso
de IPv6 se muestran y se procesan en el orden en que se introducen las
instrucciones. Recuerde que las ACL de IPv4 estándar utilizan una lógica
interna que cambia el orden y la secuencia de procesamiento.
Como se muestra en la figura 3, el resultado del comando show
running-config incluye todas las ACE y las instrucciones remark. Las
instrucciones remark pueden colocarse antes o después de las instrucciones permit
o deny, pero se debe mantener una ubicación coherente.
Lógica de ACL
de entrada y salida
Lógica de ACL de entrada
En la figura 1,
se muestra la lógica para una ACL de entrada. Si hay una coincidencia entre la
información en un encabezado de paquete y una instrucción de ACL, el resto de
las instrucciones de la lista se omiten y se permite o se deniega el paquete
según lo especificado por la instrucción de la coincidencia. Si no existe una
coincidencia entre un encabezado de paquete y una instrucción de ACL, el
paquete se prueba en relación con la siguiente instrucción de la lista. Este
proceso de búsqueda de coincidencias continúa hasta que se llega al final de la
lista.
Al final de cada
ACL hay una instrucción deny any implícita. Esta instrucción no se
muestra en el resultado. Esta instrucción implícita final se aplica a todos los
paquetes cuyas condiciones no se probaron como verdaderas. Esta condición de
prueba final coincide con el resto de los paquetes y da como resultado una
acción de denegación. En lugar de avanzar en el sentido de entrada o de salida
de una interfaz, el router descarta todos los paquetes restantes. A esta
instrucción final se la suele conocer como instrucción “deny any implícita” o
“denegación de todo el tráfico”. Debido a esta instrucción, una ACL debería
incluir, por lo menos, una instrucción permit. De lo contrario, la ACL bloquea
todo el tráfico.
Lógica
de ACL de salida
En la
figura 2, se muestra la lógica para una ACL de salida. Antes de que se
reenvíe un paquete a una interfaz de salida, el router revisa la tabla de
routing para ver si el paquete es enrutable. Si no lo es, se descarta y no se
prueba en relación con las ACE. A continuación, el router revisa si la interfaz
de salida está agrupada en una ACL. Si la interfaz de salida no está agrupada
en una ACL, el paquete se puede enviar al búfer de salida. A continuación, se
indican algunos ejemplos de la operación de la ACL de salida:
·
No se aplica ACL a
la interfaz: Si la interfaz saliente no se
agrupa con una ACL saliente, el paquete se envía directamente a la interfaz
saliente.
·
Se aplica ACL a la
interfaz: Si la interfaz saliente se agrupa
con una ACL saliente, el paquete no se envía a la interfaz saliente hasta que
se lo pruebe combinando ACE asociadas con dicha interfaz. Según las pruebas de
ACL, el paquete se permite o se deniega.
Para las listas de
salida, “permit” (permitir) significa enviar el paquete al búfer de salida y
“deny” (denegar) significa descartar el paquete.
Operaciones
lógicas de ACL
ACL y routing, y procesos de ACL en un router
En la ilustración, se muestra la lógica de los procesos de
routing y ACL. Cuando un paquete llega a una interfaz del router, el proceso
del router es el mismo, ya sea si se utilizan ACL o no. Cuando una trama
ingresa a una interfaz, el router revisa si la dirección de capa 2 de
destino coincide con la dirección de capa 2 de la interfaz, o si dicha
trama es una trama de difusión.
Si se acepta la dirección de la trama, se desmonta la
información de la trama y el router revisa si hay una ACL en la interfaz de
entrada. Si existe una ACL, el paquete se prueba en relación con las
instrucciones de la lista.
Si el paquete coincide con una instrucción, se permite o se
deniega. Si se acepta el paquete, se compara con las entradas en la tabla de
routing para determinar la interfaz de destino. Si existe una entrada para el
destino en la tabla de routing, el paquete se conmuta a la interfaz de salida.
De lo contrario, se descarta.
A continuación, el router revisa si la interfaz de salida tiene
una ACL. Si existe una ACL, el paquete se prueba en relación con las
instrucciones de la lista.
Si el paquete coincide con una instrucción, se permite o se
deniega.
Si no hay una ACL o si se permite el paquete, este se encapsula
en el nuevo protocolo de capa 2 y se reenvía por la interfaz al siguiente
dispositivo.
Proceso de
decisión de ACL estándar
Las ACL estándar solo examinan la dirección IPv4 de origen. El
destino del paquete y los puertos involucrados no se tienen en cuenta.
El proceso de decisión de una ACL estándar se detalla en la
ilustración. El software IOS de Cisco prueba las direcciones en relación con
cada una de las condiciones de la ACL. La primera coincidencia determina si el
software acepta o rechaza la dirección. Dado que el software deja de probar las
condiciones después de la primera coincidencia, el orden de las condiciones es
fundamental. Si no coincide ninguna condición, la dirección se rechaza.
Proceso de
decisión de ACL extendida
En la ilustración, se muestra la ruta de decisión lógica que
utiliza una ACL extendida creada para filtrar direcciones de origen y destino,
y números de protocolo y de puerto. En este ejemplo, la ACL primero filtra
sobre la dirección de origen y, a continuación, sobre el puerto y el protocolo
de origen. Luego, filtra por la dirección de destino y después por el puerto y
el protocolo de destino, y toma la decisión final de permiso o denegación.
Recuerde que las entradas en las ACL se procesan una tras otra,
de modo que una decisión negativa (“no”) no es necesariamente una decisión de
denegación (“deny”). A medida que avanza a través de la ruta de decisión
lógica, tenga en cuenta que un “no” significa que se debe pasar a la siguiente
entrada hasta que se encuentre una coincidencia para una condición.
Solución de
problemas de ACL IPv4. Ejemplo 1
Los comandos show descritos anteriormente sirven para
detectar la mayoría de los errores comunes de ACL. Los errores más comunes
incluyen introducir las ACE en el orden incorrecto y no aplicar los criterios
adecuados a las reglas de ACL.
En la figura, el host 192.168.10.10 no tiene conectividad de
Telnet con 192.168.30.12. Al observar el resultado del comando show
access-lists, se muestran las coincidencias para la primera instrucción
deny. Esto indica que la instrucción coincidió con el tráfico.
Solución: mire el orden de las ACE. El host
192.168.10.10 no tiene conectividad con 192.168.30.12, debido al orden de la
regla 10 en la lista de acceso. Dado que el router procesa las ACL en
orden descendente, la instrucción 10 deniega el host 192.168.10.10, por lo
que la instrucción 20 nunca puede tener una coincidencia. Las
instrucciones 10 y 20 deben invertirse. La última línea permite el resto del
tráfico que no es TCP y que se clasifica como IP (ICMP, UDP, etcétera).
Solución de
problemas de ACL IPv4. Ejemplo 2
En la ilustración, la red 192.168.10.0/24 no puede utilizar TFTP
para conectarse a la red 192.168.30.0/24.
Solución: la red 192.168.10.0/24 no puede utilizar TFTP
para conectarse a la red 192.168.30.0/24, porque TFTP utiliza el protocolo de
transporte UDP. La instrucción 30 en la lista de acceso 120 permite
todo el resto del tráfico TCP. Sin embargo, debido a que TFTP utiliza UDP en
lugar de TCP, se deniega implícitamente. Recuerde que la instrucción deny any
implícita no aparece en el resultado del comando show access-lists y,
por lo tanto, las coincidencias no se muestran.
La instrucción 30 debería ser ip any any.
Esta ACL funciona si se aplica a G0/0 del R1, a S0/0/1 del R3 o
a S0/0/0 del R2 en sentido de entrada. Sin embargo, según la regla que indica
colocar las ACL extendidas más cerca del origen, la mejor opción es colocarla
en sentido de entrada en G0/0 del R1, porque permite que el tráfico no deseado
se filtre sin cruzar la infraestructura de la red.
Solución de
problemas de ACL IPv4. Ejemplo 3
En la ilustración, la red 192.168.11.0/24 puede utilizar Telnet
para conectarse a 192.168.30.0/24, pero según la política de la empresa, esta
conexión no debería permitirse. Los resultados del comando show access-lists
130 indican que se encontró una coincidencia para la instrucción permit.
Solución: La red 192.168.11.0/24 puede usar Telnet
para conectarse a la red 192.168.30.0/24 porque el número de puerto de Telnet
de la instrucción 10 de la lista de acceso 130 figura en la posición incorrecta
en la instrucción de ACL. Actualmente, la instrucción 10 deniega cualquier
paquete de origen con un número de puerto que equivalga a Telnet. Para denegar
el tráfico de Telnet entrante en G0/1, debe denegar el número de puerto de
destino equivalente a Telnet, por ejemplo, 10 deny tcp 192.168.11.0
0.0.0.255 192.168.30.0 0.0.0.255 eq telnet.
Solución de
problemas de ACL IPv4. Ejemplo 4
En la ilustración, el host 192.168.30.12 puede conectarse a
192.168.31.12 mediante Telnet, pero la política de la empresa establece que
esta conexión no debe permitirse. Los resultados del comando show
access-lists 140 indican que se encontró una coincidencia para la
instrucción permit.
Solución: el host 192.168.30.12 puede utilizar Telnet
para conectarse a 192.168.31.12 porque no hay reglas que denieguen el host
192.168.30.12 o su red como origen. La instrucción 10 de la lista de
acceso 140 deniega la interfaz del router por la que el tráfico ingresa a
este. La dirección host IPv4 en la instrucción 10 debería ser
192.168.30.12.
Solución de
problemas de ACL IPv4. Ejemplo 5
En la ilustración, el host 192.168.30.12 puede utilizar Telnet
para conectarse a 192.168.31.12, pero según la política de seguridad, esta
conexión no debe permitirse. El resultado del comando show access-lists 150
indica que no se encontraron coincidencias para la instrucción deny según se
esperaba.
Solución: el host 192.168.30.12 puede utilizar Telnet
para conectarse a 192.168.31.12, debido al sentido en el que se aplica la lista
de acceso 150 a la interfaz G0/1. La instrucción 10 deniega la conexión de
todas las direcciones de origen al host 192.168.31.12 mediante Telnet. Sin
embargo, para un filtrado correcto, este filtro se debe aplicar en sentido de
salida en G0/1.
Solución de
problemas de ACL IPv6. Ejemplo 1
Como sucede con ACL IPv4, los comandos show ipv6 access-list
y show running-config sirven para ver los errores típicos de ACL IPv6.
En la figura 1, R1 está configurado con un ACL IPv6 para
denegar el acceso FTP de la red :10 a la red :11. Sin embargo, después de
configurar la ACL, la PC1 todavía puede conectarse al servidor FTP que se
ejecuta en la PC2. Al consultar la salida del comando show ipv6 access-list
en la figura 2, se muestran las coincidencias para la instrucción de
permitir, pero no para las instrucciones de denegar.
Solución: Las ACE de la ACL no muestran problemas de
orden ni de criterio en las reglas. El paso siguiente consiste en considerar
cómo se aplica la ACL en la interfaz con el comando ipv6 traffic-filter.
¿La ACL se aplicó utilizando el nombre correcto, la interfaz correcta y la
dirección correcta? Para comprobar si hay errores de configuración en la
interfaz, consulte la configuración en ejecución, como se muestra en la
figura 2.
La ACL se aplicó con el nombre correcto, pero con una dirección
incorrecta. La dirección entrante o saliente se determina desde la perspectiva
del router, lo que significa que, en este momento, la ACL se aplica al tráfico
antes de que se lo reenvíe por la interfaz G0/0 e ingrese en la red :10. Para
corregir este problema, elimine el comando ipv6 traffic-filter NO-FTP-TO-11 out
y reemplácelo con el comando ipv6 traffic-filter NO-FTP-TO-11 in, como se
muestra en la figura 3. Desde ahora, se denegarán los intentos de PC1 de
acceder al servidor FTP, como se verificó con el comando show ipv6
access-list.
Solución de problemas
de ACL IPv6. Ejemplo 2
En la figura, R3 está configurado con una ACL IPv6
llamada RESTRICTED-ACCESS que debe aplicar la siguiente política a la LAN de
R3:
·
Permitir acceso a la red :10
·
Denegar acceso a la red :11
·
Permitir acceso SSH a la PC en 2001:DB8:CAFE:11::11
Sin embargo,
después de configurar la ACL, la PC3 no puede llegar a la red 10 o la red 11, y
no puede utilizar SSH en el host en 2001:DB8:CAFE:11::11.
Solución: En esta situación, el problema no se debe a cómo
se aplicó la ACL. En la interfaz, la ACL no está mal escrita, y la dirección y
la ubicación son correctas, como se muestra en la figura 2. Al analizar en
detalle la ACL IPv6, se puede notar que el problema está en el orden y los
criterios de las reglas de ACE. La primera declaración de permiso debería
permitir el acceso a la red :10. Sin embargo, el administrador configuró una
instrucción de host y no especificó un prefijo. En este caso, se otorga acceso
únicamente a 2001:DB8:CAFE:10:: se permite el host.
Para corregir este
problema, elimine el argumento de host y cambie el prefijo /64 a. Puede hacer
esto sin eliminar la ACL reemplazando la ACE con el número de secuencia 10,
como se muestra en la figura 3.
El segundo error en
la ACL es el orden de las dos siguientes afirmaciones. La política especifica
que los hosts en la LAN del R3 deben poder utilizar SSH en el host
2001:DB8:CAFE:11::11. Sin embargo, la declaración deny para la red :11 se
encuentra antes de la declaración permit. Por lo tanto, todos los intentos para
acceder al: se deniega la red 11 antes de que la instrucción que permite el
acceso de SSH puede evaluarse. Una vez que se establece una coincidencia, no se
analizan otras instrucciones. Para corregir este problema, deberá eliminar las
instrucciones e ingresarlas en el orden correcto, como se muestra en la
figura 4.
Solución de
problemas de ACL IPv6. Ejemplo 3
En la figura 1, R1 está configurado con una ACL
IPv6 llamada DENY-ACCESS que debe aplicar la siguiente política para la LAN de
R3:
·
Permitir acceso a la red :11 desde la
red :30
·
Denegar acceso a la red :10
La figura 2 muestra
la configuración y la aplicación de la ACL IPv6.
La ACL DENY-ACCESS
debe permitir el acceso a la red :11 desde la red :30 y denegar el acceso a la
red :10. Sin embargo, después de aplicar la ACL a la interfaz: la red 10 aún es
accesible desde la red :30.
Solución: En esta situación, el problema no tiene que ver
con la manera en la que se escribieron las instrucciones de las ACL, sino con
la ubicación de la ACL. Dado que las ACL de IPv6 deben configurarse con un
origen y un destino, debe aplicarse lo más cerca posible del origen del
tráfico. La ACL DENY-ACCESS se aplicó en el sentido saliente en la interfaz
G0/1 de R1 que es la que más cerca está del destino. Como resultado, el tráfico
a la red :10 no se ve no se ve afectado porque alcanza la red :10 a través de
la otra interfaz de la red LAN, G0/0. Puede aplicar la ACL entrante en la
interfaz S0/0/0 del R1. Sin embargo, porque tenemos control sobre el R3, la
mejor ubicación sería configurar y aplicar la ACL lo más cerca posible del
origen del tráfico. La figura 3 muestra la eliminación de la ACL en R1 y la
configuración y la aplicación correctas de la ACL en R3.