Copy for LLM ▼

Copy Page Content Open in ChatGPT Open in Claude Open in VS Code View Markdown

PDF

Cómo MCR realiza NAT

Traducción de direcciones de red (NAT)La traducción de direcciones de red (NAT) es el proceso que traduce las direcciones IP privadas no registradas utilizadas en la red interna privada de una organización en una única dirección IP pública registrada antes de que los paquetes se envíen a una red externa. NAT permite que las redes IP privadas utilicen internet y la nube.
conserva el espacio de direcciones IPv4 al traducir las direcciones IP privadas no registradas usadas en la red interna privada de una organización a una única dirección IP pública registrada. Esta única dirección IP pública se utiliza luego para conectarse a redes externas, como internet.

Este tema describe cómo NAT en el MCR está diseñado específicamente para admitir tipos de Peering público con Proveedores de servicios en la nube.

NAT de muchos a uno usando distintos puertos

MCR admite NAT con sobrecarga, también conocido como Source Overload NAT o NAT Overload, que es una forma de NAT de muchos a uno. Funciona de la siguiente manera:

• NAT de origen (SNAT) – Traduce múltiples direcciones IP privadas a una única dirección IP pública.
• Traducción de direcciones de puerto (PAT) – Asigna puertos de origen únicos para garantizar que cada conexión siga siendo distinta.

Esta configuración admite tráfico de egreso (conectividad saliente) hacia los socios de Megaport Marketplace y otras redes externas, como internet o servicios en la nube.

El MCR normalmente realiza NAT en la frontera donde se conectan dos redes. Por ejemplo, antes de reenviar paquetes desde la red interna a la red externa, el MCR traduce las direcciones IP privadas no únicas a una única dirección IP pública globalmente única. Esta traducción de muchos a uno permite que el MCR anuncie solo una dirección IP hacia el exterior mientras oculta múltiples direcciones IP de origen privadas detrás de la dirección IP de la interfaz del MCR.

Aunque un caso de uso típico implica traducir direcciones IP privadas en la red interna a una dirección IP pública en la red externa, esto no es un requisito estricto. El MCR puede traducir cualquier dirección IP—privada o pública—en cualquiera de las interfaces según sea necesario.

Nota

NAT en el MCR es similar al NAT overload de Cisco o a la funcionalidad Hide NAT de Checkpoint.

MCR realiza el seguimiento de cada traducción de direcciones IP y asignación de puertos en una tabla de NAT que puede manejar miles de traducciones concurrentes. Cuando un puerto ya no está en uso, MCR lo libera y lo devuelve al pool de puertos disponibles.

Esta imagen muestra un MCR en el borde del centro de datos, conectándose de forma privada a la Plataforma como servicio de Azure (PaaSLos proveedores de Plataforma como Servicio (PaaS) ofrecen un entorno de desarrollo a los desarrolladores de aplicaciones. El proveedor por lo general desarrolla un conjunto de herramientas y estándares para el desarrollo y canales de distribución y de pago. En los modelos PaaS, los proveedores cloud proporcionan una plataforma de computación, que normalmente incluye sistema operativo, entorno de ejecución del lenguaje de programación, base de datos y servidor web, sin necesidad de gestionar el sistema operativo subyacente ni la arquitectura del host.
) con un Virtual Cross Connect (VXC) hacia el Peering público de Azure, conocido como Microsoft Peering. Debido a que Microsoft solo aceptará direcciones IPv4 públicas a través de Microsoft Peering, el MCR traduce las direcciones IP privadas a direcciones públicas mediante NAT. El MCR aporta el beneficio adicional de usar el número de sistema autónomo (ASN) de Megaport y espacio de direcciones IP registradas públicamente para esta conexión.

Ejemplo de NAT de MCR

En este ejemplo, MCR se sitúa lógicamente entre el centro de datos de un cliente (10.100.0.0/16) y Azure (West US 13.100.0.0/16). Los paquetes destinados a 13.100.0.0/16 se envían desde el centro de datos al MCR.

1. El centro de datos envía un paquete con una IP de origen de 10.100.20.10 y una IP de destino de 13.100.12.136 hacia el MCR.
   

2. MCR recibe el paquete en su interfaz interna. En el egreso, MCR realiza un SNAT para traducir la dirección IP de origen (10.100.20.10) a la dirección IP local de su interfaz externa (117.18.84.113). Para crear una sesión única, MCR también realiza un PAT y asigna a la sesión un puerto de origen TCP o UDP único. La IP de destino y el puerto permanecen intactos.
   

3. Cuando Azure recibe el paquete, este tiene una IP de origen de 117.18.84.113. Azure reenvía el paquete al destino 13.100.12.136 y responde al origen en 117.18.84.113.

4. Supongamos que Azure recibe otro paquete de MCR con una IP de origen de 10.100.5.16 y una IP de destino de 13.100.14.27. MCR realiza un SNAT a la misma dirección IP de 117.18.84.113. La única diferencia es el puerto de origen TCP/UDP que ha sido asignado automáticamente por MCR.

Verificación de la asignación de NAT

MCR configura automáticamente los ID de VLAN usados para Peering privado y público después de que configuras el tipo de Peering. Al aprovisionar VXCs desde el MCR a un proveedor de servicios, MCR configura el Peering privado con VLAN 100 y el Peering público con VLAN 200, de forma predeterminada.

Esta imagen muestra MCR con un VXC conectándose a Azure. Durante la configuración inicial del VXC, se seleccionaron ambos tipos de Peering de Microsoft: Privado y Público. Para esta configuración, MCR configuró automáticamente VLAN 100 para admitir el Peering privado y VLAN 200 para admitir el Peering público de Microsoft.

El campo Network Address Translation (NAT) (Traducción de direcciones de red (NAT)) aparece a la derecha del campo Direcciones IP de la interfaz. La dirección IP de origen de NAT es la dirección IP de la interfaz externa del MCR, a la que se traducirá cualquier paquete.

Nota

Cuando varios VXC de Azure en un MCR utilizan la misma etiqueta VLAN 100 (Peering privado) y la misma etiqueta VLAN 200 (Peering público), MCR gestiona el túnel 802.1Q, también conocido como túnel Q-in-Q, para cada VXC de Azure que termina en el MCR. Cada VLAN de Azure seguirá siendo una interfaz lógica independiente. Para obtener más información, consulta Configuración de Q-in-Q.