DS-Lite bloquea el alojamiento IPv4 entrante, no la VPN saliente

DS-Lite es una forma de dar a un cliente conectividad IPv4 a través de una red de acceso que solo transporta IPv6. El router doméstico no tiene una dirección IPv4 pública dedicada propia, y ese único hecho convence a la gente de que una VPN IPv4 no puede funcionar desde esa conexión. En salida, normalmente funciona bien. El proveedor traduce la conexión y el extremo remoto ve un cliente IPv4 corriente. Lo que se rompe es la dirección opuesta: alojar algo que espera IPv4 entrante no solicitado. La distinción es qué extremo inicia la conversación.

Qué extremo inicia la conexión

Un cliente que inicia una conexión crea estado de traducción a medida que avanza. El traductor del proveedor ve el primer paquete, asigna una asignación y lo reenvía. El tráfico de retorno coincide con esa asignación porque la asignación ya existe.

Un servidor que espera conexiones no tiene ese estado que crear. Alguien de fuera tiene que llegar a una dirección y un puerto que el proveedor no ha aceptado asignar, y eso es una solicitud completamente distinta.

Siga una solicitud saliente

La arquitectura de RFC 6333 nombra ambos extremos. El elemento del lado del cliente es el B4, que encapsula IPv4 en IPv6. El elemento del lado del proveedor es el AFTR, que realiza la traducción de direcciones y reenvía el paquete como IPv4.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

El servidor VPN recibe una conexión IPv4 normal desde la dirección traducida del proveedor. No necesita un modo DS-Lite, un puerto especial ni saber que la red de acceso del cliente es solo IPv6. Esa es la parte que la gente pasa por alto: el extremo remoto no puede notarlo.

La configuración del propio cliente es igual de corriente. Necesita una ruta IPv4 que funcione hasta el servidor, que B4 y AFTR proporcionan, y necesita que el nombre de host del servidor se resuelva a una dirección IPv4.

Por qué el alojamiento entrante es el caso que falla

Ejecutar un servidor VPN IPv4 en casa es el diseño que choca con el direccionamiento compartido del proveedor. El traductor del proveedor es dueño de la dirección pública y de la tabla de asignaciones, y no tiene motivo para crear una asignación entrante permanente para un solo abonado.

Una regla de reenvío de puertos en el router doméstico no puede configurar el AFTR. La regla es real y correcta en el dispositivo local, y no cambia nada aguas arriba, por eso el síntoma parece un problema de cortafuegos que no se va.

Aquí también la traducción de nivel de operador difiere de una única dirección pública: incluso un reenvío local correcto puede acabar en una dirección que comparten muchos abonados.

Diagnostique antes de cambiar el plan de acceso

Confirme primero el modo aprovisionado. La pila doble nativa, DS-Lite y una red solo IPv6 que usa otro mecanismo de traducción son tres disposiciones distintas, y los nombres comerciales del proveedor no siempre coinciden con el técnico.

Después establezca cuatro observaciones para un fallo saliente. ¿Resuelve el cliente el nombre de host de la VPN a un destino IPv4? ¿Funciona la conectividad IPv4 simple, en lugar de una solicitud del navegador que quizá usó IPv6 en silencio? ¿Qué transporte y qué puerto intenta el cliente, y los registros del punto final ven ese intento siquiera? ¿El fallo ocurre durante el intercambio inicial, tras un periodo de inactividad o solo en transferencias grandes?

Esas cuatro respuestas apuntan al filtrado, a la expiración del estado de traducción, a un punto final equivocado o al tratamiento del tamaño de paquete. Nada de eso se establece viendo DS-Lite en la página de la cuenta.

Lea con cuidado los cambios del proveedor

Un cambio de cuenta puede coincidir con una conexión que funciona mientras altera varias propiedades a la vez. Anote qué propiedad cambió, porque un nombre de paquete nuevo no es una explicación técnica.

La instrucción de activar la pila doble es ambigua hasta que alguien confirma qué aprovisiona realmente el proveedor. Tratarla como un requisito universal para clientes VPN IPv4 convierte una suposición en política.

Si el requisito real es el alojamiento IPv4 entrante, hable con el proveedor de una disposición entrante compatible, direccionamiento nativo u otro diseño de acceso. Si el requisito es un portátil que llega a un servidor remoto, pregunte en cambio por ese flujo saliente exacto. Orden de trabajo: nombre la dirección, confirme el modo aprovisionado, pruebe IPv4 simple y un transporte y cambie el plan de acceso solo si la dirección realmente lo exige.