Si desea ocultar sus dispositivos locales tras la dirección IP pública que le proporcionó su proveedor de internet, debe configurar la función de traducción de direcciones de red de origen (enmascaramiento) del enrutador MikroTik.
Supongamos que desea ocultar tanto el ordenador como el servidor de la oficina tras la IP pública 172.16.16.1. La regla será similar a la siguiente:
/ip firewall nat add chain=srcnat src-address=10.0.0.0/24 action=src-nat to-addresses=172.16.16.1 out-interface=WAN
Ahora su ISP verá todas las solicitudes que vienen con la IP 172.16.16.1 y no verá las direcciones IP de su red LAN.
Al final del artículo encontrarás un pequeño test que te permitirá evaluar los conocimientos adquiridos en esta lectura
Masquerade
La acción NAT del firewall action=masquerade es una subversión única de la acción=srcnat, fue diseñada para uso específico en situaciones donde la IP pública puede cambiar aleatoriamente, por ejemplo, el servidor DHCP cambia la IP asignada o el túnel PPPoE luego de la desconexión obtiene una IP diferente; en resumen, cuando la IP pública es dinámica.
/ip firewall nat add chain=srcnat src-address=10.0.0.0/24 action=masquerade out-interface=WAN
Cada vez que una interfaz se desconecta o cambia su dirección IP, el enrutador borra todas las entradas de seguimiento de conexión enmascaradas relacionadas con la interfaz, lo que mejora el tiempo de recuperación del sistema tras un cambio de IP pública.
Si se utiliza srcnat en lugar de masquerade, las entradas de seguimiento de conexión se conservan y las conexiones pueden reanudarse tras una falla de enlace.
Posibles inconvenientes
Desafortunadamente, esto puede generar problemas con enlaces inestables cuando la conexión se enruta por diferentes enlaces después de que el enlace principal se caiga. En este caso, pueden ocurrir las siguientes cosas:
- Al desconectarse, se purgan todas las entradas de seguimiento de conexión relacionadas.
- El siguiente paquete de cada conexión purgada (previamente enmascarada) entrará al firewall como nuevo y, si una interfaz principal no está disponible, se enrutará un paquete a través de una ruta alternativa (si existe alguna), creando así una nueva conexión enmascarada.
- El enlace principal se restablece y el enrutamiento se restaura a través de él, de modo que los paquetes que pertenecen a conexiones existentes se envían a través de la interfaz principal sin enmascararse, filtrando así las IP locales a una red pública.
Alternativa de solución
Para solucionar esta situación, se puede crear una ruta de agujero negro (blackhole route) como alternativa a la ruta que podría desaparecer al desconectarse.
Los hosts detrás de un enrutador con NAT habilitado no tienen conectividad de extremo a extremo real. Por lo tanto, algunos protocolos de Internet podrían no funcionar en escenarios con NAT. Los servicios que requieren el inicio de una conexión TCP desde fuera de la red privada o protocolos sin estado como UDP pueden verse interrumpidos.
Para superar estas limitaciones, RouterOS incluye varios asistentes NAT que permiten la navegación transversal de NAT para varios protocolos. Cuando se utiliza action=srcnat en su lugar, las entradas de seguimiento de la conexión se conservan y las conexiones pueden reanudarse.
Importante
Aunque la NAT de origen y el enmascaramiento cumplen la misma función fundamental: asignar un espacio de direcciones a otro, los detalles difieren ligeramente. En particular, el enmascaramiento selecciona la dirección IP de origen del paquete saliente a partir de la IP vinculada a la interfaz por la que saldrá el paquete.
CGNAT (NAT444)
Para combatir el agotamiento de direcciones IPv4, se implementó una nueva RFC 6598. La idea es utilizar el espacio de direcciones compartido 100.64.0.0/10 dentro de la red del operador y realizar NAT en el enrutador de borde del operador a una única IP pública o rango de IP públicas.
Debido a la naturaleza de esta configuración, también se denomina NAT444. A diferencia de una red NAT44 para un entorno NAT “normal”, se utilizan tres espacios de direcciones IPv4 diferentes.
La configuración de CGNAT en RouterOS no difiere de cualquier otra configuración de NAT de origen habitual:
/ip firewall nat
add chain=src-nat action=srcnat src-address=100.64.0.0/10 to-address=2.2.2.2 out-interface=<public_if>
Dónde:
- 2.2.2 – dirección IP pública,
- public_if – interfaz en el router perimetral del proveedor conectado a internet
Inconvenientes de NAT444
La ventaja de NAT444 es obvia: se utilizan menos direcciones IPv4 públicas. Sin embargo, esta técnica presenta importantes inconvenientes:
- El router del proveedor de servicios que realiza CGNAT necesita mantener una tabla de estado para todas las traducciones de direcciones, lo que requiere una gran cantidad de memoria y recursos de CPU.
- Problemas con los juegos de consola. Algunos juegos fallan cuando dos suscriptores que utilizan la misma dirección IPv4 pública externa intentan conectarse.
- El seguimiento de usuarios por motivos legales implica un registro adicional, ya que varios hogares se conectan a una misma dirección pública.
- Todo lo que requiera conexiones entrantes se interrumpe. Si bien esto ya ocurría con NAT convencional, los usuarios finales generalmente podían configurar el reenvío de puertos en su router NAT. CGNAT lo imposibilita. Esto significa que no se pueden alojar servidores web aquí y que los teléfonos IP tampoco pueden recibir llamadas entrantes por defecto. Algunos servidores web solo permiten un número máximo de conexiones desde la misma dirección IP pública para contrarrestar ataques DoS como las inundaciones SYN. Con CGNAT, este límite se alcanza con mayor frecuencia y algunos servicios pueden ser de baja calidad.
- 6to4 requiere direcciones con alcance global y no funcionará en redes que empleen direcciones con una extensión topológica limitada.
Filtro de paquetes
Los paquetes con direcciones de origen o destino de Espacio de Direcciones Compartido NO DEBEN reenviarse a través de los límites del proveedor de servicios. Los proveedores de servicios DEBEN filtrar dichos paquetes en los enlaces de entrada. En RouterOS, esto se puede hacer fácilmente con filtros de firewall en los enrutadores de borde:
/ip firewall filter
add chain=input src-address=100.64.0.0/10 action=drop in-interface=<public_if>
add chain=output dst-address=100.64.0.0/10 action=drop out-interface=<public_if>
add chain=forward src-address=100.64.0.0/10 action=drop in-interface=<public_if>
add chain=forward src-address=100.64.0.0/10 action=drop out-interface=<public_if>
add chain=forward dst-address=100.64.0.0/10 action=drop out-interface=<public_if>
Sugerencia de la RFC 7422
En una red CGN de gran tamaño, es posible que se requiera que los proveedores de servicios registren las direcciones MAP, lo cual puede ser problemático. Afortunadamente, la RFC 7422 sugiere una forma de gestionar las traducciones CGN que reduce significativamente la cantidad de registros necesarios, a la vez que proporciona trazabilidad para la respuesta ante abusos.
La RFC establece que, en lugar de registrar cada conexión, las CGN podrían asignar de forma determinista las direcciones privadas del cliente (recibidas en la interfaz de la CGN, es decir, interna) a direcciones públicas extendidas con rangos de puertos.
Esto significa que se deben agregar reglas NAT independientes para lograr asignaciones individuales, como las que se muestran en el siguiente ejemplo:
Inside IP | Outside IP/Port range |
100.64.0.1 | 2.2.2.2:5000-5199 |
100.64.0.2 | 2.2.2.2:5200-5399 |
100.64.0.3 | 2.2.2.2:5400-5599 |
100.64.0.4 | 2.2.2.2:5600-5799 |
100.64.0.5 | 2.2.2.2:5800-5999 |
Ejemplo usando script
En lugar de escribir las reglas manualmente, se recomienda usar un script. El siguiente ejemplo se puede adaptar a cualquier requisito de su configuración.
{
######## Adjustable values #########
:local StartingAddress 100.64.0.1
:local ClientCount 5
:local AddressesPerClient 2
:local PublicAddress 2.2.2.2
:local StartingPort 5000
:local PortsPerAddress 200
####################################
# All client chain jump
/ip firewall nat add chain=srcnat action=jump jump-target=clients \
src-address="$StartingAddress-$($StartingAddress + ($ClientCount * $AddressesPerClient) - 1)"
:local currentPort $StartingPort
:for c from=1 to=$ClientCount do={
# Specific client chain jumps
:if ($AddressesPerClient > 1) do={
/ip firewall nat add chain=clients action=jump jump-target="client-$c" \
src-address="$($StartingAddress + ($AddressesPerClient * ($c - 1)))-$($StartingAddress + ($AddressesPerClient * $c -1))"
} else={
/ip firewall nat add chain=clients action=jump jump-target="client-$c" \
src-address="$($StartingAddress + ($AddressesPerClient * ($c - 1)))"
}
# Translation rules
:for a from=1 to=$AddressesPerClient do={
/ip firewall nat add chain="client-$c" action=src-nat protocol=tcp \
src-address="$($StartingAddress + (($c -1) * $AddressesPerClient) + $a - 1)" to-address=$PublicAddress to-ports="$currentPort-$($currentPort + $PortsPerAddress - 1)"
/ip firewall nat add chain="client-$c" action=src-nat protocol=udp \
src-address="$($StartingAddress + (($c -1) * $AddressesPerClient) + $a - 1)" to-address=$PublicAddress to-ports="$currentPort-$($currentPort + $PortsPerAddress - 1)"
:set currentPort ($currentPort + $PortsPerAddress)
}
}
}Los seis valores locales se pueden ajustar y el script se puede pegar en la terminal o almacenar en la sección de scripts del sistema, por si fuera necesario regenerar la configuración posteriormente.
Tras la ejecución, debería obtener un conjunto de reglas
[admin@MikroTik] > ip firewall nat print
Flags: X - disabled, I - invalid; D - dynamic
0 chain=srcnat action=jump jump-target=clients
src-address=100.64.0.1-100.64.0.10
1 chain=clients action=jump jump-target=client-1
src-address=100.64.0.1-100.64.0.2
2 chain=client-1 action=src-nat to-addresses=2.2.2.2 to-ports=5000-5199
protocol=tcp src-address=100.64.0.1
3 chain=client-1 action=src-nat to-addresses=2.2.2.2 to-ports=5000-5199
protocol=udp src-address=100.64.0.1
4 chain=client-1 action=src-nat to-addresses=2.2.2.2 to-ports=5200-5399
protocol=tcp src-address=100.64.0.2
5 chain=client-1 action=src-nat to-addresses=2.2.2.2 to-ports=5200-5399
protocol=udp src-address=100.64.0.2
6 chain=clients action=jump jump-target=client-2
src-address=100.64.0.3-100.64.0.4
7 chain=client-2 action=src-nat to-addresses=2.2.2.2 to-ports=5400-5599
protocol=tcp src-address=100.64.0.3
8 chain=client-2 action=src-nat to-addresses=2.2.2.2 to-ports=5400-5599
protocol=udp src-address=100.64.0.3
9 chain=client-2 action=src-nat to-addresses=2.2.2.2 to-ports=5600-5799
protocol=tcp src-address=100.64.0.4
10 chain=client-2 action=src-nat to-addresses=2.2.2.2 to-ports=5600-5799
protocol=udp src-address=100.64.0.4
11 chain=clients action=jump jump-target=client-3
src-address=100.64.0.5-100.64.0.6
12 chain=client-3 action=src-nat to-addresses=2.2.2.2 to-ports=5800-5999
protocol=tcp src-address=100.64.0.5
13 chain=client-3 action=src-nat to-addresses=2.2.2.2 to-ports=5800-5999
protocol=udp src-address=100.64.0.5
14 chain=client-3 action=src-nat to-addresses=2.2.2.2 to-ports=6000-6199
protocol=tcp src-address=100.64.0.6
15 chain=client-3 action=src-nat to-addresses=2.2.2.2 to-ports=6000-6199
protocol=udp src-address=100.64.0.6
[...]
Conclusiones
- Masquerade y src-nat permiten ocultar redes privadas detrás de una IP pública, siendo masquerade ideal para conexiones con IP dinámica debido a su capacidad de limpiar conexiones al cambiar la IP.
- CGNAT (NAT444) permite ahorrar direcciones IPv4, pero limita severamente el uso de servicios que requieren conexiones entrantes, como servidores web o juegos en línea, y complica la trazabilidad legal.
- RouterOS ofrece herramientas avanzadas como scripts y filtros para implementar CGNAT de forma eficiente y segura, siguiendo buenas prácticas como el filtrado de paquetes 100.64.0.0/10 y la asignación determinista de puertos según la RFC 7422.
Breve cuestionario de conocimientos
¿Qué te pareció este artículo?
¿Te atreves a evaluar tus conocimientos aprendidos?
Libros recomendados para éste artículo
(Book) Networking with MikroTik RouterOS: A Practical Approach to Understanding and Implementing RouterOS
Study material for the MTCNA Certification Course, updated to RouterOS v7
Libro Switching y Brindging RouterOS v7
Material de estudio para el Curso de Certificación MTCSWE actualizado a RouterOS v7










