Iptables NAT FORWARD du port 29070

Bonjour,

Sur mon serveur debian, le Natage et le forward du port 29070 fonctionnait jusqu’au reboot d’hier grace la regle suivante dans mon iptables :

/sbin/iptables -t nat -A PREROUTING -p tcp -i eth2 -d 192.168.0.1 --dport 29070 -j DNAT --to-destination 10.0.1.7:29070 /sbin/iptables -A FORWARD -p tcp -i eth2 -o eth0 -d 10.0.1.7 --dport 29070 --sport 1024:65535 -m state --state NEW -j ACCEPT

Je ne sais pas comment cela ce fait mais cela ne fonctionne plus maintenant. De plus j’ai une autre règle vers un autres autres serveur et cette dernière fonctionne… :119

/sbin/iptables -t nat -A PREROUTING -p tcp -i eth2 -d 192.168.0.1 --dport 29082 -j DNAT --to-destination 10.0.1.8:29082 /sbin/iptables -A FORWARD -p tcp -i eth2 -o eth0 -d 10.0.1.8 --dport 29082 --sport 1024:65535 -m state --state NEW -j ACCEPT
Merci de votre aide pour m’aider à résoudre ce problème.

Vérifier avec iptables-save que les règles sont bien en place.
Que donne un traceroute TCP vers l’adresse d’origine et le port considérés ?
Pendant une tentative de connexion, vérifier sa présence dans la table de connexion en regardand le contenu de /proc/net/nf_conntrack.
Le serveur de destination finale est bien configuré (réseau, port) ?

Bonjour Pascal,

Depuis la machine 192.168.0.1, le telnet 10.0.1.7 29070 est OK.
Depuis ma station de travail le telnet 192.168.0.1 29070 est KO

Depuis la machine 192.168.0.1, le telnet 10.0.1.8 29082 est OK
Depuis ma station de travail le telnet 192.168.0.1 29082 est OK

A part le port et l’adresse IP de destination, les 2 regles sont strictement identiques. :12
Quand je fait les 2 telnet, évoqués ci dessus depuis ma station de travail, je n’ai pas de nouvelle log ni dans /proc/net/nf_conntrack et ni dans /var/log/kernel.log

Est ce normal?

Que signifie exactement KO ?
Les compteurs des règles concernées sont-ils incrémentés (iptables-save -c) ?

KO signifie que j’ai ceci :

:~$ telnet 192.168.0.1 29070 Trying 192.168.0.1 ... telnet: Unable to connect to remote host: Connection timed out

A la place de ceci :

:~$ telnet 192.168.0.1 29082 Trying 192.168.0.1... Connected to 192.168.0.1. Escape character is '^]'.

J’ai fais un scripts avec la commande et son PATH (/sbin/iptables) à la place d’utiliser l’utilitaire iptables-save. Puis j’ai chargé ce script avec chkconfig.

En ce qui concerne la connexion du port 29082, j’ai eu de la log dans le fichier /var/log/kern.log mais pas pour 29070

Feb 7 20:19:52 debianserver kernel: [125039.790637] [IpTables INPUT] IN=eth2 OUT= MAC=00:1e:68:49:b2:7e:00:24:f9:3d:e9:c3:08:00 SRC=88.XXX.XXX.XXX DST=192.168.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=6937 DF PROTO=TCP SPT=49107 DPT=29082 WINDOW=14600 RES=0x00 SYN URGP=0 Feb 7 20:19:55 debianserver kernel: [125042.796520] [IpTables INPUT] IN=eth2 OUT= MAC=00:1e:68:49:b2:7e:00:24:f9:3d:e9:c3:08:00 SRC=88.XXX.XXX.XXX DST=192.168.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=6938 DF PROTO=TCP SPT=49107 DPT=29082 WINDOW=14600 RES=0x00 SYN URGP=0 Feb 7 20:20:01 debianserver kernel: [125048.811825] [IpTables INPUT] IN=eth2 OUT= MAC=00:1e:68:49:b2:7e:00:24:f9:3d:e9:c3:08:00 SRC=88.XXX.XXX.XXX DST=192.168.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=6939 DF PROTO=TCP SPT=49107 DPT=29082 WINDOW=14600 RES=0x00 SYN URGP=0 Feb 7 20:20:13 debianserver kernel: [125060.828817] [IpTables INPUT] IN=eth2 OUT= MAC=00:1e:68:49:b2:7e:00:24:f9:3d:e9:c3:08:00 SRC=88.XXX.XXX.XXX DST=192.168.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=6940 DF PROTO=TCP SPT=49107 DPT=29082 WINDOW=14600 RES=0x00 SYN URGP=0

J’ai sciemment masqué l’adresse de ma freebox et celle de mon serveur qui n’est 192.168.0.1

En résumé tu m’as fait perdre mon temps. Bonne chance quand même.

Bonjour Pascal,

Je ne vois pas pourquoi tu dis cela. Je me suis peut être mal exprimer mais cela ne fonctionne toujours pas. :033

Pour dépanner, j’ai essaye de faire un tunnel avec ssh. Cela fonctionne sous linux mais pas sous windows avec putty.exe.
Putty me donne l’erreur suivante :

bind: Address already in use channel_setup_fwd_listener: cannot listen to port: 29070 Could not request local forwarding.

Erreur que je n’ai pas avec pas avec openSSH-client.

On va faire des essais avec CygWin et SSH je vous tiens au courant, mais ce n’est pas une solution finale pour moi.