OVH Cloud OVH Cloud

PB avec le MASQUERADING

2 réponses
Avatar
hifiman
Bonjour, j'utilise ce medium pour la première fois. Pardonnez mes
erreurs éventueles.

J'ai un problème de MASQUERADING. Vient-il de IPTABLES ? Je l'ignore.
Quelqu'un pourrait-il m'aider SVP ?

Le voici: J'ai un poste linux qui route ma connexion internet par
modem pour mon LAN. Le masquerading fonctionne mais j'ai découvert par
hazard grace aux logs que

1. Des paquets à destination de 192.168.x.y (une station du LAN autre
que le routeur) transitent sur le firewall (table FILTER) alors qu'une
règle les interdit en provenance de ppp0 dans la chaine PREROUTING de
la table NAT. Ceux que je vois sont filtrés parcequ'ils arrivent en
grand nombre avec un flag RST.

2. Des paquets de source 192.168.x.y à destination d'internet sont
également logués par le filtre lorsqu'ils correspondent à une règle.

Est-ce normal que des paquets entrants aient une adresse de
destination privée qui corresponde à mon laptop alors qu'ils auraient
dû être natés ?

2 réponses

Avatar
Pascal
Salut,

J'ai un problème de MASQUERADING. Vient-il de IPTABLES ? Je l'ignore.


Es-tu obligé de CRIER ?

Le voici: J'ai un poste linux qui route ma connexion internet par
modem pour mon LAN. Le masquerading fonctionne mais j'ai découvert par
hazard grace aux logs que

1. Des paquets à destination de 192.168.x.y (une station du LAN autre
que le routeur) transitent sur le firewall (table FILTER)


C'est parfaitement normal. Les opérations de masquerading et de
dé-masquerading ont lieu respectivement dans les chaînes POSTROUTING et
PREROUTING de la table nat. Donc les paquets qui traversent la chaîne
FORWARD de la table filter portent l'adresse privée de la station qui
émet ou reçoit ces paquets.

alors qu'une
règle les interdit en provenance de ppp0 dans la chaine PREROUTING de
la table NAT.


Règle importante : *on ne doit pas* faire de filtrage dans la table nat
car seul le premier paquet d'une connexion traverse les règles. La même
opération que celle qui a été appliquée à ce premier paquet est ensuite
appliquée à tous les paquets suivants appartenant à la même connexion.
Si on a besoin de filtrer à l'entrée avant toute opération de NAT sur
les paquets destinés au réseau local, au pire on peut filtrer dans la
table mangle, même si à la base elle n'est pas faite pour ça. Mais il
est plus propre de marquer les paquets (cible MARK) dans la chaîne
PREROUTING de la table mangle et ensuite de filtrer sur ce critère
(correspondance mark) dans la chaîne FORWARD de la table filter dont
c'est le rôle.

Ceux que je vois sont filtrés parcequ'ils arrivent en
grand nombre avec un flag RST.


Tu filtres sur quel critère exactement ? Il n'est pas anormal de
recevoir un tel paquet, il peut simplement correspondre à une demande de
connexion TCP d'une de tes machines locales qui a été refusée par la
machine distante (port fermé).

2. Des paquets de source 192.168.x.y à destination d'internet sont
également logués par le filtre lorsqu'ils correspondent à une règle.


Contre ceux-là, le plus simple est d'activer le reverse path filtering
(anti-spoofing) en mettant /proc/sys/net/ipv4/conf/*/rp_filter à 1.

Est-ce normal que des paquets entrants aient une adresse de
destination privée qui corresponde à mon laptop alors qu'ils auraient
dû être natés ?


Ça dépend à quel endroit de Netfilter. Dans la chaîne FORWARD, oui c'est
normal à cause du masquerading. Si c'est dans la chaîne PREROUTING,
alors non ce n'est pas normal, et ton FAI doit avoir de *gros* problèmes
de routage pour acheminer de tels paquets jusqu'à toi.

Conclusion : la lecture du fonctionnement de Netfilter s'impose.
http://www.netfilter.org/documentation/index.html

Avatar
Pascal


2. Des paquets de source 192.168.x.y à destination d'internet sont
également logués par le filtre lorsqu'ils correspondent à une règle.


Contre ceux-là, le plus simple est d'activer le reverse path filtering
(anti-spoofing) en mettant /proc/sys/net/ipv4/conf/*/rp_filter à 1.


Pardon, j'ai mal lu. Je pensais que c'étaient des paquets entrants.

Si ce sont des paquets sortants traversant la chaîne FORWARD, c'est
parfaitement normal puisque la modification de l'adresse source
(masquerading) a lieu dans la chaîne POSTROUTING, donc après la
traversée de FORWARD. Dans FORWARD, les paquets sortants portent encore
l'adresse source privée de la station émettrice.
Symétriquement, la modification de l'adresse destination des paquets de
réponse entrants a lieu dans la chaîne PREROUTING, donc avant la
traversée de FORWARD. Dans FORWARD, les paquets entrants portent déjà
l'adresse destination privée de la station réceptrice.