miércoles, 17 de octubre de 2018

Cloud NAT [Nuevo servicio en Google Cloud]

cloud_NAT.png 


En Google Cloud español nos hacemos eco de que  hace unos días, se anuncio la versión beta del servicio servicio Cloud NAT totalmente gestionado.
 

Los usos del "Cloud NAT"


Cuando coloca una aplicación detrás de una puerta de enlace NAT en el Cloud, puede acceder a Internet (para actualizaciones, parches, administración de configuración y más) de una manera controlada y eficiente, pero los recursos externos no pueden acceder directamente a esas instancias. Esto ayuda a mantener sus VPC de Google Cloud más aisladas y seguras.
Cloud NAT ofrece una serie de ventajas en comparación con otras ofertas de NAT:
  • Como una solución definida por software sin un proxy central administrado, Cloud NAT ofrece un diseño  que es altamente confiable, de alto rendimiento y escalable.
  • Cloud NAT es compatible con las máquinas virtuales (VM) de Google Compute Engine y con el motor de Google Kubernetes (contenedores).
  • La capacidad de configurar múltiples direcciones IP de NAT por puerta de enlace NAT le permite escalar según el tamaño de su red sin tener que agregar o administrar otra puerta de enlace NAT.
  • Los modos Manual y Automático para la asignación de IP NAT le permiten ajustar según sus requisitos específicos.En modo manual proporciona un control total al especificar IP, y en modo Automático permite que las IP de NAT se asignen y escalen automáticamente según el número de instancias.
  • Ajuste los valores de timeout del NAT.
  • NAT todas las subredes en una VPC para una región a través de una única puerta de enlace NAT, independientemente del número de instancias en esas subredes.
  • Alta disponibilidad regional incluso si una zona no está disponible.

Los primeros usuarios de Cloud NAT están implementando y presenta un correco funcionamiento dentro de sus implementaciones existentes de Google Cloud.


NAT  chokepoint, definido por software

Chokepoint-free.png

 
Cloud NAT es un servicio totalmente administrado, definido por software, no una solución basada en instancias o dispositivos. Esto difiere de las soluciones de proxy NAT tradicionales porque no hay proxies intermedios NAT en la ruta desde la instancia hasta el destino. En su lugar, a cada instancia se le asigna una IP NAT junto con una asignacion del rango de puerto asociado. Esta IP asignada y el rango de puertos está programado por nuestra pila de virtualización de red de Andrómeda en la instancia y luego la instancia lo utiliza para realizar NAT.

La implementación de Cloud NAT, es similar a nuestros cortafuegos, se distribuye sin ningún punto de estrangulamiento en la ruta entre su instancia interna y su destino externo. Este enfoque ofrece una mayor escalabilidad, rendimiento, rendimiento y disponibilidad para Cloud NAT.

Modos de asignación de IP NAT


Cuando se diseño el modelo de asignación de IP de Cloud NAT, por peticion de los clientes que apuntaban a  la capacidad de configurar las IP de NAT estáticas y especificadas manualmente es esencial para que puedan abrir firewalls para estas IP de NAT en los servidores externos. Tambien se puede  escalar automáticamente las IP de la nube como lo hacen nuestros balanceadores de carga.

Por eso se puede ofrecer dos opciones para la asignación de IP NAT:
  •     Podemos usar la asignación automática de direcciones IP mediante una puerta de enlace NAT: GCP asigna automáticamente las direcciones IP de NAT y las ajusta automáticamente en función del número de máquinas virtuales. Esta es la mejor manera de garantizar que haya suficientes IP disponibles para NAT. Tenga en cuenta que con este método, las IP de la lista blanca en el lado receptor se ajustan peor  porque algunas IP se liberan cuando ya no son necesarias.
  •     Configure una (s) IP (s) NAT específica (s) para ser utilizadas por una puerta de enlace NAT: En este caso, debe especificar manualmente una o más IP de NAT para que la puerta de enlace NAT las utilice. Estas direcciones IP deben ser reservadas y estáticas, y no se realiza una autoasignación de direcciones IP. Se prefiere este modo si necesita incluir en la lista blanca las direcciones IP de NAT en el lado receptor. Tenga en cuenta que si no hay suficientes IP NAT para realizar NAT para todas las instancias requeridas, entonces algunas de estas instancias no podrán usar NAT. Recibirá un mensaje de registro cuando se requieran más direcciones IP de NAT.

Creando una puerta de enlace NAT en su VPC


Para configurar una puerta de enlace NAT en su entorno. Echemos un vistazo a un ejemplo.

Digamos que tiene una red GCP que contiene tres subredes en dos regiones:
    us-este1
        subred 1 (10.240.0.0/16) y subred 2 (172.16.0.0/16)
          europa-oeste
                subred 3 (192.168.1.0/24)

Las máquinas virtuales en la subred 1 (10.240.0.0/16) y la subred 3 (192.168.1.0/24) no tienen direcciones IP externas, pero necesitan obtener actualizaciones periódicas de un servidor externo al 203.0.113.1. Las máquinas virtuales en la subred 2 (172.16.0.0/16) no necesitan obtener estas actualizaciones y no se les debe permitir conectarse a Internet en absoluto, incluso con NAT.

VMs in subnet.png
 
Para lograr esta configuración, primero configure una puerta de enlace NAT por región, por red:

   1. Configure NAT-GW-US-EAST para la subred 1 (10.240.0.0/16).

   2. Configure NAT-GW-EU para la subred 3 (192.168.1.0/24).

   3. Configure cada puerta de enlace NAT con la (s) subred (s) para la cual debe traducir el tráfico:

        subred 1 (10.240.0.0/16) para NAT-GW-US-EAST

        subred 3 (192.168.1.0/24) para NAT-GW-EU

   4. No configure NAT para la subred 2. Esto lo aísla de Internet, como lo requiere este ejemplo.

Para obtener información detallada sobre cómo configurar Cloud NAT, puede ver las configuraciones de Cloud NAT para Google Compute Engine y Google Kubernetes Engine aquí.

Cloud NAT para GKE

Puede usar Cloud NAT para los contenedores de Kubernetes de Google (GKE) configurando Cloud NAT a NAT-traducir todos los rangos en la subred.


GKE.png

Tanto los nodos como los pods pueden usar Cloud NAT. Si no desea que los Pods puedan usar NAT, puede crear una Política de red de clústeres para evitarlo.

En el ejemplo anterior, se permite que sus contenedores se traduzcan a NAT. Para habilitar NAT para todos los contenedores y el nodo GKE, debe elegir todos los rangos de IP de la subred 1 como candidatos de NAT. No es posible utilizar NAT solo para container1 o container2.

Precios y disponibilidad

Cloud NAT está disponible en todas las regiones de Google Cloud, y durante el período beta, lo ofrecemos de forma gratuita. Una vez que Cloud NAT está disponible en general (GA), cada puerta de enlace tiene el precio siguiente:
  •     A partir de $ 0.045 por hora de puerta de enlace NAT
  •     Cargos de procesamiento de datos NAT

Además, los costos de transferencia de salida para mover datos entre una instancia de GCP e Internet permanecen sin cambios. Para obtener más información, lea acerca de los precios de NAT de la nube aquí.

Prueba Cloud NAT

Hemos estado ocupados ofreciendo capacidades como Cloud NAT para hacer que sus cargas de trabajo y servicios de Google Cloud sean fáciles de implementar y administrar. Lea  la documentación en línea de Cloud NAT y comience con una implementación de muestra utilizando nuestro ejemplo de Cloud NAT. También nos encantaría recibir sus comentarios, puede contactar en gcp-networking@google.com.

No hay comentarios:

Publicar un comentario

Nota: solo los miembros de este blog pueden publicar comentarios.