[Résolu][IPTABLES] problème avec NAT

problème avec NAT [Résolu][IPTABLES] - Codes et scripts - Linux et OS Alternatifs

Marsh Posté le 06-09-2009 à 11:34:47    

Bonjour,
 
je fais appel à vous pour un problème sur iptables.
L'architecture de mon réseau est la suivante :
 
MODEM -> Routeur (iptables) -> Réseau (1 ou plusieurs PC)
 
Mon but est de réussir avec iptables à obtenir des courbes de trafic (conso...) par protocole et par utilisateur du réseau.
Par défaut, tout est filtré en sortie et redirigé vers une page web sur le routeur.
La personne peut alors cliquer sur un bouton de cette page web et accéder à Internet.(ici des règles de nat sont mises en place)
 
Tout fonctionne très bien à ce niveau là.
J'arrive également au niveau de la chaîne prerouting du NAT à obtenir pour chaque utilisateur du réseau les paquets envoyés pour établir les connexions aux serveurs et ce pour les protocoles à surveiller spécifiés (http, ftp, pop...).
 
Mon problème est que, si par exemple un téléchargement est lancé, je n'arrive à pas à obtenir la quantité d'octets téléchargée.
Je vois les paquets passer dans les chaînes INPUT et OUTPUT de la table FILTER mais impossible de les isoler dans une règle comprenant à la fois le port source et l'adresse de destination dans le réseau derrière le routeur.
 
En effet, dans INPUT je peux récupérer tout ce qui vient du --sport 80 par exemple mais le paquet est à ce niveau destiné à mon routeur (donc -d @IP derrière routeur ne fonctionne pas).
Dans la chaîne OUTPUT, je peux récupérer tout ce qui est à destination de l'@IP réseau local mais aucune correspondance avec le port d'origine ne fonctionne.
 
J'imagine que le NAT est à l'origine de ce problème (réalisé en MASQUERADE en sortie sur l'interface WAN dans la chaîne POSTROUTING de la table nat).
 
Y a-t-il donc un moyen de récupérer en même temps dans une même règle le trafic à destination d'une @IP précise du réseau local et originaire d'un port particulier?
 
Merci pour votre aide qui me serait très précieuse :)


Message édité par josephorfeuil le 06-09-2009 à 21:38:05
Reply

Marsh Posté le 06-09-2009 à 11:34:47   

Reply

Marsh Posté le 06-09-2009 à 11:42:18    

Vue que le trafic est généré par et pour les équipements du réseau et non pas le firewall lui même, c'est dans la chaine FORWARD que tu dois regarder.

 

Mais netfilter/iptables n'est pas fait spécifiquement pour ça...

 

Regarde plutôt du côté de cacti/netflow ou autre outils de monitoring réseau


Message édité par o'gure le 06-09-2009 à 12:39:37

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 06-09-2009 à 11:51:12    

Oui j'ai déjà regardé du côté de cacti...
C'est bien mais le problème est qu'il me faut en quelque sorte quelque chose sur mesure. Si je veux celà avec des outils tiers, je devrais les adapter et je pense que ça me prendra plus de temps.
 
Quoi qu'il en soit, je pensais également que la décision de routage envoyait les paquets dans la chaîne forward.
Mais lorsque je regarde les compteurs et essaye de retrouver mes petits (octets correspondant au téléchargement d'un fichier par exemple) je ne les vois pas passer dans la chaîne FORWARD mais bel et bien dans input et output.
 
Alors, soit je n'ai pas la possibilité de matcher l' @IP dest (chaîne INPUT) soit le port source (chaîne OUTPUT) :(
 
J'ai bien des correspondances à la fois pour le port source et l'@IP dest dans la chaîne FORWARD mais le compte d'octets n'est pas le bon

Reply

Marsh Posté le 06-09-2009 à 11:57:07    

Voici les compteurs qui se remplissent bien (étonnament dans OUTPUT).
Ici 7M ont été téléchargés, ils sont envoyés dans une chaîne qui a l'adresse MAC correspodant à l'@IP de destination dans le réseau local.
Dans cette chaîne sont placés les différents protocoles à logger mais on se rend bien compte que le port source a alors du changer au niveau du noyau (très certainement à cause du NAT) et ne match donc aucune règle sauf celle qui log tout
 

Code :
  1. Chain OUTPUT (policy ACCEPT 5148 packets, 533K bytes)
  2. pkts bytes target     prot opt in     out     source               destination
  3. 5228 7278K 00:11:43:53:6f:7b  all  --  any    any     anywhere             192.168.6.12        state RELATED,ESTABLISHED
  4. Chain 00:11:43:53:6f:7b (1 references)
  5. pkts bytes target     prot opt in     out     source               destination
  6.     0     0 ACCEPT     tcp  --  any    any     anywhere             192.168.6.12        state RELATED,ESTABLISHED tcp spt:www
  7.     0     0 ACCEPT     tcp  --  any    any     anywhere             192.168.6.12        state RELATED,ESTABLISHED tcp spt:https
  8.     0     0 ACCEPT     tcp  --  any    any     anywhere             192.168.6.12        state RELATED,ESTABLISHED tcp spt:smtp
  9.     0     0 ACCEPT     tcp  --  any    any     anywhere             192.168.6.12        state RELATED,ESTABLISHED tcp spt:pop3
  10.     0     0 ACCEPT     tcp  --  any    any     anywhere             192.168.6.12        state RELATED,ESTABLISHED tcp spt:ftp
  11. 5228 7278K ACCEPT     all  --  any    any     anywhere             192.168.6.12        state RELATED,ESTABLISHED

Reply

Marsh Posté le 06-09-2009 à 21:41:11    

Bonsoir,
 
problème résolu donc :)
Merci tout de même à o'gure qui avait bel et bien raison sur le fait que les paquets auraient du revenir par la chaîne forward.
 
En fait, en reprenant tout à plat et en repartant d'un firewall vraiment basique, les paquets passaient bien par la chaîne forward.
 
C'est donc mon génial squid qui faisait que seules les requêtes http finalement revenaient par les chaînes input et output...
 
Bah ouais... c'est bien à lui que je demande les pages web (et donc au parfeu du routeur directement d'où la décision de routage...).
 
Bref merci et en tous cas ça marche


Message édité par josephorfeuil le 06-09-2009 à 21:42:09
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed