Bonsoir à tous !    
 
J'ai un petit casse tête à résoudre pour les pros ou les passionnés réseaux ! Pour ceux que ça intéresse prenez le temps de bien comprendre ce que j'explique, c'est assez technique ! J'ai déjà parlé de ça à quelques "admin" réseau, et ils n'ont pas bien compris ma requête et m'ont même pris pour un fou. Bon faut avouer que c'est pas évident à comprendre, mais je vais essayer d'être le plus clair possible, attention suivez bien c'est parti :
 
Je développe des systèmes électroniques embarqués communicants, qui fonctionnent sous linux embarqué. Ces systèmes sont installés sur le réseau local de mes clients, ou "des clients de mes clients".
Ces systèmes électroniques embarquent entre autres un serveur web, ainsi qu'un serveur ssh. Le serveur web c'est pour que le client puisse accéder à l'interface de configuration/supervision de l'appareil, et le serveur ssh c'est uniquement pour moi, pour me logguer depuis mon bureau sur les systèmes afin d'en effectuer la maintenance.
 
La contrainte principale qui implique la complexité qui va suivre, c'est donc que :
 
1) Le client doit pouvoir accéder à l'interface web du système depuis son réseau local.
2) Le client doit également pouvoir accéder à l'interface web du système depuis l'extérieur de son réseau, depuis Internet en fait (quand il est en déplacement par exemple).
3) Je dois pouvoir me logguer en SSH sur le système depuis l'extérieur de son réseau, donc depuis Internet (à partir de mon bureau par exemple).
 
Tout cela est normalement très simple :
 
- Pour le point 1, il suffit de configurer le serveur dhcp du réseau pour qu'il attribue toujours la même IP au système en fonction de son adresse mac. Il accède alors à l'interface web du système avec son navigateur en l'ouvrant directement sur l'ip, par exemple http://192.168.1.123. On peut également configurer le système électronique pour qu'il ait directement une IP fixe.
- Pour les points 2 et 3, ce n'est guère plus compliqué, il suffit de créer des règles de redirection NAT sur le routeur/modem qui gère l'accès internet du client. Ensuite soit l'IP publique du client est fixe et on accède à l'interface par exemple par http://ip.pu.bli.que:1234, ou l'IP publique n'est pas fixe et il suffit de mettre en place un système de dyndns dans mon système embarqué.
 
Seulement voilà, tout cela ne fonctionne très bien et n'est envisageable QUE si l'utilisateur du système électronique a les moyens de configurer le réseau de son entreprise à sa guise ! Et en fait, dans 99% des cas, ce n'est pas possible car :
 
- Personne ne s'y connaît en réseau et les explications que je donne ou qui sont décrites dans la notice c'est du chinois, du coup ça leur parait super compliqué et ne veulent pas aller plus loin
- Mon interlocuteur n'y connaît rien en réseau et fait passer les demandes de configuration réseau à l'administrateur réseau, qui a les compétences pour faire la configuration, mais ne veut pas les faire, soit par ce que ça le fait chier ou qu'il veut montrer que c'est lui le chef, soit parce qu'il est persuadé qu'ouvrir des ports depuis l'extérieur c'est horriblement dangereux car ça ouvre des failles de sécurités.
- Soit l'admin réseau n'est pas super compétent, veut bien jouer le jeu mais ne comprend pas trop ce qu'il fait ou ce que je lui demande, et là je passe des heures à essayer d'expliquer au téléphone. Du coup du côté des clients, on pense que le système que je fournis est une usine à gaz et que c'est beaucoup trop compliqué à utiliser.
- Soit la gestion réseau est sous traitée à une entreprise extérieure, et là je crois que c'est pire que tout, en général j'abandonne de suite....
 
Donc j'ai beaucoup réfléchi au problème, et j'ai trouvé une solution élégante, qui "fonctionnellement" est compliquée mais qui fait qu'au niveau de l'utilisation c'est totalement plug and play et transparent pour le client.
En fait, le souci principal c'est pour rentrer sur le réseau du client depuis l'extérieur. Par contre dans l'autre sens, sortir du réseau du client pour aller sur Internet c'est beaucoup plus facile !
Du coup je procède de la sorte, attention c'est là que ça se complique un peu    
 
Mes systèmes électroniques, à chaque mise sous tension et à chaque fois que le lien est rompu, ouvrent une connexion sortante vers un de mes serveurs quelque part sur internet, qui possède une IP fixe et un nom de domaine. Ce lien, ou cette "socket" si vous préférez, est donc continuellement ouvert et joue le rôle de "tunnel". D'ailleurs, la carte et le serveur s'échangent des petites données de temps en temps pour vérifier leur présence respective et garder le tunnel ouvert (car sinon au bout d'un certain temps d'inactivité, les routeurs et passerelles NAT coupent la socket pour libérer de la place dans la table de routage).
 
Ensuite, quand je veux atteindre un de mes systèmes électroniques, je passe par mon serveur, qui fait office de passerelle/point d'entrée, et redirige mes requêtes dans le bon tunnel, vers le système électronique qui se trouve à l'autre bout, chez le client.
Du coup pour le client c'est du vrai plug and play : il branche le système sur son réseau, dans 99% du temps il y a un serveur DHCP actif, du coup le système chope une IP, l'adresse de la passerelle, et peut se connecter sur internet et ouvrir son tunnel vers mon serveur. En fait, vous l'aurez compris, j'en ouvre 2, un tunnel pour le serveur HTTP (interface web de configuration/supervision), et un tunnel pour le serveur ssh (prise de main à distance pour la maintenance).
 
Pour ceux qui n'ont pas abandonné la lecture, je continue :
 
Pour mettre en place ce système de tunnel, en fait je n'ai rien fait de particulier, j'exploite juste des options pas forcément très connus de ssh, qui permettent de faire des redirections de ports distantes :
 
- J'ai mon serveur sur Internet avec IP fixe + nom de domaine sur lequel tourne un serveur ssh
- Le système électronique chez le client ouvre une première connexion sortante ssh avec le serveur, et demande au serveur de rediriger le port distant XXXXX vers le port local 80 (interface web). Et en parallèle le système ouvre une 2eme connexion sortante ssh vers le serveur, en lui demandant de rediriger le port distant YYYYY vers le port local 22 (prise de main à distance).
 
Du coup, pour accéder à l'interface web du système (depuis l'extérieur du réseau client mais même depuis l'intérieur), il suffit de saisir dans son navigateur http://mon_serveur.com:XXXXX
La requête http est alors faite sur le port XXXX de mon serveur, qui redirige alors les paquets vers le port 80 de mon système électronique en passant par le tunnel SSH ! Génial non !?    
 
Et moi pour prendre la main à distance en ssh sur mon système électronique, il me suffit d'ouvrir ma connexion ssh vers le port qui va bien sur le serveur, en faisant : ssh -p YYYYY root@mon_serveur_com
Même principe que ci dessus, le serveur va alors rediriger tous les paquets vers le port 22 de mon système électronique en passant par le tunnel SSH existant entre le système électronique et le serveur. C'est terriblement efficace.
 
Vous l'aurez compris, chaque système électronique que je fournis utilise des numéros de ports différents, ce qui permet d'accéder à tous mes systèmes en me connectant uniquement sur mon serveur mais en spécifiant le port en fonction du système que je veux joindre, par exemple :
ssh -p 12345 root@mon_serveur_com
ssh -p 12346 root@mon_serveur_com
ssh -p 12347 root@mon_serveur_com
ssh -p 12348 root@mon_serveur_com
etc...
 
Et pour le client, c'est tout pareil, il peut accéder à son ou ses systèmes en boormarquant simplement les url correspondantes (et permanentes) à chacun des systèmes :
http://mon_serveur_com:23456
http://mon_serveur_com:23457
http://mon_serveur_com:23458
http://mon_serveur_com:23459
etc...
 
Avec ce système je frise la perfection, je n'ai quasiment plus de souci, vu que du côté du client, en principe il n'a qu'à brancher le système sur son réseau, et il n'a même pas besoin de connaître l'IP qui a été attribuée au système, c'est moi qui lui donne directement le lien permanent permettant d'accéder au système (http://mon_serveur.com:XXXXX).
Mais ça ne fait que friser la perfection, j'ai encore des petits soucis malheureusement    
Et oui, il arrive (de plus en plus fréquemment malheureusement) que sur certain réseaux l'admin ait verrouillé tous les ports en sortie, en ne laissant ouverts que les ports strictement nécessaires : http, https, pop3, etc...
 
Du coup, mon système utilisant le port 22 pour se connecter en ssh vers mon serveur pour ouvrir le tunnel et lancer la redirection de port distante, ne peut pas se connecter et ouvrir le tunnel si le port 22 est verrouillé en sortie ! Pour résoudre ce problème, j'ai trouvé une astuce qui consiste à ne plus utiliser le port 22, mais le port 80 ou 443 qui sont habituellement forcément ouverts en sortie.
Mais du coup, l'autre souci c'est que le client ne peut pas utiliser le lien direct et permanent vers son système (http://mon_serveur.com:XXXXX) depuis l'intérieur de son réseau, puisque le port XXXXX est bloqué en sortie !!!!
 
Du coup j'ai une idée pour résoudre ce problème, mais je ne sais pas si c'est faisable : il faudrait que le lien direct permanent vers les systèmes installés chez les clients ne soient plus sous la forme http://mon_serveur.com:XXXXX, mais sous la forme :
 
http://systeme1.mon_serveur.com
http://systeme2.mon_serveur.com
http://systeme3.mon_serveur.com
http://systeme4.mon_serveur.com
etc...
 
Du coup ça passerait par le port 80 et le client aurait accès à l'interface du système. Mais techniquement, ça implique que sur mon serveur j'ai plusieurs virtual host (un par système en fait), mais que le serveur web du serveur ne réponde pas lui même à la requête, mais ne fasse que la rediriger vers localhost:XXXXX, de manière à ce que la requête puisse alors partir vers le bon système en passant par le bon tunnel ssh.
Ou alors de faire un peu comme un proxy, le client accède à son système par l'adresse http://systeme1.mon_serveur.com, et sur mon serveur, dans le virtual host correspondant, je charge en réalité la page demandée mais sur l'adresse localhost:XXXXX, puis je recopie la réponse faite par le système à l'autre bout du tunnel vers le navigateur du client.
 
Est-ce que vous pensez qu'un système comme ça soit envisageable, et comment je pourrai mettre ça en place sur mon serveur ?
 
Si vous m'avez lu jusqu'au bout et que vous ne vous êtes pas endormi : merci, bonne nuit, et bon week end à tous  

En gros, je dirais "oui" pour la plupart des trucs (la fin en fait avec des "noms" qui renvoient à un adressage), qui reviendrait à "refaire" le même système qui est utilisé par le service DynDNS pour les redirections gratuites.
 
Après c'est le début qui me pose soucis : en effet comme tu le soulignes tout dépendra de la configuration réseau chez le client.
Le plus simple étant plutôt de faire d'insérer un formulaire (papier) pour ce matériel dans le contrat de maintenance du matériel, que le client devra transmettre à qui de droit (avec une IP libre à fixer, le masque de sous-réseau, la passerelle par défaut). Si l'entreprise ne connaît pas son propre réseau, proposes-leur de voir directement sur place en leur expliquant
 
S'il ne le fait pas, ben ce n'est pas à toi de te débrouiller à faire la chasse au réseau sauf si tu veux t'enquiquiner  
 
Pour l'histoire des ports à ouvrir, là il te faudra voir avec le client qui devra se débrouiller aussi pour le faire, en indiquant la finalité de chaque port ouvert, ainsi que le niveau de sécurité mis en place.

J'ai eu le même problème que toi.
Ma solution : OpenVPN sur port 443. OpenVPN accepte de multiple connexions sur le même port (donc tu peut avoir 1 serveur qui écoute sur le port 443 et de multiple clients qui se connectent sur ce port). De plus, pour passer à travers le firewall d'entreprise, il n'y a pas mieux, tu peut même passer à travers un proxy http si tu as envie (et si le proxy filtre les user-agents, tu peut aussi en spécifier un valide). C'est aussi assez facile à mettre en place.
 
Les inconvénients: Il faut bien sécuriser le tout (il ne faut pas que les clients puissent se voir entre eux) et dans certaines grosse boîtes, ça ne plait pas du tout (Hien, comment vous avez fait pour casser notre part-feu? Désactivez moi ça tout de suite...   ) et le terme VPN fait plus peur que "Socket SSH".
 
Enfin, çela fait quelque années que j'utilise ça (parfois j'utilise même le VPN pour avoir une connexion ouverte au net depuis le système embarqué - pour de la VoIP par exemple) et cela me convient parfaitement...
 
Par curiosité, quelle genre de matériel (embarqué) utilises-tu et qu'en fais-tu?

bardiel : le but c'est qu'il n'y ait rien à faire chez le client, même quand tout est bien expliqué, c'est un cirque pas possible pour les différentes raisons que j'ai expliquées !!
 
JinKazama : le vpn ok, mais comment le client accède à l'interface web du système ! Il est évidemment pas question que je lui fasse installer un client vpn sur ses machines, dans la plupart des cas ils n'y connaissent strictement rien, ils ne savent même pas ce que c'est qu'une adresse IP !!

J'en ai plusieurs, mais celui qui me pose le plus de problème c'est celui qu'utilisent des clients qui n'y connaissent que dalle en réseau : c'est un appareil spécial qui contrôle des électrolyses dans le cadre de la restauration de patrimoine sous marin métalliques : canons, ancres, etc...
C'est de l'électronique maison avec un processeur ARM 200Mhz, 64Mo de SDRAM et 512Mo de flash, plus tous les périphériques qui vont autour.

mod_proxy en reverse ne pourrait pas faire l'affaire ?
(pas pour le SSH cependant...)

D'après http://httpd.apache.org/docs/2.0/mod/mod_proxy.html :
 

A première vue, ça me semble plutôt pas mal, c'est bien ce dont j'ai besoin : apache reçoit une requête mais ne la traite pas lui même, il la renvoit ailleurs, et retourne la réponse en faisant simplement l'intermédiaire.
Par contre, moi dans mon besoin chaque virtual host apache doit donc transférer la requête sur une URL différente, en l'occurence http://locahost:XXXXX, les XXXXX étant le numéro du port.
Du coup il faudrait que mod_proxy puisse avoir une config différente pour chaque virtual host, serait-ce possible ? Peut être avec un fichier .htaccess ?
 
Je vais aller lire la doc pour en savoir plus sur mod_proxy !

Pour le ssh c'est pas génant, c'est uniquement moi qui me loggue en ssh et moi mes ports ne sont pas verrouillés en sortie au bureau, le ssh -p XXXXX root@mon_serveur.com marche à merveille.

BMenez : bon ça sent bon tout ça !!
 
D'après la page http://www.apachefrance.com/Manuel [...] proxy.html
 
Je dois utiliser l'option proxyRemote à priori (l'option ProxyPass ne semble pas gérer des urls avec un numéro de port derrière).
Ces options semblent pouvoir être définies pour chaque Virual Host, donc c'est justement ce dont j'ai besoin !!
La config pour un virtual host serait simplement un truc du style:
 
ProxyRemote * http://localhost:XXXXX
 
Apache devrait donc rediriger la requête vers la même machine mais sur un n° de port différent, ce qui fait que la requête devrait partir dans le tunnel SSH vers le système embarqué chez le client.
 
Je crois que je vais pas pouvoir attendre demain, je vais tester de suite !!
 

a

C'est trop fort, ça marche !!
 
C'est tout con à mettre en place, et ça va méchamment me simplifier la vie !
Il faut activer les modules proxy et proxy_http :
 

Ensuite édition du fichier de config /etc/apache2/mods-available/proxy.conf pour autoriser le reverse proxy à tout le monde :
 
       

Et ensuite il y a juste à configurer le bon paramètre dans chaque Virtual host :
 

Ce qui est bien c'est que je n'ai pas besoin de DocumentRoot, du coup ça encombre pas le dossier /var/www !
 
Apache renvoie toute les requêtes qui accèdent à partir de la racine vers la même machine mais vers le port qui va bien, donc ça redirige dans le tunnel SSH vers mon système distant chez le client !
 
C'est tout simplement énorme !!
 
Je n'aurai plus besoin de passer des heures à réexpliquer sans arrêt les mêmes choses aux admins réseau qui veulent que tous les ports soient fermés en entrée mais également en sortie !
Et les utilisateurs de mes systèmes n'auront plus à se prendre la tête, c'est du plug and play quasiment pur dans la majorité des configurations réseaux :
- si un serveur dhcp est dispo sur le réseau
- si le port 80 est ouvert en direct vers le net
 
Du coup je récapitule :
 
- Le système est branché dans le réseau, il se chope une IP (qu'on a même pas besoin de connaître) et l'adresse de la passerelle Internet
- Il ouvre une connexion SSH vers mon serveur en passant par le port 80, en demandant une redirection distante du port 12345 par exemple vers le port 80 local
- Il ouvre une connexion SSH vers mon serveur en passant par le port 80, en demandant une redirection distante du port 54321 par exemple vers le port 22 local
 
- Pour me logguer en SSH sur mon système j'ai juste à faire un ssh -p 54321 root@mon_serveur.com
- Et pour l'accès à l'interface web, que le client soit dans son réseau local ou en déplacement hors de son réseau, il a juste à aller sur http://nom_du_système.mon_serveur.com
- Sur mon serveur l'hote virtuel "nom_du_système" contient le paramètre ProxyPass / http://localhost:12345/
 
Avec ça maintenant la perfection que je recherchais est atteinte
 
Il y a juste 3 cas qui posent problèmes, mais là je ne pourrai pas passer outre, il faudra passer par la case admin réseau :
- Pas de serveur dhcp sur le serveur : l'utilisateur ou l'admin réseau devra configurer le système pour lui indiquer les paramètres réseau, IP et passerelle
- Serveur dhcp en place mais obligation que l'adresse mac soit reconnue : l'utilisateur devra demander à l'admin réseau qu'il configure le serveur dhcp
- Le port 80 n'est pas ouvert directement et l'accès web se fait à travers un proxy : le système ne pourra pas ouvrir son tunnel ssh, il faudra absolument que l'admin réseau configure le routeur firewall pour que le système puisse accéder en direct au net par le port 80.
 
L'autre problème qui se pose, c'est si un admin se pose la question de savoir comment il arrive à accéder à l'interface web du système qui est sur le réseau local en allant sur une adresse extérieure....
Ou comment j'arrive à me logguer dessus pour la maintenance alors que dans sa config tout est fermé en entrée comme en sortie
Là je crois que ça sera compliqué à lui expliquer

Salut, tu devrais aussi ajouter la directive ProxyPassReverse. Dans ton exemple :  

elle sert à quoi cette directive ?

Ah ok je crois que je vois l'utilité, c'est pour que Apache convertisse les liens des pages provenant du serveur backend pour que le navigateur du client passe toujours bien par l'url d'origine.
Effectivement c'est une bonne idée. Je n'ai pas constaté de problème dans mon cas car tous mes liens sont relatifs dans mon système installé chez le client, mais je vais quand même rajouter l'option !

Question un peu annexe, il est sécurisé comment ton système ? S'il venait a l'idée d'une personne de taper sur un port au hasard de ton serveur, il pourrait pas tomber sur un équipement chez un de tes clients ?

Si on fait un scan sur mon serveur sur la plage complète de port, en effet les ports qui servent pour faire les redirections http/ssh vers mes systèmes chez les clients seront vus comme ouverts. Du coup c'est comme si on essayait d'accéder directement aux systèmes chez les clients en fin de compte. Mais sur l'interface web il faut se logguer avant de pouvoir faire quoi que ce soit, et au niveau ssh, on peut se connecter qu'avec un seul nom d'utilisateur, le mot de passe est très compliqué et il n'y a que moi qui le connaît. Donc à moins d'une faille à priori personne ne peut accéder aux systèmes.
 
Et à la limite, les systèmes étant des systèmes embarqués, si quelqu'un arrive à pénétrer dedans, il ne pourra pas faire grand chose d'intéressant !
 

Vu que tu passes par ton reverse proxy, tu devrais en profiter pour sécuriser un peu le truc alors, genre restreindre les ports ouverts sur localhost, et de l'authent http au passage.
 
Ca limiterait un peu les risques et ca éviterait que tes systèmes embarqués puissent par exemple se faire flooder.

Effectivement le flood pourrait être problématique.
 
Mais du coup j'ai la solution, vu que maintenant le reverse proxy fonctionne et que le client et moi même pouvons accéder aux interfaces web des systèmes en se connectant au port http normal de mon serveur, je peux configurer le serveur ssh pour que les redirections de port ne soient visibles que depuis localhost. Du coup un scan de port sur toute la plage ne révélera que les ports http et ssh ouverts (et encore sur un n° de port non conventionnel pour ssh...).
 
Ca devient très sécurisé car :
 
- Pour accéder aux interfaces web des systèmes il faut connaître le nom de domaine exact correspondant aux virtual host
- Pour prendre la main en ssh sur les systèmes, il faut d'abord que je me loggue sur mon serveur, puis que je me loggue ensuite sur les systèmes avec la commande ssh -p XXXXX root@localhost (puisque le port XXXXX ne sera plus ouvert depuis l'extérieur).
 
Ca me plait bien tout ça !!