Question sur une règle iptables

Support Debian
#1

Bonjour tout le monde,
j’ai vu dans des scripts ces règles iptables mais je ne sais pas vraiment à quoi ça correspond:

iptables -A FORWARD -i lo -j ACCEPT iptables -A FORWARD -o lo -j ACCEPT

une idée ?

#2

Tu acceptes les connexions de ton ordinateur vers lui-même. C’est assez raisonnable, tu peux laisser :slightly_smiling:

#3

Merci fran.b

#4

Pour être exact en fait, «forward» indique le relais et lo = interface loopback donc l’ordinateur lui même. Cette règle accepte de relayer une connexion venant de l’ordinateur lui même.

#5
  • le traffic de l’extérieur vers la machine locale traverse la chaîne INPUT
  • le traffic à destination de l’extérieur depuis la machine locale traverse la chaîne OUTPUT

Je ne vois pas trop comment on pourrait passer par la chaîne FORWARD.

http://www.plouf.fr.eu.org/bazar/netfilter/schema_netfilter.txt

#6

FORWARD est utilisé quand ta machine sert de passerelle… de ton réseau interne vers le net.

#7

[quote=“thialme”]* le traffic de l’extérieur vers la machine locale traverse la chaîne INPUT

  • le traffic à destination de l’extérieur depuis la machine locale traverse la chaîne OUTPUT

Je ne vois pas trop comment on pourrait passer par la chaîne FORWARD.

http://www.plouf.fr.eu.org/bazar/netfilter/schema_netfilter.txt[/quote]

Je me suis posé également la question. Peut être dans la config suivante: Sur ta machine tu fais une redirection du port 80 vers le port 8080 et tu fais une connexion vers le port 80 de ta machine. Mais ça concerne la table nat…
En fait il faudrait faire un -j LOG pour voir si ça arrive.

#8

[quote=“fran.b”]
Je me suis posé également la question. Peut être dans la config suivante: Sur ta machine tu fais une redirection du port 80 vers le port 8080 et tu fais une connexion vers le port 80 de ta machine. Mais ça concerne la table nat…
En fait il faudrait faire un -j LOG pour voir si ça arrive.[/quote]
J’y ai rapidement réfléchi aussi, mais rien ne m’est venu à l’esprit. En effet, ton exemple est à essayer. Le routage sur lo j’ai encore jamais appliqué.

#9

Tu aurais un exemple ?

#10

[quote=“ymer”]
Tu aurais un exemple ?[/quote]
Non, je n’arrive pas à en faire…

#11

Dommage, parce-que je n’arrive pas à comprendre :cry:

#12

Si ça peu aider, voici le résultat des deux règles postée plus haut:
je poste la partie forward au complet:

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT 0 -- lo any anywhere anywhere 0 0 ACCEPT 0 -- any lo anywhere anywhere 0 0 ACCEPT tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 0 0 TCPMSS tcp -- any eth0 anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU 0 0 ACCEPT 0 -- any any 192.168.0.0/24 anywhere 0 0 ACCEPT 0 -- any any anywhere 192.168.0.0/24 0 0 ULOG 0 -- any any anywhere anywhere ULOG copy_range 0 nlgroup 1 prefix `FORWARD' queue_threshold 1

#13

Bon alors j’ai fait un petit test.

Le principe consisterait à faire du DNAT sur une connection locale pour l’envoyer vers un serveur externe. En fait, en considérant un serveur externe écoutant sur le port 585, et que je veux rediriger le traffic local destiné à ce même port pour ma machine vers ce serveur.

Soit deux cas :

1/ je vois le paquet sortir (OUTPUT) et je le redirige.
2/ je vois le paquet (PREROUTING) qui entre et je le redirige pour tenter de le faire passer par FORWARD

Le cas 1 étant le plus logique.

$IPTABLES -t nat -A PREROUTING -i lo -j LOG \ --log-prefix "FORWARD " --log-ip-options --log-tcp-options $IPTABLES -t nat -A OUTPUT -p tcp --dport 585 -j LOG \ --log-prefix "OUTPUT " --log-ip-options --log-tcp-options $IPTABLES -t nat -A INPUT -p tcp --dport 585 -j LOG \ --log-prefix "INPUT " --log-ip-options --log-tcp-options
Je fais un petit telnet sur 127.0.0.1 sur le port 585, et la je m’aperçois qu’il n’y a aucun log dans PREROUTING et INPUT, contrairement à OUTPUT, donc impossibilité de rediriger le paquet pour le faire transiter vers FORWARD.

Sachant que les paquets traversant la table nat sont les premiers des connexions, et que l’on peut le (la connexion en telnet) voir en OUTPUT avec les logs, alors celui-ci ne sera jamais vu dans la table nat de la chaine PREROUTING et dans la table nat de la chaîne INPUT. Ce qui confirme ce que je vois au dessus.

C’est le seul cas auquel j’ai pensé mais qui n’est pas viable du fait du fonctionnement de Netfilter.

Quelqu’un pour confirmer ?

#14

iptables -A FORWARD -i lo -j ACCEPT iptables -A FORWARD -o lo -j ACCEPT
L’interface de “loopback” lo sert exclusivement à envoyer et recevoir des paquets localement de la machine vers elle-même. A contrario, la chaîne FORWARD n’est traversée que par des paquets “relayés”, c’est-à-dire reçus d’une autre machine à destination d’une autre machine ; l’interface d’entrée ou de sortie ne peut donc pas être lo. Par conséquent ces règles ne servent à rien, aucun paquet ne pouvant correspondre.

Pour accepter les communications de la machine vers elle-même, il faut juste les règles suivantes :

iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT

C’est un peu plus tordu que ça. Le premier paquet qui traverse OUTPUT, PREROUTING puis revient par PREROUTING et INPUT est toujours le même premier paquet. Pourtant il ne traverse pas la chaîne PREROUTING de la table nat. En fait le paquet traverse la table nat tant que la création de la nouvelle connexion n’est pas confirmée. Cette confirmation intervient après la traversée des chaînes POSTROUTING et INPUT. Si le paquet n’arrive pas jusque là parce qu’il a été bloqué ou rejeté avant, la nouvelle connexion sera effacée. Ici, la création de la connexion a été confirmée après la traversée de POSTROUTING, donc à partir de là le paquet ne traverse plus la table nat.

#15

[quote=“thialme”]…Je fais un petit telnet sur 127.0.0.1 sur le port 585, et la je m’aperçois qu’il n’y a aucun log dans PREROUTING et INPUT, contrairement à OUTPUT, donc impossibilité de rediriger le paquet pour le faire transiter vers FORWARD.
[…]
Quelqu’un pour confirmer ?[/quote]
Oui, pour ma j’avais essayé bêtement de faire une translation de port en local et ça ne marche pas (cf mon message «je n’y arrive pas») totoche:~# iptables -A FORWARD -i lo -j LOG totoche:~# iptables -A FORWARD -o lo -j LOG totoche:~# iptables -t nat -p tcp -A PREROUTING --dport 8888 -j DNAT --to 127.0.0.1:22 totoche:~# telnet localhost 8888 Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused
j’ai fait plusieurs variantes. Je me demande comment faire une telle translation de port d’ailleurs…

#16

[quote=“fran.b”]totoche:~# iptables -t nat -p tcp -A PREROUTING --dport 8888 -j DNAT --to 127.0.0.1:22 totoche:~# telnet localhost 8888 Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused
j’ai fait plusieurs variantes. Je me demande comment faire une telle translation de port d’ailleurs…[/quote]
Pour que la redirection fonctionne depuis la machine elle-même, il faut créer la règle DNAT dans la chaîne OUTPUT.

#17

[quote=“PascalHambourg”]
Pour que la redirection fonctionne depuis la machine elle-même, il faut créer la règle DNAT dans la chaîne OUTPUT.[/quote]
Une connexion sur lo n’est pas considérer comme INPUT?

#18

Un paquet passant par lo est à la fois sortant et entrant puisqu’il est à la fois émis et reçu par l’interface lo qui est une boucle. Du point de vue du suivi de connexion (conntrack) et donc du NAT, une connexion sur lo est plutôt sortante puisque le premier paquet est vu la première fois lors qu’il sort, juste avant de traverser les chaînes OUTPUT.

#19

Ceci explique cela donc, je comprends mieux mais c’est dommage car ça introduit une asymétrie entre une connexion venant de lo (donc vu comme sortante) et venant d’une interface eth.