soucis avec le DNAT [ netfilter / iptables / DNAT ] - réseaux et sécurité - Linux et OS Alternatifs
Marsh Posté le 22-03-2003 à 09:41:24
un p'tit ajout qui n'est pas anodin, l'interface à rediriger est ppp0 étant un ECI USB
je pensais aussi à un problème de route mais ça n'a pas l'air d'être le cas : tout le reste fonctionnant très bien
je n'ai pas de message lors du rejet des connexions (log des paquets), l'erreur se caratérise surtout par un gros refus de connexion lors du contact du port (entre autres j'ai 3 ports http à rerouter, respectivement : 84, 85, 86) même en spécifiant d'autres ports ça ne passe pas, quelque soit le protocole utilisé
Marsh Posté le 22-03-2003 à 18:31:12
BMOTheKiller a écrit : un p'tit ajout qui n'est pas anodin, l'interface à rediriger est ppp0 étant un ECI USB |
ppour rediriger un port:
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to 192.168.0.1
et faut autorise le traffic a passe:
iptables -A FORWARD -i ppp0 -d 192.168.0.1 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -o ppp0 -s 192.168.0.1 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
Marsh Posté le 22-03-2003 à 18:45:23
un extrait de ma table PREROUTING :
Code :
|
la correspondance dans FORWARD :
Code :
|
mon réseau est en 10.0.0.0/255.0.0.0
bon, ça c'est l'état actuel du firewall, mais même en créant les règles avec les tables à vide et les polices en ACCEPT (sans TCPMSS, LOG et compagnie), ça fonctionne pas d'un poil
on voit bien qu'il y a des paquets qui passent, à mon avis c'est la prise de contact, mais aussitôt ça part en connexion refusée, je remets portfwd en route : ça fonctionne (et ce même lorsque le firewall est en utilisation normale c'est à dire sans les ports correspondants ouverts en INPUT
c'est spécial comme problème
Marsh Posté le 23-03-2003 à 17:23:05
un p'tit up si quelqu'un a une idée après lecture du topic
Marsh Posté le 02-04-2003 à 02:21:30
bon je retente un p'tit up pour la forme
du nouveau : c'est plus le même noyau, mais c'est toujours pareil
personne n'a de soucis DNAT sous RH 8.0 ?
Marsh Posté le 02-04-2003 à 02:46:48
Dsl ... pas de Linux sous la main, et encore moins ma config iptables sous les yeux pour t'aider ...
EDIT : essaies d'enlever les lignes de ton script iptables/netfilter qui te génèrent les entrées du style flags:!SYN,RST,ACK/SYN state NEW ...
Marsh Posté le 02-04-2003 à 02:53:19
Zzozo a écrit : Dsl ... pas de Linux sous la main, et encore moins ma config iptables sous les yeux pour t'aider ... |
merci quand même
Marsh Posté le 02-04-2003 à 02:56:52
BMOTheKiller a écrit : |
J'ai édité ... ... cé marrant qd il y a un pb iptables/netfilter/réseau, je traine souvent dans les parages ... ... je sais pas pourquoi, ca doit être une vocation ... ...
Marsh Posté le 02-04-2003 à 03:02:45
p'têt, spécialiste iptables (après spécialiste gros smiley > )
bon, comme diit précédemment, même le firewall à vide avec juste le routage activé (postrouting ppp0 du réseau + ip_forward à 1) ça me le fait, j'ai réessayé récemment en changeant le noyau, toujours pareil... je comprends pas, ça me le faisait déjà sous RH 7.2 quand j'avais pas encore mon script avec filtrage des paquets incorrects
Marsh Posté le 02-04-2003 à 03:08:30
BMOTheKiller a écrit : p'têt, spécialiste iptables (après spécialiste gros smiley > ) |
A vide, cad sans le DNAT ?
EDIT : Bon je dois là ... je suis trop crevé ... ptet que demain, si j'ai un peu de temps, et un accès Internet décent (passer de l'ADSL au RTC qui marche une fois sur quinze ca fait drole qd même ... ), j'essaierai de voir ce qui va pas ...
Marsh Posté le 02-04-2003 à 03:11:11
à vide, je veux dire sans tout le reste du script, les polices à "accept", le nat, puis j'ajoute les règles dnat par là-dessus quoi
Marsh Posté le 02-04-2003 à 03:12:37
BMOTheKiller a écrit : à vide, je veux dire sans tout le reste du script, les polices à "accept", le nat, puis j'ajoute les règles dnat par là-dessus quoi |
Postes ton script de "fw à vide" ou envoies le moi en PM ... je le regarderai à l'occasion ...
Marsh Posté le 02-04-2003 à 03:34:50
ce que j'utilise pour tester à ce que j'appelle "à vide" :
Code :
|
puis reconnection simple sans firewall "startmodem" (le script est éxécuté séparément sauf au boot de la machine), je continue avec :
iptables -t nat -I PREROUTING -p TCP -i ppp0 --dport 85 -j DNAT --to 10.0.0.30:85
...de même avec les autres ports...
je teste sur une machine du réseau : connec refusée
bref dans ce script c'est large quoi, y a rien qui devrait barrer
merci
Marsh Posté le 22-03-2003 à 09:20:17
j'ai mis un peu de temps avant de me décider à poster ce problème vu que dans le fond c'était pas trop dérengeant, mais finalement ça devient de moins en moins pratique à gérer mon histoire, flashback :
sous RH 7.2, mon script firewall se basait sur ipchains, celui-ci ne gérant pas le forwarding de port (DNAT) je me suis tourné vers un p'tit démon appelé portfwd ( http://portfwd.sf.net ) pour combler ce manque, tout fonctionnait impecc... ipchains devenant trop limite pour mon utilisation, je décide de passer sous iptables et revoir mon script en fonction de celui-ci, pas de problème, sauf au niveau DNAT où la redirection ne passe pas malgré tous mes essais et donc je décide de conserver portfwd. petit truc étrange, sans ouvri mes ports en INPUT, mais en rentrant les ports à rediriger en PREROUTING : portfwd arrive les rediriger, donc j'en conclu que le soucis n'est pas directement lié à la table PREROUTING... passage sous RH 8.0 : même soucis, toujours pas moyen d'avoir du DNAT avec iptables, donc je continu toujours avec mes règles PREROUTING comme si de rien n'était avec portfwd qui fait le relais vers les machines, pensant que j'avais peut-être un soucis au niveau réseau, je revois ma config IP fixe en DHCP : toujours le même problème, pas moyen de rediriger directement les ports avec iptables, j'ai pensé à un problème de configuration du noyau, mais même avec un noyau officiel RH : ça ne passe pas
le problème étant que portfwd ouvre un processus pour chaque redirection, c'est bien gentil mais au bout d'un moment ça commence à charger et faut le redémarrer pour prendre en compte l'ajout d'un port, ce qui n'est franchement pas du tout pratique quand certains ports redirigés sont en cours d'utilisation, puis si le démon a le malheur de crasher : plus de redirection sur auncun port
d'où ma question, what's the fucking ?