El enrutamiento asimétrico es una condición normal pero no deseada en una red IP. El Enrutamiento asimétrico es una situación en la cual, por alguna razón, los paquetes que estan fluyendo (por ejemplo en una conexión TCP) eligen diferentes rutas para ambas direcciones del flujo.
Por ejemplo, un host A y un host B están ubicados en diferentes continentes y están intercambiando datos a través de una conexión TCP. Los segmentos enviados del host A hacia el B usan el enlace de un ISP1, los segmentos que responde el host B hacia el A usan el enlace de un ISP2 diferente del primero.
El Enrutamiento asimétrico no debería ser un problema para las implementaciones TCP/IP modernas, ya que las conexiones TCP no toman en cuenta cual es la ruta que sigue un paquete IP, mientras este alcance el destino dentro de un tiempo razonable.
El Enrutamiento asimétrico puede ocurrir también en una pequeña escala. Puede ocurrir en una empresa que usa dos diferentes rutas, como un enlace VPN y un enlace dedicado, hacia una de sus sucursales.
En un contexto de tecnología de Cluster completo, se habla de Enrutamiento asimétrico cuando se da una situación donde los segmentos de una conexión ingresan a la red por un nodo y salen de la red por otro nodo diferente.
El Enrutamiento asimétrico no es un problema en si mismo, pero puede causar problemas cuando se usa Traducción de Direcciones de Red (NAT) o Firewalls en la ruta.
Por ejemplo, en los Firewalls, cierta información sobre el estado de una comunicación es almacenada cuando los paquetes fluyen de un área de alta seguridad a un área de menor seguridad. El Firewall siempre va a ser el punto de salida de un área de seguridad hacia otro.
Si el flujo de datos de una comunicación regresa a través de otro firewall entonces el paso de ese paquete va a ser denegado porque viene de un área de seguridad baja hacia uno de seguridad alta, entonces en esta situación no va a generarse ninguna información de estado en el segundo Firewall. La información de estado existe en el primer firewall. (Vea la primera imagen de este post para una referencia de este tipo de situación).
En otra situación de ejemplo, en el siguiente diagrama observe que el tráfico que se genera desde la PC usuario hacia el servidor Finance o el servidor WWW puede fluir de manera asimétrica en varios puntos a lo largo de la red.
Entre la PC y el servidor Finance, los Switches S1 y S3 representan el principal lugar donde esta situación puede ocurrir.
Entre la PC y el servidor WWW, el tráfico podría tomar una ruta asimétrica en S1 y S2 o en la Internet cuando el trafico regresa a través del ISP A o del ISP B. La mayoría de los diseñadores no tienen ningún problema con el tráfico asimétrico porque las redes IP son asimétricas por naturaleza. En cada punto de la transmisión un Router IP tomará la decisión de reenvío basándose en su propio punto de vista de la red: Su propia tabla de enrutamiento.
En este escenario es que el Enrutamiento asimétrico puede comenzar a causar problemas. Cosidere nuevamente que la PC se está comunicando con el servidor WWW. Un paquete puede fluir a través del S4 - S1 - FW1 - Inet_RTR_1 - ISP A en de ahí al servidor WWW.
En este camino el FW1 aprende que la PC está tratando de comunicarse con el servidor WWW, entonces añade una entrada en su tabla de estados para habilitar el tráfico de retorno cuando este fluya desde el servidor WWW hacia la PC. Entonces imaginemos que el tráfico de retorno desde el servidor WWW hacia la PC se enruta desde ISP B, Inet_RTR_2, FW2, S2, S4 y la PC. En este caso el paquete nunca llega a la PC porque el FW2 no tiene ninguna información de estado para esa comunicación.
Desde el punto de vista del servidor WWW, este está iniciando nuevas comunicaciones hacia la PC las cuales son bloqueadas en base a la política de seguridad configurada.
Este problema puede complicarse si estamos usando Sistemas de Detección de Intrusiones (IDS) en nuestra red o cerca de los Firewalls. Si el trafico fluye de manera asimétrica un IDS no va a poder ver la comunicación completa. En consecuencia se puede generar alarmas acerca de un tráfico que es benigno (falso positivo) o podría no detectarse un ataque completo (falso negativo).
Lamentablemente no hay una solución sencilla para este problema. En la siguiente sección se incluye una lista de posibles soluciones para un problema de tráfico asimétrico observado en una red:
- Enrutar el tráfico simétricamente
- Balanceo de carga "por flujo" (en lugar de "por paquete")
- Use dispositivos de seguridad que comparten el estado
- Considere la redundancia a nivel de Capa 2 (L2)
- Manipulación de flujos usando enrutamiento o NAT
- Use funciones de seguridad sin estado
Enrutar el tráfico simétricamente
Esta solución parece ser sencilla, pero en diseño de redes reales puede representar un desafío significante. Incluso usted podría sorprenderse al ver cuantas redes grandes usan el enrutamiento simétrico para garantizar el funcionamiento de dispositivos de seguridad con estado o para resolver otros problemas de Networking.Esta solución es particularmente común en bordes de Internet, donde es frecuente ver que la totalidad de la carga es manejada a través de un solo ISP mientras que la conexión secundaria queda como reserva.
A continuación se muestra otro ejemplo de enrutamiento asimétrico:
Balanceo de carga "por flujo" (en lugar de "por paquete")
La mayoría de los dispositivos de Capa 3 (L3) pueden ser configurados para hacer una de dos cosas cuando existen dos rutas de igual costo para una determinada red de destino. La primera opción es que los paquetes son balanceados, por los enlaces de mismo costo, en un formato simple de "uno por cada enlace a la vez" (Round-robin) donde cada paquete sucesivo va hacia el siguiente router disponible en la secuencia. Esta opción es la que mas problemas causa en sistemas de seguridad internos como los IDS.La segunda opción, la mejor en este caso, es la de balancear el tráfico por un flujo determinado. Esto significa que el tráfico detectado, desde un cierto origen y hacia un cierto destino, es siempre enviado a través de un router específico. Esto permite a los sistemas IDS y otros dispositivos que inspeccionan estados, ver al menos la mitad de la comunicación de una manera consistente. Desafortunadamente no es posible determinar cual es el camino que toma (o que va a tomar) el tráfico de retorno el cual todavía podría tomar un camino diferente.
Use dispositivos de seguridad que comparten el estado
A medida que el problema del trafico asimétrico se ha manifestado en las redes, los fabricantes de equipos de seguridad han comenzando a ofrecer soluciones que permiten que varios dispositivos de seguridad compartan la información de estado.
Los Firewall ASA1 y ASA2 pueden intercambiar la información de sus tablas de estados para garantizar que si el otro dispositivo ve parte de un flujo entonces este va a conocer cual es el tráfico de retorno que debe permitir. Frecuentemente la cantidad de información intercambiada por estos dispositivos es grande y requiere que se configure un link dedicado entre los Firewalls.
Considere la redundancia a nivel de Capa 2 (L2)
Con la introducción de redundancia a nivel L2 como alternativa a la redundancia en L3, tecnologías como Virtual Router Redundancy Protocol (VRRP) o Hot Standby Router Protocol (HSRP) pueden permitir que el tráfico fluya a través de un solo punto garantizando la redundancia. Esta opción es la que mejor funciona en conexiones de alta velocidad donde el uso de un solo enlace, en lugar de dos o mas, no afecta la performance de la red.
El resultado es que el tráfico normalmente asimétrico puede ser simétrico por distancias cortas de la red, como por ejemplo el trafico que pasa a través de un Firewall.
Si los Firewalls FW1 y FW2 están conectados a la misma red L2 entonces se puede usar VRRP para que puedan verse como un solo dispositivo desde el punto de vista de los routers que están al rededor. Esto significa que el tráfico puede fluir de manera asimétrica en la Internet y en la red interna, pero fluye de manera simétrica cuando atraviesa el Firewall. Esto a veces no es una solución posible cuando los dos dispositivos Firewall no se encuentran cerca (o en la misma red).
Manipulación de flujos usando enrutamiento o NAT
El tema de la preferencia de rutas BGP es demasiado amplio como para poder incluirlo en este post. Sin embargo vale la pena mencionar que se pueden hacer algunas cosas con protocolos de enrutamiento para poder determinar cual es el camino que los paquetes deben seguir. De alguna manera es posible influenciar que camino deberían tomar las redes externas cuando desean comunicarse con nuestra red.Otras posibles soluciones implican el uso de diferentes POOLs NAT basados en cual es el dispositivo de seguridad que atraviesa un paquete. Entonces los paquetes que retornan hacia nuestra red pueden ser "forzados" a elegir un dispositivo de seguridad en particular gracias a que tiene un POOL NAT específico asociado a ese dispositivo.
Use funciones de seguridad sin estado
Los Firewalls son dispositivos de seguridad ampliamente utilizados hace muchos años. Sin embargo algunas compañías aún utilizan ACLs básicas en lugar de un dispositivo Firewall para poder lidiar, entre otras cosas, con el tema del Enrutamiento asimétrico.Hacer esto evidentemente sacrifica ciertas funcionalidades de seguridad. Los ACLs básicos no hacen un seguimiento a la información de estado, pero si el tráfico de la red es relativamente sencillo de categorizar entonces es posible lograr un nivel aceptable de seguridad sin necesidad de tráfico simétrico. Recuerde que el tema de la seguridad es un tema integral que debe considerar todos los aspectos en la red.
Con los sistemas IDS, las firmas que no trabajan bien con entornos de enrutamiento asimétrico podrían ser apagadas para prevenir que generen alarmas de tipo "falso positivo". Pero esto va a reducir la seguridad que estos sistemas proporcionan, sin embargo permiten que las demás firmas si generen alarmas oportunamente.
--------------
Post tomado de: http://www.networksbaseline.in/2016/01/the-concept-of-asymmetric-routing.html con aportes del editor del Blog.
Traducido por José Torrico Gumucio, Cisco Networking Academy Instructor.
No hay comentarios:
Publicar un comentario