Editor Top
|
|
Hoy anunciamos dos nuevas capacidades para la puerta de enlace NAT de Amazon Virtual Private Cloud (VPC) y Amazon Route 53, lo que permite que sus cargas de trabajo solo IPv6 se comuniquen de manera transparente con servicios solo IPV4. ¿Curioso? Sigue leyendo; Tengo detalles para ti.
Algunos de ustedes ejecutan cargas de trabajo muy grandes que involucran decenas de miles de máquinas virtuales, contenedores o microservicios. Para hacerlo, configuró estas cargas de trabajo para que funcionen en el espacio de direcciones IPv6. Esto evita el problema de quedarse sin direcciones IPv4 disponibles (una sola VPC tiene un tamaño teórico máximo de 65 536 direcciones IPv4, en comparación con los rangos de /56 para IPv6, lo que permite un tamaño teórico máximo de 2^73 -1 direcciones IPv6), y le ahorra dolores de cabeza adicionales causados por la administración de redes complejas basadas en IPv4 (piense en subredes que no se superponen entre VPC que pertenecen a varias cuentas de AWS, regiones de AWS o redes locales).
Pero, ¿realmente puede ejecutar una carga de trabajo IPv6 de forma aislada del resto del mundo IPv4? La mayoría de ustedes nos dijo que es importante dejar que dichas cargas de trabajo continúen comunicándose con los servicios de IPv4, ya sea para realizar llamadas a API más antiguas o simplemente como un diseño transitorio, mientras migra múltiples cargas de trabajo dependientes de IPv6 a IPv4. No tener la capacidad de llamar a un servicio IPv4 desde hosts IPv6 hace que las migraciones sean más lentas y difíciles de lo que debería ser. Obligó a algunos de ustedes a crear soluciones personalizadas que son difíciles de mantener.
Es por eso que estamos lanzando dos nuevas capacidades que permiten que sus cargas de trabajo de IPv6 se comuniquen de manera transparente con los servicios de IPv4: NAT64 (léase «seis a cuatro») para la puerta de enlace VPC NAT y DNS64 (también «seis a cuatro») para la resolución de Amazon Route 53 .
¿Como funciona?
Como se ilustra en el siguiente diagrama, imaginemos que tengo una instancia de Amazon Elastic Compute Cloud (Amazon EC2) con una dirección solo de IPv6 que tiene que realizar una llamada API a un servicio IPv4 que se ejecuta en otra instancia de EC2. En el diagrama, elegí tener el host solo de IPv4 en una VPC separada en la misma cuenta de AWS, pero estas capacidades funcionan para conectarse a cualquier servicio de IPv4, ya sea en la misma VPC o en la VPC de otra cuenta de AWS, su entorno local. red, o incluso en la Internet pública. Mi host solo de IPv6 solo conoce el nombre DNS del servicio.
Esta es la secuencia que sucede cuando el host de solo IPv6 inicia una conexión con el servicio IPv4:
1. El host IPV6 realiza una llamada DNS para resolver el nombre del servicio en una dirección IP. Sin DNS64, Route 53 habría devuelto una dirección IPv4. Los hosts solo de IPv6 no habrían podido conectarse a esa dirección IPv4. Pero a partir de hoy, puede activar DNS64 para su subred. El solucionador de DNS primero verifica si el registro contiene una dirección IPv6 (AAAA registro). Si es así, se devuelve la dirección IPv6. El host IPv6 puede conectarse al servicio usando solo IPv6. Cuando el registro solo contiene una dirección IPv4, el solucionador de Route 53 sintetiza una dirección IPv6 anteponiendo el conocido 64:ff9b::/96 prefijo de la dirección IPv4.
Por ejemplo, cuando el servicio IPv4 tiene la dirección 34.207.250.62Vuelve la Ruta 53 64:ff9b::ffff:22cf:fa3e.
| IPv6 (hexadecimal): | 64:ff9b::ffff: | 22 | cf | fa | 3e |
| IPv4 (decimales): | – | 34 | 207 | 250 | 62 |
64:ff9b::/96es un prefijo bien conocido definido en el RFC 6052 norma propuesta para el IETF. Leer el texto de la norma es una gran manera dormirse rapido para conocer todos los detalles sobre la traducción de IPv6 a IPv4.
2. El host IPv6 inicia una conexión a 64:ff9b::ffff:22cf:fa3e. Puede configurar el enrutamiento de subred para enviar todos los paquetes que comienzan con 64:ff9b::/96 a la puerta de enlace NAT. La puerta de enlace NAT reconoce el prefijo de la dirección IPv6, extrae la dirección IPv4 e inicia una conexión IPv4 con el destino. Como de costumbre, la dirección IPv4 de origen es la dirección IPv4 de la propia puerta de enlace NAT.
3. Cuando llega la respuesta del paquete, la puerta de enlace NAT vuelve a llenar la dirección IPv6 del host de destino y antepone el prefijo conocido 64:ff9b::/96 a la dirección IP de origen del paquete de respuesta.
Ahora que comprende cómo funciona, ¿cómo puede configurar su VPC para aprovechar estas dos nuevas capacidades?
Cómo empezar
Para habilitar estas dos capacidades, debo ajustar dos configuraciones: primero, señalo las subredes que requieren traducción DNS64 y, segundo, agrego una ruta a la tabla de enrutamiento de subredes IPv6 para enviar parte del tráfico IPv6 a la puerta de enlace NAT.
Para habilitar DNS64, tengo que usar el nuevo --enable-dns64 opción para modificar mis subredes existentes. En esta demostración, utilizo el modify-subnet-attribute mando. Esta es una operación de una sola vez. Puedo hacerlo con la API de VPC, la interfaz de línea de comandos (CLI) de AWS o la consola de administración de AWS. Tenga en cuenta que esta es una configuración de nivel de subred que debe activarse explícitamente. De forma predeterminada, se mantiene el comportamiento existente.
aws ec2 modify-subnet-attribute --subnet-id subnet-123 --enable-dns64
Tengo que agregar una ruta a la tabla de enrutamiento de la subred para permitir que VPC reenvíe paquetes IPv6 con el prefijo DNS64 a la puerta de enlace NAT. Le dice que enrute todos los paquetes con destino 64:ff9b::/96 a la puerta de enlace NAT.
aws ec2 create-route --route-table-id rtb-123 –-destination-ipv6-cidr-block 64:ff9b::/96 –-nat-gateway-id nat-123
El siguiente diagrama ilustra estos dos simples cambios de configuración.
Con estos dos cambios simples, mis cargas de trabajo solo de IPv6 en la subred ahora pueden comunicarse con los servicios de IPv4. El servicio IPv4 puede residir en la misma VPC, en otra VPC o en cualquier lugar de Internet.
Puede continuar usando su puerta de enlace NAT existente y no se requiere ningún cambio en la puerta de enlace en sí o en la tabla de enrutamiento adjunta a la subred de la puerta de enlace NAT.
Precios y disponibilidad
Estas dos nuevas capacidades para la puerta de enlace NAT de VPC y la ruta 53 están disponibles hoy en todas las regiones de AWS sin costo adicional. Es posible que se apliquen cargos regulares de puerta de enlace NAT.
¡Vaya y construya sus redes solo IPv6!
