ce qui veut dire qu'il track les connexions, et dans NAT il y a _translation_, ce qui veut dire que B va bien faire croire à A que c'est lui qui a inité la connexion.
Dans DNAT il y a Destination, donc seule la destination est modifiée c'est bien pour ça qu'il faut également modifier la source pour faire croire à A que c'est B qui a initié la connection.
quelles sont les autres règles du par-feu ? À priori c'est effectivement un problème de "retour" des paquets, mais il faudrait par exemple bien voir si B qui forwarde autorise bien les paquets retour (avec une règle genre --cstate ESTABLISHED,RELATED), etc.
Les chaines sont en ACCEPT, donc à priori le pare-feu est ouvert (sauf si certaines règles de DROP se trouvent dans la chaine FORWARD..).
A ma connaissance, NEW, ESTABLISHED.. servent à affiner le filtrage du paquet par rapport a l'état de sa connection (si le protocole est stateful). Si ce n'est pas spécifié, pas de filtrage sur ce point.
RELATED c'est utile avec certains protocoles qui ouvrent des ports dynamiquements et qui peuvent être autorisés grace à un 'connection tracker' tel que: irc_conntrack, ftp_conntrack...
Iptables est un firewall _statefull_,
Iptables stateful? j'ai des doutes, car ça dépend du protocole.
Je pense que l'ont peut configurer un firewall stateful avec iptables, mais que ce n'est pas une obligation.
Exemple, UDP est stateless par nature, il me semble qu'iptables simule du stateful en se servant d'un module externe (xt_state, xt_tcpudp probablement) qui utilise des temporisateurs configurables comme ici: /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout.
Ainsi, il est possible d'utiliser des choses tel que -m state --state NEW sur une connection UDP. Mais ça reste optionel (-m).
D'ailleur il me semble que c'est à cause de ce 'UDP-timeout' que quand l'on décide d'interdire un flux UDP, il faut attendre un certain temps avant que cette règle ne soit fonctionnelle sur le traffique déjà existant.. à confirmer..
[^] # Re: Normal
Posté par petit_bibi . En réponse au message iptables port forwarding. Évalué à 2.
ce qui veut dire qu'il track les connexions, et dans NAT il y a _translation_, ce qui veut dire que B va bien faire croire à A que c'est lui qui a inité la connexion.
Dans DNAT il y a Destination, donc seule la destination est modifiée c'est bien pour ça qu'il faut également modifier la source pour faire croire à A que c'est B qui a initié la connection.
quelles sont les autres règles du par-feu ? À priori c'est effectivement un problème de "retour" des paquets, mais il faudrait par exemple bien voir si B qui forwarde autorise bien les paquets retour (avec une règle genre --cstate ESTABLISHED,RELATED), etc.
Les chaines sont en ACCEPT, donc à priori le pare-feu est ouvert (sauf si certaines règles de DROP se trouvent dans la chaine FORWARD..).
A ma connaissance, NEW, ESTABLISHED.. servent à affiner le filtrage du paquet par rapport a l'état de sa connection (si le protocole est stateful). Si ce n'est pas spécifié, pas de filtrage sur ce point.
RELATED c'est utile avec certains protocoles qui ouvrent des ports dynamiquements et qui peuvent être autorisés grace à un 'connection tracker' tel que: irc_conntrack, ftp_conntrack...
Iptables est un firewall _statefull_,
Iptables stateful? j'ai des doutes, car ça dépend du protocole.
Je pense que l'ont peut configurer un firewall stateful avec iptables, mais que ce n'est pas une obligation.
Exemple, UDP est stateless par nature, il me semble qu'iptables simule du stateful en se servant d'un module externe (xt_state, xt_tcpudp probablement) qui utilise des temporisateurs configurables comme ici: /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout.
Ainsi, il est possible d'utiliser des choses tel que -m state --state NEW sur une connection UDP. Mais ça reste optionel (-m).
D'ailleur il me semble que c'est à cause de ce 'UDP-timeout' que quand l'on décide d'interdire un flux UDP, il faut attendre un certain temps avant que cette règle ne soit fonctionnelle sur le traffique déjà existant.. à confirmer..