OpenVPN via un proxy HTTP : lisez d’abord la réponse CONNECT

Pointez un client VPN vers un proxy HTTP d’entreprise, et le premier fait utile est que le proxy ne parle pas le protocole du VPN. Il ouvre une connexion TCP ordinaire vers l’adresse que vous avez indiquée, puis s’efface, laissant votre client et le serveur mener leur propre échange à travers ce flux. Tout ce dont le client a besoin, du type de transport à l’écouteur du serveur, doit correspondre à cet agencement. Deux incompatibilités expliquent la plupart des échecs : un profil UDP visant un proxy CONNECT, et une réponse du proxy prise pour une erreur du VPN.

Ce que le proxy transporte, et ce qu’il ne transporte pas

Le proxy n’est qu’un saut de transport. Il ne devient pas votre proxy de navigateur, il ne met pas en cache les sites que vous visitez par le tunnel, et il ne voit pas le trafic interne à moins que quelqu’un ait délibérément configuré une inspection. Le tunnel qu’il ouvre est opaque pour lui par conception.

Cela signifie aussi que le proxy ne peut pas réparer un serveur qui n’a pas d’écouteur correspondant. L’autorisation d’atteindre une destination et un service qui écoute sur cette destination sont deux faits distincts, et seul le premier relève de l’administrateur du proxy.

Le support doit être TCP aux deux extrémités

Un proxy CONNECT classique ne relaie qu’un flux d’octets , donc le client doit utiliser un transport de flux. Un fragment de client pour ce cas ressemble à ceci :

proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128

Le côté serveur a besoin d’un véritable écouteur TCP sur le port nommé dans la ligne remote. Remplacer proto udp par proto tcp-client dans un profil crée un client qui attend un flux ; cela ne crée pas le flux de l’autre côté. Si le même serveur répond aussi en UDP sur ce port, c’est un autre écouteur, pas un second mode du même.

Là où une instance TCP distincte existe, son périphérique de tunnel, son pool d’adresses et son routage sont des ressources propres. Copier une configuration qui fonctionne et modifier le mot de transport laisse ces ressources pointer vers l’instance d’origine, ce qui produit une connexion qui s’authentifie puis ne route rien.

Lisez la réponse du proxy avant le résultat du VPN

Le premier échange du client est une ligne de requête nommant l’hôte et le port de destination. La réponse à cette ligne vous dit si un flux d’octets existe du tout, et elle arrive avant que le moindre certificat ou identifiant ne soit vérifié :

CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194

Une réponse de classe 200 à CONNECT signifie que le flux existe. Elle ne dit rien sur la confiance accordée au certificat de la passerelle, sur la correspondance de la clé partagée ou sur la validité du compte utilisateur. Ces vérifications ont lieu ensuite, à l’intérieur du flux, et elles échouent avec les messages propres au client plutôt qu’avec une ligne d’état HTTP. Cherchez dans le journal du client le premier OpenVPN événement après la poignée de main avec le proxy, et non la dernière ligne avant la fermeture de la fenêtre.

Les identifiants du proxy et ceux du VPN sont souvent des identités différentes détenues par des équipes différentes. Un 407 n’est pas un mauvais mot de passe du compte VPN, et un certificat rejeté n’est pas un problème d’autorisation du proxy.

Ce que CONNECT n’expose pas

Un tunnel CONNECT explicite n’est pas une interception. Le proxy transmet des octets et ne termine pas la session TLS du VPN, donc la vérification du certificat du serveur par le client reste pertinente et devrait rester activée. Désactiver la vérification pour franchir un proxy résout un autre problème que le vôtre.

Il existe des dispositifs distincts où une organisation termine et inspecte TLS délibérément. Ceux-ci exigent leur propre configuration de confiance et leur propre décision de politique, et ils ne sont pas ce que demande une ligne http-proxy ordinaire.

Le coût de TCP dans TCP

Faire passer le tunnel sur TCP garde le flux extérieur ordonné et retransmis, et le trafic intérieur est généralement TCP lui aussi. Les deux mécanismes de récupération ne se coordonnent pas, si bien qu’un seul segment perdu peut bloquer tout ce qui partage ce flux extérieur jusqu’à sa retransmission. C’est un vrai compromis pour la compatibilité, pas une mise à niveau gratuite.

Utilisez le chemin par le proxy lorsque le réseau ne vous laisse aucune alternative, et préférez un chemin UDP direct là où la politique l’autorise. Dans tous les cas, après un changement, confirmez que le même proxy, la même destination et le même profil atteignent l’étape suivante ; un navigateur qui charge une page à cette adresse exerce un autre protocole et ne prouve rien sur le tunnel.