Laboratorio NAT Físico y GNS3
Sitio: | Facultad de Ingeniería U.Na.M. |
Curso: | Comunicaciones 2 ET544 |
Libro: | Laboratorio NAT Físico y GNS3 |
Imprimido por: | Invitado |
Día: | miércoles, 4 de diciembre de 2024, 23:37 |
1. Objetivos
El propósito de este Laboratorio es configurar un router y lograr que los equipos conectados a las distintas LANs puedan navegar por Internet.
2. Introducción
El propósito de este Laboratorio es configurar un router Mirotik.
Este equipo tiene varias interfaces. Vamos a describir el esquema que vamos a armar.
- En la interfaz ether1 del MK estará conectado a Internet, será la conexión a la red WAN.
- En la interfaz ether1 del MK tendrá habilitada el cliente DHCP para obtener una IP desde el lado de la WAN.
- En el MK se configurarán las reglas de NAT. NAT significa Network Address Traslation o traducción de direcciones de red. NAT toma una dirección de la red privada y la cambia por una pública en el Datagrama IP o viceversa. Se usa cuando necesitamos que nuestros dispositivos en la red (con IP privadas) se comuniquen a través de Internet (IP pública).
- La interfaz ether2 se configura con la subred 172.31.200.0/24.
- En la LAN asociada a ether2 se conecta un Servidor Web (IP Estática: 172.31.200.2) una PC con SO Debian
- La interfaz ether3 se configura con al subred 172.31.100.0/24y se habilita el servidor DHCP.
- En la red LAN asociada al ether3 conecta un Switch, y al mismo tres máquinas que deben poder navegar por Internet, hacer ping a DNS (google.com) y poder acceder al Servidor Web Debian de IP 172.31.200.2.
- Se podrá acceder al servidor web desde la WAN.
3. Direcciones IP/Redes
Establecer las direcciones IP de las interfaces del Router. Se acostumbra utilizar la 1er dirección de la red para el gateway. Para ambas redes LAN el gateway es el router.
- La interfaz ether1 obtiene su IP del servidor DHCP de Cloud1 *(ver en IP->DHCP Client)
- ether2 (webserver: 172.31.200.1/24
- ether3 (LAN): 172.31.100.1/24
Para evitar confusiones vamos a identificar las interfaces con un comentario descriptivo
ahora agregamos las direcciones IP. Vemos que la interfaz ether1 ya tiene su IP y a la izquierda hay una "D" de dinámica (DHCP)
después de agregar ambas interfaces nos debería quedar así:
3.1. DHCP Client
Aquí podemos ver los que el servidor DHCP de Cloud1 le asignó a ether1.
4. Tabla de Rutas
Una vez configuradas las direcciones IP se crea automáticamente un tabla de rutas.
Se aprecia que a la dirección 0.0.0.0/0 (todas las direcciones de todas las redes) se llega a través de ether1 con una distancia de 1 salto hasta el gateway. Como la dirección 0.0.0.0/0 incluye también las IP publicas el router entiende que esa interfaz es la conectada a WAN (internet) y la misma se convierte en el gateway de la topología. Las interfaces locales tiene una distancia de 0.
las siglas de la izquierda son:
- D = dinámica
- A = activa
- S = estática
- C = conectado
5. Probando la conectividad del Router
Con el botón "New Terminal" se abre una consola donde poder ejecutar ping
como se ve ya tenemos conectividad a internet.
También hay una herramienta ping en el menú "Tools"
6. DNS
Opcionalmente se puede habilitar la chache DNS. De esta manera se puede reducir las consultas DNS a un servidor externo y minimizar los tiempos de resolución DNS.
Si la opción "Allow Remote Requests"está habilitada el router puede ser utilizado como servidor DNS por los clientes de las redes conectadas al mismo. Pero también tendrán acceso las conexiones provenientes desde la WAN. Por ello hay que tomar los recaudos necesarios para proteger el router y la red, por ejemplo con una regla del firewall que niegue las conexiones WAN al puerto 53 (DNS)
7. Servidor DHCP
Los router MikroTik tienen un asistente para configurar el servidor DHCP pero por cuestiones didácticas lo vamos a realizar manualmente mediante los siguientes pasos:
- Crea los "pools"
- Crear los servicios DHCP
- Crear las redes
7.1. Crear los pools
Primero debemos crear los conjuntos de direcciones a usar en cada red (pool)
Vamos a crear dos "pools":
- red lan: rango de direcciones 172.31.100.100-172.31.100.200
- red webserver: rango de direcciones 172.31.200.100-172.31.200.200
7.2. Servicios DHCP
vamos a crear un servicio para cada red local: lan y webserver
se puede ver que las configuraciones asignadas van a ser válidas por 10 minutos (Lease Time). Pasado ese periodo el nodo deberá solicitar una nueva configuración.
No olvidar activar (Enable) el recién creado servidor DHCP
7.3. Redes DHCP
por último creamos 2 redes para el servidor DHCP:
- Address: 172.31.100.0/24
Gateway: 172.31.100.1
DNS Server: 172.31.100.1 - Address: 172.31.200.0/24
Gateway: 172.31.200.1
DNS Server: 172.31.200.1
8. Solicitando dirección
VPCS
En las PC1 y PC2, para adquirir una configuración IP utilizamos el comando de consola:
ip dhcp
Verificamos con el comando:
show ip all
Nodo Firefox
ifconfig
ip addr show eth0
Debian (webserver)
8.1. Leases (arrendamientos)
En la configuración del servidor DHCP del Mikrotik, en la pestaña "Leases", se pueden ver las direcciones IP asignadas.
8.2. Direcciones estáticas
Como vimos en la tabla de leases las direcciones arrendadas son dinámicas (la D a la izquierda de cada fila)
esto es muy práctico para reutilizar las direcciones a medida que se recambian los dispositivos, pero no es lo más indicado para servidores, ya que siempre queremos acceder a ellos con la misma IP. Por ello es recomendable asignarles una IP fija.
ahora ya no figura la "D" de dinámica y la próxima vez que acceda la configuración de ese arrendamiento se va a poder cambiar la IP
Nótese que el nodo sigue con su IP anterior hasta que expire el "lease time" y solicite una nueva configuración o hasta que se lo haga manualmente en el nodo.
9. NAT
(Acá video NAT)
Mikrotik distingue entre 2 tipos de NAT:
- Source NAT o NAT de origen: cuando la comunicación se inicia desde una red "NATeada", típicamente una red LAN.
- Destination NAT o NAT de destino; cuando la comunicación se inicia desde una WAN pretendiendo llegar a un destino detrás de un router NAT.
9.1. Source NAT - Masquerade
Si intentamos realizar un ping desde algún host de la LAN o webserver no vamos a alcanzar un destino en internet.
esto se debe a que las direcciones privadas no se pueden enrutar en internet. Más genéricamente hablando, las direcciones privadas no se deben enrutar en WANs. Para convertir direcciones privadas en públicas se utiliza NAT.
Mikrotik tiene un tipo especial de Source NAT pensado para situaciones donde la IP publica puede cambiar. El caso típio de ADSL con direcciones públicas dinámicas.
Para crear una regla de NAT vamos a IP->Firewall pestaña NAT
Como la comunicación se va a iniciar en una zona privada se trata de una source nat (chain: scrnat) y la comunicación va a salir por la interfaz ether1 que es la que está conectada al gateway.
Por último definimos la acción a llevar a cabo en esta regla de NAT: masquerade
Una vez creada la regla NAT volvemos a probar ping desde debian1 a internet y vemos que ahora si funciona
9.2. Destination NAT
En el host webserver (172.31.200.254) está corriendo un servidor web que escucha en el puerto 80.
Acceso desde LAN
Podemos acceder al mismo desde el nodo Firefox incluso estando en otra red. Esto es posible porque el nodo con Fiirefox se percata que la IP destino no está en su red y por lo tanto direcciona la comunicación hacia el gateway (mikrotik). El router Mikrotik conoce la ruta hacia la red destino así que establece el enlace.
Acceso desde la nube
Si probamos acceder al webserver (172.31.200.254) desde el Frefox del Linux Lite no vamos a poder conectarnos. Esto es lógico ya que Linux Lite está del otro lado de la nube y no conoce las redes privadas que están detrás del mikrotik. Como linux Lite tiene configurado como GW su salida a internet las IP de otras redes las envía ahí.
La única dirección IP de nuestra topología de GNS3 que conoce Linux Lite es la que tiene la interfaz 1 (gateway) del router MikroTik (192.168.122.156). Si tratamos de acceder a esa IP se nos presenta el entorno de configuración web del router. Esto debido a que el router también tiene un servidor web que está corriendo en el puerto 80.
Para acceder a nuestro webserver desde la nube se debe agregar una regla que redirigir el tráfico del puerto 80 que llega desde la nube a un host en la zona NAT. Esto se conoce como "destination NAT", también conocido como "Port Forwarding".
Creamos una nueva regla NAT del tipo dstnat como muestra la figura
Se necesita por lo menos uno de los datos señalados. Antes de terminar debemos especificar la acción que debe realizar esta regla
Luego de crear la regla dstnat ya podremos acceder a nuestro servidor web desde la nube (internet) utilizando la IP no local 192.168.122.156.
9.3. Más de un servior
Tarea
10. Reglas de Firewall
Seguridad básica
Input Chain Rules
/ip firewall filter
add action=accept chain=input connection-state=established,related,untracked comment="DEFAULT: Accept established, related, and untracked traffic."
add action=drop chain=input connection-state=invalid comment="DEFAULT: Drop invalid traffic."
add action=accept chain=input protocol=icmp comment="DEFAULT: Accept ICMP traffic."
add action=drop chain=input in-interface-list=!LAN comment="DEFAULT: Drop all other traffic not coming from LAN."
Forward Chain Rules
/ip firewall filter
add action=accept chain=forward ipsec-policy=in,ipsec comment="DEFAULT: Accept In IPsec policy."
add action=accept chain=forward ipsec-policy=out,ipsec comment="DEFAULT: Accept Out IPsec policy."
add action=accept chain=forward connection-state=established,related,untracked comment="DEFAULT: Accept established, related, and untracked traffic."
add action=drop chain=forward connection-state=invalid comment="DEFAULT: Drop invalid traffic."
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface-list=WAN comment="DEFAULT: Drop all other traffic from WAN that is not DSTNATed."
10.1. Bloquear a un nodo
Mediante una regla del cortafuegos (firewall) vamos a bloquear la comunicación del nodo Firefox. Para ello creamos una nueva regla
en lugar de utilizar la dirección de origen de capa 3 optamos por la dirección MAC, ya que es menos probable que cambie
en la pestaña de acción podemos elegir entre "Drop" y "Reject".
La diferencia es que "drop" simplemente descarta el paquete mientras que "Reject" rechaza con el envío "ICMP
destination-unreachable" a la aplicación tratando de comunicarse. De esta manera la aplicación cesa sus intentos de comunicación y evita sobrecargas en la infraestructura. Con drop el host no se entera del problema e interpreta que se perdió el paquete y reintenta la comunicación periódicamente. Estos reiterados intentos se pueden prolongar hasta por 3 minutos.
No olvidarse de agregar un comentario para identificar la finalidad de la regla
Con la regla habilitada no se puede establecer una comunicación a través del router
en la lista de reglas se puede ver estadísticas de uso de la misma
con los botones se puede habilitar y deshabilitar las distintas reglas
11. Captura de paquetes
Primero recomendamos cambiar la configuración del nodo Debian para que utilice IP estática
Como alternativa se podría definir una dirección MAC fija para evitar de que esta cambie cada vez que se inicia el nodo y por lo tanto el DHCP server le asigne otra IP.
(se utilizó una dirección MAC generada por el mismo nodo la primera vez que inició)
11.1. Captura
Luego iniciar la captura entre Firefox y el SwitchDesde el firefox del nodo firefox acceda a la siguiente página web alojada en el servidor web
172.31.200.254/form.html
Completar el formulario y enviar
y analice el tráfico http