Je sais que mon poste n'est pas relatif a debian, mais en desespoir de
cause....
J'ai aquit un WRT54GL et l'ai flash=E9 en dd'wrt, donc en linux.
Iptables tourne dessus.
Plan reseau:
WWW ----- WRT54GL ---- LAN
Sur mon reseau LAN, j'ai install=E9 un serveur DNS pour mon reseau local, c=
a
fonctionne bien. Ce dns gerre aussi mon domaine sur internet.
Il me faut donc rediriger toutes les requette qui viennent d'internet sur l=
e
port 53 vers mon serveur DNS interne, et que ce dns interne renvois la
reponse =E0 son expediteur sur le net.
J'ai donc plac=E9 une regle PREROUTING qui DNAT mon port:
Ca ne marche pas. J'ai fait pareil avec le port 80 tcp pour ecarter une
erreur de mon dns.
J'ai donc essay=E9 ca (53 et 80):
$IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT
$IPTABLES -t nat -A PREROUTING -p udp -i $IP_WAN --dport 53 -j DNAT
--to-destination $MOE:53
Idem, aucun resultat.
Je precise que par defaut, j'ai INPUT OUTPUT FORWARD a ACCEPT
Du coup, je vois pas trop comment faire pour que mon serveur MOE soit
accessible depuis internet sur ses port 53 et 80.
J'ai essay=E9 d'autres solutions trouv=E9es sur le net, et aucuns resultats=
. En
bref, je suis en train de m'arracher les cheuveux depuis 3 jours...
Bonjour,<br><br>Je sais que mon poste n'est pas relatif a debian, mais =
en desespoir de cause....<br><br>J'ai aquit un WRT54GL et l'ai flas=
h=E9 en dd'wrt, donc en linux.<br>Iptables tourne dessus.<br><br>Plan r=
eseau:
<br>WWW ----- WRT54GL ---- LAN<br><br>Sur mon reseau LAN, j'ai install=
=E9 un serveur DNS pour mon reseau local, ca fonctionne bien. Ce dns gerre =
aussi mon domaine sur internet.<br>Il me faut donc rediriger toutes les req=
uette qui viennent d'internet sur le port 53 vers mon serveur DNS inter=
ne, et que ce dns interne renvois la reponse =E0 son expediteur sur le net.
<br><br>J'ai donc plac=E9 une regle PREROUTING qui DNAT mon port:<br><b=
r>$IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT<br>$IP=
TABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT<br>$IPTABL=
ES -t nat -A PREROUTING -p udp -d $IP_WAN --dport 53 -j DNAT --to-destinati=
on $MOE:53
<br><br>Ca ne marche pas. J'ai fait pareil avec le port 80 tcp pour eca=
rter une erreur de mon dns.<br>J'ai donc essay=E9 ca (53 et 80):<br>$IP=
TABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT<br>
$IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT<br>
$IPTABLES -t nat -A PREROUTING -p udp -i $IP_WAN --dport 53 -j DNAT --to-de=
stination $MOE:53<br><br>Idem, aucun resultat.<br>Je precise que par defaut=
, j'ai INPUT OUTPUT FORWARD a ACCEPT<br><br>Du coup, je vois pas trop c=
omment faire pour que mon serveur MOE soit accessible depuis internet sur s=
es port 53 et 80.
<br>J'ai essay=E9 d'autres solutions trouv=E9es sur le net, et aucu=
ns resultats. En bref, je suis en train de m'arracher les cheuveux depu=
is 3 jours...<br><br>merci d'avance pour toute piste ou solution.<br>
<br>
------=_Part_119032_15621868.1175523472860--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Mercredi 04 Avril 2007 23:24, Pascal Hambourg a écrit :
Serge Cavailles a écrit : >>Note toutefois que le suivi de connexion de >>Netfilter a ses limites, sauf aide d'un module "helper" pour certains >>protocoles particuliers.
[...]
>>Autre exemple, il ne sait pas reconnaître >>tout seul la réponse à une requête TFTP (en UDP) car le port sour ce >> dans le paquet de réponse du serveur est différent du port destina tion >> dans le paquet de requête du client. Pour des protocoles aussi >> courants que Netbios et TFTP, il existe des modules "helpers" > > De manière similaire à ce qui existe pour FTP (en TCP) pour les m êmes > raisons. Ok.
Plus ou moins, car TFTP est vraiment spécial. En FTP, du point de vue réseau la connexion TCP de données est totalement indépendante de la connexion TCP de contrôle. En TFTP c'est un peu bâtard : la réponse est envoyée par le serveur depuis un port UDP source différent du port TF TP ayant reçu la requête mais vers le même port UDP destination que le port source utilisé par la requête du client. C'est d'ailleurs grâce à cette particularité que le helper reconnaît la réponse.
Cela veut-il dire que les paquets en provenance du serveur par cette 2e voi e sont considérés RELATED? La question me vient suite aux questionnements de Franck.
[snip]
> Oui, j'ai une gestion 'explicite' de l'ICMP actuellement
Moi aussi en fait : comme je suis un peu parano, je n'accepte pas tous les types ICMP qui sont classés dans l'état RELATED mais seulement ce ux que je considère comme indispensables (destination unreachable, time exceeded, parameter problem). Idem pour les ICMP classés NEW : seul echo request (ping) est accepté. En revanche tous les ICMP classés ESTABLISHED sont acceptés : s'ils sont dans cet état, c'est qu'ils ont été sollicités, donc il n'y a pas de raison de les bloquer.
> qui n'a donc pas lieu d'exister.
Disons qu'il y a moyen de simplifier la gestion des ICMP ESTABLISHED.
Oui. Je me suis mal exprimé.
Pour les autres états, c'est selon ses goûts.
Restons donc parano^W raisonablement optimiste ;)
Merci pour ces infos. -- Serge
Le Mercredi 04 Avril 2007 23:24, Pascal Hambourg a écrit :
Serge Cavailles a écrit :
>>Note toutefois que le suivi de connexion de
>>Netfilter a ses limites, sauf aide d'un module "helper" pour certains
>>protocoles particuliers.
[...]
>>Autre exemple, il ne sait pas reconnaître
>>tout seul la réponse à une requête TFTP (en UDP) car le port sour ce
>> dans le paquet de réponse du serveur est différent du port destina tion
>> dans le paquet de requête du client. Pour des protocoles aussi
>> courants que Netbios et TFTP, il existe des modules "helpers"
>
> De manière similaire à ce qui existe pour FTP (en TCP) pour les m êmes
> raisons. Ok.
Plus ou moins, car TFTP est vraiment spécial. En FTP, du point de vue
réseau la connexion TCP de données est totalement indépendante de la
connexion TCP de contrôle. En TFTP c'est un peu bâtard : la réponse est
envoyée par le serveur depuis un port UDP source différent du port TF TP
ayant reçu la requête mais vers le même port UDP destination que le port
source utilisé par la requête du client. C'est d'ailleurs grâce à cette
particularité que le helper reconnaît la réponse.
Cela veut-il dire que les paquets en provenance du serveur par cette 2e voi e
sont considérés RELATED? La question me vient suite aux questionnements de
Franck.
[snip]
> Oui, j'ai une gestion 'explicite' de l'ICMP actuellement
Moi aussi en fait : comme je suis un peu parano, je n'accepte pas tous
les types ICMP qui sont classés dans l'état RELATED mais seulement ce ux
que je considère comme indispensables (destination unreachable, time
exceeded, parameter problem). Idem pour les ICMP classés NEW : seul echo
request (ping) est accepté. En revanche tous les ICMP classés
ESTABLISHED sont acceptés : s'ils sont dans cet état, c'est qu'ils ont
été sollicités, donc il n'y a pas de raison de les bloquer.
> qui n'a donc pas lieu d'exister.
Disons qu'il y a moyen de simplifier la gestion des ICMP ESTABLISHED.
Le Mercredi 04 Avril 2007 23:24, Pascal Hambourg a écrit :
Serge Cavailles a écrit : >>Note toutefois que le suivi de connexion de >>Netfilter a ses limites, sauf aide d'un module "helper" pour certains >>protocoles particuliers.
[...]
>>Autre exemple, il ne sait pas reconnaître >>tout seul la réponse à une requête TFTP (en UDP) car le port sour ce >> dans le paquet de réponse du serveur est différent du port destina tion >> dans le paquet de requête du client. Pour des protocoles aussi >> courants que Netbios et TFTP, il existe des modules "helpers" > > De manière similaire à ce qui existe pour FTP (en TCP) pour les m êmes > raisons. Ok.
Plus ou moins, car TFTP est vraiment spécial. En FTP, du point de vue réseau la connexion TCP de données est totalement indépendante de la connexion TCP de contrôle. En TFTP c'est un peu bâtard : la réponse est envoyée par le serveur depuis un port UDP source différent du port TF TP ayant reçu la requête mais vers le même port UDP destination que le port source utilisé par la requête du client. C'est d'ailleurs grâce à cette particularité que le helper reconnaît la réponse.
Cela veut-il dire que les paquets en provenance du serveur par cette 2e voi e sont considérés RELATED? La question me vient suite aux questionnements de Franck.
[snip]
> Oui, j'ai une gestion 'explicite' de l'ICMP actuellement
Moi aussi en fait : comme je suis un peu parano, je n'accepte pas tous les types ICMP qui sont classés dans l'état RELATED mais seulement ce ux que je considère comme indispensables (destination unreachable, time exceeded, parameter problem). Idem pour les ICMP classés NEW : seul echo request (ping) est accepté. En revanche tous les ICMP classés ESTABLISHED sont acceptés : s'ils sont dans cet état, c'est qu'ils ont été sollicités, donc il n'y a pas de raison de les bloquer.
> qui n'a donc pas lieu d'exister.
Disons qu'il y a moyen de simplifier la gestion des ICMP ESTABLISHED.
Oui. Je me suis mal exprimé.
Pour les autres états, c'est selon ses goûts.
Restons donc parano^W raisonablement optimiste ;)
Merci pour ces infos. -- Serge
Pascal Hambourg
Serge Cavailles a écrit :
Le Mercredi 04 Avril 2007 23:54, Franck Joncourt a écrit :
De maniere generale, pour le suivi de connexion, cela se presente de la facon suivante :
## ICMP : echo-request/echo-reply : NEW > ESTABLISHED autres : NEW > RELATED
Je ne suis pas certain de comprendre ce que signifie ce NEW > RELATED. Il y a d'autres types ICMP avec un schéma requête/réponse que l'echo qui doivent prendre les états NEW et ESTABLISHED : timestamp, information, address mask... Les types ICMP correspondant à des messages d'erreurs sont bien sûr dans l'état RELATED quand ils sont liés à une "connexion" existante, mais ne sont pas forcément émis en réponse à un paquet dans l'état NEW. Par exemple : fragmentation needed pour un paquet ESTABLISHED trop gros appartenant à une connexion déjà établie.
## TCP : NEW, RELATED, ESTABLISHED
## UDP : NEW, ESTABLISHED
On peut trouver des paquets RELATED en UDP aussi, ainsi que dans d'autres protocoles de niveau 4 (couche transport). Je pense notamment au tunnel GRE (protocole n° 41) des VPN PPTP.
L'etat RELATED associé aux connexions TCP n'existe que grace aux modules de suivi de connexion conntrack specifiques.
Idem pour UDP et les autres protocoles de couche transport.
Oui. Ce qui m'amène à me demander si on ne peut pas en dire autant à propos de l'UDP , et considérer donc que, dans le cas par exemple du TFTP cité par Pascal, RELATED puisse aussi s'appliquer en UDP aux paquets de la connexion 'retour' initiée par le serveur.
Je n'ai pas vérifié le cas de TFTP (ou bien c'était il y a longtemps et j'ai oublié) mais ce serait logique. Même chose pour SIP, RTSP...
Je vois ce dernier comme la *dérivation* d'une connexion qualifiée comme ESTABLISHED. Vous voyez cela comment ?
Je ne suis pas certain de bien "voir" ce que tu veux dire. Il faut que le paquet soit lié à une "connexion" *existante* (connue par le suivi de connexion), pas forcément à une connexion établie (qui a engendré du trafic dans les deux sens). Par exemple un ICMP port unreachable en réponse à un TCP SYN ou une requête UDP (par exemple DNS) qui sont dans l'état NEW sans qu'il y ait eu de connexion établie. Quand l'état RELATED concerne une vraie connexion liée (connexion de données en FTP, tunnel GRE en PPTP...) il remplace l'état NEW du premier paquet de cette connexion.
Celà ne traduit pas pleinement à mon sens qu'il s'agit de "connexions" _distinctes_ qui sont *induites*(1) par la "connexion" initiale. Le terme connexion désigne ici plutôt un canal de communication s'il doit aussi être applicable pour l'udp.
Les guillements sont de rigueur, particulièrement quand la "connexion" est en fait un simple message d'erreur ICMP. C'est d'ailleurs le seul type de paquet qui peut être classé dans l'état RELATED par le suivi de connexion de base sans helper spécifique, car ICMP fait partie intégrante de la suite TCP/IP.
La définition donnée sur le site de netfilter: [cite] RELATED
Un paquet qui est relaté
Quelle horreur ! A défaut de paquet "relaté", c'est au moins la traduction qui est frelatée... ;-)
a, mais pas partie de, une connection existante, comme une erreur ICMP, ou ( avec le module ftp chargé), un paquet qui etablit une connection de données ftp. [/cite]
La définition est bonne.
(1) dépendantes, liées, subordonnées, apparentées (on retrouve 'related' en anglais pour ce dernier)
Moi j'aime bien "lié".
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles a écrit :
Le Mercredi 04 Avril 2007 23:54, Franck Joncourt a écrit :
De maniere generale, pour le suivi de connexion, cela se presente de la
facon suivante :
## ICMP :
echo-request/echo-reply : NEW > ESTABLISHED
autres : NEW > RELATED
Je ne suis pas certain de comprendre ce que signifie ce NEW > RELATED.
Il y a d'autres types ICMP avec un schéma requête/réponse que l'echo qui
doivent prendre les états NEW et ESTABLISHED : timestamp, information,
address mask...
Les types ICMP correspondant à des messages d'erreurs sont bien sûr dans
l'état RELATED quand ils sont liés à une "connexion" existante, mais ne
sont pas forcément émis en réponse à un paquet dans l'état NEW. Par
exemple : fragmentation needed pour un paquet ESTABLISHED trop gros
appartenant à une connexion déjà établie.
## TCP :
NEW, RELATED, ESTABLISHED
## UDP :
NEW, ESTABLISHED
On peut trouver des paquets RELATED en UDP aussi, ainsi que dans
d'autres protocoles de niveau 4 (couche transport). Je pense notamment
au tunnel GRE (protocole n° 41) des VPN PPTP.
L'etat RELATED associé aux connexions TCP n'existe que grace aux modules
de suivi de connexion conntrack specifiques.
Idem pour UDP et les autres protocoles de couche transport.
Oui. Ce qui m'amène à me demander si on ne peut pas en dire autant à propos
de l'UDP , et considérer donc que, dans le cas par exemple du TFTP cité par
Pascal, RELATED puisse aussi s'appliquer en UDP aux paquets de la connexion
'retour' initiée par le serveur.
Je n'ai pas vérifié le cas de TFTP (ou bien c'était il y a longtemps et
j'ai oublié) mais ce serait logique. Même chose pour SIP, RTSP...
Je vois ce dernier comme la
*dérivation* d'une connexion qualifiée comme ESTABLISHED. Vous voyez
cela comment ?
Je ne suis pas certain de bien "voir" ce que tu veux dire.
Il faut que le paquet soit lié à une "connexion" *existante* (connue par
le suivi de connexion), pas forcément à une connexion établie (qui a
engendré du trafic dans les deux sens). Par exemple un ICMP port
unreachable en réponse à un TCP SYN ou une requête UDP (par exemple DNS)
qui sont dans l'état NEW sans qu'il y ait eu de connexion établie. Quand
l'état RELATED concerne une vraie connexion liée (connexion de données
en FTP, tunnel GRE en PPTP...) il remplace l'état NEW du premier paquet
de cette connexion.
Celà ne traduit pas pleinement à mon sens qu'il s'agit de "connexions"
_distinctes_ qui sont *induites*(1) par la "connexion" initiale. Le terme
connexion désigne ici plutôt un canal de communication s'il doit aussi être
applicable pour l'udp.
Les guillements sont de rigueur, particulièrement quand la "connexion"
est en fait un simple message d'erreur ICMP. C'est d'ailleurs le seul
type de paquet qui peut être classé dans l'état RELATED par le suivi de
connexion de base sans helper spécifique, car ICMP fait partie
intégrante de la suite TCP/IP.
La définition donnée sur le site de netfilter:
[cite]
RELATED
Un paquet qui est relaté
Quelle horreur ! A défaut de paquet "relaté", c'est au moins la
traduction qui est frelatée... ;-)
a, mais pas partie de, une connection
existante, comme une erreur ICMP, ou ( avec le module ftp chargé),
un paquet qui etablit une connection de données ftp.
[/cite]
La définition est bonne.
(1) dépendantes, liées, subordonnées, apparentées (on retrouve 'related' en
anglais pour ce dernier)
Moi j'aime bien "lié".
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Mercredi 04 Avril 2007 23:54, Franck Joncourt a écrit :
De maniere generale, pour le suivi de connexion, cela se presente de la facon suivante :
## ICMP : echo-request/echo-reply : NEW > ESTABLISHED autres : NEW > RELATED
Je ne suis pas certain de comprendre ce que signifie ce NEW > RELATED. Il y a d'autres types ICMP avec un schéma requête/réponse que l'echo qui doivent prendre les états NEW et ESTABLISHED : timestamp, information, address mask... Les types ICMP correspondant à des messages d'erreurs sont bien sûr dans l'état RELATED quand ils sont liés à une "connexion" existante, mais ne sont pas forcément émis en réponse à un paquet dans l'état NEW. Par exemple : fragmentation needed pour un paquet ESTABLISHED trop gros appartenant à une connexion déjà établie.
## TCP : NEW, RELATED, ESTABLISHED
## UDP : NEW, ESTABLISHED
On peut trouver des paquets RELATED en UDP aussi, ainsi que dans d'autres protocoles de niveau 4 (couche transport). Je pense notamment au tunnel GRE (protocole n° 41) des VPN PPTP.
L'etat RELATED associé aux connexions TCP n'existe que grace aux modules de suivi de connexion conntrack specifiques.
Idem pour UDP et les autres protocoles de couche transport.
Oui. Ce qui m'amène à me demander si on ne peut pas en dire autant à propos de l'UDP , et considérer donc que, dans le cas par exemple du TFTP cité par Pascal, RELATED puisse aussi s'appliquer en UDP aux paquets de la connexion 'retour' initiée par le serveur.
Je n'ai pas vérifié le cas de TFTP (ou bien c'était il y a longtemps et j'ai oublié) mais ce serait logique. Même chose pour SIP, RTSP...
Je vois ce dernier comme la *dérivation* d'une connexion qualifiée comme ESTABLISHED. Vous voyez cela comment ?
Je ne suis pas certain de bien "voir" ce que tu veux dire. Il faut que le paquet soit lié à une "connexion" *existante* (connue par le suivi de connexion), pas forcément à une connexion établie (qui a engendré du trafic dans les deux sens). Par exemple un ICMP port unreachable en réponse à un TCP SYN ou une requête UDP (par exemple DNS) qui sont dans l'état NEW sans qu'il y ait eu de connexion établie. Quand l'état RELATED concerne une vraie connexion liée (connexion de données en FTP, tunnel GRE en PPTP...) il remplace l'état NEW du premier paquet de cette connexion.
Celà ne traduit pas pleinement à mon sens qu'il s'agit de "connexions" _distinctes_ qui sont *induites*(1) par la "connexion" initiale. Le terme connexion désigne ici plutôt un canal de communication s'il doit aussi être applicable pour l'udp.
Les guillements sont de rigueur, particulièrement quand la "connexion" est en fait un simple message d'erreur ICMP. C'est d'ailleurs le seul type de paquet qui peut être classé dans l'état RELATED par le suivi de connexion de base sans helper spécifique, car ICMP fait partie intégrante de la suite TCP/IP.
La définition donnée sur le site de netfilter: [cite] RELATED
Un paquet qui est relaté
Quelle horreur ! A défaut de paquet "relaté", c'est au moins la traduction qui est frelatée... ;-)
a, mais pas partie de, une connection existante, comme une erreur ICMP, ou ( avec le module ftp chargé), un paquet qui etablit une connection de données ftp. [/cite]
La définition est bonne.
(1) dépendantes, liées, subordonnées, apparentées (on retrouve 'related' en anglais pour ce dernier)
Moi j'aime bien "lié".
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
>>## TCP : >>NEW, RELATED, ESTABLISHED >> >>## UDP : >>NEW, ESTABLISHED
On peut trouver des paquets RELATED en UDP aussi, ainsi que dans d'autres protocoles de niveau 4 (couche transport). Je pense notamment au tunnel GRE (protocole n° 41) des VPN PPTP.
Donc on distingue en fait deux cas pour l'etat RELATED : - suite a une connexion existante mais non etablie (soit NEW), un message ICMP est envoye avec l'etat RELATED. - suite à une connexion etablie (ESTABLISHED), une nouvelle connexion est cree grace aux *helpers*.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
>>## TCP :
>>NEW, RELATED, ESTABLISHED
>>
>>## UDP :
>>NEW, ESTABLISHED
On peut trouver des paquets RELATED en UDP aussi, ainsi que dans
d'autres protocoles de niveau 4 (couche transport). Je pense notamment
au tunnel GRE (protocole n° 41) des VPN PPTP.
Donc on distingue en fait deux cas pour l'etat RELATED :
- suite a une connexion existante mais non etablie (soit NEW), un
message ICMP est envoye avec l'etat RELATED.
- suite à une connexion etablie (ESTABLISHED), une nouvelle connexion
est cree grace aux *helpers*.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>>## TCP : >>NEW, RELATED, ESTABLISHED >> >>## UDP : >>NEW, ESTABLISHED
On peut trouver des paquets RELATED en UDP aussi, ainsi que dans d'autres protocoles de niveau 4 (couche transport). Je pense notamment au tunnel GRE (protocole n° 41) des VPN PPTP.
Donc on distingue en fait deux cas pour l'etat RELATED : - suite a une connexion existante mais non etablie (soit NEW), un message ICMP est envoye avec l'etat RELATED. - suite à une connexion etablie (ESTABLISHED), une nouvelle connexion est cree grace aux *helpers*.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Franck Joncourt a écrit :
Je pensais qu'il n'y avait que le echo-reply qui était qualifie de ESTABLISHED pour le protocol ICMP.
C'est seulement le type le plus connu.
Je ne me suis pas trop penche sur les types timestamp, information
Moi non plus, à vrai dire. Je n'en connais que le nom, pas le rôle. AMA on peut très bien s'en passer.
[...]
Donc on distingue en fait deux cas pour l'etat RELATED : - suite a une connexion existante mais non etablie (soit NEW), un message ICMP est envoye avec l'etat RELATED. - suite à une connexion etablie (ESTABLISHED), une nouvelle connexion est cree grace aux *helpers*.
Il y a bien ces deux cas, mais l'état de la connexion originale n'est pas un critère de distinction. Un message ICMP dans l'état RELATED aussi bien peut être lié à une connexion dans l'état ESTABLISHED (suite à un problème réseau qui se produit alors que la connexion originale est déjà établie par exemple). Inversement, une nouvelle connexion dans l'état RELATED peut aussi bien être liée à une connexion dans l'état NEW (cas de TFTP, la "connexion" initiale du client sur le port UDP 69 du serveur étant composée d'un unique paquet de requête).
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Franck Joncourt a écrit :
Je pensais qu'il n'y avait que le echo-reply qui était qualifie de
ESTABLISHED pour le protocol ICMP.
C'est seulement le type le plus connu.
Je ne me suis pas trop penche sur les types timestamp, information
Moi non plus, à vrai dire. Je n'en connais que le nom, pas le rôle. AMA
on peut très bien s'en passer.
[...]
Donc on distingue en fait deux cas pour l'etat RELATED :
- suite a une connexion existante mais non etablie (soit NEW), un
message ICMP est envoye avec l'etat RELATED.
- suite à une connexion etablie (ESTABLISHED), une nouvelle connexion
est cree grace aux *helpers*.
Il y a bien ces deux cas, mais l'état de la connexion originale n'est
pas un critère de distinction. Un message ICMP dans l'état RELATED aussi
bien peut être lié à une connexion dans l'état ESTABLISHED (suite à un
problème réseau qui se produit alors que la connexion originale est déjà
établie par exemple). Inversement, une nouvelle connexion dans l'état
RELATED peut aussi bien être liée à une connexion dans l'état NEW (cas
de TFTP, la "connexion" initiale du client sur le port UDP 69 du serveur
étant composée d'un unique paquet de requête).
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Je pensais qu'il n'y avait que le echo-reply qui était qualifie de ESTABLISHED pour le protocol ICMP.
C'est seulement le type le plus connu.
Je ne me suis pas trop penche sur les types timestamp, information
Moi non plus, à vrai dire. Je n'en connais que le nom, pas le rôle. AMA on peut très bien s'en passer.
[...]
Donc on distingue en fait deux cas pour l'etat RELATED : - suite a une connexion existante mais non etablie (soit NEW), un message ICMP est envoye avec l'etat RELATED. - suite à une connexion etablie (ESTABLISHED), une nouvelle connexion est cree grace aux *helpers*.
Il y a bien ces deux cas, mais l'état de la connexion originale n'est pas un critère de distinction. Un message ICMP dans l'état RELATED aussi bien peut être lié à une connexion dans l'état ESTABLISHED (suite à un problème réseau qui se produit alors que la connexion originale est déjà établie par exemple). Inversement, une nouvelle connexion dans l'état RELATED peut aussi bien être liée à une connexion dans l'état NEW (cas de TFTP, la "connexion" initiale du client sur le port UDP 69 du serveur étant composée d'un unique paquet de requête).
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
[...] >Donc on distingue en fait deux cas pour l'etat RELATED : >- suite a une connexion existante mais non etablie (soit NEW), un > message ICMP est envoye avec l'etat RELATED. >- suite à une connexion etablie (ESTABLISHED), une nouvelle connexi on > est cree grace aux *helpers*.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
[...]
>Donc on distingue en fait deux cas pour l'etat RELATED :
>- suite a une connexion existante mais non etablie (soit NEW), un
> message ICMP est envoye avec l'etat RELATED.
>- suite à une connexion etablie (ESTABLISHED), une nouvelle connexi on
> est cree grace aux *helpers*.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
[...] >Donc on distingue en fait deux cas pour l'etat RELATED : >- suite a une connexion existante mais non etablie (soit NEW), un > message ICMP est envoye avec l'etat RELATED. >- suite à une connexion etablie (ESTABLISHED), une nouvelle connexi on > est cree grace aux *helpers*.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
