Un firewall et iptables. Dans la table "nat", en "POSTROUTING", j'ai
naturellement de la translation d'adresse.
Comment puis-je avoir les translation en cours ? Je m'explique : j'aimerai
demander au firewall la table des connexions avec translations qui sont en
cours, c'est-à-dire la liste des couples adresses-port sortant qui ont été
translatés.
Dans le message <news:clqtp6$l34$, *Xavier* tapota sur f.c.o.l.configuration :
Le champ « ASSURED » nous indique que la connexion a pu s'établir dans les deux sens et est donc suivie.
Même remarque qur précédemment ...
C'est-à-dire ? Je ne vois pas ce qu'on peut dire de plus sur ce champ.
Si j'ai "ASSURED", pas de problème. Par contre, si je ne l'ai pas, tout comme "UNREPLIED", il se peut qu'il y ait un problème (interne).
Quand on a ni l'un ni l'autre, alors il peut s'agir d'un protocole non géré (ipv6 par exemple) ou bien, par exemple lors de l'envoit d'un SYN dans une connexion TCP, si la réponse au SYN a eu lieu alors le champ UNREPLIED disparait mais tant que la connexion n'est pas passée à l'état ESTABLISHED elle ne peut être suivie et donc le champ ASSURED ne peut être présent.
Comme toujours, on n'a pas le besoin de ce qu'on ne connait pas ... Ma question initiale était bel et bien pour faire, en quelque sorte, du "contrôle de trafic" et notamment détecter des machines et/ou applications mal configurées qui polluaient le traffic.
Attention, quand je parle de contrôle de trafic, je parle de shapping, de régularisation de débit mais pas de la surveillance du trafic. Attention à ne pas utiliser /proc/net/ip_conntrack comme un moyen de surveiller les problèmes de réseau, ça n'est pas fait pour ça. C'est fait pour indiquer l'état actuel des connexions suivies ou non et on ne peut pas déduire les raisons pour lesquelles une connexion n'est pas suivie, elles peuvent être multiple.
Si je peux aller plus loin dans le sujet, peut-être par ce "-j MARK", ça m'intéresse !!
Je vous invite à lire le HowTo LARTC pour en savoir plus sur le sujet.
Merci (encore ...)
De rien.
-- TiChou
Dans le message <news:clqtp6$l34$1@biggoron.nerim.net>,
*Xavier* tapota sur f.c.o.l.configuration :
Le champ « ASSURED » nous indique que la connexion a pu s'établir dans
les deux sens et est donc suivie.
Même remarque qur précédemment ...
C'est-à-dire ? Je ne vois pas ce qu'on peut dire de plus sur ce champ.
Si j'ai "ASSURED", pas de problème. Par contre, si je ne l'ai pas, tout
comme "UNREPLIED", il se peut qu'il y ait un problème (interne).
Quand on a ni l'un ni l'autre, alors il peut s'agir d'un protocole non géré
(ipv6 par exemple) ou bien, par exemple lors de l'envoit d'un SYN dans une
connexion TCP, si la réponse au SYN a eu lieu alors le champ UNREPLIED
disparait mais tant que la connexion n'est pas passée à l'état ESTABLISHED
elle ne peut être suivie et donc le champ ASSURED ne peut être présent.
Comme toujours, on n'a pas le besoin de ce qu'on ne connait pas ...
Ma question initiale était bel et bien pour faire, en quelque sorte, du
"contrôle de trafic" et notamment détecter des machines et/ou applications
mal configurées qui polluaient le traffic.
Attention, quand je parle de contrôle de trafic, je parle de shapping, de
régularisation de débit mais pas de la surveillance du trafic. Attention à
ne pas utiliser /proc/net/ip_conntrack comme un moyen de surveiller les
problèmes de réseau, ça n'est pas fait pour ça. C'est fait pour indiquer
l'état actuel des connexions suivies ou non et on ne peut pas déduire les
raisons pour lesquelles une connexion n'est pas suivie, elles peuvent être
multiple.
Si je peux aller plus loin dans le sujet, peut-être par ce "-j MARK", ça
m'intéresse !!
Je vous invite à lire le HowTo LARTC pour en savoir plus sur le sujet.
Dans le message <news:clqtp6$l34$, *Xavier* tapota sur f.c.o.l.configuration :
Le champ « ASSURED » nous indique que la connexion a pu s'établir dans les deux sens et est donc suivie.
Même remarque qur précédemment ...
C'est-à-dire ? Je ne vois pas ce qu'on peut dire de plus sur ce champ.
Si j'ai "ASSURED", pas de problème. Par contre, si je ne l'ai pas, tout comme "UNREPLIED", il se peut qu'il y ait un problème (interne).
Quand on a ni l'un ni l'autre, alors il peut s'agir d'un protocole non géré (ipv6 par exemple) ou bien, par exemple lors de l'envoit d'un SYN dans une connexion TCP, si la réponse au SYN a eu lieu alors le champ UNREPLIED disparait mais tant que la connexion n'est pas passée à l'état ESTABLISHED elle ne peut être suivie et donc le champ ASSURED ne peut être présent.
Comme toujours, on n'a pas le besoin de ce qu'on ne connait pas ... Ma question initiale était bel et bien pour faire, en quelque sorte, du "contrôle de trafic" et notamment détecter des machines et/ou applications mal configurées qui polluaient le traffic.
Attention, quand je parle de contrôle de trafic, je parle de shapping, de régularisation de débit mais pas de la surveillance du trafic. Attention à ne pas utiliser /proc/net/ip_conntrack comme un moyen de surveiller les problèmes de réseau, ça n'est pas fait pour ça. C'est fait pour indiquer l'état actuel des connexions suivies ou non et on ne peut pas déduire les raisons pour lesquelles une connexion n'est pas suivie, elles peuvent être multiple.
Si je peux aller plus loin dans le sujet, peut-être par ce "-j MARK", ça m'intéresse !!
Je vous invite à lire le HowTo LARTC pour en savoir plus sur le sujet.
