DS-Lite bloqueja l’allotjament IPv4 entrant, no la VPN sortint

DS-Lite és una manera de donar a un client connectivitat IPv4 a través d’una xarxa d’accés que només transporta IPv6. El router de casa no té cap adreça IPv4 pública dedicada pròpia, i aquest sol fet convenç la gent que una VPN IPv4 no pot funcionar des d’aquella connexió. En sortida, normalment funciona bé. La connexió la tradueix el proveïdor, i el costat remot veu un client IPv4 corrent. El que es trenca és la direcció oposada: allotjar alguna cosa que espera IPv4 entrant no sol·licitat. La distinció és quin costat inicia la conversa.

Quin costat inicia la connexió

Un client que inicia una connexió crea estat de traducció a mesura que avança. El traductor del proveïdor veu el primer paquet, assigna una mapatge i el reenvia. El trànsit de retorn coincideix amb aquest mapatge perquè el mapatge ja existeix.

Un servidor que espera connexions no té cap estat així per crear. Algú de fora ha d’arribar a una adreça i un port que el proveïdor no ha acceptat de mapar, i això és una sol·licitud completament diferent.

Seguiu una sol·licitud sortint

L’arquitectura de RFC 6333 anomena els dos extrems. L’element del costat del client és el B4, que encapsula IPv4 dins d’IPv6. L’element del costat del proveïdor és l’AFTR, que fa la traducció d’adreces i reenvia el paquet com a 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 rep una connexió IPv4 normal des de l’adreça traduïda del proveïdor. No necessita cap mode DS-Lite, cap port especial ni cap coneixement que la xarxa d’accés del client sigui només IPv6. Aquesta és la part que la gent passa per alt: el costat remot no ho pot saber.

La configuració del mateix client és igualment corrent. Necessita un camí IPv4 que funcioni fins al servidor, que el B4 i l’AFTR proporcionen, i necessita que el nom d’amfitrió del servidor es resolgui a una adreça IPv4.

Per què l’allotjament entrant és el cas que falla

Executar un servidor VPN IPv4 a casa és el disseny que xoca amb l’adreçament compartit del proveïdor. El traductor del proveïdor és propietari de l’adreça pública i de la taula de mapatge, i no té cap motiu per crear un mapatge entrant permanent per a un sol abonat.

Una regla de reenviament de port al router de casa no pot configurar l’AFTR. La regla és real i correcta al dispositiu local, i no canvia res aigües amunt, i per això el símptoma sembla un problema de tallafocs que no marxa.

Aquí és també on la traducció de nivell d’operador es diferencia d’una única adreça pública: fins i tot un reenviament local correcte pot acabar en una adreça que comparteixen molts abonats.

Diagnostiqueu abans de canviar el pla d’accés

Primer confirmeu el mode subministrat. La pila doble nativa, DS-Lite i una xarxa només IPv6 que fa servir un altre mecanisme de traducció són tres arranjaments diferents, i els noms comercials del proveïdor no sempre coincideixen amb el tècnic.

Després establiu quatre observacions per a una fallada de sortida. El client resol el nom d’amfitrió de la VPN a una destinació IPv4? Funciona la connectivitat IPv4 simple, en lloc d’una sol·licitud de navegador que potser ha usat IPv6 en silenci? Quin transport i quin port prova el client, i els registres del punt final veuen aquest intent? La fallada passa durant l’intercanvi inicial, després d’un període inactiu o només en transferències grans?

Aquestes quatre respostes apunten a filtratge, a temps d’espera de l’estat de traducció, a un punt final equivocat o al tractament de la mida del paquet. Cap d’elles no s’estableix veient DS-Lite a la pàgina del compte.

Llegiu els canvis del proveïdor amb atenció

Un canvi de compte pot coincidir amb una connexió que funciona mentre altera diverses propietats alhora. Anoteu quina propietat ha canviat, perquè un nom de paquet nou no és una explicació tècnica.

La instrucció d’activar la pila doble és ambigua fins que algú confirma què subministra realment el proveïdor. Tractar-la com un requisit universal per als clients VPN IPv4 converteix una suposició en política.

Si el requisit real és allotjament IPv4 entrant, parleu amb el proveïdor d’un arranjament entrant suportat, d’adreçament natiu o d’un altre disseny d’accés. Si el requisit és un portàtil que arriba a un servidor remot, pregunteu en canvi per aquest flux sortint exacte. Ordre de treball: anomeneu la direcció, confirmeu el mode subministrat, proveu IPv4 simple i un transport, i canvieu el pla d’accés només si la direcció realment ho requereix.