Proxy HTTP, tunnel SSH ou VPN : choisir la bonne couche

Demandez à trois ingénieurs comment atteindre un service interne et vous obtiendrez trois architectures : un proxy web, un tunnel SSH ou un VPN complet. Les trois peuvent mettre un service distant à portée, et les trois peuvent faire croire que le trafic vient d’ailleurs. Les différences apparaissent plus tard, quand le protocole utilisé n’est pas celui que l’outil choisi suppose. Une architecture qui passe une vérification rapide dans le navigateur échoue régulièrement sur l’application qui a motivé la demande.

Décidez à partir de deux faits : quels protocoles doivent traverser et qui peut résoudre les noms concernés. Tout le reste est affaire de préférence.

Un proxy ne déplace que ce qu’il comprend

Un proxy web analyse le protocole pour lequel il a été conçu. Le client lui remet une requête et il la remet plus loin, si bien qu’une application sans réglage de proxy ne participe pas du tout. Pour HTTPS, le client a besoin d’un canal opaque, que le proxy fournit via CONNECT plutôt qu’en lisant la requête.

Un transfert dynamique SSH ouvre un port local qui parle SOCKS, et ce port relaie un flux TCP vers n’importe quelle destination nommée par le client. Les protocoles bâtis sur TCP y fonctionnent généralement. UDP non, à moins qu’un outil n’ajoute explicitement la prise en charge. Un transfert local est encore plus étroit : un port local associé à un hôte et un port fixes, ce qui sert un seul service connu et rien de plus.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

Un VPN déplace des paquets. Tout ce que le client route dans le tunnel le traverse, UDP et ICMP compris, ce qui explique qu’il convienne à une exigence de réseau et non à une connexion unique.

Quelqu’un doit résoudre le nom

Quand le nom cible n’existe que dans le DNS du réseau distant, la machine qui fait la requête doit pouvoir voir cette zone. Un proxy web fait lui-même la requête, si bien qu’un nom interne fonctionne à travers lui même quand l’ordinateur portable ne peut pas du tout résoudre le nom. SOCKS peut se comporter de la même façon, mais seulement si le client transmet le nom au lieu de se connecter à une adresse qu’il a déjà résolue. Ce choix appartient au client, pas au serveur.

curl montre clairement la séparation : un indicateur transmet le nom d’hôte au proxy, un autre le résout d’abord localement. Avec une résolution locale, un nom purement interne échoue avant qu’aucun tunnel ne soit touché, et l’erreur accuse le proxy de ce qui était en réalité une décision DNS.

Un VPN prend la troisième voie en installant le résolveur privé et le domaine de recherche à côté des routes. C’est pratique, et cela fabrique une illusion familière : une route qui existe avec un résolveur qui ne répond pas ressemble exactement à un tunnel mort, alors même que les paquets atteignent l’autre côté.

Quand le réseau n’autorise qu’une seule sortie

Beaucoup de réseaux d’entreprise n’autorisent les connexions sortantes que par un proxy web authentifié. OpenVPN et SSH peuvent tous deux y être rendus fonctionnels, le premier en tunnelisant son propre transport à travers le proxy et le second au moyen d’une commande proxy qui lance un petit assistant CONNECT.

Les tunnels bâtis sur TCP survivent à cette contrainte, et un VPN fondé sur UDP non, ce qui explique un grand nombre de configurations qui marchent à la maison et échouent au bureau. Un second coût est facile à manquer : un tunnel TCP porté dans une connexion TCP proxifiée a désormais deux couches qui retransmettent, et en cas de perte ce couple se bloque d’une manière qu’aucune couche ne produit seule.

Enchaîner des intermédiaires est une autre question que choisir une couche. Ajouter un second proxy ou Tor change qui observe quoi, et la position dans la chaîne décide quel saut voit le texte chiffré.

L’ordre compte plus que le nombre de sauts. Un saut extérieur observe un flux chiffré tandis qu’un saut intérieur voit le texte en clair qu’il transporte, si bien qu’une chaîne n’est privée que comme son maillon le moins soigneux. Mélanger les protocoles d’un saut à l’autre n’améliore pas cela automatiquement. Cela rend surtout les modes de défaillance plus difficiles à raisonner.

Une adresse forgée ne fait pas partie des options

Fabriquer des paquets avec l’adresse source de quelqu’un d’autre n’aboutit à rien d’utile : les réponses voyagent vers le véritable propriétaire, et la plupart des réseaux écartent purement et simplement le trafic. Un intermédiaire est nécessaire précisément parce que la source ne peut pas être inventée, et c’est la justification honnête des trois architectures.

Cela borne aussi ce que chacune peut prétendre. Paraître provenir d’une adresse donnée est une question de savoir où cette adresse est légitimement attribuée et qui peut la router, non de savoir quel outil peut falsifier un en-tête. Si une architecture suppose le contraire, l’hypothèse échoue chez le premier fournisseur qui la filtre. Écrivez l’hypothèse pour que la défaillance soit reconnaissable quand elle survient.

Décidez par les protocoles et les noms

Prenez un proxy quand un seul client web a besoin d’un seul service web et dispose de réglages de proxy. Prenez un tunnel SSH quand une poignée de services TCP connus suffit et que l’accès SSH existe déjà. Prenez un VPN quand plusieurs applications, du trafic non TCP, un DNS privé ou un chemin réutilisable font partie de l’exigence.

Vérifiez ensuite avec le vrai client et le vrai nom. Charger une page via un proxy ne vous apprend rien sur UDP, et faire fonctionner un outil via SOCKS ne vous apprend rien sur le résolveur du système. Lisez quelle adresse locale le processus a liée et quel résolveur a répondu. C’est la différence entre un chemin qui fonctionne et un chemin qui a fonctionné une fois par hasard.