Atrás 
Artículo escrito conjuntamente por Jeff Brainard y Jason Hofmann
En más de una conversación con clientes de grandes empresas, hemos escuchado a los directores de redes e infraestructuras responsables de gestionar la WAN global de la organización referirse en broma a sí mismos como el "Chief Hairpinning Officer" o CHO. A priori, parece gracioso. Sin embargo, hay algo de verdad en esta afirmación si se tiene en cuenta que gran parte del tiempo, la energía y el presupuesto de los profesionales de las redes se ha dedicado tradicionalmente a gestionar complejas decisiones de enrutamiento de la red. Estas decisiones eran clave para unir las diferentes sedes y sucursales de la empresa con el centro de datos, al mismo tiempo que tenían que trabajar con múltiples proveedores de servicios de Internet para garantizar un acceso rápido y fiable para sus usuarios y una experiencia de aplicación expeditiva. En los últimos años, el problema ha sido alinear estos objetivos de red con los crecientes requisitos de seguridad a los que se enfrentan las empresas. El problema no ha hecho más que empeorar con la migración de las aplicaciones y los datos a la nube y a servicios SaaS, los ataques cada vez más complejos y la reciente explosión del teletrabajo.
¿Qué es la horquilla?
Hoy en día, la mayoría de las empresas aprovechan una arquitectura que se basa en gran medida en la "horquilla" o lo que también se conoce comúnmente como backhauling de tráfico. En un contexto de redes, la horquilla se refiere a la forma en que un paquete viaja a una interfaz, sale hacia Internet pero en lugar de continuar, hace un "giro de horquilla" (solo piense en el instrumento cotidiano que se usa para mantener el cabello de una persona en su lugar) y regresa a la misma interfaz. El escenario clásico es la sucursal, donde ningún tráfico debe entrar o salir sin antes pasar por un control de seguridad. La implementación de una pila de seguridad independiente en cada sucursal, en docenas o incluso cientos de sucursales en todo el mundo, podría ser una estrategia viable, pero desde el punto de vista del costo, la complejidad y la carga administrativa sería una pesadilla.
En su lugar, la estrategia preferida ha sido hacer que todas las solicitudes de los clientes para acceder a Internet se envíen (o se envíen de vuelta) desde la sucursal a una ubicación central, como el centro de datos, donde se aplica la seguridad, y sólo entonces—después de ser escaneado—el tráfico sale a Internet. Lo mismo ocurre si se hace una solicitud de contenido web o se interactúa con una aplicación SaaS crítica para el negocio. En la respuesta del servidor, el tráfico debe seguir el mismo camino de vuelta a través del centro de datos, a la sucursal y, finalmente, al escritorio del usuario. No hace falta ser un ingeniero de redes para darse cuenta de que este enfoque va a afectar a la experiencia del usuario, añadiendo latencia y ralentizando las cosas de forma significativa. Dejando a un lado la experiencia del usuario y, en última instancia, la productividad de la empresa, este enfoque también supone una mayor carga para los enlaces WAN privados, caros y difíciles de mantener, como las conexiones MPLS, en los que las empresas han confiado durante mucho tiempo para unir su empresa distribuida.
La evolución de la horquilla a WAN/SD-WAN
Con el indiscutible desplazamiento de aplicaciones y datos a la nube, y el creciente volumen y criticidad de este tráfico, uno de los grandes atractivos del modelo de seguridad en la nube es eliminar las horquillas y simplificar drásticamente el diseño de la red. También es uno de los impulsores clave del floreciente mercado de SD-WAN y el impulso para proyectos de transformación de redes a gran escala. Esto se cubrió en otro blog reciente titulado "Cómo Netskope NewEdge lleva SD-WAN al siguiente nivel". La conclusión que se puede sacar es que los profesionales de las redes preferirían evitar el hairpinning y el futuro consistirá cada vez más en enviar su tráfico directamente a la red con un enfoque de seguridad que dé prioridad a la nube. Entonces, ¿por qué un cliente seleccionaría una solución de seguridad en la nube que se basa en una arquitectura de red cerrada?
Por desgracia, una de las cosas que hemos visto repetidamente en el mercado, y que es habitual en casi todos los proveedores de seguridad en la nube, es que han diseñado mal sus nubes. Básicamente, lo que se encuentra es que están repitiendo los errores inherentes al diseño de la WAN empresarial tradicional y replicándolos dentro de un factor de forma en la nube. El ejemplo clásico de esto es el punto de presencia virtual (o vPOP), un enfoque públicamente conocido por ser utilizado por proveedores como Broadcom/Symantec, Palo Alto, Forcepoint, McAfee y otros. (Si no se fía de mí, sólo tiene que consultar sus sitios web y buscar frases como "Ubicación física del procesamiento de la seguridad" o el término "vPOP".) Los vPOP no sólo proporcionan una visión engañosa de la cobertura, sino que también engañan sobre dónde se produce el procesamiento del tráfico dentro de la red del proveedor de seguridad en la nube.
En el nivel más simple, los vPOPs proporcionan un punto de entrada y salida para el tráfico. Un ejemplo comentado en un blog anterior titulado "Para entender la cobertura, no basta con contar los centros de datos" mostraba un escenario con un usuario remoto en Chile. Este usuario tendría que conectarse a un vPOP en Santiago, hacer que su tráfico se enviara a Miami (Florida, EE.UU.) para su procesamiento y, a continuación, volver a Santiago antes de que la solicitud del usuario se dirigiera a Internet y a la web, la nube o la aplicación SaaS a la que intentaba acceder. Imagínese la latencia que se produce con este tráfico de ida y vuelta, enrutado a través de enormes distancias, sobre múltiples redes, que en última instancia ralentiza significativamente la experiencia del usuario. El problema es que los vPOPs son literalmente una red de tráfico de retorno, con las mismas implicaciones en cuanto a complejidad, latencia y, potencialmente, coste.
Y cuando los proveedores dependen de la infraestructura de nube pública, como AWS, Azure o GCP, dependen de los centros de datos del proveedor de la nube pública para proporcionar puntos de salida regionales para el tráfico (Palo Alto). O, lo que es peor, y mucho más común, hacen retorno del tráfico a través de la congestionada e impredecible Internet pública y utilizan una "centralita telefónica" de IPs de salida, cada una registrada en un país diferente, para implementar sus vPOPs (como hacen el resto). El mismo problema se manifiesta de nuevo, con el tráfico teniendo que ser conducido a través de enormes distancias, con retornos y bucles de tráfico entre múltiples ubicaciones, antes de llegar finalmente a las pocas -a menudo menos de 30- ubicaciones únicas en el mundo donde se encuentran los recursos de computación y puede tener lugar el procesamiento del tráfico de seguridad. Los clientes creen que est