DS-Lite bloque l’hébergement IPv4 entrant, pas le VPN sortant

DS-Lite est un moyen de donner à un client une connectivité IPv4 sur un réseau d’accès qui ne transporte que de l’IPv6. La box n’a pas d’adresse IPv4 publique dédiée qui lui soit propre, et ce seul fait convainc les gens qu’un VPN IPv4 ne peut pas fonctionner depuis cette connexion. En sortie, cela fonctionne généralement bien. La connexion est traduite par le fournisseur, et l’extrémité distante voit un client IPv4 ordinaire. Ce qui casse, c’est la direction opposée : héberger quelque chose qui attend de l’IPv4 entrant non sollicité. La distinction tient à quel côté engage la conversation.

Quel côté ouvre la connexion

Un client qui initie une connexion crée de l’état de traduction au fur et à mesure. Le traducteur du fournisseur voit le premier paquet, alloue une correspondance et le transmet. Le trafic de retour correspond à cette correspondance parce que la correspondance existe déjà.

Un serveur qui attend des connexions n’a pas un tel état à créer. Quelqu’un à l’extérieur doit atteindre une adresse et un port que le fournisseur n’a pas accepté de mapper, et c’est une requête entièrement différente.

Suivez une requête sortante

L’architecture de la RFC 6333 nomme les deux extrémités. L’élément côté client est le B4, qui encapsule l’IPv4 dans de l’IPv6. L’élément côté fournisseur est l’AFTR, qui effectue la traduction d’adresse et transmet le paquet en IPv4.

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

Le serveur VPN reçoit une connexion IPv4 normale depuis l’adresse traduite du fournisseur. Il n’a besoin ni d’un mode DS-Lite, ni d’un port spécial, ni de savoir que le réseau d’accès du client est uniquement IPv6. C’est la partie que les gens manquent : l’extrémité distante ne peut pas le voir.

La configuration du client lui-même est tout aussi ordinaire. Il lui faut un chemin IPv4 fonctionnel vers le serveur, que le B4 et l’AFTR fournissent, et il lui faut que le nom d’hôte du serveur se résolve en une adresse IPv4.

Pourquoi l’hébergement entrant est le cas qui échoue

Faire tourner un serveur VPN IPv4 à la maison est le choix qui se heurte à l’adressage partagé du fournisseur. Le traducteur du fournisseur possède l’adresse publique et la table de correspondance, et il n’a aucune raison de créer une correspondance entrante permanente pour un seul abonné.

Une règle de redirection de port sur la box ne peut pas configurer l’AFTR. La règle est réelle et correcte sur l’appareil local, et elle ne change rien en amont, c’est pourquoi le symptôme ressemble à un problème de pare-feu qui ne disparaît pas.

C’est aussi là que la traduction d’opérateur diffère d’une adresse publique unique : même une redirection locale correcte peut atterrir sur une adresse que partagent de nombreux abonnés.

Diagnostiquez avant de changer l’offre d’accès

Confirmez d’abord le mode provisionné. Le double pile natif, DS-Lite et un réseau uniquement IPv6 utilisant un autre mécanisme de traduction sont trois dispositions différentes, et les noms commerciaux du fournisseur ne correspondent pas toujours au nom technique.

Établissez ensuite quatre observations pour une panne sortante. Le client résout-il le nom d’hôte du VPN vers une destination IPv4 ? La connectivité IPv4 simple fonctionne-t-elle, plutôt qu’une requête de navigateur qui a peut-être utilisé IPv6 sans le dire ? Quel transport et quel port le client tente-t-il, et les journaux du point de terminaison voient-ils cette tentative ? La panne survient-elle pendant l’échange initial, après une période d’inactivité, ou seulement sur les transferts plus gros ?

Ces quatre réponses pointent vers le filtrage, l’expiration de l’état de traduction, un mauvais point de terminaison ou la gestion de la taille des paquets. Aucune n’est établie en voyant DS-Lite sur la page du compte.

Lisez attentivement les changements du fournisseur

Un changement de compte peut coïncider avec une connexion qui fonctionne tout en modifiant plusieurs propriétés à la fois. Notez quelle propriété a changé, car un nouveau nom d’offre n’est pas une explication technique.

L’instruction d’activer le double pile reste ambiguë tant que personne n’a confirmé ce que le fournisseur provisionne réellement. La traiter comme une exigence universelle pour les clients VPN IPv4 transforme une supposition en politique.

Si l’exigence réelle est l’hébergement IPv4 entrant, discutez avec le fournisseur d’une disposition entrante prise en charge, d’un adressage natif ou d’une autre conception d’accès. Si l’exigence est un portable qui atteint un serveur distant, renseignez-vous plutôt sur ce flux sortant précis. Ordre du travail : nommer la direction, confirmer le mode provisionné, tester l’IPv4 simple et un transport, puis changer l’offre d’accès seulement si la direction l’exige vraiment.