Journal Accéder à son PC à la maison quand on est derrière un proxy

Posté par  .
Étiquettes :
3
20
juil.
2010
Cher journal,

Je t'écris pour partager mon expérience concernant les réglages de mon routeur fonctionnant sous DD-WRT au cas où ça puisse servir à quelqu'un.
Mon besoin de départ était de pouvoir accéder à mes PC à la maison depuis n'importe quel endroit et notamment au boulot derrière les différents pare-feu et proxy.
Je vais parler du DD-WRT mais cette config devrait sûrement être adaptable à d'autres systèmes.

1ère étape : config. d'un nom DNS pour passer outre l'adressage IP dynamique imposé par mon FAI (SFR).
J'ai ouvert un compte gratuit DynDNS que j'ai ensuite configuré sur mon dd-wrt dans Configuration->DDNS. Ainsi l'IP est mise à jour par le routeur.

2ème étape : activation de l'accès SSH sur le routeur.
Dans Administration->Services j'ai activé SSHd sur le port 443. Ce port me permet d'avoir un accès depuis mon boulot car il est forcément ouvert en sortie car utilisé par https. Bon l'inconvénient c'est qu'à priori je ne pourrai pas utiliser de SSL sur un serveur chez moi car dans ce cas il faudrait rediriger ce port 443 et donc il y aurait un conflit.
A ce stade, il est donc possible d'accéder à son routeur depuis l'extérieur en SSH, c'est déjà un bon début. J'utilise pour cela putty (PC sous Windows oblige) configuré avec le proxy du boulot (cf réglages du navigateur par exemple) et je me connecte avec le DNS attribué ci-dessus sur le port 443.

3ème étape : tunneling d'un port via SSH.
Toujours avec putty, je configure la connexion avec le forward d'un port dynamique (disons le port 6060) qui se traduirait par un ssh -D 8080 -p 443 user@dnsdemonserveur. Ainsi je vais pouvoir utiliser ce port pour me connecter via un tunnel ssh. Par exemple au boulot, si je souhaite accéder à un site avec firefox via mon tunnel et donc dans les mêmes conditions que si j'étais chez moi, je configure firefox en lui disant d'utiliser un proxy Socks (4 ou 5) sur l'hôte localhost et le port 6060. Ceci peut être aussi utile pour par exemple pidgin qui est bloqué par un proxy à mon boulot, mais qui configuré de la même façon va pouvoir fonctionner.

En espérant vous avoir donné des idées.

  • # Autres solutions

    Posté par  . Évalué à 5.

    ajaxterm : lent et ne gère pas l'utf8, mais simple à déployer et fonctionne dans un browser, donc sur virtuellement tous les clients du monde disposant d'un navigateur supportant le js (en théorie du moins en pratique, on a parfois des surprises).

    corkscrew : peut être utilisé avec d'autres services en 443 autant que je me souvienne. Nécessite juste un .ssh_config bien configuré.

    • [^] # Re: Autres solutions

      Posté par  . Évalué à 2.


      ~% cat .ssh/config2
      ProxyCommand corkscrew addresseproxyhttp portproxyhttp %h %p ~/.ssh/auth
      ~% cat .ssh/auth
      user:password


      Ma configuration de corkscrew, quand j'en ai besoin, je renomme .ssh/config2 en .ssh/config et ça marche :)
      Pensez à remplacer addresseproxyhttp et portproxyhtttp, ainsi que user et password dans le .ssh/auth.

      • [^] # Re: Autres solutions

        Posté par  . Évalué à 3.

        ~% cat .ssh/config
        #config spécifique pour chez moi
        host myhome.dyndns.com
        ProxyCommand corkscrew addresseproxyhttp portproxyhttp %h %p ~/.ssh/proxyauth
        user Myhomeuser
        port 443
        ServerAliveInterval 300
        #config general pour le reste
        host *
        ServerAliveInterval 300

        comme ça quand je me connecte chez moi je fait juste ssh myhome.dyndns.com et quand je me connecte a un serveur au boulot je fais ssh boulot sans changer de fichier de conf.

        (à noter que l'on doit pouvoir spécifier de créer un tunnel ssh directement dans le ficher de config (man ssh_config)

      • [^] # Re: Autres solutions

        Posté par  (site web personnel) . Évalué à 1.

        Pourquoi tu n'utilises pas une clef ssh à la place de ton fichier .ssh/auth ?

        • [^] # Re: Autres solutions

          Posté par  . Évalué à 3.

          Euh, on parle bien des identifiants du proxy HTTP là ?

          • [^] # Re: Autres solutions

            Posté par  (site web personnel) . Évalué à 1.

            Arf, désolé, je venais de me lever :). Et c'est là que je réalise qu'on ne peut pas se moinsser soit même...

            Transformons juste mon intervention précédente par : Et avec une clef ssh ça va encore plus vite pour se connecter :). Quoi que c'est pas tellement plus intéressant...

            Et sinon j'utilise très régulièrement le script vpn-pppssh que j'ai légèrement modifié pour être utilisable avec un openwrt. Ça marche très bien, je recommande. Ça permet de pouvoir avoir son ssh qui tourne sur le port 443 et pouvoir faire un vpn sans avoir à installer d'autres softs.
            Bien sûr ça marche qu'avec Linux mais c'est tout ce dont j'ai besoin.

            • [^] # Re: Autres solutions

              Posté par  (site web personnel) . Évalué à 3.

              Accessoirement, OpenSSH intègre déjà un mode VPN (-w)…

              • [^] # Re: Autres solutions

                Posté par  (site web personnel) . Évalué à 3.

                Sur mon wrt ce n'est pas OpenSSH qui tourne. Est-ce qu'il faut OpenSSH en serveur aussi ou l'avoir en client suffit ?

                J'aurais bien testé mais j'ai visiblement perdu la main sur le routeur et ya personne pour me le redémarrer... :D

              • [^] # Re: Autres solutions

                Posté par  . Évalué à 4.

                Bonjour,

                T'imagines pas à quel point ce que tu viens de dire me bouleverse... Je n'avais jamais fait attention à cette option et là je suis d'autant plus "frustré" qu'après une rapide recherche sur google cette option est disponible depuis la 4.3 semble-t-il donc au moins 2006...

                Et moi qui passait du temps à faire des tunnels sur plusieurs ports d'une même machine....

                Bon, je dis merci et je vais songer dès demain à revoir tous les "man" des commandes que j'utilise régulièrement, j'ai peut être loupé d'autres options tout aussi importantes !!!

    • [^] # Re: Autres solutions

      Posté par  . Évalué à 2.

      Une autre solution du même genre qu'Ajaxterm, c'est Guacamole, un client VNC en JavaScript/HTML5. Cela nécessite d'avoir un serveur Java qui fait le lien entre le protocole VNC et le navigateur web.

      http://guacamole.sourceforge.net/

      • [^] # Re: Autres solutions

        Posté par  (site web personnel) . Évalué à 4.

        C'est, comment dire… bourrin.

      • [^] # Re: Autres solutions

        Posté par  . Évalué à 2.

        sauf erreur de ma part, avec ce genre de solution on ne peut pas faire des tunnels/vpn qui partent dans toutes les directions (pour acceder à jabber, au site de p0rn interdit à la boite, etc...)

        • [^] # Re: Autres solutions

          Posté par  . Évalué à 1.

          Bah, tu peux toujours lancer un Firefox dans ton onglet Guacamole :-p

          Blague à part, en effet on peut pas faire de tunnel, mais ça a l'avantage de pouvoir être utilisé sur n'importe quel ordinateur, sans configuration.

  • # SSH + SSL, c'est possible avec SSLH

    Posté par  (site web personnel) . Évalué à 10.

    Bon l'inconvénient c'est qu'à priori je ne pourrai pas utiliser de SSL sur un serveur chez moi car dans ce cas il faudrait rediriger ce port 443 et donc il y aurait un conflit.

    Personnellement, j'utilise SSLH ( http://www.rutschle.net/tech/sslh.shtml ), pour contourner le problème.

    il s'agit d'un "wrapper", qui permet de switcher une connexion entrante sur un port (typiquement TCP/443), afin de la rediriger soit vers un serveur HTTPS (SSL), soit vers un serveur SSH.

    C'est du C, donc cela doit pouvoir se compiler, et s'exécuter directement sur on WRT. Après, il ne te reste qu'à le configurer, pour diriger les flux SSL et SSH vers les bons serveurs.

  • # sinon openvpn

    Posté par  (site web personnel) . Évalué à 3.

    En tcp sur 443.
    Il existe l'option port-share si tu veux partager le port 443 avec un serveur https.

  • # Foxyproxy

    Posté par  . Évalué à 2.

    C'est un addon pour Firefox qui permet de switcher rapidement d'un proxy à l'autre sans repasser par les paramètres de configuration : https://addons.mozilla.org/en-US/firefox/addon/2464/

    Très très pratique si tu vas en Chine un jour.

  • # Correction

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    [...] je configure la connexion avec le forward d'un port dynamique (disons le port 6060) qui se traduirait par un ssh -D 8080 -p 443 user@dnsdemonserveur.

    Si on forward le port 6060, alors la ligne de commande doit se traduire par ssh -D 6060 -p 443 user@dnsdemonserveur.

    mes 2 cents

    • [^] # Re: Correction

      Posté par  . Évalué à 1.

      C'est sûr que ça marchera beaucoup mieux comme ça.

  • # arf

    Posté par  . Évalué à 1.

    le soucis commence quand ce cher proxy bloque systématiquement tout ce qui passe ressemble à dyndns et ses congénaires.

    Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

    • [^] # Re: arf

      Posté par  . Évalué à 2.

      Il suffit de se faire envoyer par mail l'adresse IP de la maison en cas d'adresse dynamique (ou bêtement la noter en cas d'adresse statique).

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: arf

        Posté par  . Évalué à 1.

        J'ai essayé aussi, bloqué... mais je ne sais pas pourquoi. J'ai imaginé que soit :
        1- les plages d'adresses orange sont bloquées
        2- les requetes sortant directement par l'adresse IP (sans résolution de DNS) sont bloquées

        Dans les deux cas, rien à faire.

        Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

        • [^] # Re: arf

          Posté par  . Évalué à 3.

          2- les requetes sortant directement par l'adresse IP (sans résolution de DNS) sont bloquées

          Je doute vu que ça voudrait dire que les machines n'avaient pas de cache DNS, ce qui doit être légèrement ennuyant.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: arf

      Posté par  (site web personnel) . Évalué à 5.

      Lorsque j'étais chez une grande société de sopra-no ... il y avait
      - une liste noire qui coupait tous les dyndns etc.
      - une liste blanche comportait quelques regexpr bien planquées (genre *\.oracle\.*)
      - une liste gris (soumise à un quota)

      Il suffisait d'avoir son propre nom de domaine et d'y mettre un "monserver.oracle.mondomaine.com" et le tour était joué.

      Après y a encore plus bourrin (mais lent), le tunneling over dns.

      • [^] # Re: arf

        Posté par  (site web personnel) . Évalué à 2.

        J'avais vu une fois un article dans linux magasine à propos du tunneling over dns. Quelqu'un a de bons liens à ce sujet ?

  • # Encore une autre solution

    Posté par  . Évalué à 4.

    Xavier Claessens est en train de finir un plugin pour Telepathy nommé « ssh-contact » (anciennement telepathy-ssh).

    En pratique, il permet de faire du SSH à traver Jabber en passant par la connexion avec un contact local à la machine à atteindre (si j'ai bien compris). Donc si tu as deux comptes Jabber, tu peux utiliser cette méthode aussi. Plus de souci de routage.

    Plus d'infos sur http://blogs.gnome.org/xclaesse/2010/07/16/telepathy-ssh-ren(...) .

    Je trouve cette idée géniale, c'est une preuve des capacités d'extensibilité de XMPP et de Telepathy.

    Au passage, c'est dans Incoming, ça devrait donc entrer dans Debian sous peu.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Encore une autre solution

      Posté par  . Évalué à 1.

      hum si il y a juste le port 80 et 443 qui sortent, tu dois même pas pouvoir utiliser un client Jabber digne de te nom et devoir te rabattre sur un client web hébergé ailleurs... bof niveau confidentialité.

      • [^] # Re: Encore une autre solution

        Posté par  . Évalué à 2.

        Si par contre ton serveur jabber ecoute aussi sur le port 443 alors tu a deja gagné. Mais pour ca il faut être sur le bon serveur...

  • # dns

    Posté par  (site web personnel) . Évalué à 2.

    Comment faites-vous pour faire les requêtes DNs, c'est de l'UDP je crois, peut-on faire la résolution de nom à travers le proxy socks ?

    En général lorsqu'il y a un proxy il n'y a pas de serveur DNS puisque c'est le proxy qui fait la résolution, inutile de répondre aux requêtes DNS des crapwares qui n'utilisent pas le proxy !

    Il m'est arrivé plusieurs fois de faire des tunnels SSH à travers des proxys, mais j'ai toujours été limité par l'absence de résolution DNS, alors peut-être ai-je bêtement oublié quelque chose…


    Au passage cela rappelle que même en passant à travers un proxy, si le serveur DNS n'est pas dans le tunnel (je ne sais pas faire) ou bien un cache local, le flux d'information n'est certes pas visible, mais les requêtes de résolution le sont (même problème que TOR).

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: dns

      Posté par  . Évalué à 3.

      en géneral j'utilise le dns de la boite, ce qui est vrai casse la confidentialité.

      Dans les quelques cas où la boite bloquait certaines requêtes dns, firefox propose l'option network.proxy.socks_remote_dns, si tu utilise ton ssh pour faire socks, la résolution sera faites à l'autre bout du tunnel.

      Autre solution, dans ton resolv.conf tu précise localhost comme serveur de nom, et tu fais du port fowarding dans ton tunnel ssh (en configurant ton relay/serveur dns sur du tcp). Si ton dns ne fait pas tcp, la solution gruicky, cest de faire de l'udp port fowarding sur un port arbitraire (de tête, donc ca ne marche peut être pas out of the box, et si quelqu'un sait faire du fowarding udp directement via ssh, jsuis preneur)

      ssh -L4242:localhost:4242

      au bout du tunnel:

      mkfifo monfifo
      nc -l -p 4242 < monfifo | nc -u tondns 53 > monfifo

      sur ton poste
      mkfifo monfifo
      nc -l -u -p 53 < monfifo | nc localhost 4242 > monfifo

      • [^] # Re: dns

        Posté par  (site web personnel) . Évalué à 2.

        merci, les outils unix sont vraiment très pratiques :)

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: dns

          Posté par  . Évalué à 2.

          de rien
          et pour éviter de faire un tunnel udp dans ton tunnel ssh, tu peux installer au bout de ton tunnel maradns (petit serveur dns) ou pdnsd (cache dns), qui te serviront de relay dns, et qui peuvent écouter en tcp.

    • [^] # Re: dns

      Posté par  . Évalué à 1.

      Une fois le tunnel ssh configuré et firefox / moz configuré pour passer a travers, il y a une option dans firefox permettant de faire la résolution via le tunnel:

      URL: about:config
      rechercher: socks
      network.proxy.socks_remote_dns;true (à false par défaut)

      et voilà !

      • [^] # Re: dns

        Posté par  (site web personnel) . Évalué à 1.

        oui mais justement le fait d'utiliser un proxy socks c'est pour ne pas faire que de l'http ! (et j'utilise assez rarement firefox).

        ce commentaire est sous licence cc by 4 et précédentes

  • # Proxytunnel

    Posté par  . Évalué à 8.

    Dans certaines entreprises il n'y a carrément pas de routes ip vers internet. Dans ce cas tout passe par le proxy et c'est lui qui route http/https, et ouvrir un sshd sur le port 443 ne fonctionnera pas.

    C'est pour ça que dieu a inventé proxytunnel (http://proxytunnel.sourceforge.net/) : ça permet (entre autre) de faire du ssh over https (mais on doit aussi pouvoir faire du vpn over https). Résultat on a notre connexion ssh, et sur le réseau il ne passe que du https, donc on ne voit pas que c'est du ssh encapsulé.

    En plus proxytunnel ne tourne que côté client.

    La conf ssh:

    ProxyCommand proxytunnel -X ip_proxy_entreprise:port -r ip_serveur_perso:443 -d %h:%p -H "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)\n"


    À personnaliser avec le user-agent du navigateur habituel au boulot pour rendre définitivement méconnaissable les données qui transitent.


    Côté serveur il suffit d'avoir un proxy https quelconque qui redirige le trafic vers le démon ssh, et le tour est joué. Par exemple un serveur apache qui tourne déjà sur le port 443 fera très bien l'affaire (il faudra juste bien régler les permissions sur le mod_proxy pour ne pas faire open proxy).

    Au final les données passent par le proxy entreprise, puis le proxy sur le serveur personnel, puis vers le démon ssh.


    Un howto bien pratique, avec la config client openssh/putty et serveur apache :
    http://dag.wieers.com/howto/ssh-http-tunneling/


    Attention : pour que ça fonctionne avec apache il faut soit une version trunk, soit appliquer un patch (voir https://issues.apache.org/bugzilla/show_bug.cgi?id=29744 ).

    • [^] # Re: Proxytunnel

      Posté par  (site web personnel) . Évalué à 2.

      il y a une différence avec corkscrew cité plus haut ?

      • [^] # Re: Proxytunnel

        Posté par  . Évalué à 1.

        corkscrew n'a l'air de gérer qu'un seul proxy.
        Donc il envoie un connect server_perso:port_sshd au proxy de l'entreprise, et après il envoie les données ssh directement en clair au travers du proxy entreprise.

        La conséquence de tout ça c'est que le proxy entreprise voit qu'il ne relaie pas du https comme il devrait habituellement le faire. Ça peut donc être détecté/bloqué.

        proxytunnel permet de faire du vrai ssh over https: le contenu n'est pas distinguable d'un vrai flux https (sauf si on se met à faire des études statistiques sur le flux, là ça doit moins ressembler à du https, mais bon).

    • [^] # Re: Proxytunnel

      Posté par  (site web personnel) . Évalué à 1.

      proxy https quelconque

      une autre idée si on a pas envie d'avoir un apache bien lourd ?

      par exemple quelque chose de léger qui peut s'installer sur un openwrt ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.