DS-Lite bloquea o aloxamento IPv4 entrante, non a VPN saínte

DS-Lite é unha forma de darlle a un cliente conectividade IPv4 a través dunha rede de acceso que só transporta IPv6. O router doméstico non ten un enderezo IPv4 público dedicado propio, e ese único feito convence a xente de que unha VPN IPv4 non pode funcionar desde esa conexión. En saída, normalmente funciona ben. O provedor traduce a conexión e o extremo remoto ve un cliente IPv4 corrente. O que se rompe é a dirección oposta: aloxar algo que espera IPv4 entrante non solicitado. A distinción é que extremo inicia a conversa.

Que extremo inicia a conexión

Un cliente que inicia unha conexión crea estado de tradución a medida que avanza. O tradutor do provedor ve o primeiro paquete, asigna unha asignación e reenvíao. O tráfico de retorno coincide con esa asignación porque a asignación xa existe.

Un servidor que espera conexións non ten ese estado que crear. Alguén de fóra ten que chegar a un enderezo e un porto que o provedor non aceptou asignar, e iso é unha solicitude completamente distinta.

Siga unha solicitude saínte

A arquitectura de RFC 6333 nomea ambos os extremos. O elemento do lado do cliente é o B4, que encapsula IPv4 en IPv6. O elemento do lado do provedor é o AFTR, que realiza a tradución de enderezos e reenvía o paquete como IPv4.

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

O servidor VPN recibe unha conexión IPv4 normal desde o enderezo traducido do provedor. Non necesita un modo DS-Lite, un porto especial nin saber que a rede de acceso do cliente é só IPv6. Esa é a parte que a xente pasa por alto: o extremo remoto non pode notalo.

A configuración do propio cliente é igual de corrente. Necesita unha ruta IPv4 que funcione ata o servidor, que B4 e AFTR proporcionan, e necesita que o nome de host do servidor se resolva a un enderezo IPv4.

Por que o aloxamento entrante é o caso que falla

Executar un servidor VPN IPv4 na casa é o deseño que choca co enderezo compartido do provedor. O tradutor do provedor é dono do enderezo público e da táboa de asignacións, e non ten motivo para crear unha asignación entrante permanente para un só abonado.

Unha regra de reenvío de portos no router doméstico non pode configurar o AFTR. A regra é real e correcta no dispositivo local, e non cambia nada augas arriba, por iso o síntoma parece un problema de devasas que non se vai.

Aquí tamén a tradución de nivel de operador difire dun único enderezo público: mesmo un reenvío local correcto pode acabar nun enderezo que comparten moitos abonados.

Diagnostique antes de cambiar o plan de acceso

Confirme primeiro o modo aprovisionado. A pila dobre nativa, DS-Lite e unha rede só IPv6 que usa outro mecanismo de tradución son tres disposicións distintas, e os nomes comerciais do provedor non sempre coinciden co técnico.

Despois estableza catro observacións para un fallo saínte. Resolve o cliente o nome de host da VPN a un destino IPv4? Funciona a conectividade IPv4 simple, en lugar dunha solicitude do navegador que quizais usou IPv6 en silencio? Que transporte e que porto intenta o cliente, e os rexistros do punto final ven ese intento? O fallo ocorre durante o intercambio inicial, tras un período de inactividade ou só en transferencias grandes?

Eses catro respostas apuntan ao filtrado, á expiración do estado de tradución, a un punto final equivocado ou ao tratamento do tamaño do paquete. Nada diso se establece vendo DS-Lite na páxina da conta.

Lea con coidado os cambios do provedor

Un cambio de conta pode coincidir cunha conexión que funciona mentres altera varias propiedades á vez. Anote que propiedade cambiou, porque un nome de paquete novo non é unha explicación técnica.

A instrución de activar a pila dobre é ambigua ata que alguén confirma que aprovisiona realmente o provedor. Tratala como un requisito universal para clientes VPN IPv4 converte unha suposición en política.

Se o requisito real é o aloxamento IPv4 entrante, fale co provedor dunha disposición entrante compatible, enderezo nativo ou outro deseño de acceso. Se o requisito é un portátil que chega a un servidor remoto, pregunte en cambio por ese fluxo saínte exacto. Orde de traballo: nomee a dirección, confirme o modo aprovisionado, probe IPv4 simple e un transporte e cambie o plan de acceso só se a dirección realmente o esixe.