Yoran 7 janvier, 2013 - 03:48 ssh weechat mutt socks proxychains
Faire passer son trafic dans un tunnel SSH

Il y a un petit moment j'avais présenté une méthode pour envoyer des mails à travers un tunnel SSH. Après un an de bons et loyaux services, j'en arrive à vouloir étendre ce système bien pratique à un plus grand nombre de ports. Alors VPN ?

Ben non, encore ce bon vieux SSH mais utilisé d'une "nouvelle" manière.

Le besoin

Le besoin d'origine était de pouvoir, de mon portable et de n'importe où, envoyer un mail de manière sécurisée. J'avais à l'époque joué avec la capacité de redirection de ports de SSH. J'envoyais alors mon courrier sur le port 25 local et il était émis à travers un tunnel chiffré sur le port 25 de mon serveur de courrier.

Mais récemment, j'ai été amené à étendre cette logique à d'autres services. Étant obligé pendant un temps de passer par une connexion 3G, j'ai ainsi voulu appliquer le même principe à la réception de mail (IMAP) mais aussi au chat (bitlbee & IRC) et au web. En gros à tout mon trafic externe quoi.

Pour ceux qui se demanderait quel intérêt peut on avoir de s'enquiquiner de la sorte, une petite liste non exhaustive des raisons :

  • Déjà pour accéder à des services sur une machine distante que l'on ne souhaite pas ouvrir sur le net généralement par soucis de sécurité ET de simplicité. C'est typiquement le cas de mon service SMTP. Passer par un tunnel me permet d'envoyer du courrier comme si j'étais sur mon réseau local, de manière sûre et sans problématique de sécurité supplémentaire.
  • Ensuite, pour ne plus se soucier d'emprunter des connexions douteuses. En effet en mode "nomade", on est déjà content d'avoir un réseau, on ne va pas en plus faire le difficile. Et pourtant, entre la 3G d'un opérateur qui porte une couleur comme marque et qui pratique le DPI à ses heures perdues, la connexion d'un hôtel dont tout les routeurs ont admin/admin comme identifiant/mot de passe, la borne WIFI du voisin imprudent qui ne l'est peut-être pas, il vaut mieux être un minimum méfiant. Avoir son trafic ainsi chiffré est une véritable paix de l'esprit dans ce genre de situation.
  • Enfin simplement pour améliorer la qualité des connexions. On ne parle pas non plus de miracle, mais un tunnel SSH dispose de deux caractéristiques bien pratiques. D'abord il est possible d'activer la compression des données, ce qui dans certain cas est très significatif. Un fichier texte (ex. un mail) se comprime à 30% de son volume initial... Ensuite le tunnel dispose de mécanisme permettant de vérifier que la connexion est toujours viable et permet même de récupérer sa connexion en cas de coupure (pas trop longue).

Autant de raisons qui font du tunnel chiffré un précieux outil. Reste maintenant à voir comment généraliser la bidouille d'origine à tout le trafic sans pour autant passer par un VPN pur et dur ou par une avalanche de TUN/TAP/iptables.

SOCKS

SOCKS est un protocole qui permet (en simplifié) à une application cliente d'accéder aux ressources réseau d'une machine distante. Ainsi, au lieu d'accéder directement au net, l'application cliente va uniquement causer au service SOCKS qui lui va parler au net. Dans sa version 5 (RFC 1928) ce protocole permet outre la transmission TCP, la transmission UDP, l'authentification, la résolution des noms de domaine et la prise en charge d'IPv6.

Or il se trouve que dans sa grande générosité, SSH offre le protocole SOCKS V5. Une application cliente va ainsi pouvoir parler SOCKS dans un port ouvert par SSH pour cet usage, ce dernier va faire transiter les demandes par le tunnel SSH et ces dernières seront "exécutées" sur la machine distante.

Pour tester cela en 10 secondes, rien du plus simple. Il vous faut une machine distante accessible et bien évidemment connectée au net et un compte sur cette machine. Si tel est le cas, dans un terminal, lancez la commande suivante

gastonssh -nvNT -C -D 1080 gaston@mon_serveur_distant
...
debug1: Local connections to LOCALHOST:1080 forwarded to remote address SOCKS:0
...
debug1: Entering interactive session

Voilà c'est gagné. Vous avez maintenant un service local SOCKS sur le port 1080 prêt à discuter bout de net avec la machine distante.

On s'arrête un peu sur les arguments utilisés. -n indique juste qu'il n'y a aucune saisie clavier à attendre de notre part (dit autrement /dev/null redirigé sur stdin). -N pour signifier à SSH qu'il n'y a aucune commande à lancer, on ne cherche qu'à créer un tunnel pour le proxy SOCKS. Et pour enfoncer le clou, -T désactive toute allocation de pseudo terminal.

-D 1080, c'est la partie intéressante, on demande à SSH de créer un service SOCKS sur le port local 1080. À partir de là, toute requête faite sur le port 1080 de la machine locale, passera par le tunnel chiffré et sera exécutée sur la machine distante.

-C va quant à lui activer la compression du trafic et enfin -v est juste là pour rendre SSH plus bavard. Suivent enfin le nom d'utilisateur à utiliser pour la connexion et le nom de la machine distante.

Pour tester cela, prenez Iceweasel/Firefox et allez modifier les réglages dans Édition ⇨ Préférences ⇨ Avancées ⇨ Réseau ⇨ Réglages pour cocher Configuration manuelle du proxy. Dans le champs SOCKS host nous allons mettre localhost et 1080 dans le champ Port. Cochez SOCKS v5 puis validez. Il ne vous reste plus qu'à aller sur votre site préféré pour voir SSH jacasser dans son terminal, votre trafic passe maintenant par le tunnel SSH.

Petite note pour ceux qui comme moi sont amoureux de VIM et qui utilisent donc forcement le fantastique pentadactyl, il est possible d'activer/désactiver le proxy en ajoutant ceci à votre ~/.pentadactylrc

command! -nargs=1 proxy :set! network.proxy.type=<args>

Ceci fait, un coup de :restart et vous pouvez activer le proxy par :proxy 1 et le désactiver (et donc ne plus utiliser le tunnel) par :proxy 0.

Script de contrôle du tunnel

Tout ceci est bien sympa, reste à le rendre fonctionnel à travers un script qui pourra allumer, éteindre et vérifier l'état du tunnel. Dans la mesure où je suis un membre de la secte "moins je touche au système et plus j'en ai dans mon dossier ~, mieux je me porte, je crée ici un script qui sera exécutable sans droits particulier tout en fonctionnant de manière très similaire aux scripts présents en /etc/init.d :

#! /bin/bash

# nom du service
name=tunnel

# paramétres
port=1080
user=gaston
host=machine_distante

# PID et logs
pid_file=~/.local/var/run/$name
log_file=~/.local/var/logs/$name.log
mkdir -p $(dirname $pid_file) $(dirname $log_file)

# Arrêt du service
function stop {
  if [ -f $pid_file ] ; then
    echo -n "Arrêt de $name..."
    kill -9 $(cat $pid_file)
    rm $pid_file
    echo "OK"
  fi
}

# Démarrage du service
function start {
  stop
  echo -n "Démarrage de $name..."
  command="ssh -nvNT -C -D $port $user@$host"
  ($command &> $log_file) &
  echo $! > $pid_file
  until nc -zw30 localhost $port &> /dev/null ; do
    echo -n "."
    sleep 1
  done
  echo " OK"
}

# test
function check {
  if nc -zw30 localhost $port &> /dev/null ; then
    echo "actif"
    return 0
  else
    echo "inactif"
    return 1
  fi
}

# commandes
case $1 in
  "start")
    start ;;
  "stop")
    stop  ;;
  "check")
    check ; exit $? ;;
  *)
    echo "usage: $(basename $0) start|stop"
    exit 1
esac

Ce script fonctionne donc comme les scripts de démarrage de service système à la différence prés que le PID du processus SSH et ses logs sont stockés en local, sur mon compte, dans les dossiers ~/.local/var/logs et ~/.local/var/run/.

Le tunnel se lance par un tunnel start, s'arrête par un tunnel stop et son état peut être lu par un tunnel check. Cette dernier commande me permet d'afficher l'état du tunnel dans la barre d'info d'awesome ce qui est bien pratique.

Pour compléter le dispositif, vous pouvez configurer dans votre ~/.ssh/config un temps au bout duquel SSH devra vérifier si le tunnel est encore fonctionnel. Bien utile lorsque l'on passe par de la 3G.

Host *
  ServerAliveInterval 5
~/.ssh/config

Ouvrir le tunnel à la connexion

Il est possible de pousser un cran plus loin l'automatisation en lançant automatiquement le tunnel à la connexion et en le tuant à la déconnexion. En tout cas c'est possible avec l'excellentissime wicd. Pour ceux qui ne connaîtrait pas cet outil, c'est le gestionnaire de connexion le plus efficace pour qui construit un bureau minimaliste. Il permet de gérer les connexions filaires, les connexions USB/RNIS (modem 3G via android), et les connexions WIFI de manière fiable et robuste, à travers une interface en ligne de commande ou en ncurses (il y aussi une version graphique pour ceux que cela amuse).

Wicd autorise la mise en place de scripts exécutés avant et après la connexion et la déconnexion. Ces scripts ne sont malheureusement pas dans un dossier ~/.wicd ce qui est bien triste mais dans le dossier /etc/wicd/scripts. Il suffit donc de lancer le tunnel en ajoutant le code suivant dans /etc/wicd/scripts/postconnect/tunnel.sh

#! /bin/bash

sudo -u gaston /home/gaston/bin/tunnel start
/etc/wicd/scripts/postconnect/tunnel.sh

Le second script je vous laisse l'écrire, il se place dans /etc/wicd/scripts/postdisconnect/tunnel.sh.

À partir de là, il suffit de lancer wicd-ncurses, de se connecter et hop, le tunnel est actif.

Et les autres applications ?

La grande majorité des applications qui utilisent le net offrent un support pour SOCKS v5. Une page bien pratique pour savoir comment faire est le manuel de configuration des applications pour le réseau TOR.

Cependant pour toutes les autres applications qui ne savent pas utiliser un proxy SOCKS (au hasard mutt), il existe une solution magique : proxychains

Proxychains est un superbe utilitaire qui va servir de lanceur pour les applications réseau. Son fonctionnement consiste à intercepter les appels aux sockets pour les rediriger sur le serveur mandataire qui va bien. Cela fonctionne très bien pour la grande majorité des applications. Cela permet aussi d'utiliser le proxy sur des applications qui prennent en charge SOCKS mais pour lesquels nous n'avons envie de nous prendre la tête.

Proxychains est en standard dans les dépôts Debian (et sûrement dans celui d'autres distribs). Pour l'installer vous devez donc lancer un sudo aptitude install proxychains.

Lorsque c'est fait, prenez votre éditeur préféré et éditez ~/.proxychains/proxychains.conf :

strict_chain
quiet_mode
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
socks5   127.0.0.1 1080

L'option strict_chain indique que les proxys doivent être chaînés dans l'ordre de leur déclaration. En effet, l'outil est velu et ne porte pas ce drôle de nom pour des prunes. Il permet en effet de chaîner toute une série de proxys les uns aux autres. Mais dans notre cas seul un proxy sera déclaré, pas besoin donc d'aller plus loin.

quiet_mode demande gentiment à proxychains d'arrêter de jacasser dans stdout. Mine de rien sans cela c'est assez pénible. proxy_dns va quant à lui permettre de faire aussi passer les requêtes DNS dans le tuyau du proxy. C'est un peu plus long mais ainsi tout passe dans le tunnel sans écoute possible.

Je passe sur les quelques timeouts de bonne hygiène pour en venir à l'essentiel, la déclaration de la liste des proxy qui dans notre cas ne contiendra que socks5 127.0.0.1 1080, le service que nous avons créé plus haut.

Il ne reste maintenant plus qu'à lancer une commande nécessitant l'accès au réseau :

gastonproxychains wget -O - http://artisan.karma-lab.net

Et c'est tout. Comme vous le voyez, c'est plutôt simple d'usage et cela fonctionne sur à peu prés toutes les commandes (mutt, wget, telnet, etc). La seule application qui lui dit "crotte" jusqu'ici c'est weechat qui dispose de toute façon d'une très bonne prise en charge native de SOCKS.

Amélioration de la vérification du tunnel

Fort de notre connaissance de proxychains, nous pouvons améliorer le script d'ouverture du tunnel pour ne pas simplement dire actif lors d'un tunnel check mais de nous renvoyer plutôt la qualité du tunnel, ce qui est fort pratique.

Pour cela il nous suffit de modifier comme ceci

function check {
  if nc -zw30 localhost $port &> /dev/null ; then
    lattence=$(proxychains nmap -sP azuris.karma-lab.net|grep -Eo '[[:digit:]]+\.[[:digit:]]+s' | tr -d 's')
    echo $lattence
    return 0
  else
    echo "inactif"
    return 1
  fi
}

Le principe est d'utiliser la commande nmap pour aller faire un ping sur le serveur distant à travers le tunnel via proxychains. Une fois le ping reçu, nmap fournit la latence exprimée en secondes que l'on n'a plus qu'à grepper.

Conclusion

Une fois de plus SSH s'impose en outil incontournable. Comme je le disais plus haut, chez moi le tunnel SOCKS fait maintenant partie intégrante de mon "bureau", se lance tout seul dés lors qu'une connexion sur le net est ouverte. Et comme tout ceci ne repose que sur SSH et des scripts "userland", cela fonctionne de manière propre et homogène sur toutes mes machines sans configuration (mon dossier home étant synchronisé d'une machine à l'autre via unison).

Vos remarques et commentaires...

Anonymous, le 7 janvier, 2013 - 09:10

Salut,

Intéressant, mais c'est quand même beaucoup plus simple de mettre en place un VPN du style OpenVPN.

Yoran, le 7 janvier, 2013 - 12:02

Pour cette histoire d'OpenVPN. J'ai essayé, j'ai testé et mes conclusions sont les suivantes :

  1. C'est sûrement simple pour un adminsys, beaucoup moins pour moi et mon background de développeur. Mais même au delà, Ici tout tient en une seule commande SSH et un script qui m'a demandé en gros 10 minutes à coder. Après c'est juste du paramétrage basique pour les clients (proxychains est plus une chose rigolote mais finalement utilisée seulement pour mutt). Si je compare à ce qu'il faut pour mettre en place OpenVPN je pense que je reste gagnant (je me suis basé sur ce tuto http://www.hermann-uwe.de/blog/howto-using-openvpn-on-debian-gnu-linux)
  2. Je cherche autant à accéder à des ressources de mon LAN (ex. mail) qu'utiliser l'accès internet de mon LAN à travers un tube chiffré. Il est sûrement possible de répondre au second point avec OpenVPN mais moi et iptable, ça fait deux (et encore je suis gentil avec moi-même :-) Si encore je cherchais à accéder à des ressources type NAS. Mais là c'est juste des services type "telnet". Avec l'option SOCKS, je peux tant accéder à mes ressources LAN que chiffrer mes accès à internet, le tout de manière simple et directe.
  3. OpenVPN cela implique paramétrage et installation au niveau de mon serveur qui est une toute toute petite bestiole (ATOM). Il ne faut pas oublier qu'on est ici dans le cas de figure de l'auto-hébergement et d'un serveur domestique. Avec l'option Socks, j'utilise juste le démon SSH déjà présent et testé.
  4. L'installation d'iptables, la mise en place du forwarding, tout ça, sur le serveur, c'est sûrement simple pour quelqu'un qui maîtrise les réseaux mais moi j'ai toujours peur de faire une connerie (en faut, j'en ai déjà fait :-).
  5. là aussi il s'agit sûrement d'une lacune de connaissance de ma part, mais je n'ai jamais trouvé le moyen de spécifier à OpenVPN de fonctionner "par application". J'ai des applications qui ne nécessite pas de passer par un tunnel (ex. voip), d'autres oui (ex. mail), d'autres au besoin (ex. web). Avec l'option SOCKS je choisi précisément qui passe par le tunnel et qui ne passe pas.

Maintenant une fois de plus, je ne suis pas adminsys et les solutions type ssh me font clairement mon peur que ce genre d'outil :)

lord, le 7 janvier, 2013 - 09:54

Oui un openvpn est plus simple, sinon un mix entre les deux serait sshuttle qui permet de rediriger de manière transparente tout son traffic tcp en une commande. c'est à base de ssh et iptables avec un enrobage een python.

Yoran, le 7 janvier, 2013 - 12:41
@lord

merci pour le pointeur vers sshuttle. J'ai surtout apprécié l'explication du gars sur la page du site. Cela m'a fait comprendre ce qui déconnait en terme de perf avec une première tentative que j'avais faite avec SSH/PermitTunnel.

Sinon j'ai installé la bête et testé.

  1. Je note deux pré-requis qui s'ajoute à ceux de "ma" solution : le sudo de préférence sans mot de passe car sinon c'est une vraie galère, et la présence d'iptable. Ce n'est pas un drame non plus. En revanche rien n'est nécessaire côté serveur.
  2. Lorsque les pré-requis sont replis c'est vraiment ultra simple, ça marche juste tout seul. J'aime beaucoup le mode -vv qui donne plein d'info (paramétage iptable, tout ça).
  3. Tout ce que j'ai testé passe bien par le tunnel, y compris la VoIP. C'est clairement plus efficace que mon approche SOCKS.
  4. En revanche, comme pour OpenVPN, j'ai un problème de la souplesse "par application" car comme OpenVPN, SSHuttle fonctionne sur la couche réseau. C'est peut-être contournable, à creuser.
  5. Côté performances, c'est Wow... c'est super rapide, plus rapide que ma solution et même qu'OpenVPN. En gros j'ai un bon -40% sur la latence entre SSHUttle et SOCKS. Côté transfert, le gain est ~10%.

C'est donc en effet une très bonne solution. Le seul point "négatif" serait l'histoire du "par application". En même temps, cet aspect était nécessaire avec SOCKS car beaucoup d'applications ne savent pas faire avec ou sans SOCKS en fonction de sa dispo. Du coup dans mon approche le tunnel était toujours actif, que je sois ou pas en mobilité. Avec ta solution, il est plus logique de zapper l'aspect automatique et juste de lancer le tunnel lorsqu'on est en mobilité (ou mieux détecter une connexion en mode "mobilité" par exemple en pingant une ressource LAN.

Bref, merci beaucoup, je risque juste d'avoir à tout ré-écrire :-)

Chimrod, le 7 janvier, 2013 - 16:26

Quitte à modifier le ssh_config, pourquoi ne pas définir le tunel dedans ?

Host host.tld
User user
LocalForward 2525 127.0.0.1:25
[…]

Ainsi on ne s'occupe pas de savoir si le tunnel est déjà ouvert ou pas, c'est ssh qui l'ouvre automatiquement dès la connexion.

D'autre part, ça permet de centraliser tous les tunnels dans une seule config (très utile au boulot où j'ai besoin de mettre des tunnels différents selon les sites).

Après, ça ne retire pas les tests qui vont s'assurer que le tunnel n'est pas tombé…

Yoran, le 7 janvier, 2013 - 22:56

Ah bé tu vois je n'avais même pas noté que l'on pouvait configurer cela au sein de la conf du client ssh. C'est bon à savoir. Maintenant ce n'est pas forcement idéal dans mon cas car outre le tunnel, je peux avoir plusieurs connexion ssh vers un même serveur.

Giljåm, le 7 janvier, 2013 - 20:09

Bonjour,

Avez vous jeter un oeil sur ce type de solution: https://help.ubuntu.com/community/SSH_VPN . Je n'ai pas (encore) essayé mais ça à l'air assez élégant sur le papier, par contre je ne sais pas ce que cela donne au niveau performence.

Yoran, le 7 janvier, 2013 - 22:55

J'avais déjà jeté un oeil sur cet approche. Pas via ce projet mais en faisant la même chose à la main. Car il s'agit en réalité de la simple exploitation d'une possibilité offerte par ssh depuis sa version 4.3 : créer des pseudo-interfaces réseau (TUN) à chaque bout du tunnel. Et j'ai mis du temps à comprendre pourquoi ça marchait très bien sur mon LAN mais devenait un vrai désastre lorsque je passais sur de la 3G.

Une fois de plus, je ne suis pas spécialiste réseau. Mais de ce que j'ai pu comprendre, le problème de ce type d'approche est que tu encapsules un flux de paquets TCP dans un flux de paquets TCP. Ce qui pose un problème de performance. Pas à cause du coût en bande passante de l'encapsulation en elle-même, mais à cause d'un dérèglements induit dans la gestion des débits.

En effet, TCP est un protocole robuste qui adapte le débit des paquets à la qualité du chemin emprunté. L'émetteur envoie un segment TCP, et s'attend à un acquittement au bout d'un certain temps. S'il ne reçoit pas cet acquittement il va augmenter le "certain temps" et renvoyer le segment. Dit autrement, si le chemin est mauvais, le débit sera abaissé. Et la qualité de chemin est déterminé par taux de perte de segments. Au final cela doit s'équilibrer sans congestion ni rupture de sorte à ce que la connexion soit fiable et que l'on ait la garantie que chaque segment est bien reçu. Chaque segment contient une partie de la donnée à transmettre (la charge utile), dans notre cas, les données chiffrées de SSH.

Maintenant à ce que j'ai compris encore une fois, TUN est une pseudo interface qui fonctionne au niveau IP. Du coupe si tu places deux interfaces TUN à chaque bout du tunnel, la communication entre les deux interfaces sera là aussi par des segments TCP. Et c'est là que les ennuis commencent car pour cette couche haute, il n'y aura jamais de perte vu que la couche basse le garanti. Du coup la fréquence d'émission de segments toujours au maximum. Cela ne pose pas de soucis si la fréquence de la couche basse est aussi au max, dans un LAN par exemple, sans perte de paquets. Mais si la connexion de la couche basse se dégrade (typiquement pour la 3G), le temps de ré-émission va augmenter, le débit va baisser pour éviter la congestion du lien physique. Mais sur la couche haut, ça continuer à bombarder à haut débit et du coup provoquer une sorte de "congestion interne". Le débit constaté d'un bout à l'autre des deux interfaces TUN va s'effondrer bien en dessous de la qualité réelle du chemin.

C'est pour cela que tout les techniques de "poor man's vpn" qui se basent sur du TCP over TCP, est à éviter absolument dés lors que la connexion physique est mauvaise. C'est valable pour TUN/SSH, ça l'est aussi pour une plus ancienne technique PPP/SSH.

L'avantage de Socks, OpenVPN ou encore SSHuttle, c'est que la charge utile du tunnel SSH n'est pas un flux IP. C'est un flux de données "de base".

François, le 7 janvier, 2013 - 21:10

Salut,

Ne pas oublier de modifier dans about:config de firefox, le booléen
correspondant au DNS pour le proxy socks. Autrement, les requêtes DNS fuitent.

Yoran, le 7 janvier, 2013 - 23:02

Ah bé bravo firefox, à quoi cela sert du coup d'avoir une case à cocher Socks v5, c'est pour faire joli j'imagine...

En tout cas merci du tuyau, je vais mettre cela en note.

vlp, le 15 janvier, 2013 - 00:43

Hello,

Merci pour ce tuto !!

Tu px préciser pour les DNS ?

Merci beaucoup!

vlp

Anonymous, le 17 mai, 2013 - 15:16

Date de janvier mais,

Ton navigateur envoie une requête pour que les noms de domaines soient résolus, mais celle-ci ne passe par défaut pas par le proxy.
Donc par exemple, s'il y a filtrage DNS sur ton réseau, sans ajuster network.proxy.socks_remote_dns à true, ça ne passera pas à travers.

Ju, le 6 mars, 2013 - 12:45

Super les explications !

Quelques petites questions cependant, j'ai mon ordi (sous windows) et un serveur dédié chez ovh pour mes sites que je compte aussi utiliser pour le tunnel. Une fois le tunnel activé:

-Mon IP public sera celle de mon serveur ?
-Du coup aurais-je accès aux services de TV replay depuis l’étranger (via l'ip française de mon serveur) ?
-ça pourrait résoudre le bridage entre youtube et free ?
-y a moyen de faire genre un fichier batch ou autre sous windows pour pouvoir activer le tunnel simplement en exécutant le fichier ? (désolé mais j'suis un peu un handicapé du réseau, j'ai du mal ^^)

Ju, le 7 mars, 2013 - 09:45

Hop je m'auto répond ^^

1/ oui, j'ai maintenant l'IP dovh quand j'active le tunnel
2/ oui puisque IP d'un serveur français
3/ oui, j'arrive maintenant à lire des vidéo 1080p alors qu'avant même en 480p ça ramait
4/ oui, en creant un session avec Putty (ou Kitty dans mon cas) et en la démarrant directement via un raccourci sur le bureau

Par contre j'ai du coup une nouvelle question: Comment je peux faire pour passer par mon tunnel avec chaque ordi de mon réseau local, sans avoir à ouvrir Putty sur chaque ordi ?

IPC, le 13 juillet, 2013 - 19:18

tsocks est très bien comme proxy.:
1) ssh .... -D8080 -x -C -N -f
2) tsocks firefox
ou encore
tsocks chrome
tsocks qbittorent
....

Yoran, le 30 septembre, 2013 - 00:47

Yep mais quel est l'avantage par rapport à proxychains ?

Publier un nouveau commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
  • To highlight piece of code, just surround them with <code type="language"> Your code &tl;/code>>. Language can be java,c++,bash,etc... Everything Geshi support.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <div> <p> <br>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.

Plus d'informations sur les options de formatage

CAPTCHA
Cette question est là pour déterminer si vous êtes humain ou pas...