Je cherche un logiciel "X" capable :
- d'ouvrir un tunnel TLS vers un site distant
- de relayer des requêtes HTTP de clients locaux, vers ce site distant, et de relayer les réponses.
- de maintenir le tunnel TLS ouvert et d'y enfiler toutes les requêtes HTTP (les requêtes-réponses les unes après les autres, sur la même socket donc)
- de fonctionner en mode "daemon" : il se met en attente, et les requêtes des clients arrivent au fil de l'eau
Un petit schéma pour illustrer :
Notes :
client-1 client-2 .... client-N
| | |
| | |
V v V
+-----------------------------------------+
| le logiciel X que je cherche |
+-----------------------------------------+
|
| tunnel TLS
|
V
example.com
- les clients sont typiquement des process type cURL, qui effectuent une seule requête.
- les clients sont sur le même PC linux que X.
- les flèches indiquent le sens d'établissement des connections.
Le but est de gagner en performance, en évitant que chacun des clients ouvre son propre tunnel TLS le temps d'une requête.
cURL peut enfiler plusieurs requêtes dans un même tunnel TLS, mais pas en mode daemon.
# openssh?
Posté par freem . Évalué à 3.
openssh devrait faire l'affaire, avec un tunnel.
Et si jamais tu dois, comme moi au taf, te connecter depuis un réseau GPRS dont tu n'as pas la maîtrise, rien n'empêche d'utiliser openssh-client pour faire un tunnel inversé.
Vu que, au taf, j'ai un nombre indéfini et grossissant de systèmes qui se connectent en GPRS, j'ai même pris le parti d'établir un tunnel entre le système distant et un socket sur un serveur. Pour accéder au système distant depuis un autre système distant il faut donc établir un tunnel vers ce socket, en étant connu du serveur, et connaître le nom du fichier qui est, du coup, un peu plus parlant qu'un numéro de port.
[^] # Re: openssh?
Posté par goeb . Évalué à 1.
Oui, openssl s_client permet d'établir le tunnel, accessible via le stdin et stdout de s_client.
Mais ensuite, comment se connecter sur le stdin/stdout de s_client à partir de plusieurs process curl distincts ?
[^] # Re: openssh?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3. Dernière modification le 30 septembre 2018 à 23:15.
l'option -D d'openssh ?
[^] # Re: openssh?
Posté par B r u n o (site web personnel) . Évalué à 1.
Quand j'ai eu besoin d'utiliser des tunnels pour sortir d'un réseau, j'ouvrais le tunnel (
ssh -2NfCT -D 8080 user@example.org
voir leman
pour la signification des différents paramètres) puis j'utilisais localhost:8080 comme proxy socks.Et il semble que curl accepte d'utiliser un proxy socks : "
curl -x socks5h://localhost:8080 …
"[^] # Re: openssh?
Posté par Marc Quinton . Évalué à 2.
socat ? http://heapspray.net/post/using-socat-to-proxy-ssl-connections/
[^] # Re: openssh?
Posté par Cyril Brulebois (site web personnel) . Évalué à 2. Dernière modification le 30 septembre 2018 à 18:56.
Effectivement, j'ai déjà utilisé
socat
avec succès dans ce genre de contexte. Voir aussi l'optionfork
, qui peut être utile (mais faire attention, OpenSSL est géré de manière spécifique). Bref, une lecture de page de manuel s'impose. ;)Debian Consultant @ DEBAMAX
[^] # Re: openssh?
Posté par goeb . Évalué à 2.
Non, cette commande socat ferme le tunnel TLS dès que le client cURL se termine. Le client cURL suivant déclenche un nouvel établissement de TLS. On le voit avec le options socat -d -d.
[^] # Re: openssh?
Posté par goeb . Évalué à 1.
Mais openssh, il ne fait pas le protocole TLS, il me semble. Il fait SSH seulement.
# stunnel ?
Posté par Sclarckone . Évalué à 2.
Jamais utilisé mais ça a l'air de ressembler à ce que tu cherches : https://www.stunnel.org/index.html
[^] # Re: stunnel ?
Posté par Kerro . Évalué à 2.
Je l'utilise parfois pour un besoin précis. Ça fait ce qui est demandé ici, et ça fait le job sans faillir.
# un proxy
Posté par NeoX . Évalué à 2.
le but d'un proxy, c'est justement que les clients demandent au proxy, qui demande au site distant.
dans ton cas, le probleme c'est qu'il faut reecrire les requetes
car j'imagine que tes scripts clients vont demander http://leserveur.domain.tld
et que tu veux que le proxy aille sur https://leserveur.domain.tld
[^] # Re: un proxy
Posté par Kerro . Évalué à 2.
Probablement pas, car il exige que le tunnel reste établi.
[^] # Re: un proxy
Posté par NeoX . Évalué à 2.
si le poste utilisateur requete
http://leserveur.domain.tld/lechemin/lefichier
le proxy doit reecrire pour passer dans le tunnel et demander https://…
maintenant si le tunnel doit etre transparent, c'est peut-etre plus vers un VPN qu'il faut aller, non ?
[^] # Re: un proxy
Posté par Kerro . Évalué à 2. Dernière modification le 09 octobre 2018 à 00:34.
C'est ce que j'ai pensé également, mais il indique vouloir un tunnel.
Bon après sans explications de pourquoi un tunnel, et pourquoi pas de reconnexion, ça ne va pas être facile :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.