NAT de IPv4 a IPv6 en AWS

Question

AWS admite la conexión a servicios externos solo IPv4 desde un nodo solo IPv6 mediante NAT64. ¿Existe un equivalente para lo contrario?

Por contexto, tengo un clúster EKS, que actualmente es solo IPv4, todo en subredes privadas. La comunicación a cualquier IP externa se realiza a través de una puerta de enlace NAT (normalmente para webhooks o solicitudes salientes similares). Ahora algunos servicios externos están cambiando a IPv6 únicamente. ¿Hay alguna manera de conectarse a ellos sin migrar todo el clúster a IPv6? Dado que EKS no admite redes de doble pila, la migración podría ser un proyecto bastante grande y arriesgado.

Answer 1

No, el origen IPv4 y el destino IPv6 no son tan fáciles. En comparación con ir al revés o IPv6 nativo.

DNS64 + NAT64, un mecanismo de transición utilizado en redes solo IPv6 para conectarse a v4, es simple. Un pequeño prefijo v6 puede contener todo el espacio de direcciones v4. Fancy DNS genera registros AAAA en este prefijo cuando el resultado solo tiene un registro A. Y la NAT de doble pila tiene que realizar una simple conversión sin estado 1 a 1, que es rápida y no necesita configuración.

Contraste con ir en sentido contrario. Digamos que la dirección del servicio remoto es. 2001:db8:114:6614:240e:6d9d:8a1d:59d3 El espacio completo de direcciones IPv4 de 32 bits solo podría contener los dos últimos grupos de dígitos, la 8a1d:59d3parte. Por lo tanto, los trucos sofisticados de DNS y las aplicaciones no modificadas no funcionarán. En teoría, un proxy de doble pila podría terminar las conexiones v4 y hacer que las v6 se apaguen. Pero, ¿cómo va a pasar las direcciones v6 y analizar el tráfico de aplicaciones en busca de nombres en DNS o TLS? ¿Y cómo mantener los flujos, NAT con estado?

Sin embargo, Kubernetes tiene sus propias ideas sobre redes y EKS no es una excepción. Si bien no se trata solo de incluir un NAT64,EKS tiene diseños de doble pila.v6 asignada a pods, pero también una v4 solo de host que recibe NAT un par de veces en el caso de v4 a Internet.

Tenga en cuenta lo simple que es la v6 en la aplicación a la v6 en Internet, fuera de la puerta de enlace de salida de Internet sin NAT. Obtener esta conectividad con recursos externos v6 es una razón para que su organización haga esto. Además de eliminar las preocupaciones sobre el tamaño de las subredes para la cantidad de pods.

Implementar esto en la Internet moderna es un proyecto, sí. Lo primero que ocurreuna lista de verificación para IPv6 en EKSEl clúster debe crearse con v6.

Puedes hacer este proyecto. Cree un segundo grupo con este nuevo diseño. Inicie nuevas aplicaciones en él y migre otras cuando exista una oportunidad de mantenimiento. Tenga un plan de reversión si hay algún problema, para volver a como era antes. En el peor de los casos, el antiguo grupo podría reconstruirse tal como estaba. Después de todo, esto es infraestructura como código.

Answer 2

La opción está bastante oculta en los documentos, pero es posible realizar la salida IPv6 desde un clúster EKS IPv4. Esto se puede hacer usando elENABLE_V6_EGRESSopción en el complemento vpc-cni.

Esto configura cada pod con una dirección privada de nodo en el rango "fd00::ac:00/118". Para puntos finales externos, el pod luego realiza NAT a través del nodo.

Técnicamente, esto no es "NAT de IPv4 a IPv6", pero logra el objetivo de salida de IPv6 en un clúster EKS de IPv4.

Pasos requeridos:

1. Asigne bloques IPv6 en la VPC y las subredes, y habilite "Asignar automáticamente dirección IPv6" en las subredes. Agregue una puerta de enlace a Internet de solo salida y configure las tablas de enrutamiento de manera adecuada.
2. Gire todos los nodos para asignar una dirección IPv6 a cada uno.
3. Asegúrese de que el complemento vpc-cni tenga la versión 1.13+.
4. Actualice el complemento vpc-cni con la siguiente configuración: {"env":{"ENABLE_V6_EGRESS":"true"},"init":{"env":{"ENABLE_V6_EGRESS":"true"}}}. Haga esto solo después de rotar todos los nodos; de lo contrario, la implementación fallará.