Hoy continuaremos con el tema del video tutorial el día 27 y haremos un estudio en profundidad de las ACL: hablaremos un poco sobre la máscara inversa Wildcard Mask, la lista extendida de ACL, la configuración de la lista extendida de ACL y los comandos que ayudan a diagnosticar problemas de diseño de red.
En la lección anterior, presentamos un nuevo concepto de máscara inversa para nosotros, y ahora hablaré sobre Wildcard Mask con más detalle. Si recuerda, la máscara de subred nos ayuda a dividir visualmente la red en la parte de dirección de la red y la parte de dirección del host.
Si va al nivel de bits, puede ver que la máscara de subred consiste en una serie de unidades que denotan la parte de la red y una serie de ceros que indican parte del host. La máscara inversa es muy similar a la máscara de subred, solo en la forma "invertida", donde hay unidades en la máscara de subred, los ceros están en la máscara inversa y viceversa. Esta no es una regla obligatoria: en algunos casos, la máscara inversa se forma de acuerdo con un principio diferente; en el aprendizaje de CCNA, esta regla siempre se aplica.
La mejor manera de calcular la máscara inversa es restar los octetos de la máscara de subred de la máscara global, que siempre se ve como 255.255.255.255.
Entonces, para calcular la máscara inversa para la máscara de subred 255.255.255.0, simplemente la restamos de la máscara global y obtenemos 0.0.0.255.
En este ejemplo, miramos la red 192.168.100.255/24, y ahora veamos la red / 26. Si tiene / 26, entonces el último octeto de la máscara de subred será 192.
Si observa la forma de bits de estas direcciones IP, verá que la máscara de subred contiene 26 bits simples y 6 bits cero.
En este caso, la máscara inversa debe constar de 26 ceros y 6 unidades. Como ya dijimos, los lugares donde se encuentran 0 muestran los parámetros de dirección coincidentes, y los lugares donde se encuentran las unidades, puede ignorar.
Para hacerlo más claro, escribiré la dirección IP en forma decimal en la parte superior. El último octeto de la máscara inversa corresponde al número 63, y puedo mostrarlo como 0.0.0.63. En pocas palabras, / 26 significa que los 26 ceros, o los primeros 3 octetos de la dirección IP son iguales, y los últimos 6 bits pueden ser cualquier cosa: ceros o unos.
Vea: si reemplazamos estos últimos 6 bits de la dirección IP con ceros, obtenemos el número 192, y si a los que obtenemos el número 255. Por lo tanto, la máscara inversa muestra que la subred con direcciones IP cuyo último octeto está en el rango de 192 a 255 , es decir, parte de la red 192.168.100.225/26, está sujeta a la condición de ACL especificada.
Puede preguntar por qué se necesitan dos máscaras: una máscara de subred y una máscara comodín. Yo mismo hice esta pregunta cuando era estudiante, y todavía muchas personas, incluso trabajando en Cisco, hacen esta pregunta. Trataré de responderlo. En general, la máscara de subred y la máscara inversa muestran lo mismo cuando se trata de la subred, es decir, parte de la dirección IP que denota la red. Cuando identificamos toda la red, la máscara inversa es simplemente una versión "invertida" de la máscara directa.
Sin embargo, la identificación del host es diferente. Si desea identificar toda la subred con todas las direcciones incluidas, puede usar la máscara de subred. Pero si solo necesita identificar algunos hosts de esta red para aplicarles selectivamente las reglas de ACL, necesita una máscara inversa.
Nunca verá una máscara de subred que consista en alternar unos y ceros; siempre tiene unidades primero y ceros al final. Por lo tanto, el comodín se llama "comodín" porque puede consistir en cualquier secuencia de unos y ceros. Para aclararlo, solucionemos el problema: "identifique hosts en una red determinada que tengan números pares en el cuarto octeto".
Esto es necesario para crear una regla ACL de este tipo: permitir 192.168.100.0 <máscara inversa>, es decir, se permitirá el tráfico para las direcciones IP de esta subred con solo el cuarto octeto. ¿Se puede hacer esto usando una máscara de subred? No lo creo, porque el cuarto octeto de una máscara de subred normal puede contener solo un número específico. Veamos una máscara inversa de 4 octetos.
En el último octeto de la máscara inversa, puede colocar los siguientes bits: 11111110. Explicaré de qué se trata. Si el 4to octeto contiene números pares, entonces el último bit del octeto es necesariamente 0, y si el último bit es 1, entonces el número es impar. Si estamos hablando de la subred / 24, solo el último octeto puede contener un número par.
En el caso de la máscara inversa, los primeros tres octetos son 0, y los primeros siete bits del cuarto octeto no nos molestan, lo principal es que el octavo bit del octeto es cero, porque debe coincidir con el último octeto de la dirección IP de la red, que es 0.
Si el último bit de la dirección IP es 1, esta dirección será denegada, ahora agregaré la condición a nuestra ACL - Denegar cualquiera. Por lo tanto, solo si el último octeto de cualquier dirección IP de nuestra subred termina con 0, es decir, será par, cumpliremos la condición para hacer coincidir la máscara hacia atrás, que también termina con 0, y la condición ACL "permite todas las direcciones con un cuarto octeto" Estará satisfecho. De lo contrario, es decir, para todas las direcciones IP impares, se aplicará la denegación de cualquier condición.
Por lo tanto, no nos importa qué valor exacto tendrá un octeto par: 2,4,6, 8, etc., lo principal es que tendrá un bit cero al final. Si usáramos una máscara de subred regular, necesitaríamos crear una entrada separada para cada dirección IP que tenga un cuarto octeto. El uso de la máscara inversa le permite reemplazar todas estas entradas con una.
Exactamente el mismo principio se aplica a los números impares del 4to octeto, solo el último bit de la máscara inversa en este caso debería ser 1. En este caso, se establecerá una regla general, permitir o denegar, para todas las direcciones IP de la subred que tengan un 4 impar el octeto Vea cómo se ve este ejemplo decimal.
Si uso la máscara inversa 0.0.0.254, nuestro problema se resolverá: todos los hosts con incluso un cuarto octeto están permitidos, y todos los demás hosts están prohibidos. La ventaja de una máscara inversa es que cuando crea una ACL, puede configurarla para satisfacer sus necesidades. No tiene que preocuparse mucho por las máscaras inversas específicas, porque CCNA no requiere esto. Es suficiente recordar la regla: la máscara inversa se obtiene cuando la máscara de subred se elimina de la máscara global 255.255.255.255. Tenga en cuenta que el curso CCNA se centra más en las subredes que en los hosts.
Volvamos a la diapositiva anterior, y hablaré sobre otra forma de calcular la máscara Wildcard.
Si recuerda de nuestra tabla "mágica", / 26 significa que el tamaño del bloque de bits es igual a 64. Si este bloque es 64, el último octeto de la máscara inversa tendrá el valor (64-1) = 63. Si tenemos / 25, el tamaño del bloque será 128, lo que significa que el último octeto de la máscara inversa será (128-1) = 127. Esta es otra pista para facilitar el cálculo del valor de la máscara inversa. Pero si no desea usarlo, use el método habitual, restando la máscara de subred de la máscara global.
Ahora pasemos a la sintaxis de los comandos ACL extendidos. Al igual que con la ACL estándar, hay dos tipos de grabación de comandos: clásica y moderna.
El comando clásico es la entrada access-list <número ACL> <deshabilitar / permitir> <protocolo>. Por lo tanto, el primer comando ACL extendido difiere del comando ACL estándar al especificar un protocolo, no un criterio. Esto significa que aquí el tráfico no se filtra por la dirección IP del origen o destino, sino por el protocolo utilizado.
En todos los casos, utilizamos el protocolo IP, que es de tres tipos: ICMP, o el ping que conocemos, TCP, que depende del puerto específico 21,23, etc., y UDP. Permítame recordarle que Wikipedia tiene un artículo con una lista de todos los protocolos y sus números de puerto correspondientes.
La siguiente es la línea de comando <IP de origen> <máscara inversa> [información del protocolo]. La información del protocolo significa especificar un número de puerto. Es decir, en el comando anterior como <protocol> usted especifica ICMP, TCP o UDP, y en el segundo comando como parámetro [información de protocolo] especifique el número de puerto 21.23, etc.
La tercera línea del comando es <IP de destino> <máscara inversa> [información de protocolo], es decir, los parámetros relacionados con el destino.
Si recuerda de lecciones anteriores, el número de puerto de origen es un número aleatorio, porque el dispositivo que envía el tráfico crea un puerto de número aleatorio para esto. En este sentido, en la primera línea con respecto a la fuente de tráfico, usted indica [información de protocolo] del destino, por ejemplo, FTP, es decir, el protocolo del dispositivo cuyo tráfico desea bloquear.
Permítame recordarle que para realizar cambios en la lista de ACL extendidas del tipo clásico, deberá volver a formar la lista completa manualmente, como en el caso de las ACL estándar del tipo clásico.
Un equipo de aspecto moderno comienza con la expresión ip, que no tiene nada que ver con el protocolo IP, es solo una palabra clave. Entonces, la primera línea contiene la palabra clave ip, el parámetro "lista de acceso extendida" y el número o nombre de la ACL. Después de ejecutar el primer comando, cambia al modo de subcomando config-ext-nacl e ingresa <deshabilitar / permitir> <protocolo>, como discutimos anteriormente.
Los siguientes son los dos comandos <origen IP> <máscara inversa> [información de protocolo] y <IP de destino> <máscara inversa> [información de protocolo], el primero generalmente ignora el parámetro [información de protocolo de origen] y, en su lugar, el parámetro [información de protocolo] destino]. A veces puede ser necesario especificar el puerto de origen, pero en CCNA, en la mayoría de los casos, este parámetro puede ignorarse.
Usar una ACL extendida es similar a usar una ACL estándar. Aquí también debe especificar la interfaz del dispositivo al que se aplica la lista, luego usar el parámetro ip access-group, el número o nombre de la lista ACL y la dirección del flujo de tráfico: entrante o saliente. En el video anterior, ya discutimos cómo se determina la dirección del tráfico para un puerto específico.
Pasemos al esquema y configuremos la ACL avanzada utilizando la topología de red de la lección anterior. El problema número 1 es: "Las computadoras en la red del departamento de administración y la red del departamento financiero pueden acceder a través de los protocolos HTTP (80) y FTP (21) solo al servidor Server0 ubicado en la red del servidor".
Al mismo tiempo, no se permite todo el tráfico, sino solo el que proviene de los puertos 80 y 21, es decir, por ejemplo, el tráfico a través del protocolo SSH debe bloquearse. Si recuerda, la ACL extendida debe aplicarse más cerca de la fuente, por lo que para el departamento de administración debe aplicarse al puerto G0 / 0 del enrutador R1, y para la contabilidad, al puerto G0 / 0 del enrutador R2. En relación con el enrutador, bloqueamos el tráfico entrante, por lo que utilizamos el parámetro IN en los comandos de la lista. Asigne la ACL a la lista número 101 y haga una lista de líneas que debería contener usando el enfoque clásico.
La primera línea permite TCP, porque el puerto HTTP 80 significa TCP, luego indicamos la red del departamento de administración, 192.168.1.224/28. En este ejemplo, omito la máscara inversa, la usamos en Packet Tracer, hasta ahora el principio de formación de listas es importante para nosotros. La red de administración es la fuente del tráfico, después de que se indica la dirección IP de destino 192.168.1.194/32, donde 194 es el último octeto de la dirección del Servidor0, y / 32 significa que la condición se aplica solo a este dispositivo en particular ubicado en la subred 192.168.1.192/27. Al final de la línea, indicamos el puerto de destino permitido 80, destinado al tráfico HTTP.
Del mismo modo, se crea una entrada para el puerto 21 utilizado para transmitir tráfico FTP. No estoy escribiendo una tercera línea, que por defecto se parece a Denegar y prohíbe el tráfico saliente de dispositivos que no pertenecen a esta subred. A continuación, debe especificar que la lista se aplica al puerto G0 / 0 de R1 en la dirección IN, es decir, para el tráfico entrante.
Hacemos lo mismo al compilar entradas ACL Allow_Acc para el departamento de finanzas, permitiendo el tráfico TCP desde los puertos 80 y 21 y aplicando esta lista a la interfaz de entrada G0 / 0 del enrutador R2.
El problema número 2 es: "Las computadoras en la red del departamento de ventas pueden usar todos los protocolos excepto PING (ICMP) solo en el Servidor1, ubicado en la red del servidor". Esto significa que para la comunicación con el servidor, las computadoras del departamento de ventas pueden usar los protocolos HTTP, SSH, FTP, cualquier protocolo que no sea ICMP. En este caso, la lista de condiciones de ACL se verá así.
En la primera línea, prohibimos todo el tráfico a través de ICMP, colocando una condición específica en la parte superior de la lista, y general al final de la lista. Este registro muestra el identificador de subred del departamento de ventas 192.168.1.0/25, la dirección IP de un servidor específico del servidor 1 es 192.168.1.195/32. El parámetro echo significa tráfico en forma de ping, es decir, se debe denegar un paquete que se envía al servidor para volver a la computadora.
La segunda línea permite el resto del tráfico procedente de la subred 192.168.1.0/25 a la dirección del servidor 192.168.1.195/32. Como de costumbre, al final de la lista, la línea predeterminada es Denegar cualquiera, lo que significa que si las computadoras del departamento de ventas intentan comunicarse con el departamento de finanzas, dicho tráfico se descartará. A continuación, indicamos a qué interfaz de enrutador se debe aplicar la ACL, y se resuelve el segundo problema.
La Tarea 3 es: "Ventas2 laptop Laptop2 y departamento de finanzas PC0 pueden acceder a management0 laptop Laptop0". Suponga que estos dispositivos son administrados por los jefes de los departamentos de ventas y contabilidad que pueden comunicarse con el CFO del CFO ubicado en el departamento de administración. Sin embargo, no hay restricciones en los protocolos utilizados, incluido ICMP.
Ya tenemos tres ACL aplicadas a las interfaces que rodeé en rojo en el diagrama. Laptop2 no puede contactar Laptop0 en este momento, porque esto contradice las condiciones del problema 3.
Para comunicarse entre estos dos dispositivos, debe agregar condiciones adicionales a la ACL Allow_Sa.
Del mismo modo, debe agregar condiciones a la ACL Allow_Acc para que PC0 pueda comunicarse libremente con Laptop0.
En ambas listas, agregamos líneas con el parámetro Permitir IP, lo que significa permitir el tráfico sobre cualquier protocolo IP.
Como sabe, ICMP utiliza tráfico bidireccional: envía ping y echo lo devuelve. En nuestra situación, si Laptop2 aborda el ping de Laptop0, el tráfico fluirá libremente a la red del departamento de administración. Sin embargo, cuando el paquete se devuelva a la computadora portátil del departamento de ventas, irá a la interfaz G0 / 0 del enrutador R1, donde está activo el ACL 101. Dado que el tráfico de retorno no cumple con ninguna de las condiciones de esta lista, se bloqueará. Por lo tanto, debemos complementar la lista ACL101 con condiciones de resolución para hacer ping desde Sales2 Laptop2 del departamento de ventas y hacer ping desde la PC0 del departamento de finanzas.
Hemos resuelto la Tarea Nº 3 y ahora pasamos a resolver el Problema Nº 4: "El portátil Sales3 Laptop3 solo puede acceder a su propia red de VENTAS y solo al Servicio Web a través del puerto 80 en el Servidor 1".
La primera parte de la tarea significa que tan pronto como Laptop3 intente abandonar la red de VENTAS, el enrutador R2 bloqueará su tráfico. Sin embargo, de acuerdo con la segunda parte de la tarea, esta computadora debe tener acceso a un servicio web ubicado fuera de la red de VENTAS. Esto significa que todo el tráfico, excepto el tráfico dirigido al servidor, está bloqueado.
De las tareas anteriores, sabemos que el tráfico proveniente del departamento de ventas está regulado por la ACL Allow_Sa, que aplicamos a la interfaz de entrada G0 / 1 del enrutador R2. Por lo tanto, debemos cambiar esta lista, primero agregando la línea “permitir TCP al servidor 1 a través del puerto 80” del siguiente tipo: Permiso TCP 192.168.1.3/32 192.168.1.195/32 80
La primera línea significa que cualquier tráfico HTTP llega al servidor, y la segunda Denegar IP 192.168.1.3/32 significa que el resto del tráfico, por ejemplo, FTP proveniente de Laptop3, se eliminará. Además, dejamos sin cambios las tres líneas siguientes de la ACL anterior, resolviendo así el problema 4.
Ya dije que le aconsejo que escriba las soluciones a estos problemas en papel o las escriba manualmente en una computadora, porque cambian, y en papel o en una computadora siempre puede agregar, tachar o eliminar líneas. Le llamo la atención sobre el hecho de que si simplemente agrega la solución al cuarto problema al final de la ACL, agregando dos líneas, el sistema las ignorará, porque las condiciones ubicadas arriba absorben estas reglas. Dado que la segunda línea de la lista anterior permite todo el tráfico, la condición de denegación de IP 192.168.1.3/32, ubicada al final de la lista, simplemente no se cumplirá.
Por lo tanto, la secuencia correcta de entradas de ACL es de suma importancia. Primero, debe desarrollar una cadena lógica de operaciones y organizar las líneas para que no se contradigan entre sí. Ahora pasemos a Packet Tracer y completemos todos los ajustes de acuerdo con las soluciones.
Comencemos la configuración desde el primer enrutador, Router1. Uso el comando show access-list para mostrar que falta la ACL actualmente. Luego, usando el comando show ip route, muestro que el RIP entre los dos enrutadores ya está configurado y funcionando.
Vayamos a Laptop0 y hagamos ping al Servidor1 en 192.168.1.195. Como puede ver, el ping es exitoso, ya que no tenemos ninguna ACL que prohíba o filtre el tráfico. También soy libre de hacer ping a Server0.
Ahora iremos al enrutador Router1, ingresaremos al modo de configuración global y crearemos la lista ACL 101. Para hacer esto, escribo el comando access-list 101 permit tcp. Tenga en cuenta que el sistema da una pista de qué valor de parámetro, además de tcp, se puede utilizar en este comando.
esp, icmp, osfp . CCNA ip, ismp, tcp udp.
, access-list 101 permit tcp 192.168.1.224. /28 16 , 0.0.0.15.
28 4 , 1 , 128, 2 – 64, – 32, 4 16, , (16-1) =15. , . , host IP-, : access-list 101 permit tcp 192.168.1.224 0.0.0.15 host 192.168.1.194.
, , , .
dscp, , eq, , gt – , , lt – .. , eq. .
0 65535, , . FTP 21, SMTP – 25, www – HTTP- 80. 80.
do show run , , 80 www. , , 80 21: access-list 101 permit tcp 192.168.1.224 0.0.0.15 host 192.168.1.194 eq 21.
ICMP-, . access-list 101 permit icmp. host, , IP- 192.168.1.226 0.0.0.0, , . host IP- Laptop2 – 192.168.1.2. – , .
, echo-replay. , . : access-list 101 permit icmp192.168.1.226 0.0.0.0 host 192.168.1.2 echo-replay. : access-list 101 permit icmp 192.168.1.226 0.0.0.0 host 192.168.1.130 echo-replay.
, int g0/0 ip access-group, 101 , IN. Laptop0 192.168.1.194, ACL . , , . IP- 192.168.1.195, .
, Server0 Laptop0 . HTTP FTP- 80 21, ICMP-, . .
-, 192.168.1.194, - Server0.
192.168.1.195, , ACL .
№1 R2 ACL – Allow_Ac. , ACL , . ip access-list extended Allow_Ac .
permit tcp 192.168.1.128. /26, , , – 128, – 64, , 0.0.0.63. , 255.255.255.192 255.255.255.255. permit tcp 192.168.1.128 0.0.0.63 host 192.168.1.194 eq 80. : permit tcp 192.168.1.128 0.0.0.63 host 192.168.1.194 eq 21.
№1 – PC0 Laptop0 . permit ip host 192.168.1.130 host 192.168.1.226 , .
ACL g0/0, ip access-group Allow_Ac IN. , PC0 Server 0, - . PC0 192.168.1.194, Packet Tracer, , R2 .
ACL , ip access-list extended Allow_Sa permit tcp host 192.168.1.3 host 192.168.1.195 eq 80. , HTTP- , , deny ip host 192.168.1.3 any.
, , . deny icmp 192.168.1.0. /25, 1 , 128 , , 0.0.0.127. 192.168.1.195, Server2. ACL : deny icmp 192.168.1.0 0.0.0.127 host 192.168.1.195 echo.
4- , , : permit ip 192.168.1.0 0.0.0.127 host 192.168.1.195.
, Laptop2 Laptop0. permit host 192.168.1.2 host 192.168.1.226, g0/1 ip access-group Allow_Sa IN.
, ACL Laptop3, , - . 192.168.1.195 , PC 192.168.1.130 192.168.1.226. , – - Server1.
Laptop2 Laptop0, . , , 192.168.1.226. Laptop1 , ACL , Laptop0. Laptop2 Server1 192.168.1.195, - . , 4- , ACL.
, , . ACL – , . , , , .
CCNA , . , . , .
Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes?
Apóyenos haciendo un pedido o recomendándolo a sus amigos, un
descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato? ¡Solo tenemos
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre
Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?