[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: syntaxe iptables



prego jérémy a écrit :

donc dans ce cas,  la règle iptables :
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 5557 -j DNAT --to-
destination 192.168.1.3:5557

devrai fonctionner directement

jerem

Sauf si il y a un iptables -t filter -P FORWARD DROP (parce qu'il me semble que le NAT/PAT et le filtrage sont bien deux choses indépendantes), ou toute autre règle similaire interdisant le traffic entre deux interfaces d'une même babasse.

Et dans ce cas, les deux règles :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 5557 -j DNAT --to-destination 192.168.1.3:5557

et

iptables -A FORWARD -p tcp -i eth0 --dport 5557 -j ACCEPT

sont nécessaires, bien que je considère la deuxième un poil trop laxiste. (mais peut être a t'elle été élargie pour diagnostiquer plus en détail le problème) .
Quoi qu'il en soit, ca devrait fonctionner comme ca.

Le coup du forward (via sysctl ou la méthode /proc/sys/net/ipv4/ip_forward) est également un erreur courante . Mais j'ai l'impression que de ce que je lis du premier post de zulian (alias Frédéric), que le problème n'est pas la.

Du coup, Frédéric , plusieurs questions :


Est-ce que l'adresse IPv4 publique arrive directement sur la machine qui fait office de firewall ?

As tu , dans tes règles IPTables en toute fin de chaine FORWARD un ligne du style :

iptables -t filter -A FORWARD -j LOG --log-prefix "IPTables Packet Dropped: " --log-level 7

? (au quel cas , tu peux voir dans le syslog si il y a des paquets rejetés).

y'a t'il au tout début de ta règle forward, un truc du genre :

iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
(à compléter avec des -i et -o le cas échéant)

ou au contraire, une autre regle qui interdirait tout traffic en provenance de l'extérieur vers l'intérieur, avant de demander à accepter le traffic.

Que l'on me corrige si je me trompe, mais sous netfilter/iptables , c'est la première règle qui l'emporte , contrairement à d'autres (pf pour exemple, hormis l'utilisation du mot clé "quick"), ou c'est la dernière qui l'emporte.

Et dernière question, depuis quelle machine testes tu la connexion à l'adresse IP publique ? (une machine à l'extérieur, ou une machine de ton réseau local ? ) ... Si c'est depuis le réseau local, il y a de fortes chances que cela ne fonctionne pas (a part quelques bidouilles), puisque c'est la machine qui détient l'adresse IP publique qui va tenter de répondre avec ses ports ouverts , plutôt que la machine destinataire de la règle NAT. Et ce n'est donc pas un test fiable.


@+
Christophe.


Reply to: