[RESOLU] tunnel ssh du wan vers le lan

[fabzz007]

bonjour,

j'ai installé un serveur ssh sur mon lan et je voudrais pouvoir y accéder depuis le wan afin de faire de la redirection de port et pouvoir ouvrir un connexion au bureau à distance (3389) de manière crypté...

depuis une machine du lan pas de problème biensur j'utiloise putty en créant une redirection du port 3389 de la machine distante sur le port 3389 de la machine local

De ce que j'ai pu comprendre en farfouillant sur ixus il faut donc que je j'ajoute une règle dans shorewall afin de rediriger le requete ssh provenant de wan vers le mon serveur ssh du lan...

Mais a vrai dire toute mes tentative son infructueuses donc si l'un d'entre vous pouvais éclairer ma lanterne

voici la règle que j'ai ajouter dans shorewall :

action : DNAT
client : wan:22
serveur : lan:10.0.0.1
protocol : tcp+udp
services prédéfinis :ssh

où 10.0.0.1 est l'adresse ip de mon serveur ssh

je seche please help !

[Franck78]

client: wan:22

C'est pas le numéro de protocole qui est demandé dans ce champ. C'est la/les machines autorisées. IP, nom de domaine, range, je sais pas, mais surement pas '22' tout seul !


Et pas besoin d'UDP pour ssh.

bye

[HaM]

La regle à rajouter est celle-ci

Code: Tout sélectionner

DNAT   wan   lan:10.0.0.1   tcp   22   -

A rajouter dans le fichier /etc/shorewall/rules

[fabzz007]

je vais tester tout ça de ce pas merci Je vous tiendrais informé

[fabzz007]

Bon je viens d'ajouter cette règle et de restarter shorewall mais sans succès
Je suis avec un mnf 8.2 n'y avait-il pas un soucis avec le dnat de cette version ???

[fabzz007]

bon alors voici je l'espère la suite et fin de mes pérégrinations

Tout d'abord merci à ceux qui m'ont aidé ainsi qu'a toute la communauté ixus qui fait vraiment un bon boulot....

Voici la règla à ajouter

Action : ACCEPT
Service Prédéfini : ssh
Protocol : tcp
client : wan
serveur : lan:@ip_du_serveur_ssh
adresse de renvoie : all

Notez qu'apparement le DNAT ne fonctionne pas sur le version 8.2 de la mnf c'est pourquoi il faut utiliser accept et le renvoie to : all

mais que a partir de la version 10 (alias mnf2) DNAT fonctionnerai à confirmé par ceux qui l'utilise

@++

[jdh]

Dans la configuration Shorewall, on peut utiliser plusieurs actions (de base) :

DROP : on ne traite pas
REJECT : on ne traite pas et on informe que l'on ne traite pas
ACCEPT : on autorise
DNAT : on autorise en transférant vers une autre machine que le firewall (avec eventuellement changement de port)
REDIRECT : on autorise en transférant localement sur le firewall (port).

Donc DROP et REJECT sont assez clair. La différence entre ACCEPT et DNAT est qu'ACCEPT ne change aucune adresse alors que DNAT traite des paquets reçus à destination du firewall en les transférant à la machine cible (donc le paquet est réécrit avant d'être transféré).

REDIRECT est un transfert local : le n° de port d'un paquet reçu par le firewall est modifié pour être traité par le vrai programme. Par exemple : le traffic du port TCP/80 (à destination de l'extérieur) est transféré au firewall sur le port TCP/3128 pour utiliser SQUID en mode transparent.


Le cas qui est posé est celui d'un tunnel. Les éléments qui interviennent sont :

- le Client source,
- le Firewall,
- le Serveur cible.

Il faut ajouter un Intermédiaire qui est souvent le Firewall. Il me semble que cela est oublié.


Un pgm lancé sur le Client source veut accéder au Serveur cible via un port donné. Or le Firewall n'ouvre pas le port prévu.

Un tunnel est construit entre 2 extrémités : le Client avec un pgm créant localement un port donné et transférant via un traffic TCP/22=SSH vers un Intermédiaire qui peut lui atteindre le Serveur cible avec le vrai port cible.

Au final, le vrai pgm du Client attaque non le Serveur cible sur un port cible mais localement le pgm d'entrée du tunnel sur un autre port (ou le même).

Il n'empeche, il faut un Intermédiaire qui soit l'extrémité du tunnel et qui "depaquete" le traffic afin de le transférer vers la Cible port Cible. Cet Intermédiaire est nécessairement situé à partir du Firewall puisqu'il faut qu'il atteigne le Serveur cible. Il peut être le Firewall.

Il est important de bien comprendre que ce n'est pas Shorewall qui fait le boulot de cet Intermédiaire. L'instruction DNAT ne fait qu'un transfert. En l'occurence l'instruction indiquée NE fait QUE transférer du traffic 22 vers le Serveur cible.

En général, c'est le serveur SSH du Firewall qui fait le boulot d'Intermédiaire. Donc la programmation du firewall revient à autoriser l'accès à ce serveur SSH, c'est à dire "ACCEPT net fw tcp 22".

J'espère avoir fait avancer le schmilblick. Mais je note que je n'explique pas pas précisément le montage du tunnel. Il me semble que PuTTY est une bonne extrémité local du tunnel. Mais j'ignore comment se règle l'autre bout du tunnel qui est bien souvent le serveur OpenSSH.

J'ignore exactement cette partie mais le réglage Firewall devrait être facile ensuite.

[jdh]

J'ai trouvé une page interessante sur les réglages pour un tunnel SSH : http://people.via.ecp.fr/~dragon/tunnelingssh.htm.

[Gandalf]

Tu devrais être prof jdh, tes explications sont toujours très intéressantes ! Donc si je veux résumer le problème de notre ami : il veut attaquer une machine de son lan ( à la maison par exemple ) depuis son travail !
Il crée une connexion ssh entre la machine cible ( chez lui ) et MNF, et en attaquant le MNF depuis son boulot celui-ci va relayer les trames vers la machine cible ? Est-ce juste ?

[fabzz007]

C'est juste ou devrais-je dire c'était juste puisque le problème n'existe plus Car comme je l'ai dit plus haut j'ai trouvée la règle me permettant de rediriger les requete ssh qui arrive sur mon ip public vers un ip privé de mon lan.

Les explications jhd sont claire dans la théorie mais dans la pratique le DNAT ne fonction pas sur la 8.2 en tout cas je n'ai pas réussi à l'utiliser.

Deplus lorsque on veut ajouter une règle simple avec la mnf et qu'on clic sur le bouton aide l'exemple qui est afficher est justement celui qui nous intéresse ici : Comment rediriger une connexion ssh qui arrive sur le firewall vers une machine du lan... Et dans cette exemple il utilise ACCEPT et non DNAT ce qui est bizard je vous l'accorde puisque le dnat devrait servir à ça pourtant

bref un petit edit de mon post pour le marquer en tant que résolu et je vous remercie de votre aide

[jdh]

Shorewall a évolué dans les actions. Il faut donc faire attention à la version. Il est possible que DNAT ne fonctionne pas comme prévu depuis les versions 1.4,2.0, 2.1 ou 2.2.

Il n'empeche que le tunnel impose bien 2 extrémités dont une près de la cible. Le transfert de traffic ne fait iren à l'affaire.