|
|
|
|
En plus a ta liste
http:/http-tunnel.com sous windows mais payant. le tunnel sort de ton reseau derière ton firewall et va sur ta machine qui est sur le net c'est ça ? a mon avis tu dois configurer ta station linux pour accepter seulement ton ip a communiquer avec elle. plus faire un http-tunnel en ssl. pour la compression ? je vois pas bien ? Yota238 - www.e-reservoir.ch |
Je pense (mais c a confirmer) que l'authentification peut se faire sur la becane distante.
si g bien compris, ton tunnel aura une sortie sur chaque becane... logiquement seules ces deux becanes en question pourront l'utiliser.... donc ce que tu souhaite ce serait surtout qu'un indelicat n'ouvre pas un nouvo tunnel sur ton serveur... il "sufirait" (enfin je suppose) de n'authoriser les connexions sur un certain port qu'avec authentification... la question du "comment" reste cependant... si tu progresses ds tes recherhces, fait nous signe, c super interressant comme sujet .O (_)__... Castor |
Hello... merci pour vos réponses.
http://http-tunnel.com je connais, leur service gratuit me conviendrais très bien si les trames ne transitaient pas en clair sur le réseau local (pas glop avec NNTP : le mot de passe est en clair). Je ne peux pas filtrer par les IP: L'IP du client n'est pas fixe (proxy avec load balancer), et le serveur non plus (IP dynamique). Il me faut donc un filtrage avec mot de passe ou équivalent (fichier certificat ou autre). castor, en effet, c'est bien sur le serveur (celui qui est en dehors du firewall) que je veux pouvoir authentifier l'utilisateur (je veux pouvoir être le seul à utiliser le serveur tunnel installé sur ma machine). La version payante de HTTPort fait exactement ce que je veux, mais c'est payant, et pas donné. En fait, je veux pouvoir faire passer n'importe quel protocole à travers un proxy HTTP. Il faut absolument que ça soit chiffré (pour la compression, c'est optionnel ; pour l'authentification, elle n'est nécessaire que si je dois installer le serveur tunnel sur une machine à moi.) J'avais pensé utiliser Zebedee (chiffrement SSL+compression) avec une clé fixe (authentification), mais il ne résiste pas à des attaques de type replay. L'idéal serait: flux TCP <---> compression <---> authentification des paquets/du user <---> chiffrement <---> encapsulation HTTP Ainsi, on pourrait authentifier l'utilisateur sans être sensibles aux attaques replay (grâce à la négociation de nouvelles clé SSL à chaque 'connexion'). On pourrait bien sûr simplifier un peu en utilisant directement SSL sur le proxy (ce que fait HTTPort, sans la compression): flux TCP <---> compression <---> authentification des paquets/du user <---> encapsulation HTTPS. Je suis en train de me demander si je ne pourrais pas programmer ça moi-même - si j'en avais le temps :-( |
Alors Sebsauvage du nouveau? ;-) |
|
Même si la conversation est un peu ancienne, on ne sait pas si tu as trouvé en effet Seb :)
Et ca reste interressant En relisant je viens de penser à un truc: Faire un tunnel HTTP, puis a l'intérieur un tunnel SSH qui permetttrait donc chiffrement+authentification. En n'authorisant que le protocole SSH à traverser ton tunnel HTTP .Ô Messire Castor (_)__ Sans Kangourou ni Ragondin |