Conceptos básicos del enrutamiento estático en Mikrotik RouterOS

El enrutamiento es el proceso de encontrar la mejor ruta para transmitir paquetes a través de redes TCP/IP. Cualquier dispositivo conectado a una red IPv4 contiene un proceso y tablas de enrutamiento.

Este artículo no es un CÓMO, describe el enrutamiento estático en RouterOS con ejemplos, omití deliberadamente el resto de las configuraciones (por ejemplo, srcnat para acceder a Internet), por lo que comprender el material requiere un cierto nivel de conocimiento de redes y RouterOS.

Conmutación y enrutamiento

La conmutación es el proceso de intercambio de paquetes dentro de un segmento Layer2 (Ethernet, ppp, ...). Si el dispositivo ve que el destinatario del paquete está en la misma subred Ethernet que él, aprende la dirección mac utilizando el protocolo arp y transmite el paquete directamente, sin pasar por el enrutador. Una conexión ppp (punto a punto) puede tener solo dos participantes y el paquete siempre se envía a una dirección 0xff.

El enrutamiento es el proceso de transferencia de paquetes entre segmentos Layer2. Si un dispositivo quiere enviar un paquete cuyo destinatario está fuera del segmento Ethernet, busca en su tabla de enrutamiento y pasa el paquete a una puerta de enlace que sabe dónde enviar el paquete a continuación (o puede que no lo sepa, el remitente original del paquete es no es consciente de esto).

La forma más sencilla de pensar en un enrutador es como un dispositivo conectado a dos o más segmentos Layer2 y capaz de pasar paquetes entre ellos al determinar la mejor ruta de la tabla de enrutamiento.

Si entiendes todo, o ya lo sabías, sigue leyendo. Por lo demás, le recomiendo encarecidamente que se familiarice con un pequeño, pero muy espacioso artículo.

Enrutamiento en RouterOS y PacketFlow

Casi toda la funcionalidad relacionada con el enrutamiento estático está en el paquete te. Bolsa de plastico enrutamiento agrega soporte para algoritmos de enrutamiento dinámico (RIP, OSPF, BGP, MME), filtros de enrutamiento y BFD.

Menú principal para configurar el enrutamiento: [IP]->[Route]. Los esquemas complejos pueden requerir que los paquetes se etiqueten previamente con una marca de enrutamiento en: [IP]->[Firewall]->[Mangle] (cadenas PREROUTING и OUTPUT).

Hay tres lugares en PacketFlow donde se toman decisiones de enrutamiento de paquetes IP:

1. Enrutamiento de paquetes recibidos por el enrutador. En esta etapa, se decide si el paquete irá al proceso local o se enviará a la red. Los paquetes de tránsito reciben Interfaz de salida
2. Enrutamiento de paquetes salientes locales. Los paquetes salientes reciben Interfaz de salida
3. Paso de enrutamiento adicional para paquetes salientes, le permite cambiar la decisión de enrutamiento en [Output|Mangle]

• La ruta del paquete en los bloques 1, 2 depende de las reglas en [IP]->[Route]
• La ruta del paquete en los puntos 1, 2 y 3 depende de las reglas en [IP]->[Route]->[Rules]
• La ruta del paquete en los bloques 1, 3 se puede influir usando [IP]->[Firewall]->[Mangle]

RIB, FIB, caché de enrutamiento

Base de información de enrutamiento
La base en la que se recopilan rutas de protocolos de enrutamiento dinámico, rutas de ppp y dhcp, rutas estáticas y conectadas. Esta base de datos contiene todas las rutas, excepto las filtradas por el administrador.

Condicionalmente, podemos suponer que [IP]->[Route] muestra COSTILLA.

Base de información de reenvío

La base en la que se recogen las mejores rutas desde RIB. Todas las rutas en la FIB están activas y se utilizan para reenviar paquetes. Si la ruta se vuelve inactiva (deshabilitada por el administrador (sistema) o la interfaz a través de la cual se debe enviar el paquete no está activa), la ruta se elimina de la FIB.

Para tomar una decisión de enrutamiento, la tabla FIB utiliza la siguiente información sobre un paquete IP:

• Dirección de la fuente
• Dirección de destino
• interfaz de origen
• marca de enrutamiento
• Condiciones de servicio (DSCP)

Entrar en el paquete FIB pasa por las siguientes etapas:

• ¿El paquete está diseñado para un proceso de enrutador local?
• ¿El paquete está sujeto a las reglas PBR del sistema o del usuario?
  • En caso afirmativo, el paquete se envía a la tabla de enrutamiento especificada
• El paquete se envía a la mesa principal.

Condicionalmente, podemos suponer que [IP]->[Route Active=yes] muestra FIB.

Caché de enrutamiento
Mecanismo de almacenamiento en caché de rutas. El enrutador recuerda dónde se enviaron los paquetes y si hay paquetes similares (presumiblemente de la misma conexión) los deja ir por la misma ruta, sin verificar en la FIB. La caché de ruta se borra periódicamente.

Para los administradores de RouterOS, no crearon herramientas para ver y administrar el Caché de enrutamiento, pero cuando se puede deshabilitar en [IP]->[Settings].

Este mecanismo se eliminó del kernel de Linux 3.6, pero RouterOS todavía usa el kernel 3.3.5, tal vez Routing cahce sea una de las razones.

Cuadro de diálogo Agregar ruta

[IP]->[Route]->[+]

1. Subred para la que desea crear una ruta (predeterminado: 0.0.0.0/0)
2. IP de puerta de enlace o interfaz a la que se enviará el paquete (puede haber varias, consulte ECMP a continuación)
3. Comprobación de disponibilidad de puerta de enlace
4. Tipo de registro
5. Distancia (métrica) para una ruta
6. Tabla de ruteo
7. IP para paquetes salientes locales a través de esta ruta
8. El propósito de Scope y Target Scope está escrito al final del artículo.

Banderas de ruta

• X - La ruta está deshabilitada por el administrador (disabled=yes)
• A - La ruta se utiliza para enviar paquetes
• D - Ruta añadida dinámicamente (BGP, OSPF, RIP, MME, PPP, DHCP, Conectado)
• C - La subred está conectada directamente al enrutador
• S - Ruta estática
• r,b,o,m - Ruta añadida por uno de los protocolos de enrutamiento dinámico
• B,U,P: ruta de filtrado (elimina paquetes en lugar de transmitirlos)

¿Qué especificar en la puerta de enlace: dirección IP o interfaz?

El sistema le permite especificar ambos, mientras que no jura ni da pistas si hizo algo mal.

Dirección IP
La dirección de la puerta de enlace debe ser accesible a través de Layer2. Para Ethernet, esto significa que el enrutador debe tener una dirección de la misma subred en una de las interfaces ip activas, para ppp, que la dirección de la puerta de enlace se especifica en una de las interfaces activas como dirección de subred.
Si la condición de accesibilidad para la Capa 2 no se cumple, la ruta se considera inactiva y no cae en la FIB.

Interfaz
Todo es más complicado y el comportamiento del router depende del tipo de interfaz:

• La conexión PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) asume solo dos participantes y el paquete siempre se enviará a la puerta de enlace para su transmisión, si la puerta de enlace detecta que el destinatario es él mismo, entonces transferirá el paquete a su proceso local.
  
• Ethernet asume la presencia de muchos participantes y enviará solicitudes a la interfaz arp con la dirección del destinatario del paquete, este es un comportamiento esperado y bastante normal para las rutas conectadas.
  Pero cuando intente usar la interfaz como una ruta para una subred remota, obtendrá la siguiente situación: la ruta está activa, el ping a la puerta de enlace pasa, pero no llega al destinatario desde la subred especificada. Si observa la interfaz a través de un sniffer, verá solicitudes arp con direcciones de una subred remota.
  

Intente especificar la dirección IP como puerta de enlace siempre que sea posible. La excepción son las rutas conectadas (creadas automáticamente) y las interfaces PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*).

OpenVPN no contiene un encabezado de PPP, pero puede usar el nombre de la interfaz de OpenVPN para crear una ruta.

Ruta más específica

Regla básica de enrutamiento. La ruta que describe la subred más pequeña (con la máscara de subred más grande) tiene prioridad en la decisión de enrutamiento del paquete. La posición de las entradas en la tabla de enrutamiento no es relevante para la elección: la regla principal es más específica.

Todas las rutas del esquema especificado están activas (ubicadas en FIB). apunten a diferentes subredes y no entren en conflicto entre sí.

Si una de las puertas de enlace deja de estar disponible, la ruta asociada se considerará inactiva (eliminada de la FIB) y se buscarán paquetes de las rutas restantes.

La ruta con la subred 0.0.0.0/0 a veces tiene un significado especial y se denomina "Ruta predeterminada" o "Puerta de enlace de último recurso". De hecho, no tiene nada de mágico y simplemente incluye todas las direcciones IPv4 posibles, pero estos nombres describen bien su función: indica la puerta de enlace a la que reenviar los paquetes para los que no hay otras rutas más precisas.

La máscara de subred máxima posible para IPv4 es /32, esta ruta apunta a un host específico y se puede usar en la tabla de enrutamiento.

Comprender una ruta más específica es fundamental para cualquier dispositivo TCP/IP.

Distancia

Las distancias (o métricas) son necesarias para el filtrado administrativo de rutas a una sola subred accesible a través de múltiples puertas de enlace. Una ruta con una métrica inferior se considera prioritaria y se incluirá en la FIB. Si una ruta con una métrica más baja deja de estar activa, será reemplazada por una ruta con una métrica más alta en la FIB.

Si hay varias rutas a la misma subred con la misma métrica, el enrutador agregará solo una de ellas a la tabla FIB, guiado por su lógica interna.

La métrica puede tomar un valor de 0 a 255:

• 0 - Métrica para rutas conectadas. El administrador no puede establecer la distancia 0
• 1-254 - Métricas disponibles para el administrador para configurar rutas. Las métricas con un valor más bajo tienen una prioridad más alta
• 255 - Métrica a disposición del administrador para la configuración de rutas. A diferencia de la 1-254, una ruta con una métrica de 255 siempre permanece inactiva y no cae en la FIB
• métricas específicas. Las rutas derivadas de los protocolos de enrutamiento dinámico tienen valores métricos estándar

comprobar la puerta de enlace

Check gateway es una extensión de MikroTik RoutesOS para verificar la disponibilidad de la puerta de enlace a través de icmp o arp. Una vez cada 10 segundos (no se puede cambiar), se envía una solicitud a la puerta de enlace, si la respuesta no se recibe dos veces, la ruta se considera no disponible y se elimina de la FIB. Si la verificación de puerta de enlace se ha deshabilitado, la ruta de verificación continúa y la ruta volverá a estar activa después de una verificación exitosa.

Check gateway deshabilita la entrada en la que está configurado y todas las demás entradas (en todas las tablas de enrutamiento y rutas ecmp) con la puerta de enlace especificada.

En general, la puerta de enlace de verificación funciona bien siempre que no haya problemas con la pérdida de paquetes en la puerta de enlace. La puerta de enlace de verificación no sabe lo que está sucediendo con la comunicación fuera de la puerta de enlace verificada, esto requiere herramientas adicionales: scripts, enrutamiento recursivo, protocolos de enrutamiento dinámico.

La mayoría de los protocolos VPN y de túnel contienen herramientas integradas para comprobar la actividad de la conexión, lo que supone una carga adicional (pero muy pequeña) para el rendimiento de la red y del dispositivo.

rutas ECMP

Múltiples rutas de igual costo: envío de paquetes al destinatario utilizando varias puertas de enlace simultáneamente utilizando el algoritmo Round Robin.

El administrador crea una ruta ECMP especificando varias puertas de enlace para una subred (o automáticamente, si hay dos rutas OSPF equivalentes).

ECMP se utiliza para equilibrar la carga entre dos canales, en teoría, si hay dos canales en la ruta ecmp, entonces para cada paquete el canal saliente debe ser diferente. Pero el mecanismo de caché de enrutamiento envía paquetes desde la conexión a lo largo de la ruta que tomó el primer paquete, como resultado, obtenemos una especie de equilibrio basado en conexiones (equilibrio de carga por conexión).

Si deshabilita la memoria caché de enrutamiento, los paquetes en la ruta ECMP se compartirán correctamente, pero hay un problema con NAT. La regla NAT procesa solo el primer paquete de la conexión (el resto se procesa automáticamente), y resulta que los paquetes con la misma dirección de origen salen de diferentes interfaces.

Compruebe que la puerta de enlace no funciona en las rutas ECMP (error de RouterOS). Pero puede sortear esta limitación creando rutas de validación adicionales que deshabilitarán las entradas en ECMP.

Filtrado por medio de Enrutamiento

La opción Tipo determina qué hacer con el paquete:

• unicast - enviar a la puerta de enlace especificada (interfaz)
• agujero negro - descartar un paquete
• prohibir, inalcanzable: descartar el paquete y enviar un mensaje icmp al remitente

El filtrado generalmente se usa cuando es necesario asegurar el envío de paquetes en la dirección incorrecta, por supuesto, puede filtrar esto a través del firewall.

Un par de ejemplos

Para consolidar las cosas básicas sobre el enrutamiento.

Enrutador doméstico típico

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. Ruta estática a 0.0.0.0/0 (ruta por defecto)
2. Ruta conectada en la interfaz con el proveedor
3. Ruta conectada en la interfaz LAN

Enrutador doméstico típico con PPPoE

1. Ruta estática a la ruta predeterminada, agregada automáticamente. se especifica en las propiedades de conexión
2. Ruta conectada para conexión PPP
3. Ruta conectada en la interfaz LAN

Enrutador doméstico típico con dos proveedores y redundancia

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. Ruta estática a ruta predeterminada a través del primer proveedor con métrica 1 y verificación de disponibilidad de puerta de enlace
2. Ruta estática a ruta predeterminada a través del segundo proveedor con métrica 2
3. Rutas conectadas

El tráfico a 0.0.0.0/0 pasa por 10.10.10.1 mientras esta puerta de enlace está disponible; de ​​lo contrario, cambia a 10.20.20.1

Tal esquema puede considerarse una reserva de canal, pero no está exento de inconvenientes. Si se produce una ruptura fuera de la puerta de enlace del proveedor (por ejemplo, dentro de la red del operador), su enrutador no lo sabrá y seguirá considerando la ruta como activa.

Enrutador doméstico típico con dos proveedores, redundancia y ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. Rutas estáticas para verificar la puerta de enlace de Chack.
2. ruta ECMP
3. Rutas conectadas

Las rutas a verificar son azules (el color de las rutas inactivas), pero esto no interfiere con la puerta de enlace de verificación. La versión actual (6.44) de RoS da prioridad automática a la ruta ECMP, pero es mejor agregar rutas de prueba a otras tablas de enrutamiento (opción routing-mark)

En Speedtest y otros sitios similares, no habrá aumento en la velocidad (ECMP divide el tráfico por conexiones, no por paquetes), pero las aplicaciones p2p deberían cargarse más rápido.

Filtrado a través de enrutamiento

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. Ruta estática a ruta predeterminada
2. Ruta estática a 192.168.200.0/24 sobre túnel ipip
3. Prohibición de ruta estática a 192.168.200.0/24 a través del enrutador ISP

Una opción de filtrado en la que el tráfico del túnel no irá al enrutador del proveedor cuando la interfaz ipip esté deshabilitada. Dichos esquemas rara vez se requieren, porque puede implementar el bloqueo a través del firewall.

Bucle de enrutamiento
Bucle de enrutamiento: una situación en la que un paquete se ejecuta entre enrutadores antes de que expire el ttl. Por lo general, es el resultado de un error de configuración, en redes grandes se trata mediante la implementación de protocolos de enrutamiento dinámico, en redes pequeñas, con cuidado.

Se parece a esto:

Un ejemplo (más simple) de cómo obtener un resultado similar:

El ejemplo del bucle de enrutamiento no tiene ningún uso práctico, pero muestra que los enrutadores no tienen idea de la tabla de enrutamiento de su vecino.

Enrutamiento basado en políticas y tablas de enrutamiento adicionales

Al elegir una ruta, el enrutador usa solo un campo del encabezado del paquete (Dst. Address): este es el enrutamiento básico. El enrutamiento basado en otras condiciones, como la dirección de origen, el tipo de tráfico (ToS), el equilibrio sin ECMP, pertenece al enrutamiento basado en políticas (PBR) y utiliza tablas de enrutamiento adicionales.

Ruta más específica es la regla de selección de ruta principal dentro de la tabla de enrutamiento.

De forma predeterminada, todas las reglas de enrutamiento se agregan a la tabla principal. El administrador puede crear un número arbitrario de tablas de enrutamiento adicionales y enrutar paquetes hacia ellas. Las reglas de diferentes tablas no entran en conflicto entre sí. Si el paquete no encuentra una regla adecuada en la tabla especificada, irá a la tabla principal.

Ejemplo con distribución a través de Firewall:

• 192.168.100.10 -> 8.8.8.8
  1. El tráfico de 192.168.100.10 se etiqueta vía-isp1 в [Prerouting|Mangle]
  2. En la etapa de enrutamiento de la tabla vía-isp1 busca una ruta a 8.8.8.8
  3. Ruta encontrada, el tráfico se envía a la puerta de enlace 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. El tráfico de 192.168.200.20 se etiqueta vía-isp2 в [Prerouting|Mangle]
  2. En la etapa de enrutamiento de la tabla vía-isp2 busca una ruta a 8.8.8.8
  3. Ruta encontrada, el tráfico se envía a la puerta de enlace 10.20.20.1
• Si una de las puertas de enlace (10.10.10.1 o 10.20.20.1) deja de estar disponible, el paquete irá a la mesa principal y buscará una ruta adecuada allí

Problemas terminológicos

RouterOS tiene ciertos problemas de terminología.
Al trabajar con reglas en [IP]->[Routes] se indica la tabla de enrutamiento, aunque se escribe que la etiqueta:

В [IP]->[Routes]->[Rule] todo es correcto, en la condición de la etiqueta en la acción de la tabla:

Cómo enviar un paquete a una tabla de enrutamiento específica

RouterOS proporciona varias herramientas:

• Reglas en [IP]->[Routes]->[Rules]
• Marcadores de ruta (action=mark-routing) En [IP]->[Firewall]->[Mangle]
• VRF

Reglas [IP]->[Route]->[Rules]
Las reglas se procesan secuencialmente, si el paquete cumple las condiciones de la regla, no pasa más.

Las reglas de enrutamiento le permiten ampliar las posibilidades de enrutamiento, basándose no solo en la dirección del destinatario, sino también en la dirección de origen y la interfaz en la que se recibió el paquete.

Las reglas consisten en condiciones y una acción:

• Condiciones. Prácticamente repite la lista de signos por los cuales se verifica el paquete en la FIB, solo falta ToS.
• Actividad
  • buscar - enviar un paquete a una tabla
  • buscar solo en la tabla: bloquear el paquete en la tabla, si no se encuentra la ruta, el paquete no irá a la tabla principal
  • soltar - soltar un paquete
  • inalcanzable: descartar el paquete con la notificación del remitente

En FIB, el tráfico a los procesos locales se procesa sin pasar por las reglas [IP]->[Route]->[Rules]:

marcado [IP]->[Firewall]->[Mangle]
Las etiquetas de enrutamiento le permiten configurar la puerta de enlace para un paquete usando casi cualquier condición de Firewall:

Prácticamente, porque no todos tienen sentido, y algunos pueden funcionar de manera inestable.

Hay dos formas de etiquetar un paquete:

• poner inmediatamente marca de enrutamiento
• poner primero marca de conexión, luego en base a marca de conexión poner marca de enrutamiento

En un artículo sobre cortafuegos, escribí que es preferible la segunda opción. reduce la carga en la CPU, en el caso de marcar rutas; esto no es del todo cierto. Estos métodos de marcado no siempre son equivalentes y se suelen utilizar para resolver diversos problemas.

Ejemplos de uso

Pasemos a los ejemplos del uso de Policy Base Routing, son mucho más fáciles de mostrar por qué todo esto es necesario.

MultiWAN y tráfico saliente (salida) de retorno
Un problema común con una configuración MultiWAN: Mikrotik está disponible en Internet solo a través de un proveedor "activo".

Al enrutador no le importa a qué ip llegó la solicitud, al generar una respuesta, buscará una ruta en la tabla de enrutamiento donde la ruta a través de isp1 esté activa. Además, lo más probable es que dicho paquete se filtre en el camino hacia el destinatario.

Otro punto interesante. Si se configura una fuente nat "simple" en la interfaz ether1: /ip fi nat add out-interface=ether1 action=masquerade el paquete se pondrá en línea con src. address=10.10.10.100, lo que empeora aún más las cosas.

Hay varias formas de solucionar el problema, pero cualquiera de ellas requerirá tablas de enrutamiento adicionales:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

el uso de [IP]->[Route]->[Rules]
Especifique la tabla de enrutamiento que se usará para los paquetes con la IP de origen especificada.

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

Puede usar action=lookup, pero para el tráfico saliente local, esta opción excluye por completo las conexiones desde la interfaz incorrecta.

• El sistema genera un paquete de respuesta con Src. Dirección: 10.20.20.200
• El paso Decisión de enrutamiento (2) comprueba [IP]->[Routes]->[Rules] y el paquete se envía a la tabla de enrutamiento sobre-isp2
• De acuerdo con la tabla de enrutamiento, el paquete debe enviarse a la puerta de enlace 10.20.20.1 a través de la interfaz ether2

Este método no requiere un Rastreador de conexión en funcionamiento, a diferencia de usar la tabla Mangle.

el uso de [IP]->[Firewall]->[Mangle]
La conexión comienza con un paquete entrante, por lo que lo marcamos (action=mark-connection), para los paquetes salientes de una conexión marcada, configure la etiqueta de enrutamiento (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Si se configuran varios ips en una interfaz, puede agregar a la condición dst-address para estar seguro.

• Un paquete abre la conexión en la interfaz ether2. El paquete entra [INPUT|Mangle] que dice marcar todos los paquetes de la conexión como de-isp2
• El sistema genera un paquete de respuesta con Src. Dirección: 10.20.20.200
• En la etapa de decisión de enrutamiento (2), el paquete, de acuerdo con la tabla de enrutamiento, se envía a la puerta de enlace 10.20.20.1 a través de la interfaz ether1. Puede verificar esto iniciando sesión en los paquetes [OUTPUT|Filter]
• En el escenario [OUTPUT|Mangle] la etiqueta de conexión está marcada de-isp2 y el paquete recibe una etiqueta de ruta sobre-isp2
• El paso Ajuste de enrutamiento (3) verifica la presencia de una etiqueta de enrutamiento y la envía a la tabla de enrutamiento adecuada
• De acuerdo con la tabla de enrutamiento, el paquete debe enviarse a la puerta de enlace 10.20.20.1 a través de la interfaz ether2

MultiWAN y tráfico dst-nat de retorno

Un ejemplo es más complicado, qué hacer si hay un servidor (por ejemplo, web) detrás del enrutador en una subred privada y necesita proporcionar acceso a él a través de cualquiera de los proveedores.

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

La esencia del problema será la misma, la solución es similar a la opción Firewall Mangle, solo se utilizarán otras cadenas:

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

El diagrama no muestra NAT, pero creo que todo está claro.

MultiWAN y conexiones salientes

Puede usar las capacidades de PBR para crear múltiples conexiones vpn (SSTP en el ejemplo) desde diferentes interfaces de enrutador.

Tablas de enrutamiento adicionales:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

Marcas del paquete:

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

Reglas NAT simples; de lo contrario, el paquete dejará la interfaz con el Src incorrecto. DIRECCIÓN:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

Analizando:

• El enrutador crea tres procesos SSTP
• En la etapa Decisión de enrutamiento (2), se selecciona una ruta para estos procesos en función de la tabla de enrutamiento principal. Desde la misma ruta, el paquete recibe Src. Dirección vinculada a la interfaz ether1
• В [Output|Mangle] los paquetes de diferentes conexiones reciben diferentes etiquetas
• Los paquetes ingresan a las tablas correspondientes a las etiquetas en la etapa de Ajuste de enrutamiento y reciben una nueva ruta para enviar paquetes
• Pero los paquetes todavía tienen Src. Dirección de ether1, en el escenario [Nat|Srcnat] la dirección se sustituye según la interfaz

Curiosamente, en el enrutador verá la siguiente tabla de conexión:

Connection Tracker funciona antes [Mangle] и [Srcnat], por lo que todas las conexiones provienen de la misma dirección, si observa con más detalle, luego en Replay Dst. Address habrá direcciones después de NAT:

En el servidor VPN (tengo uno en el banco de pruebas), puedes ver que todas las conexiones provienen de las direcciones correctas:

Sostén el camino
Hay una manera más fácil, simplemente puede especificar una puerta de enlace específica para cada una de las direcciones:

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

Pero tales rutas afectarán no solo el tráfico de salida sino también el de tránsito. Además, si no necesita que el tráfico al servidor vpn pase por canales de comunicación inapropiados, tendrá que agregar 6 reglas más para [IP]->[Routes]с type=blackhole. En la versión anterior - 3 reglas en [IP]->[Route]->[Rules].

Distribución de conexiones de usuarios por canales de comunicación

Tareas sencillas y cotidianas. Nuevamente, se necesitarán tablas de enrutamiento adicionales:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

Uso [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

Si uso action=lookup, luego, cuando uno de los canales está deshabilitado, el tráfico irá a la mesa principal y pasará por el canal de trabajo. Si esto es necesario o no depende de la tarea.

Usando las marcas en [IP]->[Firewall]->[Mangle]
Un ejemplo simple con listas de direcciones IP. En principio, se puede utilizar casi cualquier condición. La única advertencia de la capa 7, incluso cuando se combina con etiquetas de conexión, puede parecer que todo funciona correctamente, pero parte del tráfico seguirá yendo por el camino equivocado.

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

Puede "bloquear" a los usuarios en una tabla de enrutamiento a través de [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

Ya sea a través [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

retiro profesional dst-address-type=!local
Condición adicional dst-address-type=!local es necesario que el tráfico de los usuarios llegue a los procesos locales del router (dns, winbox, ssh,...). Si varias subredes locales están conectadas al enrutador, es necesario asegurarse de que el tráfico entre ellas no vaya a Internet, por ejemplo, utilizando dst-address-table.

En el ejemplo usando [IP]->[Route]->[Rules] no existen tales excepciones, pero el tráfico llega a los procesos locales. El caso es que entrar en el paquete FIB marcado en [PREROUTING|Mangle] tiene una etiqueta de ruta y va a una tabla de enrutamiento distinta a la principal, donde no hay una interfaz local. En el caso de las reglas de enrutamiento, primero se verifica si el paquete está destinado a un proceso local y solo en la etapa PBR del usuario pasa a la tabla de enrutamiento especificada.

Uso [IP]->[Firewall]->[Mangle action=route]
Esta acción solo funciona en [Prerouting|Mangle] y le permite dirigir el tráfico a la puerta de enlace especificada sin usar tablas de enrutamiento adicionales, especificando la dirección de la puerta de enlace directamente:

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

Действие route tiene una prioridad más baja que las reglas de enrutamiento ([IP]->[Route]->[Rules]). En el caso de las marcas de ruta, todo depende de la posición de las reglas, si la regla con action=route Vale más que action=mark-route, entonces se utilizará (independientemente de la bandera passtrough), en caso contrario marcando la ruta.
Hay muy poca información en la wiki sobre esta acción y todas las conclusiones se obtienen de manera experimental, en cualquier caso, no encontré opciones cuando usar esta opción da ventajas sobre otras.

Equilibrio dinámico basado en PPC

Clasificador por conexión: es un análogo más flexible de ECMP. A diferencia de ECMP, divide el tráfico por conexiones de manera más estricta (ECMP no sabe nada de conexiones, pero cuando se combina con Routing Cache, se obtiene algo similar).

PCC toma campos especificados del encabezado ip, los convierte a un valor de 32 bits y los divide por denominador. El resto de la división se compara con el especificado el resto y si coinciden, se aplica la acción especificada. Más. Suena loco pero funciona.

Ejemplo con tres direcciones:

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

Un ejemplo de distribución dinámica de tráfico por src.address entre tres canales:

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

Al marcar rutas, hay una condición adicional: in-interface=br-lan, sin ella debajo action=mark-routing El tráfico de respuesta de Internet obtendrá y, de acuerdo con las tablas de enrutamiento, volverá al proveedor.

Cambio de canales de comunicación

Verificar ping es una buena herramienta, pero solo verifica la conexión con el par de IP más cercano, las redes de proveedores generalmente consisten en una gran cantidad de enrutadores y una interrupción de la conexión puede ocurrir fuera del par más cercano, y luego hay operadores de telecomunicaciones de red troncal que también pueden tiene problemas, en general, el ping de verificación no siempre muestra información actualizada sobre el acceso a la red global.
Si los proveedores y las grandes corporaciones tienen el protocolo de enrutamiento dinámico BGP, entonces los usuarios domésticos y de oficina deben descubrir de forma independiente cómo verificar el acceso a Internet a través de un canal de comunicación específico.

Por lo general, se utilizan scripts que, a través de un determinado canal de comunicación, verifican la disponibilidad de una dirección IP en Internet, eligiendo algo confiable, por ejemplo, google dns: 8.8.8.8. 8.8.4.4. Pero en la comunidad de Mikrotik, se ha adaptado una herramienta más interesante para esto.

Algunas palabras sobre el enrutamiento recursivo
El enrutamiento recursivo es necesario cuando se crea el emparejamiento BGP Multihop y entró en el artículo sobre los conceptos básicos del enrutamiento estático solo debido a los astutos usuarios de MikroTik que descubrieron cómo usar rutas recursivas combinadas con la puerta de enlace de verificación para cambiar los canales de comunicación sin scripts adicionales.

Es hora de comprender las opciones de alcance/alcance de destino en términos generales y cómo la ruta está vinculada a la interfaz:

1. La ruta busca una interfaz para enviar el paquete en función de su valor de alcance y todas las entradas en la tabla principal con valores de alcance de destino menores o iguales
2. De las interfaces encontradas, se selecciona aquella a través de la cual puede enviar un paquete a la puerta de enlace especificada
3. La interfaz de la entrada conectada encontrada se selecciona para enviar el paquete a la puerta de enlace

En presencia de una ruta recursiva, todo sucede igual, pero en dos etapas:

• 1-3 Se agrega una ruta más a las rutas conectadas, a través de la cual se puede llegar a la puerta de enlace especificada
• 4-6 Encontrar la ruta conectada ruta para la puerta de enlace "intermedia"

Todas las manipulaciones con la búsqueda recursiva ocurren en la RIB, y solo el resultado final se transfiere a la FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

Ejemplo de uso de enrutamiento recursivo para cambiar rutas

Configuración:

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

Puede verificar que los paquetes se enviarán a 10.10.10.1:

Compruebe que la puerta de enlace no sabe nada sobre el enrutamiento recursivo y simplemente envía pings a 8.8.8.8, que (según la tabla principal) es accesible a través de la puerta de enlace 10.10.10.1.

Si hay una pérdida de comunicación entre 10.10.10.1 y 8.8.8.8, la ruta se desconecta, pero los paquetes (incluidos los pings de prueba) a 8.8.8.8 continúan pasando por 10.10.10.1:

Si se pierde el enlace a ether1, se produce una situación desagradable cuando los paquetes anteriores a 8.8.8.8 pasan por el segundo proveedor:

Este es un problema si está utilizando NetWatch para ejecutar scripts cuando 8.8.8.8 no está disponible. Si el enlace se rompe, NetWatch simplemente funcionará a través del canal de comunicación de respaldo y asumirá que todo está bien. Resuelto agregando una ruta de filtro adicional:

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

Hay en habré artículo, donde se considera con más detalle la situación con NetWatch.

Y sí, al usar una reserva de este tipo, la dirección 8.8.8.8 estará conectada a uno de los proveedores, por lo que elegirla como fuente de dns no es una buena idea.

Algunas palabras sobre enrutamiento y reenvío virtuales (VRF)

La tecnología VRF está diseñada para crear varios enrutadores virtuales dentro de uno físico, esta tecnología es ampliamente utilizada por los operadores de telecomunicaciones (generalmente junto con MPLS) para proporcionar servicios L3VPN a clientes con direcciones de subred superpuestas:

Pero VRF en Mikrotik está organizado sobre la base de tablas de enrutamiento y tiene una serie de desventajas, por ejemplo, las direcciones IP locales del enrutador están disponibles en todos los VRF, puede leer más enlace.

Ejemplo de configuración de vrf:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

Desde el dispositivo conectado a ether2, vemos que el ping va a la dirección del enrutador desde otro vrf (y esto es un problema), mientras que el ping no va a Internet:

Para acceder a Internet, debe registrar una ruta adicional que acceda a la tabla principal (en terminología vrf, esto se denomina fuga de ruta):

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

Aquí hay dos formas de filtrar rutas: usando la tabla de enrutamiento: 172.17.0.1@main y usando el nombre de la interfaz: 172.17.0.1%wlan1.

Y establecer marcas para el tráfico de regreso en [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

Subredes con la misma dirección
Organización del acceso a subredes con el mismo direccionamiento en el mismo router utilizando VRF y netmap:

Configuracion basica:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

reglas del cortafuegos:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

Reglas de enrutamiento para el tráfico de retorno:

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

Agregar rutas recibidas a través de dhcp a una tabla de enrutamiento determinada
VRF puede ser interesante si necesita agregar automáticamente una ruta dinámica (por ejemplo, desde un cliente dhcp) a una tabla de enrutamiento específica.

Agregar interfaz a vrf:

/ip route vrf
add interface=ether1 routing-mark=over-isp1

Reglas para enviar tráfico (saliente y tránsito) a través de la tabla sobre-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

Ruta falsa adicional para que funcione el enrutamiento de salida:

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

Esta ruta solo es necesaria para que los paquetes salientes locales puedan pasar por la decisión de enrutamiento (2) antes [OUTPUT|Mangle] y obtenga la etiqueta de enrutamiento, si hay otras rutas activas en el enrutador antes de 0.0.0.0/0 en la tabla principal, no es necesario.

Las cadenas connected-in и dynamic-in в [Routing] -> [Filters]

El filtrado de rutas (entrantes y salientes) es una herramienta que generalmente se usa junto con los protocolos de enrutamiento dinámico (y, por lo tanto, solo está disponible después de instalar el paquete enrutamiento), pero hay dos cadenas interesantes en los filtros entrantes:

• conectado: filtrado de rutas conectadas
• dynamic-in - filtrado de rutas dinámicas recibidas por PPP y DCHP

El filtrado le permite no solo descartar rutas, sino también cambiar una serie de opciones: distancia, marca de ruta, comentario, alcance, alcance objetivo, ...

Esta es una herramienta muy precisa y si puede hacer algo sin los filtros de enrutamiento (pero no los scripts), entonces no use los filtros de enrutamiento, no se confunda a sí mismo ni a los que configurarán el enrutador después de usted. En el contexto del enrutamiento dinámico, los filtros de enrutamiento se utilizarán con mucha más frecuencia y de manera más productiva.

Configuración de la marca de ruta para rutas dinámicas
Un ejemplo de un enrutador doméstico. Tengo dos conexiones VPN configuradas y el tráfico en ellas debe ajustarse de acuerdo con las tablas de enrutamiento. Al mismo tiempo, quiero que las rutas se creen automáticamente cuando se activa la interfaz:

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

No sé por qué, probablemente sea un error, pero si crea un vrf para la interfaz ppp, entonces la ruta a 0.0.0.0/0 aún entrará en la tabla principal. De lo contrario, todo sería aún más fácil.

Deshabilitar rutas conectadas
A veces esto es necesario:

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

Herramientas de depuración

RouterOS proporciona una serie de herramientas para depurar el enrutamiento:

• [Tool]->[Tourch] - le permite ver los paquetes en las interfaces
• /ip route check - le permite ver a qué puerta de enlace se enviará el paquete, no funciona con tablas de enrutamiento
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - hacer ping y rastrear utilizando la tabla de enrutamiento especificada
• action=log в [IP]->[Firewall] - una excelente herramienta que le permite rastrear la ruta de un paquete a lo largo del flujo de paquetes, esta acción está disponible en todas las cadenas y tablas

Fuente: habr.com