Voilà, cet été je me suis fait un routeur sous Ubuntu server pour éviter d'utiliser l'interface web de ma freebox, qui m'obligeai à la rebooter a chaque changement.
Je me suis donc concocté une petite interface web qui me rempli mon fichier iptables pour faire mes regles NAT.
Bref, j'ai remarqué un problème que je n'avais pas avant (ou je ne l'ai pas remarqué, mais c'est étrange).
 
Par exemple, j'ai trois machine qui utilisent openssh server. Par défaut donc, c'est le port 22 qui écoute.
C'est bien le cas sur mon routeur, donc j'utilise la regle suivante :

 
Pas de problemes, ça marche. Là où ça se complique, c'est que sur mes deux autre machines (192.168.0.2 ainsi que 192.168.0.4), j'aimerai bien laisser le port d'écoute 22 pour le ssh.
Donc, ce que j'ai fait, par exemple pour 192.168.0.2 :

 
Théoriquement, de l'exterieur, lorsque je demande un ssh sur le port 118, le routeur est censé me le rebalancer sur 192.168.0.2 sur son port 22.
Il m'a semblé que cela fonctionnait (mais ça fait depuis aout alors je me rappelle plus si j'avais testé).
Or, ce soir, j'ai réessayé, mais ça ne donne rien : le site shieldsup m'indique que le port est stealth. Par curiosité, j'ai changé ma regle en mettant :

 
Et en mettant le serveur ssh en écoute sur le 118, là, ça marche !  
 
Pourquoi ça ne fonctionne pas avec la premiere methode ?  
Je tiens préciser que sur les deux autres machines (0.2 et 0.4) , le firewall est désactivé ou non installé. Donc ce n'est pas ces machines là qui bloque le traffic, ça vient de mon routeur.
 

 
Ca marche toujours pas la premiere méthode, j'aimerai bien comrpendre

Juste un truc ... ton serveur ssh accepte le trafic entrant depuis un port 118 (au moins en interne) ?
Sinon ... pourquoi un port < 1024 ? (juste pour savoir   )

 
1) selon la premiere méthode, le 192.168.0.2 accepte que sur le port 22. Mais en théorie, il est censé être redirigé par mon routeur : je vois pas le probleme
 
2) < 1024 car au dessus, il y a des bridages chez free

Oui c'est vrai ... le prérouting ... donc c'est bizarre que ça marche pas.
Tu n'as que l'interface eth0 ? et donc c'est pour ça que tu ne la précises pas dans le forward  en output ?

C'est normal que cela ne marche pas. La table PREROUTING est traitée avant (comme son nom l'indique) la table FORWARD.
Il faut donc que tu autorise le FORWARD sur le port naté, c'est a dire le 22, hors la tu le fait sur le 118.
 
Amha.
 

Mais comment fait il pour le port 22 qui écoute sur le routeur directement
Ca va continuer a marcher
(je parle de ça : iptables -A INPUT -p tcp -i eth0 --dport ssh -j ACCEPT)

Regarde bien la sequence de traitement des tables :

(schema tiré de la trés bonne doc iptables de Christian Caleca http://christian.caleca.free.fr/ne [...] ecture.htm )

Donc, amha, pas de problème. C'est la chaine INPUT (paquet destiné au routeur directement) qui est concernée et non la FORWARD (paquets ne faisant que traversé le routeur) (d'ailleur, je m'a gourré talleur, c'est pas table mais chaine).

Si tu veux autoriser le ssh sur le routeur tu met dans INPUT.
Si tu veux autoriser le ssh sur les machines qui sont derrières le routeur, tu met dans FORWARD.
Si tu veux autoriser le ssh sur les deux : tu met dans INPUT et FORWARD. (mais la effectivement tu est obligé de nater le port en plus de l'adresse car le port 22 en local est déja pris, et comme le nat s'effectue dans la chaine PREROUTING, donc avant FORWARD, tu autorise dans FORWARD sur l'adresse et le port naté.

Enfin je peux me gourrer, (ne prend pas le risque de perdre la main sur la machine si tu travaille a distance) mais c'est comme ça que je comprend le truc.

Je vais tester ça dans la semaine, et chez moi a coté de mon routeur (pour éviter de perdre la main )
Je vous tiens au courant

fixed