Bonjour,
 
Un petit exercice :
 
Je dispose d'un PC sous linux (la distribution n'a pas d'importance) appelons le PC1, derrière un routeur (non configurable) connecté à internet.
 
PC1 peut donc ouvrir une connexion vers l'extérieur (internet), mais ne peut pas recevoir de connexion depuis l'extérieur (le routeur ne redirigeant pas de port vers PC1).

Comment puis-je ouvrir ouvrir une connexion depuis PC1, afin d'avoir un port d'entrée pour un vnc, ftp, ssh, apache... ?
 
Je dispose d'un serveur (configurable lui) sur internet si besoin pour maintenir ladite connexion par exemple et pour forwarder un (des) port(s) éventuellement.
 
Merci d'avance.
 

Tunnel SSH .....

man ssh

euh il faut que le 22 soit ouvert aussi

Nan il suffit uniquement qu'il puisse sortir....
SSH la hantise des FW

ooh

 
pourquoi tu veux faire ça ? Ya pas moyen de voir avec le responsable du routeur ?

Non, c'est le routeur d'une résidence étudiante, donc pas de moficitation possible...
 
Oui, j'ai vu qu'il faudrait utiliser ssh. Mais ça ne fonctionne pas tout à fait comme je le souhaite :
 
Sur le serveur local (PC1, à atteindre) :

Sur un serveur distant (PC2, qui fait l'autre bout du tunnel) :

Là ça marche.
 
Mais si j'essaie depuis un PC quelconque (PCx) :

 
 
Là je peux donc accéder à PC1, mais uniquement depuis PC2 en localhost...

Tu as un message d'erreur quand depuis PC1 tu prépares le reverse tunnel (en faisant un ssh -R vers ton futur point d'accès, un PCx quelconque) ?

1. Si le responsable du réseau refuse des modifications de ce type, c'est qu'il y a une raison : sécurité, fiabilité du réseau.

• sécurité : En laissant des connexions extérieures entrées dans le réseau, tu remets en cause l'intégrité de ce réseau même. Si ton PC est compromis, le réseau entier peut etre compromis. La meilleure solution pour le compromettre c'est d'autoriser des connexions externes à rentrer. C'est pour cette raison que par défaut on refuse tout les flux entrant. Typiquement on n'autorise un tel trafic dans les DMZ, mais pas dans les réseaux communs !!

• fiabilité : de même si l'équipe ou le responsable du réseau n'a pas la maîtrise entière de ce réseau, il risque de partir en couille. Si tout le monde fait comme toi ca va etre le boxon, le réseau va devenir une passoire et sa qualité va etre médiocre (dans ce cas la je suis sûr que tu seras l'un des premier à critiquer).

2. Merci de préciser quelle sont réellement tes intentions, quel type de flux précisément désires tu réellement faire entrer.

Non non, aucun message d'erreur.
A priori ce qu'il reste à faire, c'est d'ouvrir le port du PC2 à l'extérieur car il n'écoute qu'en local :

Je suis tout à fait d'accord avec toi.
 
Cependant créer un tunnel n'ouvre un port que sur mon PC. Donc niveau sécurité, n'ayant aucun accès aux autres PC du réseau, tout ce que je risque c'est de me faire "pirater" mon PC.
 
Par rapport aux flux que je compte faire entrer c'est simplement des consoles ssh, éventuellement du VNC, peut-être quelques pages web... L'objectif est d'avoir accès à mon PC quand je ne suis pas chez moi. Rien du genre Emule, Bittorent ou autre

 
Ca ça doit être parce que de base tu n'arrives pas à atteindre le port 20000 de PC2, ou parce que le socket est configuré sur 127.0.0.1 au lieu de 0.0.0.0.
 
Et avec un
ssh PC2 -L2222:127.0.0.1:20000
combiné à un
ssh 127.0.0.1 -p2222 ?
 

Et indirectement de donner à accès à tout le réseau puisque ton PC est connecté à ce réseau.
 

 
C'est surtout que l'administrateur ne va s'amuser à configurer son firewall à la demande des besoins de chaque utilisateur, pour des raisons autant pratique que sécuritaire. Un port ouvert sur le firewall wan c'est beaucoup plus risqué qu'un port ouvert derrière le firewall à travers un tunnel. Personnellement, en tant qu'administrateur, je préfèrerai que les utilisateurs procèdent de la sorte plutôt que de gérer le port sur le firewall wan.
 
Et puis si c'est bien configuré, avant de pouvoir utiliser le tunnel, il faut réussir à s'introduire par le bout externe du tunnel.

 
Ah bon    
Tu t'occupes donc de savoir si tous les postes persos et réseaux de tes users sont sains ... Parce que sinon c'est bel et bien un soucis de securité et de fiabilité...

 
Non je m'occupe d'éviter d'avoir un programme qui s'infiltre à l'intérieur du firewall avant tout. Un port wan ouvert c'est un risque supplémentaire plus important pour le firewall lui-même qu'une attaque provenant du LAN.
 
La raison principale de ce risque est purement pratique, il faut répertorier les ports que l'on a ouvert, il faut noter sur quelle machine on redirige. Il est plus difficile de vérifier que le firewall n'a pas été piraté avec plein de paramètres de ce genre que sans. Et puis quand ça marche plus on fait quoi ?
 
Gestion, configuration, etc. l'administrateur réseau (s'il y en a un) a autre chose à faire. Dans ce genre de cas, ça doit être plutôt un prestataire donc niveau possibilité de configuration c'est proche de zéro.

in fine c'est pareil
Ce qu'il veut faire c'est que quelqu'un établissant une session TCP sur le port 80  de son PC sur le net (par exemple) soit redirigé dans le tunnel SSH qu'il a établit. Une fois le tunnel établi, c'est identique à avoir une règle inbound dans ton firewall autorisant le trafic 80 vers ce PC.

Autoriser ce type de règle dans un réseau partagé non destiné à être une DMZ ou une zone serveur est très loin d'être recommandé. Pour moi c'est une règle de base dans une politique de sécu : isolement, cloisement t'appelle ca comme tu veux !

En résumé :
une DMZ est une DMZ
un lan est un lan
le trafic provenant d'une zone non maîtrisée vers le LAN doit être interdit

WAN -> DMZ = OK
DMZ -> LAN = KO
WAN -> LAN = KO

A priori, il est isolé du reste du réseau, donc je m'en fous qu'il foute ca en place.

 
Oui, mais enfin non. Bref, passons.
 

 
Ca c'est parce qu'il ne sait pas qu'il peut protéger le port de sa machine distante, enfin il voit bien qu'il ne peut pas y accéder directement d'après ce qu'il a dit. Et puis il a pas l'air de s'y connaître en tunneling alors que "ssh -L" lui serait utile pour éviter de laisser l'entrée du tunnel accessible à tous.
 
Enfin DMZ ou LAN, de toute façon on parle d'un réseau de résidence relié à Internet, un endroit où potentiellement on a toutes les chances de croiser une machine vérolée.
Alors :
WAN -> DMZ = OK
DMZ -> LAN = NOK
WAN -> LAN = NOK
ce n'est pas un problème important à se poser
 
Et puis si l'installateur du routeur aurait vraiment voulu empêcher les gens de faire du tunneling, il aurait désactiver le port 22, donc on peut en conclure que la sécurité du LAN n'est pas à ce point critique, à vrai dire il n'en a rien à f**** du moment que le routeur ne demande pas de maintenance.

même chose... connexion refusée.
 
Comment dire qu'un port écoute en local seulement ou pas ? à priori ça serait une opération à effectuer sur PC2 non ? Car c'est lui qui possède le port en question qui n'écoute qu'en localhost.
 

Non, car bien que connecté sur ce réseau, je n'y ai absolument aucun accès à part mon petit chemin vers le routeur pour la connexion internet.
 
 

Justement, c'est pas vraiement une LAN : c'est plutôt des connexion uniques entre chaque PC et le routeur. Mais c'est clairement pas une DMZ.
 
 
Et sinon c'est interessant votre discussion au sujet de la sécurité/fiabilité. J'y avais pensé, mais pas à ce point

Content que tu ait appris quelque chose.
 
 
En théorie dans l'ordre :
1- ssh -R localhost:22 PC2
login PC2
2- ssh PC2 -L2222:127.0.0.1:20000  
login PC2
3- ssh 127.0.0.1 -p2222
login PC1
 
1- on crée le reverse tunnel qui redirige le port 20000 de PC2 sur le port 22 de PC1
2- on crée un tunnel qui redirige le port 2222 de PC1 sur le port 20000 de PC2
3- on se connecte à PC1 en utilisant le tunnel crée en 2
On connecte ssh sur le port 2222 de PC1, ce port redirige sur le port 20000 de PC2 qui lui-même redirige sur le port 22 de PC1.
 

Tant mieux alors.
 

Faudrait vérifier l'adresse de bind, après peut-être qu'on peut l'indiquer à ssh, ou bricoler une bidouille avec autre chose.
 
Sinon aussi vérifier que les redirections sont bien crées : droits suffisants; que les ports sont accessibles : parefeu etc.

Heu... c'est quoi l'intérêt là ?    
 
 
J'ai finalement trouvé la solution à mon problème : il fallait lire la doc SSH jusqu'au bout (nan nan, pas taper ).

 
J'ai donc activé l'option GatewayPorts pour SSH sur PC2, et donc maintenant le port est en écoute sur 0.0.0.0 donc accessible de l'extérieur.
 
Donc solution finale :

Et ça fonctionne !
 
Un grand merci à tous pour vos suggestions, ainsi que pour votre reflexion sur la sécurité très enrichissante

 
L'intérêt c'est que justement le port reverse tunnelé ne soit pas accessible directement de l'extérieur sans authentification sur le serveur distant.
 
Mais bon après c'est toi qui voit, dans ton cas il y a peu de chances que cette faille soit exploitée, vu le peu d'intérêt que cela pourrait rapporter.