Connexion IPv6 seule, service IPv4 : laissez un proxy SOCKS faire le pont

Vous n'avez pas besoin d'une adresse de la famille de destination pour l'atteindre, tant que quelque chose sur le chemin accepte de relayer. L'application se connecte au proxy, et le proxy ouvre une seconde connexion vers la destination. Ce sont deux sockets avec des familles d'adresses indépendantes, et rien dans l'un ou l'autre protocole n'exige qu'elles correspondent. C'est du relais au niveau applicatif, pas un chemin IPv4 natif, et cette distinction décide de ce qui fonctionnera et de ce qui ne fonctionnera pas. Confondre les deux, c'est ainsi qu'un ordinateur portable finit décrit comme ayant une connectivité IPv4 alors que tout ce qu'il a est un proxy.

Deux sockets, deux familles d'adresses

Une requête SOCKS5 nomme la destination sous l'une de trois formes : une adresse v4 littérale, une adresse v6 littérale, ou un nom que le proxy doit résoudre. La requête décrit où le proxy doit se connecter, pas à quoi ressemble la connexion client-vers-proxy.

Lisez ces types d'adresse comme trois choix indépendants au sein d'un même message. Un proxy joignable en IPv6 peut ouvrir un socket de destination IPv4 dès qu'il dispose d'une sortie IPv4 fonctionnelle et que sa politique autorise la requête. La spécification SOCKS5 les définit sans aucune référence au transport du client.

Un exemple SSH contrôlé

Prenez un hôte SSH que vous êtes autorisé à utiliser, qui répond en IPv6 et peut lui-même atteindre un service HTTPS qui n'existe qu'en v4. Le transfert dynamique d'OpenSSH place un écouteur SOCKS local sur votre machine pendant que la session de connexion passe par v6.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

L'hôte et le compte ci-dessus sont des exemples, et la liaison loopback garde l'écouteur sur cet ordinateur. Ne la remplacez pas par une liaison générique pour qu'un bureau partage un proxy sans authentification. ExitOnForwardFailure=yes existe pour qu'un transfert échoué termine la session au lieu de laisser une commande silencieuse tourner en arrière-plan.

Une fois la session lancée, la requête ressemble à ceci :

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

La connexion loopback n'est pas un chemin Internet IPv4. Ce qui quitte votre machine est la session de connexion via v6, et c'est le côté distant qui ouvre le socket de destination. La forme socks5h délègue aussi la résolution de noms à ce côté, ce qui compte quand le client n'a pas sa propre voie de résolution IPv4.

Ce que la destination voit réellement

La destination voit l'adresse de sortie du relais. Aucune adresse appartenant à votre ordinateur portable n'y apparaît. Une liste d'autorisation de sources sur ce service doit nommer le relais. Ses journaux attribueront aussi le trafic au relais. Écrivez-le dans le registre des changements avant l'audit, car une liste d'autorisation construite autour d'adresses clientes échoue dès la première requête.

Le relais est aussi l'endroit où les deux moitiés de la conversation sont visibles, ce qui est une propriété utile lors du diagnostic et une charge si le relais est partagé sans politique.

Ce n'est ni DNS64 ni NAT64

DNS64 répond avec des enregistrements synthétisés qui remplacent les destinations v4, et NAT64 réécrit les paquets le long d'un chemin configuré. Ni l'un ni l'autre ne décrit ce qui se passe ici, où une conversation de transport se termine et une autre commence et aucune adresse synthétisée n'explique le résultat. Une requête réussie ne dit donc rien des services de traduction que votre fournisseur exploite, et le proxy peut exécuter un NAT ordinaire sur sa propre sortie.

L'un ou l'autre mécanisme peut exister dans le même réseau, alors décrivez celui que vous avez réellement vérifié plutôt que celui qui sonne le plus proche.

Connaître la portée avant de la promettre

Le transfert dynamique d'OpenSSH transporte des connexions TCP, pas du trafic IP arbitraire, donc UDP, ICMP et tout protocole qui ignore le proxy nécessitent une autre conception prise en charge. Conservez la vérification de la clé d'hôte SSH, les restrictions de transfert du serveur et la validation du certificat HTTPS, car le proxy est un participant de confiance supplémentaire, pas une raison d'affaiblir les contrôles d'identité. Si l'objectif est de faire passer le transport externe d'un VPN par le proxy, vérifiez que les deux extrémités prennent en charge ce transport au lieu de supposer qu'un écouteur SOCKS quelconque peut le relayer.

Rien de tout cela ne rend le client double pile, et rien de tout cela n'est nécessaire. Cela permet à une application d'atteindre un service via un relais, ce qui est une affirmation plus modeste et bien plus facile à vérifier.