Virtual Network NAT

Paco Sepulveda
Computación en la nube
Cuando desplegamos infraestructuras en Azure nos podemos encontrar con escenarios en los que nuestras máquinas virtuales

Virtual Network NAT

Cuando desplegamos infraestructuras en Azure nos podemos encontrar con escenarios en los que nuestras máquinas virtuales IaaS no necesitan disponer de una IP pública, ya que no tenemos que acceder a ellas desde el exterior, pero estas máquinas necesitan acceso a Internet para tareas como la descarga e instalación de actualizaciones.

Que nuestras máquinas no tengan dirección IP pública incrementa su seguridad, ya que no estarán expuestas en Internet a posibles ataques de password guessing, DoS, …

Desde principios de este mes de marzo tenemos una herramienta que nos facilita el despliegue de este tipo de escenarios: Virtual Network NAT.

https://docs.microsoft.com/en-us/azure/virtual-network/nat-overview

A día de hoy, está en preview en unas pocas regiones:

  • Europe West
  • Japan East
  • US East 2
  • US West
  • US West 2
  • US West Centra

Y vamos a ver de qué forma podemos utilizar esta nueva herramienta en nuestras redes.

El primer paso para utilizar Virtual Network NAT es registrarnos para la preview. Cuando esté en disponibilidad general, esto ya no será necesario. Podemos registraros desde Azure CLI o desde PowerShell. Si elegimos PowerShell, hacemos lo siguiente:

Con el primer comando registramos nuestra suscripción en la preview pública y con el segundo comando activamos el registro.

Para hacer uso de Virtual Network NAT, crearemos en una red virtual uno o varios NAT Gateways. Cada subred de una Virtual Network puede estar asociada a un NAT Gateway diferente o al mismo.

Cuando en una subred definimos el NAT Gateway que va a usar, todo el tráfico TCP y UDP de las máquinas que están en esa subred usarán el NAT Gateway para salir al exterior.

Vamos a partir de una red virtual que ya tenemos creada con dos subnets:

Y tenemos una máquina virtual en cada subred:

Como vemos, ninguna de las dos máquinas virtuales tiene IP pública.

Vamos a configurar el NAT Gateway en la red:

Le damos un nombre y seleccionamos una región:

Le damos una IP pública a este NAT Gateway. Podría tener hasta 16 direcciones o un prefijo de direcciones IP públicas. Creamos una única IP pública:

Y seleccionamos la red y las subredes a las que asociamos el NAT Gateway:

Una vez que termina la creación del NAT Gateway, podemos comprobar en las subnets que están asociadas:

El problema que nos encontramos para comprobar que está correctamente configurado es que no podemos acceder a las máquinas porque no tienen IP pública, por lo que usaremos un bastión para acceder vía SSH a ellas y comprobar que tienen acceso a Internet a través del NAT Gateway. Ya hemos visto en otro post cómo se configura un bastión:

https://www.spainclouds.com/blog/azure-bastion-host

Si, por ejemplo, vamos a la máquina VM1, que no tiene IP pública y entramos en ella vía SSH a través del bastión:

Accedemos a la shell:

Y tratamos de conectar con Internet, por ejemplo, para lanzar un “apt update”:

Vemos que se conecta sin problemas.

Hay que tener en cuenta que el NAT Gateway envía cualquier paquete TCP y UDP al exterior, pero no ICMP, así que si tratamos de hacer un ping, no funcionará.


Paco Sepulveda

En febrero hará 19 años que trabajo como consultor y formador freelance.

Actualmente soy responsable de redes y seguridad en una empresa que ofrece servicios de telemedicina para los hospitales de la Comunidad de Madrid y para el Ejército y la Armada. Para esta empresa he implementado toda la infraestructura cloud.

Trabajo por las mañanas impartiendoel MCSE de Azure en Tajamar y también imparto ocasionalmente formación a medida para empresas en arquitectura de sistemas, redes y seguridad.

Tengo las siguientes certificaciones:

– LPIC-1 y LPIC-2

– ITIL v3 Foundation

– Cisco CCAI, CCNA, CCNP e IINS

– Microsoft: MCT, MCSE Cloud Platform and Infrastructure, MCSA Windows Server 2012 y 2016, MCSE Private Cloud.

La primera certificación de Microsoft la obtuve en 2009 con el MCSE Windows Server 2003 y después el MCITP Windows Server 2008.

Related Posts

Únete a nuestra Newsletter

Lidera la Conversación en la Nube