Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describe el planeamiento de direcciones IP públicas y privadas para las implementaciones de Azure. Aprenderá cómo asignar espacio de direcciones, evitar intervalos superpuestos, elegir el tipo adecuado de dirección IP pública y evaluar la compatibilidad con doble pila IPv6.
Lo que trata este artículo
Este artículo aborda las estrategias de asignación de direcciones privadas, los tipos y SKU de direcciones IP públicas, la planificación de CIDR para evitar rangos superpuestos, las consideraciones sobre configuraciones de doble pila con IPv6 y el Administrador de direcciones IP (IPAM) para entornos a gran escala.
Quién necesita este artículo
Lea este artículo si:
- Implementa una red virtual (VNet) en Azure y necesita decidir qué intervalos de direcciones IP se van a usar.
- Conectan redes de Azure a entornos locales y necesitan evitar conflictos de direcciones.
- Debe elegir entre direcciones IP públicas estándar, prefijos de direcciones IP públicas o aportar sus propios rangos de direcciones IP (BYOIP).
- Quiere comprender cuándo IPv6 de doble pila es apropiado para sus cargas de trabajo.
- Administra un entorno grande o creciente y necesita una estrategia para realizar un seguimiento de las asignaciones de IP a escala.
Enfoque lift and shift: Elige rangos privados que no se solapen con tu red local, de modo que el enrutamiento de VPN o ExpressRoute funcione sin traducción. Reserva un bloque grande de zona de aterrizaje con espacio suficiente para las cargas de trabajo que migrarás en los próximos años.
Enfoque Modernizar: Planifica un espacio de direcciones que no se solape entre tus regiones principal y de respaldo, de modo que las cargas de trabajo activas-activas puedan establecer conexiones entre sí más adelante, y reserva subredes del tamaño adecuado para App Service Environment y AKS.
Enfoque multinube: Cree un plan global de direccionamiento que no entre en conflicto con los rangos CIDR existentes de las VPC de AWS ni con los de Google Cloud, lo cual es obligatorio antes de conectar nubes mediante VPN o interconexión.
servicios y características de Azure
Los siguientes servicios y características admiten el planeamiento de direcciones IP en Azure:
| Servicio o característica | Qué proporciona | Cuándo usarlo |
|---|---|---|
| Espacios de direcciones privadas RFC 1918 | Tres intervalos reservados para uso privado: 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. Las redes virtuales de Azure utilizan estos rangos para la comunicación interna. | Siempre: cada VNet requiere al menos un rango de direcciones privadas de estos espacios. |
| Espacio de direcciones compartido de RFC 6598 | 100.64.0.0/10: tratado como espacio de direcciones privado en Azure. Diseñado originalmente para entornos NAT de nivel de operador (CGNAT). | Cuando su organización ya utiliza rangos RFC 6598 en las instalaciones, o cuando se agota el espacio RFC 1918. |
| Dirección IP pública estándar | Una dirección IP pública estática con redundancia de zona asignada a un único recurso. Seguro de forma predeterminada con el tráfico de entrada bloqueado. | Cuando un recurso necesita un punto de conexión público único, como un equilibrador de carga, una puerta de enlace de VPN o una máquina virtual orientada al público. |
| Prefijo IP público | Bloque contiguo reservado de direcciones IP públicas de una región de Azure específica. | Cuando necesite rangos de IP predecibles para la puerta de enlace NAT, los conjuntos de escalado de máquinas virtuales o para añadir direcciones externas a una lista aprobada. |
| BYOIP o prefijo IP personalizado | Incorpore sus propios intervalos IP públicos a Azure. Utiliza un proceso de tres fases: validar la propiedad, aprovisionar el prefijo y, a continuación, ponerlo en servicio para su uso. | Cuando necesite conservar la reputación IP existente, mantener entradas de la lista de aprobados externos o migrar cargas de trabajo sin cambiar las direcciones IP públicas. |
| Azure Virtual Network Manager IPAM | Una característica integrada de administración de direcciones IP en Azure Virtual Network Manager. Disponible con carácter general en la mayoría de las regiones. Proporciona visibilidad centralizada y seguimiento de asignación entre suscripciones. | Cuando administre muchas VNet en varias suscripciones y necesite un seguimiento automatizado de la utilización de direcciones. Consulte Administración de red centralizada. |
Cómo elegir
Use las siguientes tablas de decisiones para guiar sus decisiones de planificación de IP.
Procedimientos recomendados de planeamiento de IP
| Práctica | Por qué | Example |
|---|---|---|
| Asigne un CIDR principal grande (/16) y subdívidalo | Evita el agotamiento de direcciones a medida que crecen las cargas de trabajo. Más fácil de resumir las rutas. | Asigne 10.1.0.0/16 al entorno de producción y, a continuación, carve las subredes /24 para cada nivel de carga de trabajo. |
| Deje al menos un 30 % de margen en cada subred. | Los servicios escalables, como los conjuntos de escalado de máquinas virtuales, AKS y los entornos de App Service, consumen direcciones IP rápidamente durante la expansión horizontal. | Una subred /24 proporciona 251 direcciones IP utilizables. Si su implementación de referencia utiliza 100, tiene margen para triplicar esa cifra. |
| Uso de bloques CIDR contiguos para cada entorno | Simplifica el resumen de rutas y las reglas de firewall. Una única ruta de resumen representa todo el entorno. | Producción: 10.1.0.0/16. Entorno de prueba: 10.2.0.0/16. Desarrollo: 10.3.0.0/16. |
| Evite los rangos reservados y prohibidos por la plataforma Azure | El uso de intervalos reservados provoca errores de enrutamiento y errores de implementación. | No asigne 169.254.0.0/16, 168.63.129.16/32, 224.0.0.0/4, 127.0.0.0/8 o 255.255.255.255/32. |
| Asignaciones de documentos en Azure IPAM o una hoja de cálculo | Evita la superposición a medida que crece el entorno. Centraliza la visibilidad de los equipos de red. | Use Azure Virtual Network Manager IPAM para el seguimiento automatizado o mantenga una hoja de cálculo compartida para entornos más pequeños. |
Tipos de direcciones IP públicas
| Tipo | ¿Qué es? | Cuándo usarlo |
|---|---|---|
| Dirección IP pública estándar | Dirección IP pública estática asignada individualmente. Redundancia por zona de forma predeterminada en las regiones con zonas de disponibilidad habilitadas. Seguro de forma predeterminada: todo el tráfico entrante se bloquea hasta que una regla de NSG o equilibrador de carga lo permita. | Equilibradores de carga orientados al público, puertas de enlace de VPN, Azure Bastion, puertas de enlace de aplicaciones o cualquier recurso que necesite un punto de conexión público único. |
| Prefijo IP público | Bloque contiguo reservado de direcciones IP públicas de una región específica. Garantiza direcciones secuenciales. | NAT Gateway (requiere prefijo para varias direcciones IP de salida), Virtual Machine Scale Sets o cuando los sistemas externos necesitan agregar a una lista aprobada un intervalo predecible de direcciones IP. |
| BYOIP o prefijo IP personalizado | Intervalos ip públicos propiedad del cliente incorporados a Azure a través de un proceso de tres fases: validación, aprovisionamiento y puesta en marcha. Los prefijos regionales se activan en aproximadamente 30 minutos; los prefijos globales tardan entre 3 y 4 horas. | Preservar la reputación de la IP durante la migración a la nube, mantener entradas en listas de permitidos externas o cumplir los requisitos normativos relativos a la propiedad de la IP. Las direcciones IP derivadas de un prefijo ip personalizado también pueden usar Azure DDoS Protection. |
Note
Las direcciones IP públicas de SKU Basic se retiraron el 30 de septiembre de 2025. Las direcciones IP básicas existentes siguen funcionando, pero no son compatibles y no tienen ningún Acuerdo de Nivel de Servicio. Actualice a la SKU estándar para todas las implementaciones nuevas.
Decisión sobre IPv6
| Escenario | Recommendation | Justificación |
|---|---|---|
| La carga de trabajo solo atiende a los clientes IPv4, sin necesidad de IPv6 normativo. | Solo IPv4 | Configuración más sencilla. Evita la sobrecarga de administración de doble pila. La mayoría de los servicios Azure admiten IPv4 de forma nativa. |
| La carga de trabajo debe atender a clientes IPv6 o las regulaciones requieren compatibilidad con IPv6. | Doble pila (IPv4 + IPv6) | Las redes virtuales de Azure admiten subredes de doble pila. Implemente IPv6 junto con IPv4 en los mismos recursos. |
| La carga de trabajo necesita IPv6, pero se basa en Azure Firewall, Virtual WAN o Route Server | Solo IPv4 (con terminación IPv6 externa) | Azure Firewall, Virtual WAN y Route Server no admiten actualmente IPv6. Finalice IPv6 en un equilibrador de carga externo o un dispositivo perimetral antes de que el tráfico entre en estos servicios. VPN Gateway IPv6 está disponible en versión preliminar. |
Doble pila IPv6 en Azure
Azure admite implementaciones de pila doble IPv6 en redes virtuales. Al habilitar la doble pila, cada subred obtiene un intervalo IPv4 y un intervalo IPv6 /64. Los recursos reciben direcciones de ambas familias y pueden comunicarse a través de cualquiera de los dos protocolos simultáneamente.
IPv6 en Azure tiene requisitos de ajuste de tamaño específicos. Las subredes IPv6 deben ser exactamente /64. No se admite ninguna otra longitud de prefijo. El espacio de direcciones IPv6 que asigne a una red virtual debe ser lo suficientemente grande como para acomodar las subredes /64 para cada subred que necesite conectividad IPv6. Planee la asignación de direcciones IPv6 junto con los intervalos IPv4 durante el diseño de red inicial.
Los siguientes servicios de Azure admiten configuraciones de pila doble IPv6:
| Servicio | Compatibilidad con IPv6 |
|---|---|
| Red virtual de Azure | Subredes de doble pila con rangos IPv6 /64 |
| Balanceador de carga estándar | Frontends IPv6 públicos e internos |
| VPN Gateway | Puntos de conexión de túnel IPv6 (versión preliminar; requiere participación) |
| Puerta NAT | Traducción IPv6 saliente (solo para SKU StandardV2; el SKU Standard es solo para IPv4) |
| DIRECCIÓN IP pública (SKU estándar) | Direcciones públicas IPv6 |
| Conjuntos de máquinas virtuales escalables | Interfaces de red IPv6 |
| Emparejamiento de VNet | Tráfico IPv6 entre VNet con conexión entre pares |
| Grupos de seguridad de red | Reglas IPv6 para el filtrado |
| DNS (Azure DNS) | Compatibilidad con registros AAAA |
Servicios clave que no admiten IPv6: Azure Firewall (requiere una subred solo IPv4), Virtual WAN (solo IPv4) y Route Server (solo IPv4). VPN Gateway admite IPv6 en modo de pila doble, pero solo como función en versión preliminar (requiere suscripción previa). Si la arquitectura depende de Azure Firewall, Virtual WAN o Route Server para la inspección o enrutamiento del tráfico, diseñe la red para que el tráfico IPv6 se controle antes de llegar a estos componentes.
Para obtener información detallada sobre las funcionalidades, las limitaciones y los pasos de configuración de IPv6, consulte IPv6 para Azure Virtual Network.
direcciones reservadas por Azure
Azure reserva cinco direcciones IP en cada subred:
| Dirección reservada | propósito |
|---|---|
| Primera dirección (.0) | Identificador de red |
| Segunda dirección (.1) | Puerta de enlace predeterminada |
| Tercera dirección (.2) | Asignación de Azure DNS |
| Cuarta dirección (.3) | Asignación de Azure DNS |
| Última dirección (difusión) | Dirección de difusión |
Tenga en cuenta estas cinco direcciones reservadas en todos los cálculos de ajuste de tamaño de subred. Una subred /24 proporciona 256 direcciones totales menos 5 reservadas, lo que deja 251 direcciones IP de host utilizables. La subred IPv4 compatible más pequeña es /29 (8 direcciones menos 5 reservadas = 3 utilizables). La subred IPv4 compatible más grande es /2.
Sugerencia
Las direcciones IP públicas de SKU estándar generan cargos estén o no asociadas a un recurso. Como parte de las prácticas recomendadas de higiene de IP, elimine periódicamente las direcciones IP públicas que ya no utilice y libere los prefijos de IP públicos que ya no necesite. Las direcciones IP públicas no adjuntas son una fuente frecuente de costos evitables y una superficie de ataque innecesaria.
Consideraciones de diseño
Enfoque de diseño de planificación de IP lift-and-shift
- Reserve un único bloque CIDR grande (un /16 es habitual) para la zona de aterrizaje y subdivídalo para cada aplicación migrada, dejando un margen de aproximadamente el 20 % para el crecimiento.
- Elija intervalos que no se superpongan con redes locales que se conecten a través de VPN Gateway o ExpressRoute, por lo que el enrutamiento funciona sin traducción de direcciones.
- Tenga en cuenta las cinco direcciones reservadas de Azure por subred y las subredes dedicadas que requieren los servicios de plataforma, como
GatewaySubnet(/27) yAzureFirewallSubnet(/26). - Cuando las redes nunca se interconectan entre sí, se pueden reutilizar deliberadamente rangos privados de IPv4 para conservar el espacio de direcciones.
Modernización del enfoque de diseño del planeamiento de IP
- Asigne rangos que no se solapen en sus regiones principal y de respaldo, de modo que las cargas de trabajo activas-activas puedan utilizar el emparejamiento global más adelante sin necesidad de reasignar direcciones.
- Reserve una subred dedicada dimensionada para el entorno de App Service (/24, o /23 cerca de la escala máxima). En el caso de AKS con CNI Overlay, dimensiona la subred solo para los nodos, ya que los pods utilizan un CIDR de superposición independiente, lo que hace que la subred de los nodos sea mucho más pequeña de lo que requiere un diseño CNI plano.
- Reserve una subred dedicada para puntos de conexión privados, por lo que la adopción de PaaS no fragmenta el plan de direcciones.
- Use la administración de direcciones IP de Azure Virtual Network Manager para realizar un seguimiento y automatizar las asignaciones a medida que su entorno se amplía.
Enfoque de diseño de la planificación de IP multinube
- Establezca primero un plan de direccionamiento global: reserve bloques CIDR de Azure que no se superpongan con las VPC de AWS existentes ni con las redes de VPC de Google Cloud, lo cual es necesario para una VPN enrutada o una interconexión.
- Documente los intervalos de direcciones de cada nube y rama conectadas para que pueda planear rutas resumidas a través de Azure Virtual WAN.
- Reserva espacio de direcciones para los componentes de tránsito, como el concentrador de Virtual WAN y las subredes de la VPN Gateway, con margen para escalar a medida que añadas perímetros de nube y sucursales.
- Cuando los solapamientos sean inevitables, planifique aplicar NAT a las conexiones VPN afectadas o reasignar direcciones a las cargas de trabajo durante la migración en lugar de hacerlo después.
Prerequisites
Antes de planear la asignación de direcciones IP:
- Diseño de red virtual: Tiene una estructura de red virtual existente o planeada. Si todavía no ha diseñado sus VNets, consulte primero Redes virtuales y subredes de Azure.
- Inventario de IP local: Documente los intervalos de direcciones locales existentes, incluidos los intervalos utilizados por sucursales, centros de datos u otros proveedores de nube. Las direcciones no superpuestas son necesarias para la conectividad híbrida.
- Proyecciones de crecimiento: Calcule cuántas subredes y hosts adicionales necesitará durante los próximos 2 a 3 años. Asignar espacio de direcciones por adelantado es más fácil que expandir una red virtual más adelante.
Consideraciones de seguridad
El planeamiento de IP tiene implicaciones de seguridad directas. Siga estos procedimientos para reducir el riesgo:
- Evite la superposición de direcciones: Los intervalos de IP superpuestos entre las redes locales, las VNets de Azure y las VNets emparejadas provocan fallos de enrutamiento. El tráfico podría llegar a un destino incorrecto o ser descartado de forma silenciosa. Compruebe que cada intervalo de direcciones es único en toda la red.
-
Evitar intervalos prohibidos: Azure reserva los siguientes intervalos para las operaciones de plataforma. Nunca los use como espacio de direcciones de red virtual:
- 169.254.0.0/16 (local de vínculo)
- 168.63.129.16/32 (Azure DNS interno)
- 224.0.0.0/4 (multidifusión)
- 127.0.0.0/8 (bucle invertido)
- 255.255.255.255/32 (difusión)
- Documento y auditoría: Mantenga un registro actual de todas las asignaciones de IP. Los intervalos no documentados conducen a superposición accidental cuando se implementan nuevas cargas de trabajo. Use Azure Virtual Network Manager IPAM para el seguimiento de cumplimiento automatizado o mantenga una hoja de cálculo compartida que se revise durante cada implementación.
- Proteger direcciones IP públicas: Asocie Azure DDoS Protection con recursos de IP pública en entornos de producción. Los rangos BYOIP también se pueden proteger mediante protección contra DDoS.
Artículos relacionados
En estos artículos se tratan temas que interactúan con el planeamiento de direcciones IP:
- Azure redes virtuales y subredes: red virtual y estructura de subred donde se asignan direcciones IP.
- Grupos de seguridad de red y grupos de seguridad de aplicaciones: reglas de seguridad que hacen referencia a intervalos IP.
- Topología en estrella: planificación de direcciones IP en VNet compartidas y de cargas de trabajo en un diseño en estrella.
- Topología de Virtual WAN: planificación de direcciones para concentradores de Virtual WAN y redes virtuales conectadas.
- Redes multirregión: planificación de IP entre regiones, incluidos rangos no superpuestos para la interconexión entre regiones.
- Administración de red centralizada: Azure Virtual Network Manager IPAM para el seguimiento y la asignación de IP a gran escala.
Aprende más
- Direccionamiento IP para redes virtuales de Azure
- Direcciones IP públicas en Azure
- Prefijo de dirección IP personalizada (BYOIP)
- ¿Qué es Azure Virtual Network Manager IPAM?
- IPv6 para Azure Virtual Network
- P+F de Azure Virtual Network
Pasos siguientes
Sugerencia
¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.
Siguiente paso en su proceso de lift-and-shift:
Proteja sus subredes con grupos de seguridad de red: replique las reglas existentes de firewall como reglas de NSG para mantener su nivel de seguridad en Azure.
A continuación en su proceso de modernización:
Proteger las subredes con grupos de seguridad de red: aplique una segmentación estricta para que solo el tráfico del equilibrador de carga llegue a las subredes de la aplicación.
Próximo paso en su proceso de migración entre nubes:
Proteja sus subredes con grupos de seguridad de red: replique sus grupos de seguridad de AWS y las reglas de firewall de Google Cloud como grupos de seguridad de red (NSG) de Azure.