Azure Firewall: Internet Centralizado por Hub, Emparejamiento y Conexión vía VPN con On-Premises

En artículos anteriores os he hablado de las redes virtuales de Azure y configuraciones iniciales de Azure Firewall, los cuales os muestro a continuación:

• Azure Firewall: Centralizar la salida a Internet de las vNet
• Azure Firewall: Instalación y Configuración
• Redes Azure: Emparejamiento de redes virtuales globales
• Redes Azure: Emparejamiento de redes virtuales ubicadas en diferentes suscripciones

Pues hoy quería mostraros una topología con un poco de cada uno de los artículos anteriores, algo que cubra escenarios reales y que creo que os serán de ayuda (o eso espero), aquí la topología la cual configuraremos en este artículo:

Objetivos:

• Emparejamiento: tendremos dos topologías de Hub-Spoke en cada continente
• On-Premises: todas las vNets de Spoke deben tener acceso a la red On-Premises vía VPN ubicada en la red de Europa
• Internet:  cada vNet de Spoke se conectará a Internet mediante el Firewall “local”, evitando así latencias innecesarias

Configuraciones:

• Configurar emparejamiento de todas las vNets con el Hub ubicado en la región del Norte de Europa donde tenemos la conexión VPN
• Crear tablas de rutas:
  • Vpn Gateway: permite llegar a todas las vNets atravesando el Firewall local
  • vNets: definir el mínimo número de rutas pero que permitan:
    • Conectar a Internet saliendo por su firewall “local”
    • Conectar con los servicios de On-Premises
• Reglas de Firewall que nos permitan tener conexión entre vNets, Internet y con los servicios de On-Premises.

Pues vamos a ello, en artículos anteriores había comentado como realizar los emparejamientos, por lo que aquí únicamente voy a mostraros como han quedado los emparejamientos.

Como queremos que todas las vNets puedan conectarse a los servicios de On-Premises por el Gateway de la vNet Hub de la región del Norte de Europa, esta sería la configuración:

Con esta configuración ya tenemos conexión con el Hub del Norte de Europa y donde tenemos el Firewall que podrá configurarse para tener conexión o no entre ellas, pero ya tenemos la conexión habilitada.

Ahora tenemos que configurar las rutas que vamos a necesita para completar varios objetivos:

• Conectar las vNets de Spoke con los servicios de On-Premises vía Gateway VPN
• Que cada  topología de red (Hub-Spoke) se conecten a Internet vía su firewall “local”, evitando así que tengamos problemas de latencias

Pues aquí os voy a mostrar la configuración de las vNets que tenemos en USA:

• On-Premises y vNets de Europa: las conexiones las enviaremos mediante la IP del Firewall del Norte de Europa, el cual sabe como conectarnos  con los servicios de On-Premises
• Internet: se definirá una ruta a destinos no conocidos 0.0.0.0/0 (Internet por ejemplo) para que todo el tráfico que no tenga ruta específica pues la enviaremos al firewal “local” (ubicado en el Hub de USA)

Aquí vemos como quedarían configuradas ambas vNet de USA:

En las vNets de Europa será más “sencillo”, puesto que sólo necesitamos  definir una ruta por defecto 0.0.0.0/0 hacia el firewall “local”, puesto que así nos conectarnos a Internet de forma directa y además, el firewall nos llevará a los servicios On-Premises (porque son servicios conectados en la misma vNet de Hub en Europa donde está también el Gateway VPN)

Por último, como todo el tráfico ahora pasa por el Firewall debemos establecer una serie de rutas para el Gateway VPN para que tenga información de como se tiene que conectar a las vNets de Spoke pero sin dirigir el tráfico 0.0.0.0/0 por el Firewall (esto sería viable, pero podríamos tener problemas con las conexiones VPN)

Por último, debemos permitir en el Firewall de la región del Norte de Europa por donde pasarán todas las conexiones de las vNets hacia On-Premises, debemos definir las reglas necesarias para permitir los accesos necesarios. En mi caso, voy a permitir todo el tráfico entre vNets y On-Premises, sin permitir el tráfico entre vNets:

Si ahora desde un  equipo de On-Premises lanzamos un ping a dos servidores en vNets de regiones diferentes, ya tenemos respuesta y cada uno con sus latencias correspondientes:

Por último, vamos a comprobar si los equipos salen a Internet por su firewall correspondiente y es así, la IP Pública que os muestro es la IP del Firewall:

• vNet Centro-Norte de EE. UU:

• vNet Norte de Europa

He hecho otra prueba para comprobar la latencia entre vNets de diferentes regiones, por lo que he habilitado de forma momentánea la conexión entre subredes de diferentes vNets y la latencia es la siguiente (desde Norte de Europa hasta Centro-Norte de EE):

Como vemos es cuestión de ajustar los emparejamientos, rutas y reglas de Firewall. De esta forma conseguimos:

• Tráfico interno hasta On-Premises, utilizando los mínimos recursos necesarios (Gateway VPN) y utilizando una comunicación segura (Emparejamiento + VPN)
• Salida a Internet centralizado: evitamos que equipos de distintas regiones tengan que venir a conectarse a Internet vía un Firewall desde Hub central, de esta forma minimizamos las latencias.

En la topología he puesto unos círculos con las latencias entre vNets, espero que se pueda entender de forma sencilla. Realmente, los círculos con el mismo color/número son los que tienen interconexión entre ellos con una latencia determinada. No es lo mismo, conexiones entre subredes de la misma vNet y región que entre subredes de vNets de diferentes regiones o con los servicios On-Premises desde distintas ubicaciones.

Espero que me haya podido explicar de forma breve y clara, sino ha sido asi, por favor, dejar un comentario en el blog y os responderé encantado.

Ahora, como siempre, os toca probarlo a vosotros!!