J'ai acheté un routeur/firewall Dlink DI604. J'y ai branché ma freebox
sur "WAN" et mes deux ordinateurs sur deux des quatre prises RJ45. Il
s'administre par une interface web depuis un navigateur. Le routage
marche bien et les deux postes ont accès au net, mais au niveau de la
sécurité, je n'arrive pas à obtenir la même chose qu'avec un firewall
logiciel comme Kerio Winroute.
Avec Kerio, je pouvais bloquer tous les ports en entrée. Les personnes
cherchant à se connecter sur un port (attaque éventuelle) ne pouvaient
pas se connecter. Par contre, lorsque je faisais une requete, les
réponses à mes requetes n'étaient pas bloquées.
Avec le DI604, lorsque je crée une règle firewall pour interdire tout ce
qui provient du WAN (internet) et qui va sur le LAN, sur tous les ports
et pour toutes les IP, je ne peux plus rien faire (aller sur google par
ex). Si je ne fais ce bloquage que pour les ports 0 -> 1024, ça marche.
En prallèle, j'ai ajouté une règle pour tout autoriser en sortie
(source: LAN, destination: WAN, avec tous les ports, et toutes les IP).
Je suis donc sur que les requetes peuvent sortir.
Comment fait-on pour bloquer par défaut toutes les entrées sur les
ports, à l'exception des ports emule (4661-tcp, 4672-udp, etc), sans
bloquer les réponses à mes propres requetes ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Alni
Bonjour,
frandicz a pensé très fort :
Bonjour,
J'ai acheté un routeur/firewall Dlink DI604. J'y ai branché ma freebox sur Avec le DI604, lorsque je crée une règle firewall pour interdire tout ce qui provient du WAN (internet) et qui va sur le LAN, sur tous les ports et pour toutes les IP, je ne peux plus rien faire (aller sur google par ex).
Normal, tu bloques toutes les réponses à tes requêtes.
Si je ne fais ce bloquage que pour les ports 0 -> 1024, ça marche.
Normal, les port 1->1024 sont les ports "privilégiés" qui normalement sont ouverts par des "services" particuliers : 80=web, 21=ftp, etc... Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine. Donc toujours des ports >1024, ceux ci étant plus ou moins "reservés" par le système
En prallèle, j'ai ajouté une règle pour tout autoriser en sortie (source: LAN, destination: WAN, avec tous les ports, et toutes les IP). Je suis donc sur que les requetes peuvent sortir.
Oui, mais les réponses ne peuvent pas revenir. C'est comme si tu commandes quelque chose à la redoute, et que tu fermes complètement ta boite aux lettres, de telle façon que le facteur ne peut pas y mettre ni le colis, ni l'avis de passage....
Comment fait-on pour bloquer par défaut toutes les entrées sur les ports, à l'exception des ports emule (4661-tcp, 4672-udp, etc), sans bloquer les réponses à mes propres requetes ?
<copy/paste> (cent fois que je me répète)
Un routeur NAT/PAT (avec ou sans firewall) de part sa nature, te protège de toutes tentatives de connexions entrantes non désirées. En effet, il n'accèpte en entrée que les réponses aux requêtes émises par les stations internes, ou celles que l'on a EXPLICITEMENT déclarées si par exemple on heberge un serveur(ftp, web ou autre).
:Dans ton cas, il faut aller sur la page de réglage du DI-604 et :demander à ce que tout ce qui arrive sur le routeur sur les ports :4661-tcp, 4672-udp soient envoyés sur l'IP d'une machine particulière :(celle qui a le programme emule) :Sur un DI-614, c'est dans LAN onglet "Advanced" : :cocher "enabled" :name : emule tcp :private IP : l'ip du poste qui a emule :protocole : TCP :Private port : 4661 (d'ailleurs n'est ce pas plutôt le 4662 ?) :public port : 4661 :schedule : always ou ce que tu veux
:Faire pareil pour le UDP 4672
Par contre, il ne te protègera pas des connexion sortantes à ton insu (spywares et autres cochoneries)
extrait du site netgear : -------------------------- Question: Isn't NAT the same as "firewall"? Answer: No. Though the term "firewall" has been used when describing a router's ability to hide the LAN IP addresses, a true firewall employs a technology called Stateful Packet Inspection (SPI). Firewalls provide a greater level of security and are generally more expensive than a NAT router. Firewalls give the administrator the ability to set up specific IP addresses or domain names that are allowed to be accessed, while refusing any other attempt to access the LAN. This is often referred to as filtering. Firewalls can also allow remote access to the private network through the use of secure login procedures and authentication certificates (VPN). Firewalls are used to prevent Denial of Service (DoS) attacks and can use software to provide content filtering to deny access to unwanted web sites. ----------------------------
En gros, ce que permet un firewall et que ne permet pas le NAT, interresse l'administrateur réseau, pas le particulier qui partage sa connexion pour surfer
c'est :
Dans le sens LAN->Internet : n'autoriser l'accès qu'a certaines adresses ou certains domaines ou certains services (ex: un admin qui veut interdire les acces aux serveurs ftp ou irc depuis son LAN) (le chapitre 5 de la doc rp614 explique comment bloquer des sites)
Dans le sens Internet->LAN : la possibilité de contrôler la provenance des appels entrants vers les machine "serveur" du LAN, et aussi de reperer les tentatives d'attaque par DoS et de les filtrer.
Un exemple ou un routeur/firewall prends toute sa dimension, c'est le cas d'une entreprise qui à 8 micros et qui à un abonnement chez un FAI qui lui procure un bloc de 8 adresses IP. Chaque micro dispose donc d'une adresse IP valide sur internet et se trouve donc totalement exposé à celui-ci. Un routeur/firewall permet alors de filtrer tout ce qui rentre et tout ce qui sort.
nb: Un routeur NAT ne protège pas des virus, spywares, ni troyens pouvant être présents sur une station qui font remonter des information vers Internet.
Normalement un antivirus repère les troyens et virus, mais pas les spywares. Voir du coté de ad-aware et spybot
J'ai acheté un routeur/firewall Dlink DI604. J'y ai branché ma freebox sur
Avec le DI604, lorsque je crée une règle firewall pour interdire tout ce qui
provient du WAN (internet) et qui va sur le LAN, sur tous les ports et pour
toutes les IP, je ne peux plus rien faire (aller sur google par ex).
Normal, tu bloques toutes les réponses à tes requêtes.
Si je ne fais ce bloquage que pour les ports 0 -> 1024, ça marche.
Normal, les port 1->1024 sont les ports "privilégiés" qui normalement
sont ouverts par des "services" particuliers : 80=web, 21=ftp, etc...
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est
pas encore utilisé sur la machine. Donc toujours des ports >1024, ceux
ci étant plus ou moins "reservés" par le système
En prallèle, j'ai ajouté une règle pour tout autoriser en sortie (source:
LAN, destination: WAN, avec tous les ports, et toutes les IP). Je suis donc
sur que les requetes peuvent sortir.
Oui, mais les réponses ne peuvent pas revenir. C'est comme si tu
commandes quelque chose à la redoute, et que tu fermes complètement ta
boite aux lettres, de telle façon que le facteur ne peut pas y mettre
ni le colis, ni l'avis de passage....
Comment fait-on pour bloquer par défaut toutes les entrées sur les ports, à
l'exception des ports emule (4661-tcp, 4672-udp, etc), sans bloquer les
réponses à mes propres requetes ?
<copy/paste> (cent fois que je me répète)
Un routeur NAT/PAT (avec ou sans firewall) de part sa nature, te
protège de
toutes tentatives de connexions entrantes non désirées.
En effet, il n'accèpte en entrée que les réponses aux requêtes émises
par
les stations internes, ou celles que l'on a EXPLICITEMENT déclarées si
par
exemple on heberge un serveur(ftp, web ou autre).
:Dans ton cas, il faut aller sur la page de réglage du DI-604 et
:demander à ce que tout ce qui arrive sur le routeur sur les ports
:4661-tcp, 4672-udp soient envoyés sur l'IP d'une machine particulière
:(celle qui a le programme emule)
:Sur un DI-614, c'est dans LAN onglet "Advanced" :
:cocher "enabled"
:name : emule tcp
:private IP : l'ip du poste qui a emule
:protocole : TCP
:Private port : 4661 (d'ailleurs n'est ce pas plutôt le 4662 ?)
:public port : 4661
:schedule : always ou ce que tu veux
:Faire pareil pour le UDP 4672
Par contre, il ne te protègera pas des connexion sortantes à ton insu
(spywares et autres cochoneries)
extrait du site netgear :
--------------------------
Question:
Isn't NAT the same as "firewall"?
Answer:
No. Though the term "firewall" has been used when describing a router's
ability to hide the LAN IP addresses, a true firewall employs a
technology
called Stateful Packet Inspection (SPI). Firewalls provide a greater
level
of security and are generally more expensive than a NAT router.
Firewalls
give the administrator the ability to set up specific IP addresses or
domain
names that are allowed to be accessed, while refusing any other attempt
to
access the LAN. This is often referred to as filtering. Firewalls can
also
allow remote access to the private network through the use of secure
login
procedures and authentication certificates (VPN). Firewalls are used to
prevent Denial of Service (DoS) attacks and can use software to provide
content filtering to deny access to unwanted web sites.
----------------------------
En gros, ce que permet un firewall et que ne permet pas le NAT,
interresse
l'administrateur réseau, pas le particulier qui partage sa connexion
pour
surfer
c'est :
Dans le sens LAN->Internet : n'autoriser l'accès qu'a certaines
adresses ou
certains domaines ou certains services (ex: un admin qui veut interdire
les
acces aux serveurs ftp ou irc depuis son LAN) (le chapitre 5 de la doc
rp614
explique comment bloquer des sites)
Dans le sens Internet->LAN : la possibilité de contrôler la provenance
des
appels entrants vers les machine "serveur" du LAN, et aussi de reperer
les
tentatives d'attaque par DoS et de les filtrer.
Un exemple ou un routeur/firewall prends toute sa dimension, c'est le
cas
d'une entreprise qui à 8 micros et qui à un abonnement chez un FAI qui
lui
procure un bloc de 8 adresses IP. Chaque micro dispose donc d'une
adresse
IP valide sur internet et se trouve donc totalement exposé à celui-ci.
Un
routeur/firewall permet alors de filtrer tout ce qui rentre et tout ce
qui
sort.
nb: Un routeur NAT ne protège pas des virus, spywares, ni troyens
pouvant
être présents sur une station qui font remonter des information vers
Internet.
Normalement un antivirus repère les troyens et virus, mais pas les
spywares.
Voir du coté de ad-aware et spybot
J'ai acheté un routeur/firewall Dlink DI604. J'y ai branché ma freebox sur Avec le DI604, lorsque je crée une règle firewall pour interdire tout ce qui provient du WAN (internet) et qui va sur le LAN, sur tous les ports et pour toutes les IP, je ne peux plus rien faire (aller sur google par ex).
Normal, tu bloques toutes les réponses à tes requêtes.
Si je ne fais ce bloquage que pour les ports 0 -> 1024, ça marche.
Normal, les port 1->1024 sont les ports "privilégiés" qui normalement sont ouverts par des "services" particuliers : 80=web, 21=ftp, etc... Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine. Donc toujours des ports >1024, ceux ci étant plus ou moins "reservés" par le système
En prallèle, j'ai ajouté une règle pour tout autoriser en sortie (source: LAN, destination: WAN, avec tous les ports, et toutes les IP). Je suis donc sur que les requetes peuvent sortir.
Oui, mais les réponses ne peuvent pas revenir. C'est comme si tu commandes quelque chose à la redoute, et que tu fermes complètement ta boite aux lettres, de telle façon que le facteur ne peut pas y mettre ni le colis, ni l'avis de passage....
Comment fait-on pour bloquer par défaut toutes les entrées sur les ports, à l'exception des ports emule (4661-tcp, 4672-udp, etc), sans bloquer les réponses à mes propres requetes ?
<copy/paste> (cent fois que je me répète)
Un routeur NAT/PAT (avec ou sans firewall) de part sa nature, te protège de toutes tentatives de connexions entrantes non désirées. En effet, il n'accèpte en entrée que les réponses aux requêtes émises par les stations internes, ou celles que l'on a EXPLICITEMENT déclarées si par exemple on heberge un serveur(ftp, web ou autre).
:Dans ton cas, il faut aller sur la page de réglage du DI-604 et :demander à ce que tout ce qui arrive sur le routeur sur les ports :4661-tcp, 4672-udp soient envoyés sur l'IP d'une machine particulière :(celle qui a le programme emule) :Sur un DI-614, c'est dans LAN onglet "Advanced" : :cocher "enabled" :name : emule tcp :private IP : l'ip du poste qui a emule :protocole : TCP :Private port : 4661 (d'ailleurs n'est ce pas plutôt le 4662 ?) :public port : 4661 :schedule : always ou ce que tu veux
:Faire pareil pour le UDP 4672
Par contre, il ne te protègera pas des connexion sortantes à ton insu (spywares et autres cochoneries)
extrait du site netgear : -------------------------- Question: Isn't NAT the same as "firewall"? Answer: No. Though the term "firewall" has been used when describing a router's ability to hide the LAN IP addresses, a true firewall employs a technology called Stateful Packet Inspection (SPI). Firewalls provide a greater level of security and are generally more expensive than a NAT router. Firewalls give the administrator the ability to set up specific IP addresses or domain names that are allowed to be accessed, while refusing any other attempt to access the LAN. This is often referred to as filtering. Firewalls can also allow remote access to the private network through the use of secure login procedures and authentication certificates (VPN). Firewalls are used to prevent Denial of Service (DoS) attacks and can use software to provide content filtering to deny access to unwanted web sites. ----------------------------
En gros, ce que permet un firewall et que ne permet pas le NAT, interresse l'administrateur réseau, pas le particulier qui partage sa connexion pour surfer
c'est :
Dans le sens LAN->Internet : n'autoriser l'accès qu'a certaines adresses ou certains domaines ou certains services (ex: un admin qui veut interdire les acces aux serveurs ftp ou irc depuis son LAN) (le chapitre 5 de la doc rp614 explique comment bloquer des sites)
Dans le sens Internet->LAN : la possibilité de contrôler la provenance des appels entrants vers les machine "serveur" du LAN, et aussi de reperer les tentatives d'attaque par DoS et de les filtrer.
Un exemple ou un routeur/firewall prends toute sa dimension, c'est le cas d'une entreprise qui à 8 micros et qui à un abonnement chez un FAI qui lui procure un bloc de 8 adresses IP. Chaque micro dispose donc d'une adresse IP valide sur internet et se trouve donc totalement exposé à celui-ci. Un routeur/firewall permet alors de filtrer tout ce qui rentre et tout ce qui sort.
nb: Un routeur NAT ne protège pas des virus, spywares, ni troyens pouvant être présents sur une station qui font remonter des information vers Internet.
Normalement un antivirus repère les troyens et virus, mais pas les spywares. Voir du coté de ad-aware et spybot
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête afin qu'elles puissent être aiguillées vers le processus qui est à l'origine de la requête correspondante.
Nota: Cette discussion n'a rien à faire dans le forum dédié au matériel PC, elle serait plus à sa place dans news:fr.comp.reseaux.ip.
Alni wrote:
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est
pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête afin
qu'elles puissent être aiguillées vers le processus qui est à l'origine
de la requête correspondante.
Nota: Cette discussion n'a rien à faire dans le forum dédié au matériel
PC, elle serait plus à sa place dans news:fr.comp.reseaux.ip.
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête afin qu'elles puissent être aiguillées vers le processus qui est à l'origine de la requête correspondante.
Nota: Cette discussion n'a rien à faire dans le forum dédié au matériel PC, elle serait plus à sa place dans news:fr.comp.reseaux.ip.
Alni
"Annie D." a écrit dans le message de news:
Alni wrote:
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête
Ce port source étant pris dans le pool de ports disponibles sur la machine qui emet la requête. Je n'ai pas dit que c'est la machine qui répond à cette requête qui décide de ce port.
afin qu'elles puissent être aiguillées vers le processus qui est à l'origine de la requête correspondante.
Bien sûr.
Bon, disons que je n'ai pas été suffisement précis dans mes propos au sujet de la détermination de ce port.
"Annie D." <annie.demur@free.fr> a écrit dans le message de
news:414446CB.AC87B20F@free.fr...
Alni wrote:
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est
pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête
Ce port source étant pris dans le pool de ports disponibles sur la machine
qui emet la requête. Je n'ai pas dit que c'est la machine qui répond à cette
requête qui décide de ce port.
afin
qu'elles puissent être aiguillées vers le processus qui est à l'origine
de la requête correspondante.
Bien sûr.
Bon, disons que je n'ai pas été suffisement précis dans mes propos au sujet
de la détermination de ce port.
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête
Ce port source étant pris dans le pool de ports disponibles sur la machine qui emet la requête. Je n'ai pas dit que c'est la machine qui répond à cette requête qui décide de ce port.
afin qu'elles puissent être aiguillées vers le processus qui est à l'origine de la requête correspondante.
Bien sûr.
Bon, disons que je n'ai pas été suffisement précis dans mes propos au sujet de la détermination de ce port.
Remy Moulin
Annie D. wrote:
Alni wrote:
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête afin qu'elles puissent être aiguillées vers le processus qui est à l'origine de la requête correspondante.
Les guillemets étaient fort justement placés pour démontrer un raccourci de rédaction ...
L'explication exacte étant qu'un processus peut faire une demande de n° de port libre à l'OS pour faire ses réceptions TCP ou UDP, et que l'OS renvoie un n° entre 1024 et 65535 (Il part de 1024 et augmente de 1 jusqu'à trouver un n° libre. Arrivé à 65535, il reboucle à 1024). Vu de l'exterieur de la machine, du routeur par exemple, ce port réception semble aléatoirement choisi entre 1024 et 65535.
C'était l'idée de ce paragraphe, il est correct.
Nota: Cette discussion n'a rien à faire dans le forum dédié au matériel PC, elle serait plus à sa place dans news:fr.comp.reseaux.ip.
Tout à fait.
-- Herm
Annie D. wrote:
Alni wrote:
Les réponses aux requêtes reviennent sur un port "aléatoire" qui
n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête afin
qu'elles puissent être aiguillées vers le processus qui est à
l'origine de la requête correspondante.
Les guillemets étaient fort justement placés pour démontrer un raccourci de
rédaction ...
L'explication exacte étant qu'un processus peut faire une demande de n° de
port libre à l'OS pour faire ses réceptions TCP ou UDP, et que l'OS renvoie
un n° entre 1024 et 65535 (Il part de 1024 et augmente de 1 jusqu'à trouver
un n° libre. Arrivé à 65535, il reboucle à 1024). Vu de l'exterieur de la
machine, du routeur par exemple, ce port réception semble aléatoirement
choisi entre 1024 et 65535.
C'était l'idée de ce paragraphe, il est correct.
Nota: Cette discussion n'a rien à faire dans le forum dédié au
matériel PC, elle serait plus à sa place dans news:fr.comp.reseaux.ip.
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête afin qu'elles puissent être aiguillées vers le processus qui est à l'origine de la requête correspondante.
Les guillemets étaient fort justement placés pour démontrer un raccourci de rédaction ...
L'explication exacte étant qu'un processus peut faire une demande de n° de port libre à l'OS pour faire ses réceptions TCP ou UDP, et que l'OS renvoie un n° entre 1024 et 65535 (Il part de 1024 et augmente de 1 jusqu'à trouver un n° libre. Arrivé à 65535, il reboucle à 1024). Vu de l'exterieur de la machine, du routeur par exemple, ce port réception semble aléatoirement choisi entre 1024 et 65535.
C'était l'idée de ce paragraphe, il est correct.
Nota: Cette discussion n'a rien à faire dans le forum dédié au matériel PC, elle serait plus à sa place dans news:fr.comp.reseaux.ip.
Tout à fait.
-- Herm
Annie D.
Remy Moulin wrote:
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête afin qu'elles puissent être aiguillées vers le processus qui est à l'origine de la requête correspondante.
Les guillemets étaient fort justement placés pour démontrer un raccourci de rédaction ...
A trop raccourcir on commet des approximations douteuses et des contresens. C'est le cas ici, et les guillemets n'y changent rien.
L'explication exacte étant [coupe] C'était l'idée de ce paragraphe, il est correct.
Jamais de la vie. Détaillons. "Les réponses reviennent" => la requête du client a donc été émise => un port source a donc déjà été choisi (aléatoirement ou pas, peu importe) par le client pour émettre cette requête et écouter la réponse du serveur => au moment où le serveur émet la réponse, le port en question n'est ni "aléatoire" (puisque déjà choisi avant l'émission de la requête) ni "pas encore utilisé" puisque précisément utilisé pour écouter la réponse et éventuellement émettre un aquittement ou une autre requête dans le même flux. Bref, juste tout le contraire.
Nota: Cette discussion n'a rien à faire dans le forum dédié au matériel PC, elle serait plus à sa place dans news:fr.comp.reseaux.ip.
Tout à fait.
C'est pourquoi ma participation à celle-ci s'arrête avec cette réponse.
Remy Moulin wrote:
Les réponses aux requêtes reviennent sur un port "aléatoire" qui
n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête afin
qu'elles puissent être aiguillées vers le processus qui est à
l'origine de la requête correspondante.
Les guillemets étaient fort justement placés pour démontrer un raccourci de
rédaction ...
A trop raccourcir on commet des approximations douteuses et des
contresens. C'est le cas ici, et les guillemets n'y changent rien.
L'explication exacte étant [coupe]
C'était l'idée de ce paragraphe, il est correct.
Jamais de la vie. Détaillons.
"Les réponses reviennent" => la requête du client a donc été émise => un
port source a donc déjà été choisi (aléatoirement ou pas, peu importe)
par le client pour émettre cette requête et écouter la réponse du
serveur => au moment où le serveur émet la réponse, le port en question
n'est ni "aléatoire" (puisque déjà choisi avant l'émission de la
requête) ni "pas encore utilisé" puisque précisément utilisé pour
écouter la réponse et éventuellement émettre un aquittement ou une autre
requête dans le même flux. Bref, juste tout le contraire.
Nota: Cette discussion n'a rien à faire dans le forum dédié au
matériel PC, elle serait plus à sa place dans news:fr.comp.reseaux.ip.
Tout à fait.
C'est pourquoi ma participation à celle-ci s'arrête avec cette réponse.
Les réponses aux requêtes reviennent sur un port "aléatoire" qui n'est pas encore utilisé sur la machine.
Pas vraiment. Elles reviennent sur le port source de la requête afin qu'elles puissent être aiguillées vers le processus qui est à l'origine de la requête correspondante.
Les guillemets étaient fort justement placés pour démontrer un raccourci de rédaction ...
A trop raccourcir on commet des approximations douteuses et des contresens. C'est le cas ici, et les guillemets n'y changent rien.
L'explication exacte étant [coupe] C'était l'idée de ce paragraphe, il est correct.
Jamais de la vie. Détaillons. "Les réponses reviennent" => la requête du client a donc été émise => un port source a donc déjà été choisi (aléatoirement ou pas, peu importe) par le client pour émettre cette requête et écouter la réponse du serveur => au moment où le serveur émet la réponse, le port en question n'est ni "aléatoire" (puisque déjà choisi avant l'émission de la requête) ni "pas encore utilisé" puisque précisément utilisé pour écouter la réponse et éventuellement émettre un aquittement ou une autre requête dans le même flux. Bref, juste tout le contraire.
Nota: Cette discussion n'a rien à faire dans le forum dédié au matériel PC, elle serait plus à sa place dans news:fr.comp.reseaux.ip.
Tout à fait.
C'est pourquoi ma participation à celle-ci s'arrête avec cette réponse.
Alni
Bonjour,
Annie D. a exposé le 15/09/2004 :
Remy Moulin wrote:
Jamais de la vie. Détaillons.
"Les réponses reviennent" => la requête du client a donc été émise => un port source a donc déjà été choisi (aléatoirement ou pas, peu importe)
Tu conviens donc que ce port est "aléatoire". Je n'ai jamais précisé dans mes posts que ce port était choisi par la machine qui répond. J'ai voulu simplifier, comme le dit Remy.
-- Alni
Bonjour,
Annie D. a exposé le 15/09/2004 :
Remy Moulin wrote:
Jamais de la vie. Détaillons.
"Les réponses reviennent" => la requête du client a donc été émise => un
port source a donc déjà été choisi (aléatoirement ou pas, peu importe)
Tu conviens donc que ce port est "aléatoire".
Je n'ai jamais précisé dans mes posts que ce port était choisi par la
machine qui répond.
J'ai voulu simplifier, comme le dit Remy.
"Les réponses reviennent" => la requête du client a donc été émise => un port source a donc déjà été choisi (aléatoirement ou pas, peu importe)
Tu conviens donc que ce port est "aléatoire". Je n'ai jamais précisé dans mes posts que ce port était choisi par la machine qui répond. J'ai voulu simplifier, comme le dit Remy.
