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.
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.
/proc/net/ip_conntrack
"Xavier" wrote in message <clks1j$ib6$1@biggoron.nerim.net>:
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.
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.
/proc/net/ip_conntrack
Xavier
"Xavier" wrote in message <clks1j$ib6$:
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.
/proc/net/ip_conntrack
Super, merci !!
Xavier
"Xavier" wrote in message <clks1j$ib6$1@biggoron.nerim.net>:
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é
J'arrive à peu près à tirer des informations de ce fichier. Mais pour aller plus loin, je recherche son format exact, mais je ne le trouve pas.
Où puis-je trouver le format du fichier /proc/net/ip_conntrack ?
Merci
Xavier
Nicolas George
"Xavier" wrote in message <clob6u$2fi2$:
Où puis-je trouver le format du fichier /proc/net/ip_conntrack ?
Le mieux que je connaisse, c'est les sources du noyau. Sur un 2.6, c'est dans ip_conntrack_standalone.c (dans net/ipv4/netfilter/), à partir de la fonction list_conntracks.
"Xavier" wrote in message <clob6u$2fi2$1@biggoron.nerim.net>:
Où puis-je trouver le format du fichier /proc/net/ip_conntrack ?
Le mieux que je connaisse, c'est les sources du noyau. Sur un 2.6, c'est
dans ip_conntrack_standalone.c (dans net/ipv4/netfilter/), à partir de la
fonction list_conntracks.
Où puis-je trouver le format du fichier /proc/net/ip_conntrack ?
Le mieux que je connaisse, c'est les sources du noyau. Sur un 2.6, c'est dans ip_conntrack_standalone.c (dans net/ipv4/netfilter/), à partir de la fonction list_conntracks.
TiChou
Dans le message <news:clob6u$2fi2$, *Xavier* tapota sur f.c.o.l.configuration :
/proc/net/ip_conntrack
J'arrive à peu près à tirer des informations de ce fichier.
Je vous invite à tester le script conntrack-viewer :
http://cv.intellos.net/
Mais pour aller plus loin, je recherche son format exact, mais je ne le trouve pas. Où puis-je trouver le format du fichier /proc/net/ip_conntrack ?
Voir la réponse de Nicolas George.
Pour entrer un peu dans les détails, commentons la ligne suivante :
Les deux premiers champ correspondent au nom du protocole (tcp, udp, ipv6, icmp, ...) et à son numéro (voir fichier /etc/protocols).
Le champ suivant (431999) est le temps restant en seconde durant lequel l'entrée doit rester dans la table ip_conntrack. Si la connexion change d'état, l'entrée disparaît avant que ce temps soit écoulé.
Le champ « ESTABLISHED », présent uniquement pour les connexion tcp, est l'état de la connexion tcp. Ça peut être ESTABLISHED, TIME_WAIT, SYN_SENT, etc.
Les 4 champs suivant, src, dst, sport et dport, correspondent respectivement à l'adresse IP source, à l'adresse IP de destination, au port source et au port de destination d'une connexion avant tout processus de NAT (s'il y a lieu d'être). Bien sûr, les champs sport et dport ne sont présents que pour les connexions faites dans les protocoles TCP et UDP et ils n'apparaissent pas si la connexion se fait dans un autre protocole.
Ici ce n'est pas le cas, mais on peut avoir la présence du champ « UNREPLIED » qui nous indique alors qu'il n'y a pas eu de réponse à la connexion, aucun paquet en retour.
Les 4 autres champs suivant correspondent à la même chose mais après le processus de NAT. Si les champs sont identiques avec les précédents on peut alors déduire qu'il s'agit d'une connexion qui n'est pas « NATée », généralement une connexion issue d'un processus local.
Le champ « ASSURED » nous indique que la connexion a pu s'établir dans les deux sens et est donc suivie.
Pour le champ « use », je ne sais pas, je n'ai dans le passé jamais rien trouvé d'intéressant... faudrait que j'approfondisse.
Et enfin le dernier champ nous donne la valeur du mark pour les paquets qui auraient été marqués avec la cible '-j MARK' de la commande 'iptables' dans la table mangle, très utile pour le contrôle de trafic, le QoS, pour débugger, etc.
Je pense n'avoir rien oublié.
Merci
De rien.
-- TiChou
Dans le message <news:clob6u$2fi2$1@biggoron.nerim.net>,
*Xavier* tapota sur f.c.o.l.configuration :
/proc/net/ip_conntrack
J'arrive à peu près à tirer des informations de ce fichier.
Je vous invite à tester le script conntrack-viewer :
http://cv.intellos.net/
Mais pour aller plus loin, je recherche son format exact, mais je ne le
trouve pas.
Où puis-je trouver le format du fichier /proc/net/ip_conntrack ?
Voir la réponse de Nicolas George.
Pour entrer un peu dans les détails, commentons la ligne suivante :
Les deux premiers champ correspondent au nom du protocole (tcp, udp, ipv6,
icmp, ...) et à son numéro (voir fichier /etc/protocols).
Le champ suivant (431999) est le temps restant en seconde durant lequel
l'entrée doit rester dans la table ip_conntrack. Si la connexion change
d'état, l'entrée disparaît avant que ce temps soit écoulé.
Le champ « ESTABLISHED », présent uniquement pour les connexion tcp, est
l'état de la connexion tcp. Ça peut être ESTABLISHED, TIME_WAIT, SYN_SENT,
etc.
Les 4 champs suivant, src, dst, sport et dport, correspondent respectivement
à l'adresse IP source, à l'adresse IP de destination, au port source et au
port de destination d'une connexion avant tout processus de NAT (s'il y a
lieu d'être). Bien sûr, les champs sport et dport ne sont présents que pour
les connexions faites dans les protocoles TCP et UDP et ils n'apparaissent
pas si la connexion se fait dans un autre protocole.
Ici ce n'est pas le cas, mais on peut avoir la présence du champ «
UNREPLIED » qui nous indique alors qu'il n'y a pas eu de réponse à la
connexion, aucun paquet en retour.
Les 4 autres champs suivant correspondent à la même chose mais après le
processus de NAT. Si les champs sont identiques avec les précédents on peut
alors déduire qu'il s'agit d'une connexion qui n'est pas « NATée »,
généralement une connexion issue d'un processus local.
Le champ « ASSURED » nous indique que la connexion a pu s'établir dans les
deux sens et est donc suivie.
Pour le champ « use », je ne sais pas, je n'ai dans le passé jamais rien
trouvé d'intéressant... faudrait que j'approfondisse.
Et enfin le dernier champ nous donne la valeur du mark pour les paquets qui
auraient été marqués avec la cible '-j MARK' de la commande 'iptables' dans
la table mangle, très utile pour le contrôle de trafic, le QoS, pour
débugger, etc.
Les deux premiers champ correspondent au nom du protocole (tcp, udp, ipv6, icmp, ...) et à son numéro (voir fichier /etc/protocols).
Le champ suivant (431999) est le temps restant en seconde durant lequel l'entrée doit rester dans la table ip_conntrack. Si la connexion change d'état, l'entrée disparaît avant que ce temps soit écoulé.
Le champ « ESTABLISHED », présent uniquement pour les connexion tcp, est l'état de la connexion tcp. Ça peut être ESTABLISHED, TIME_WAIT, SYN_SENT, etc.
Les 4 champs suivant, src, dst, sport et dport, correspondent respectivement à l'adresse IP source, à l'adresse IP de destination, au port source et au port de destination d'une connexion avant tout processus de NAT (s'il y a lieu d'être). Bien sûr, les champs sport et dport ne sont présents que pour les connexions faites dans les protocoles TCP et UDP et ils n'apparaissent pas si la connexion se fait dans un autre protocole.
Ici ce n'est pas le cas, mais on peut avoir la présence du champ « UNREPLIED » qui nous indique alors qu'il n'y a pas eu de réponse à la connexion, aucun paquet en retour.
Les 4 autres champs suivant correspondent à la même chose mais après le processus de NAT. Si les champs sont identiques avec les précédents on peut alors déduire qu'il s'agit d'une connexion qui n'est pas « NATée », généralement une connexion issue d'un processus local.
Le champ « ASSURED » nous indique que la connexion a pu s'établir dans les deux sens et est donc suivie.
Pour le champ « use », je ne sais pas, je n'ai dans le passé jamais rien trouvé d'intéressant... faudrait que j'approfondisse.
Et enfin le dernier champ nous donne la valeur du mark pour les paquets qui auraient été marqués avec la cible '-j MARK' de la commande 'iptables' dans la table mangle, très utile pour le contrôle de trafic, le QoS, pour débugger, etc.
Les 4 champs suivant, src, dst, sport et dport, correspondent respectivement à l'adresse IP source, à l'adresse IP de destination, au port source et au port de destination d'une connexion avant tout processus de NAT (s'il y a lieu d'être). [...]
Les 4 autres champs suivant correspondent à la même chose mais après le processus de NAT. Si les champs sont identiques avec les précédents on peut alors déduire qu'il s'agit d'une connexion qui n'est pas « NATée », généralement une connexion issue d'un processus local.
J'ai compris la chose un peu différemment, voici comment je l'explique.
Le premier quartet {src, dst, sport, dport} correspond aux adresses et ports sources et destinations contenus dans l'en-tête des paquets "aller" tels qu'ils entrent dans Netfilter avant toute opération de NAT, par la chaîne PREROUTING s'ils de l'extérieur, ou par la chaîne OUTPUT s'ils viennent de la machine elle-même. Le sens de "aller" est ici défini comme similaire au premier paquet vu ayant initié la connexion quelles que soient sa source et sa destination.
Le second quartet correspond aux adresses et ports sources et destinations contenus dans l'en-tête des paquets "retour" tels que Netfilter s'attend à les reconnaître à leur arrivée par les mêmes chaînes que précédemment, donc également avant toute opération de NAT. Le sens de "retour" est ici défini comme réponse attendue aux paquets aller. Ces paquets étant supposés être symétriques par rapport aux paquets aller sortis de Netfilter, le quartet tient évidemment compte des opérations de NAT qui sont réalisées sur ces derniers.
Dans l'exemple donné qui ne comporte pas de NAT, le quartet retour est parfaitement symétrique par rapport au quartet aller, les adresses et ports sources et destinations sont simplement permutés.
Dans le cas d'une connexion avec NAT (cas un peu tordu) :
Les 4 champs suivant, src, dst, sport et dport, correspondent
respectivement à l'adresse IP source, à l'adresse IP de destination, au
port source et au port de destination d'une connexion avant tout
processus de NAT (s'il y a lieu d'être).
[...]
Les 4 autres champs suivant correspondent à la même chose mais après le
processus de NAT. Si les champs sont identiques avec les précédents on
peut alors déduire qu'il s'agit d'une connexion qui n'est pas « NATée »,
généralement une connexion issue d'un processus local.
J'ai compris la chose un peu différemment, voici comment je l'explique.
Le premier quartet {src, dst, sport, dport} correspond aux adresses et
ports sources et destinations contenus dans l'en-tête des paquets
"aller" tels qu'ils entrent dans Netfilter avant toute opération de NAT,
par la chaîne PREROUTING s'ils de l'extérieur, ou par la chaîne OUTPUT
s'ils viennent de la machine elle-même. Le sens de "aller" est ici
défini comme similaire au premier paquet vu ayant initié la connexion
quelles que soient sa source et sa destination.
Le second quartet correspond aux adresses et ports sources et
destinations contenus dans l'en-tête des paquets "retour" tels que
Netfilter s'attend à les reconnaître à leur arrivée par les mêmes
chaînes que précédemment, donc également avant toute opération de NAT.
Le sens de "retour" est ici défini comme réponse attendue aux paquets
aller. Ces paquets étant supposés être symétriques par rapport aux
paquets aller sortis de Netfilter, le quartet tient évidemment compte
des opérations de NAT qui sont réalisées sur ces derniers.
Dans l'exemple donné qui ne comporte pas de NAT, le quartet retour est
parfaitement symétrique par rapport au quartet aller, les adresses et
ports sources et destinations sont simplement permutés.
Dans le cas d'une connexion avec NAT (cas un peu tordu) :
Les 4 champs suivant, src, dst, sport et dport, correspondent respectivement à l'adresse IP source, à l'adresse IP de destination, au port source et au port de destination d'une connexion avant tout processus de NAT (s'il y a lieu d'être). [...]
Les 4 autres champs suivant correspondent à la même chose mais après le processus de NAT. Si les champs sont identiques avec les précédents on peut alors déduire qu'il s'agit d'une connexion qui n'est pas « NATée », généralement une connexion issue d'un processus local.
J'ai compris la chose un peu différemment, voici comment je l'explique.
Le premier quartet {src, dst, sport, dport} correspond aux adresses et ports sources et destinations contenus dans l'en-tête des paquets "aller" tels qu'ils entrent dans Netfilter avant toute opération de NAT, par la chaîne PREROUTING s'ils de l'extérieur, ou par la chaîne OUTPUT s'ils viennent de la machine elle-même. Le sens de "aller" est ici défini comme similaire au premier paquet vu ayant initié la connexion quelles que soient sa source et sa destination.
Le second quartet correspond aux adresses et ports sources et destinations contenus dans l'en-tête des paquets "retour" tels que Netfilter s'attend à les reconnaître à leur arrivée par les mêmes chaînes que précédemment, donc également avant toute opération de NAT. Le sens de "retour" est ici défini comme réponse attendue aux paquets aller. Ces paquets étant supposés être symétriques par rapport aux paquets aller sortis de Netfilter, le quartet tient évidemment compte des opérations de NAT qui sont réalisées sur ces derniers.
Dans l'exemple donné qui ne comporte pas de NAT, le quartet retour est parfaitement symétrique par rapport au quartet aller, les adresses et ports sources et destinations sont simplement permutés.
Dans le cas d'une connexion avec NAT (cas un peu tordu) :
Ici le paquet aller, généré localement, correspond au quartet suivant quand il arrive à l'entrée de la chaîne OUTPUT :
{src!3.41.173.35 dst!3.41.173.35 sport55}
C'est le premier quartet de la ligne de /proc/net/ip_conntrack. Il subit une opération de NAT destination (DNAT) dans la table OUTPUT :
213.41.173.35:222 -> 192.168.0.242:22
suivie d'une opération de NAT source (SNAT) automatique à cause du changement d'interface de sortie :
213.41.173.35:1255 -> 192.168.0.1:1255
Après la traversée de Netfilter, le paquet aller correspond au quartet suivant :
{src2.168.0.1 dst2.168.0.242 sport55 dport"}
Et le paquet retour attendu en réponse est symétrique :
{src2.168.0.242 dst2.168.0.1 sport" dport55}
C'est le second quartet de la ligne de /proc/net/ip_conntrack.
TiChou
Dans le message <news:clopcb$2o70$, ** tapota sur f.c.o.l.configuration :
Le second quartet correspond aux adresses et ports sources et destinations contenus dans l'en-tête des paquets "retour" tels que Netfilter s'attend à les reconnaître à leur arrivée par les mêmes chaînes que précédemment, donc également avant toute opération de NAT. Le sens de "retour" est ici défini comme réponse attendue aux paquets aller.
Au temps pour moi, vous avez raison. Ce second quartet correspond effectivement bien ce à quoi Netfilter s'attend à voir des paquets de retour.
-- TiChou
Dans le message <news:clopcb$2o70$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :
Le second quartet correspond aux adresses et ports sources et destinations
contenus dans l'en-tête des paquets "retour" tels que Netfilter s'attend à
les reconnaître à leur arrivée par les mêmes chaînes que précédemment,
donc également avant toute opération de NAT. Le sens de "retour" est ici
défini comme réponse attendue aux paquets aller.
Au temps pour moi, vous avez raison. Ce second quartet correspond
effectivement bien ce à quoi Netfilter s'attend à voir des paquets de
retour.
Dans le message <news:clopcb$2o70$, ** tapota sur f.c.o.l.configuration :
Le second quartet correspond aux adresses et ports sources et destinations contenus dans l'en-tête des paquets "retour" tels que Netfilter s'attend à les reconnaître à leur arrivée par les mêmes chaînes que précédemment, donc également avant toute opération de NAT. Le sens de "retour" est ici défini comme réponse attendue aux paquets aller.
Au temps pour moi, vous avez raison. Ce second quartet correspond effectivement bien ce à quoi Netfilter s'attend à voir des paquets de retour.
-- TiChou
Xavier
Salut,
Merci pour tes précisions. Pour les champs avec addresses et port, pour moi, c'était bon. C'était plus les autres champs que je n'expliquais pas vraiment.
Ici ce n'est pas le cas, mais on peut avoir la présence du champ « UNREPLIED » qui nous indique alors qu'il n'y a pas eu de réponse à la connexion, aucun paquet en retour.
C'est par exemple ce champ qui attirait mon attention. Es-tu d'accord pour dire que s'il y a ce champ "UNREPLIED", c'est qu'il y a un problème ? En tout cas, c'est ce que j'ai observé (j'avais sur mon réseau des machines qui cherchait des adresses inexistantes).
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 ...
Pour le champ « use », je ne sais pas, je n'ai dans le passé jamais rien trouvé d'intéressant... faudrait que j'approfondisse.
Bon, je l'oublie ...
Et enfin le dernier champ nous donne la valeur du mark pour les paquets qui
auraient été marqués avec la cible '-j MARK' de la commande 'iptables' dans
la table mangle, très utile pour le contrôle de trafic, le QoS, pour débugger, etc.
Ca, je ne connais pas (et donc je n'utilise pas). Peut-il y avoir un intérêt (dans mon cas, utilisation en Firewall) ?
Merci
Xavier
Salut,
Merci pour tes précisions. Pour les champs avec addresses et port, pour moi,
c'était bon. C'était plus les autres champs que je n'expliquais pas
vraiment.
Ici ce n'est pas le cas, mais on peut avoir la présence du champ «
UNREPLIED » qui nous indique alors qu'il n'y a pas eu de réponse à la
connexion, aucun paquet en retour.
C'est par exemple ce champ qui attirait mon attention. Es-tu d'accord pour
dire que s'il y a ce champ "UNREPLIED", c'est qu'il y a un problème ? En
tout cas, c'est ce que j'ai observé (j'avais sur mon réseau des machines qui
cherchait des adresses inexistantes).
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 ...
Pour le champ « use », je ne sais pas, je n'ai dans le passé jamais rien
trouvé d'intéressant... faudrait que j'approfondisse.
Bon, je l'oublie ...
Et enfin le dernier champ nous donne la valeur du mark pour les paquets
qui
auraient été marqués avec la cible '-j MARK' de la commande 'iptables'
dans
la table mangle, très utile pour le contrôle de trafic, le QoS, pour
débugger, etc.
Ca, je ne connais pas (et donc je n'utilise pas). Peut-il y avoir un intérêt
(dans mon cas, utilisation en Firewall) ?
Merci pour tes précisions. Pour les champs avec addresses et port, pour moi, c'était bon. C'était plus les autres champs que je n'expliquais pas vraiment.
Ici ce n'est pas le cas, mais on peut avoir la présence du champ « UNREPLIED » qui nous indique alors qu'il n'y a pas eu de réponse à la connexion, aucun paquet en retour.
C'est par exemple ce champ qui attirait mon attention. Es-tu d'accord pour dire que s'il y a ce champ "UNREPLIED", c'est qu'il y a un problème ? En tout cas, c'est ce que j'ai observé (j'avais sur mon réseau des machines qui cherchait des adresses inexistantes).
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 ...
Pour le champ « use », je ne sais pas, je n'ai dans le passé jamais rien trouvé d'intéressant... faudrait que j'approfondisse.
Bon, je l'oublie ...
Et enfin le dernier champ nous donne la valeur du mark pour les paquets qui
auraient été marqués avec la cible '-j MARK' de la commande 'iptables' dans
la table mangle, très utile pour le contrôle de trafic, le QoS, pour débugger, etc.
Ca, je ne connais pas (et donc je n'utilise pas). Peut-il y avoir un intérêt (dans mon cas, utilisation en Firewall) ?
Merci
Xavier
TiChou
Dans le message <news:clq73o$9fe$, *Xavier* tapota sur f.c.o.l.configuration :
Ici ce n'est pas le cas, mais on peut avoir la présence du champ « UNREPLIED » qui nous indique alors qu'il n'y a pas eu de réponse à la connexion, aucun paquet en retour.
C'est par exemple ce champ qui attirait mon attention. Es-tu d'accord pour dire que s'il y a ce champ "UNREPLIED", c'est qu'il y a un problème ?
Non, pas obligatoirement. Il peut y avoir un refus volontaire de l'hôte à répondre, il peut y avoir un certain temps de latence avant que le paquet retour arrive, l'hôte peut tout simplement ne pas être disponible, etc. Ce champ ne fait juste indiquer que pas de retour, les raisons pouvant être diverses.
En tout cas, c'est ce que j'ai observé (j'avais sur mon réseau des machines qui cherchait des adresses inexistantes).
Effectivement dans ce cas on aura ce champ.
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.
Et enfin le dernier champ nous donne la valeur du mark pour les paquets qui auraient été marqués avec la cible '-j MARK' de la commande 'iptables' dans la table mangle, très utile pour le contrôle de trafic, le QoS, pour débugger, etc.
Ca, je ne connais pas (et donc je n'utilise pas). Peut-il y avoir un intérêt (dans mon cas, utilisation en Firewall) ?
Comme je l'ai dit, l'intérêt il est dans par exemple le contrôle de trafic, si vous n'avez pas ce besoin, alors vous pouvez oublier ce champ.
Merci
De rien.
-- TiChou
Dans le message <news:clq73o$9fe$1@biggoron.nerim.net>,
*Xavier* tapota sur f.c.o.l.configuration :
Ici ce n'est pas le cas, mais on peut avoir la présence du champ «
UNREPLIED » qui nous indique alors qu'il n'y a pas eu de réponse à la
connexion, aucun paquet en retour.
C'est par exemple ce champ qui attirait mon attention. Es-tu d'accord pour
dire que s'il y a ce champ "UNREPLIED", c'est qu'il y a un problème ?
Non, pas obligatoirement. Il peut y avoir un refus volontaire de l'hôte à
répondre, il peut y avoir un certain temps de latence avant que le paquet
retour arrive, l'hôte peut tout simplement ne pas être disponible, etc.
Ce champ ne fait juste indiquer que pas de retour, les raisons pouvant être
diverses.
En tout cas, c'est ce que j'ai observé (j'avais sur mon réseau des
machines
qui cherchait des adresses inexistantes).
Effectivement dans ce cas on aura ce champ.
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.
Et enfin le dernier champ nous donne la valeur du mark pour les paquets
qui auraient été marqués avec la cible '-j MARK' de la commande
'iptables'
dans la table mangle, très utile pour le contrôle de trafic, le QoS, pour
débugger, etc.
Ca, je ne connais pas (et donc je n'utilise pas). Peut-il y avoir un
intérêt (dans mon cas, utilisation en Firewall) ?
Comme je l'ai dit, l'intérêt il est dans par exemple le contrôle de trafic,
si vous n'avez pas ce besoin, alors vous pouvez oublier ce champ.
Dans le message <news:clq73o$9fe$, *Xavier* tapota sur f.c.o.l.configuration :
Ici ce n'est pas le cas, mais on peut avoir la présence du champ « UNREPLIED » qui nous indique alors qu'il n'y a pas eu de réponse à la connexion, aucun paquet en retour.
C'est par exemple ce champ qui attirait mon attention. Es-tu d'accord pour dire que s'il y a ce champ "UNREPLIED", c'est qu'il y a un problème ?
Non, pas obligatoirement. Il peut y avoir un refus volontaire de l'hôte à répondre, il peut y avoir un certain temps de latence avant que le paquet retour arrive, l'hôte peut tout simplement ne pas être disponible, etc. Ce champ ne fait juste indiquer que pas de retour, les raisons pouvant être diverses.
En tout cas, c'est ce que j'ai observé (j'avais sur mon réseau des machines qui cherchait des adresses inexistantes).
Effectivement dans ce cas on aura ce champ.
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.
Et enfin le dernier champ nous donne la valeur du mark pour les paquets qui auraient été marqués avec la cible '-j MARK' de la commande 'iptables' dans la table mangle, très utile pour le contrôle de trafic, le QoS, pour débugger, etc.
Ca, je ne connais pas (et donc je n'utilise pas). Peut-il y avoir un intérêt (dans mon cas, utilisation en Firewall) ?
Comme je l'ai dit, l'intérêt il est dans par exemple le contrôle de trafic, si vous n'avez pas ce besoin, alors vous pouvez oublier ce champ.
Merci
De rien.
-- TiChou
Xavier
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).
Comme je l'ai dit, l'intérêt il est dans par exemple le contrôle de trafic,
si vous n'avez pas ce besoin, alors vous pouvez oublier ce champ.
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. Si je peux aller plus loin dans le sujet, peut-être par ce "-j MARK", ça m'intéresse !!
Merci (encore ...)
Xavier
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).
Comme je l'ai dit, l'intérêt il est dans par exemple le contrôle de
trafic,
si vous n'avez pas ce besoin, alors vous pouvez oublier ce champ.
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. Si je peux aller plus loin dans
le sujet, peut-être par ce "-j MARK", ça m'intéresse !!
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).
Comme je l'ai dit, l'intérêt il est dans par exemple le contrôle de trafic,
si vous n'avez pas ce besoin, alors vous pouvez oublier ce champ.
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. Si je peux aller plus loin dans le sujet, peut-être par ce "-j MARK", ça m'intéresse !!
