j'ai quelques soucis de fragmentation sur ma passerelle.
J'ai mis en place une passerelle (que l'on appellera 192.168.1.254)
sous OpenBSD 3.1. Cette passerelle realise une translation d'adresses
(NAT).
Elle accede à internet grace a une autre passerelle (redhat) dont
l'adresse serais 192.168.2.254.
J'ai donc le schema suivant :
reseau interne(192.168.1.0/24) <--> OpenBSD-31(192.168.1.254)
OpenBSD-31(192.168.2.1)<--->RedHat(192.168.2.254).
Donc sur le reseau local la passerelle est openbsd.
Sur Openbsd la passerelle est RedHat.
sur RedHat je ping google.fr sans aucuns soucis.
Sur celle ci aussi je ping google avec des 1600 octets
de donnees sans aucuns problemes. (ping -s 1600 google.fr)
Sur OpenBSD je ping google sans aucuns soucis aussi :)
En revanche les paquets supperieurs a 1500 ne passent pas.
Sur le reseau local idems bien evidemment.
Dans le pf.conf je n'ai pas de regles particuliere, d'ailleurs
en faisant un "pfctl -d" cela ne marche pas mieux.
Depuis le reseau local les pings inferieurs a 1500 passent aussi.
Un traceroute marche a merveille. Je ne comprend vraiment pas d'ou
cela peut venir.
Essaie de pinger en lancant tcpdump comme ca (sur la bonne interface): # tcpdump -nnvi BONNE_INTERFACE icmp
Et montre la capture.
Je sens un truc a cause de la NAT.
manu
Sebastien Vincent wrote:
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
Ca ne resout pas frocement ton problème: que se passe-t-il si le site en face essaye de t'envoyer un paquet marqué DF (don't fragment) et au dessus du MTU de ton lien ADSL? Réponse: le paquet est rejeté.
Bien sur le coup est prévu, et il existe des mécanismes de découverte du PMTU (le plus petit MTU du chemin), mais quand on filtre n'importe quoi au niveau ICMP on anihile ces mecanismes. Le filtrage en forme de n'importe quoi peut se passer sur la machine en face sur laquelle tu n'as pas de controle.
La solution c'est d'utiliser le Maximum Segment Size (MSS) de TCP, qui permet d'indiquer à la machine en face la taille maximum des paquets attendus, au moment de l'initiation d'une connexion TCP. Problème: il faudrait que toutes les machines de ton réseau soit aware du problème pour fixer un MSS adéquat. Solution: le MSS clamping, qui consiste à faire modifier au vol les MSS par ta passerelle.
Note que ca ne regle le probème que pour TCP. La vraie solution c'est que tout le monde partout sur Internet laisse passer le traffic ICMP indispensable au bon fonctionnement de IP.
Derniere question, comment mettre en place le MSS clamping. Avec IPFilter, ca se fait dans ipnat.conf: map pppoe0 10.0.0.0/24 -> 0/32 portmap tcp/udp 40000:42999 mssclamp 1352 map pppoe0 10.0.0.0/24 -> 0/32 mssclamp 1352
Si on veut faire du MSS clamping sans NAT, il suffit de faire un NAT 1:1 map pppoe0 10.0.0.0/24 -> 0/0 mssclamp 1352
Bon, j'ai mis 1352, on peut monter un petit peu, tout dépend de ce qu'on fait passer comme protocole d'encapsulation.
Avec Packet Filter, c'est scrub qui fait le travail: scrub in all max-mss 1352 no-df
Le thread reste ouvert haha :)
Je vois surtout que je commence à avoir des choses à mettre dans une 3eme edition du cahier de l'admin BSD :)
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Vincent <svincent@idems.fr> wrote:
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
Ca ne resout pas frocement ton problème: que se passe-t-il si le site en
face essaye de t'envoyer un paquet marqué DF (don't fragment) et au
dessus du MTU de ton lien ADSL? Réponse: le paquet est rejeté.
Bien sur le coup est prévu, et il existe des mécanismes de découverte du
PMTU (le plus petit MTU du chemin), mais quand on filtre n'importe quoi
au niveau ICMP on anihile ces mecanismes. Le filtrage en forme de
n'importe quoi peut se passer sur la machine en face sur laquelle tu
n'as pas de controle.
La solution c'est d'utiliser le Maximum Segment Size (MSS) de TCP, qui
permet d'indiquer à la machine en face la taille maximum des paquets
attendus, au moment de l'initiation d'une connexion TCP. Problème: il
faudrait que toutes les machines de ton réseau soit aware du problème
pour fixer un MSS adéquat. Solution: le MSS clamping, qui consiste à
faire modifier au vol les MSS par ta passerelle.
Note que ca ne regle le probème que pour TCP. La vraie solution c'est
que tout le monde partout sur Internet laisse passer le traffic ICMP
indispensable au bon fonctionnement de IP.
Derniere question, comment mettre en place le MSS clamping. Avec
IPFilter, ca se fait dans ipnat.conf:
map pppoe0 10.0.0.0/24 -> 0/32 portmap tcp/udp 40000:42999 mssclamp 1352
map pppoe0 10.0.0.0/24 -> 0/32 mssclamp 1352
Si on veut faire du MSS clamping sans NAT, il suffit de faire un NAT 1:1
map pppoe0 10.0.0.0/24 -> 0/0 mssclamp 1352
Bon, j'ai mis 1352, on peut monter un petit peu, tout dépend de ce qu'on
fait passer comme protocole d'encapsulation.
Avec Packet Filter, c'est scrub qui fait le travail:
scrub in all max-mss 1352 no-df
Le thread reste ouvert haha :)
Je vois surtout que je commence à avoir des choses à mettre dans une
3eme edition du cahier de l'admin BSD :)
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
Ca ne resout pas frocement ton problème: que se passe-t-il si le site en face essaye de t'envoyer un paquet marqué DF (don't fragment) et au dessus du MTU de ton lien ADSL? Réponse: le paquet est rejeté.
Bien sur le coup est prévu, et il existe des mécanismes de découverte du PMTU (le plus petit MTU du chemin), mais quand on filtre n'importe quoi au niveau ICMP on anihile ces mecanismes. Le filtrage en forme de n'importe quoi peut se passer sur la machine en face sur laquelle tu n'as pas de controle.
La solution c'est d'utiliser le Maximum Segment Size (MSS) de TCP, qui permet d'indiquer à la machine en face la taille maximum des paquets attendus, au moment de l'initiation d'une connexion TCP. Problème: il faudrait que toutes les machines de ton réseau soit aware du problème pour fixer un MSS adéquat. Solution: le MSS clamping, qui consiste à faire modifier au vol les MSS par ta passerelle.
Note que ca ne regle le probème que pour TCP. La vraie solution c'est que tout le monde partout sur Internet laisse passer le traffic ICMP indispensable au bon fonctionnement de IP.
Derniere question, comment mettre en place le MSS clamping. Avec IPFilter, ca se fait dans ipnat.conf: map pppoe0 10.0.0.0/24 -> 0/32 portmap tcp/udp 40000:42999 mssclamp 1352 map pppoe0 10.0.0.0/24 -> 0/32 mssclamp 1352
Si on veut faire du MSS clamping sans NAT, il suffit de faire un NAT 1:1 map pppoe0 10.0.0.0/24 -> 0/0 mssclamp 1352
Bon, j'ai mis 1352, on peut monter un petit peu, tout dépend de ce qu'on fait passer comme protocole d'encapsulation.
Avec Packet Filter, c'est scrub qui fait le travail: scrub in all max-mss 1352 no-df
Le thread reste ouvert haha :)
Je vois surtout que je commence à avoir des choses à mettre dans une 3eme edition du cahier de l'admin BSD :)
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Patrice Auffret
On Tue, 24 Aug 2004 17:04:05 +0400 Sebastien Vincent wrote: [..]
Avec un "ping -s 1500 192.168.2.254" depuis mon poste sur le reseau local.
Le tcpdump sur mon poste : shinmei # tcpdump -nnvi eth0 icmp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes 16:44:40.747367 IP (tos 0x0, ttl 64, id 38149, offset 0, flags [+], length: 1500) 192.168.1.36 > 192.168.2.254: icmp 1480: echo request seq 1 16:44:40.747382 IP (tos 0x0, ttl 64, id 38149, offset 1480, flags [none], length: 48) 192.168.1.36 > 192.168.2.254: icmp
Ok, donc les datagrammes IP sont expédiés frgamentés, c'est ok.
Maintenant, il faut voir sur la cible les traces tcpdump de ce qui est recu avec un filter `icmp' également.
le tcpdump sur OpenBSD (interface reseau local) : bsd# tcpdump -nnvi rl1 icmp [..]
Effectivement, y'a de la NAT ici. En court de fragmentation il semblerait. Interressant. Je ne sais que dire :)
espie
In article <cgermv$vjl$, Sebastien Vincent wrote:
Emmanuel Dreyfus wrote:
Sebastien Vincent wrote:
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet redhat se connecte en pppoe en effet.
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
dans pf.conf (sur openbsd) : scrub in all fragment reassemble scrub out all fragment reassemble
A ce moment la, je crois avoir compris que j'ai demande a openbsd de prendre tous les paquets et de les reassembler puis refragmenter pour qu'il fassent 200 octets. (ce qui devrais passer des deux cotes)
mtu et fragments sont deux choses differentes. En particulier, tu ne veux generalement pas de fragments en TCP, mais bien une MTU correcte.
La decouverte de MTU se fait en balancant des paquets avec le drapeau `don't fragment' leve, et en regardant les ICMP qui reviennent.
Les sources habituelles de problemes sont les ICMP qui se perdent, et donc empechent la decouverte de MTU de se faire correctement, ou de petits problemes d'encapsulation des paquets, par exemple avec pppoe, qui rajoutent des entetes qui font que la detection de MTU est faussee...
Chez moi, j'ai set mtu max 1452 set mru max 1452
et j'ai plus vu le moindre probleme a ce niveau...
In article <cgermv$vjl$1@news-reader1.wanadoo.fr>,
Sebastien Vincent <svincent@idems.fr> wrote:
Emmanuel Dreyfus wrote:
Sebastien Vincent <svincent@idems.fr> wrote:
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet
redhat se connecte en pppoe en effet.
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
dans pf.conf (sur openbsd) :
scrub in all fragment reassemble
scrub out all fragment reassemble
A ce moment la, je crois avoir compris que j'ai demande a openbsd
de prendre tous les paquets et de les reassembler puis refragmenter
pour qu'il fassent 200 octets. (ce qui devrais passer des deux cotes)
mtu et fragments sont deux choses differentes.
En particulier, tu ne veux generalement pas de fragments en TCP, mais
bien une MTU correcte.
La decouverte de MTU se fait en balancant des paquets avec le drapeau
`don't fragment' leve, et en regardant les ICMP qui reviennent.
Les sources habituelles de problemes sont les ICMP qui se perdent, et
donc empechent la decouverte de MTU de se faire correctement, ou de
petits problemes d'encapsulation des paquets, par exemple avec pppoe,
qui rajoutent des entetes qui font que la detection de MTU est faussee...
Chez moi, j'ai
set mtu max 1452
set mru max 1452
et j'ai plus vu le moindre probleme a ce niveau...
donc le schema localnet<->openbsd<->redhat<->model adsl ppoe<->internet redhat se connecte en pppoe en effet.
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
dans pf.conf (sur openbsd) : scrub in all fragment reassemble scrub out all fragment reassemble
A ce moment la, je crois avoir compris que j'ai demande a openbsd de prendre tous les paquets et de les reassembler puis refragmenter pour qu'il fassent 200 octets. (ce qui devrais passer des deux cotes)
mtu et fragments sont deux choses differentes. En particulier, tu ne veux generalement pas de fragments en TCP, mais bien une MTU correcte.
La decouverte de MTU se fait en balancant des paquets avec le drapeau `don't fragment' leve, et en regardant les ICMP qui reviennent.
Les sources habituelles de problemes sont les ICMP qui se perdent, et donc empechent la decouverte de MTU de se faire correctement, ou de petits problemes d'encapsulation des paquets, par exemple avec pppoe, qui rajoutent des entetes qui font que la detection de MTU est faussee...
Chez moi, j'ai set mtu max 1452 set mru max 1452
et j'ai plus vu le moindre probleme a ce niveau...
manu
Sebastien Vincent wrote:
Je vois surtout que je commence à avoir des choses à mettre dans une 3eme edition du cahier de l'admin BSD :) On peut pas "louer" le deuxieme le temps que le troisième sorte :) ?
T'inquiete pas, je ne vais pas en sortir une nouvelle edition tous les 10 mois. Faut quand même avoir un peu plus à rajouter que des precisions et corrections.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Vincent <svincent@idems.fr> wrote:
Je vois surtout que je commence à avoir des choses à mettre dans une
3eme edition du cahier de l'admin BSD :)
On peut pas "louer" le deuxieme le temps que le troisième sorte :) ?
T'inquiete pas, je ne vais pas en sortir une nouvelle edition tous les
10 mois. Faut quand même avoir un peu plus à rajouter que des precisions
et corrections.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Je vois surtout que je commence à avoir des choses à mettre dans une 3eme edition du cahier de l'admin BSD :) On peut pas "louer" le deuxieme le temps que le troisième sorte :) ?
T'inquiete pas, je ne vais pas en sortir une nouvelle edition tous les 10 mois. Faut quand même avoir un peu plus à rajouter que des precisions et corrections.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Miod Vallat
T'inquiete pas, je ne vais pas en sortir une nouvelle edition tous les 10 mois. Faut quand même avoir un peu plus à rajouter que des precisions et corrections.
En fait, tu veux que NetBSD 2.0 sorte avant de publier la prochaine
édition, ce qui laisse effectivement allégrement plus de dix mois.
T'inquiete pas, je ne vais pas en sortir une nouvelle edition tous les
10 mois. Faut quand même avoir un peu plus à rajouter que des precisions
et corrections.
En fait, tu veux que NetBSD 2.0 sorte avant de publier la prochaine
édition, ce qui laisse effectivement allégrement plus de dix mois.
T'inquiete pas, je ne vais pas en sortir une nouvelle edition tous les 10 mois. Faut quand même avoir un peu plus à rajouter que des precisions et corrections.
En fait, tu veux que NetBSD 2.0 sorte avant de publier la prochaine
édition, ce qui laisse effectivement allégrement plus de dix mois.
Arnaud Launay
Le Tue, 24 Aug 2004 17:16:35 +0400, Sebastien Vincent écrivit:
Bah là en l'occurence, l'architecture c'est Moi(gentoo 2.6.8)
Stooooooooop ! Il est probablement là le problème, essaye de repasser en 2.6.7.
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester. Donc la tous les paquets sont coupes pour faire 200.
Ca ne resout pas frocement ton problème: que se passe-t-il si le site en face essaye de t'envoyer un paquet marqué DF (don't fragment) et au dessus du MTU de ton lien ADSL? Réponse: le paquet est rejeté.
Bah là en l'occurence, l'architecture c'est Moi(gentoo 2.6.8)<---[100BaseT]-->OpenBSD<---[100BaseT]--->RedHat<----[PPPoE]--->Modem Ethernet<--->Internet
Le probleme surbien quand je ping Redhat depuis mon poste.
Sur OpenBSD je fait une translation d'adresse. Normalement toutes les MTU en 1500 ca devrait passer sans problemes.
Pas de filtrage de l'icmp (nulle part).
J'ai tenté un scrub in/out all no-df, rien de mieux :/
Bien sur le coup est prévu, et il existe des mécanismes de découverte du PMTU (le plus petit MTU du chemin), mais quand on filtre n'importe quoi au niveau ICMP on anihile ces mecanismes. Le filtrage en forme de n'importe quoi peut se passer sur la machine en face sur laquelle tu n'as pas de controle.
Ca je l'ai appris recemment (probablement dans les cahiers de l'admin) :))
La solution c'est d'utiliser le Maximum Segment Size (MSS) de TCP, qui permet d'indiquer à la machine en face la taille maximum des paquets attendus, au moment de l'initiation d'une connexion TCP. Problème: il faudrait que toutes les machines de ton réseau soit aware du problème pour fixer un MSS adéquat. Solution: le MSS clamping, qui consiste à faire modifier au vol les MSS par ta passerelle.
Bah je ne pense pas que ca viennent de là, puisque depuis openbsd sur je ping openbsd.org avec un paquet de 1600 octets ca passe. mais depuis le reseau local niettes :/
Note que ca ne regle le probème que pour TCP. La vraie solution c'est que tout le monde partout sur Internet laisse passer le traffic ICMP indispensable au bon fonctionnement de IP.
En l'occurence là, pas de filtrage :)
Derniere question, comment mettre en place le MSS clamping. Avec IPFilter, ca se fait dans ipnat.conf: map pppoe0 10.0.0.0/24 -> 0/32 portmap tcp/udp 40000:42999 mssclamp 1352 map pppoe0 10.0.0.0/24 -> 0/32 mssclamp 1352
Si on veut faire du MSS clamping sans NAT, il suffit de faire un NAT 1:1 map pppoe0 10.0.0.0/24 -> 0/0 mssclamp 1352
Bon, j'ai mis 1352, on peut monter un petit peu, tout dépend de ce qu'on fait passer comme protocole d'encapsulation.
Avec Packet Filter, c'est scrub qui fait le travail: scrub in all max-mss 1352 no-df
Ca je note :))) Je vias googler pour mieux comprendre comment cela se passe :)
Le thread reste ouvert haha :)
Je vois surtout que je commence à avoir des choses à mettre dans une 3eme edition du cahier de l'admin BSD :)
On peut pas "louer" le deuxieme le temps que le troisième sorte :) ?
Amicalement,
Seb :)
Emmanuel Dreyfus wrote:
Sebastien Vincent <svincent@idems.fr> wrote:
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester.
Donc la tous les paquets sont coupes pour faire 200.
Ca ne resout pas frocement ton problème: que se passe-t-il si le site en
face essaye de t'envoyer un paquet marqué DF (don't fragment) et au
dessus du MTU de ton lien ADSL? Réponse: le paquet est rejeté.
Bah là en l'occurence, l'architecture c'est
Moi(gentoo
2.6.8)<---[100BaseT]-->OpenBSD<---[100BaseT]--->RedHat<----[PPPoE]--->Modem
Ethernet<--->Internet
Le probleme surbien quand je ping Redhat depuis mon poste.
Sur OpenBSD je fait une translation d'adresse. Normalement toutes les
MTU en 1500 ca devrait passer sans problemes.
Pas de filtrage de l'icmp (nulle part).
J'ai tenté un scrub in/out all no-df, rien de mieux :/
Bien sur le coup est prévu, et il existe des mécanismes de découverte du
PMTU (le plus petit MTU du chemin), mais quand on filtre n'importe quoi
au niveau ICMP on anihile ces mecanismes. Le filtrage en forme de
n'importe quoi peut se passer sur la machine en face sur laquelle tu
n'as pas de controle.
Ca je l'ai appris recemment (probablement dans les cahiers de l'admin)
:))
La solution c'est d'utiliser le Maximum Segment Size (MSS) de TCP, qui
permet d'indiquer à la machine en face la taille maximum des paquets
attendus, au moment de l'initiation d'une connexion TCP. Problème: il
faudrait que toutes les machines de ton réseau soit aware du problème
pour fixer un MSS adéquat. Solution: le MSS clamping, qui consiste à
faire modifier au vol les MSS par ta passerelle.
Bah je ne pense pas que ca viennent de là, puisque depuis openbsd
sur je ping openbsd.org avec un paquet de 1600 octets ca passe.
mais depuis le reseau local niettes :/
Note que ca ne regle le probème que pour TCP. La vraie solution c'est
que tout le monde partout sur Internet laisse passer le traffic ICMP
indispensable au bon fonctionnement de IP.
En l'occurence là, pas de filtrage :)
Derniere question, comment mettre en place le MSS clamping. Avec
IPFilter, ca se fait dans ipnat.conf:
map pppoe0 10.0.0.0/24 -> 0/32 portmap tcp/udp 40000:42999 mssclamp 1352
map pppoe0 10.0.0.0/24 -> 0/32 mssclamp 1352
Si on veut faire du MSS clamping sans NAT, il suffit de faire un NAT 1:1
map pppoe0 10.0.0.0/24 -> 0/0 mssclamp 1352
Bon, j'ai mis 1352, on peut monter un petit peu, tout dépend de ce qu'on
fait passer comme protocole d'encapsulation.
Avec Packet Filter, c'est scrub qui fait le travail:
scrub in all max-mss 1352 no-df
Ca je note :)))
Je vias googler pour mieux comprendre comment cela se passe :)
Le thread reste ouvert haha :)
Je vois surtout que je commence à avoir des choses à mettre dans une
3eme edition du cahier de l'admin BSD :)
On peut pas "louer" le deuxieme le temps que le troisième sorte :) ?
Bon, ben l'affaire est entendue: un problème de MTU.
J'ai mis mtu 200 sur les deux interfaces d'openbsd pour tester. Donc la tous les paquets sont coupes pour faire 200.
Ca ne resout pas frocement ton problème: que se passe-t-il si le site en face essaye de t'envoyer un paquet marqué DF (don't fragment) et au dessus du MTU de ton lien ADSL? Réponse: le paquet est rejeté.
Bah là en l'occurence, l'architecture c'est Moi(gentoo 2.6.8)<---[100BaseT]-->OpenBSD<---[100BaseT]--->RedHat<----[PPPoE]--->Modem Ethernet<--->Internet
Le probleme surbien quand je ping Redhat depuis mon poste.
Sur OpenBSD je fait une translation d'adresse. Normalement toutes les MTU en 1500 ca devrait passer sans problemes.
Pas de filtrage de l'icmp (nulle part).
J'ai tenté un scrub in/out all no-df, rien de mieux :/
Bien sur le coup est prévu, et il existe des mécanismes de découverte du PMTU (le plus petit MTU du chemin), mais quand on filtre n'importe quoi au niveau ICMP on anihile ces mecanismes. Le filtrage en forme de n'importe quoi peut se passer sur la machine en face sur laquelle tu n'as pas de controle.
Ca je l'ai appris recemment (probablement dans les cahiers de l'admin) :))
La solution c'est d'utiliser le Maximum Segment Size (MSS) de TCP, qui permet d'indiquer à la machine en face la taille maximum des paquets attendus, au moment de l'initiation d'une connexion TCP. Problème: il faudrait que toutes les machines de ton réseau soit aware du problème pour fixer un MSS adéquat. Solution: le MSS clamping, qui consiste à faire modifier au vol les MSS par ta passerelle.
Bah je ne pense pas que ca viennent de là, puisque depuis openbsd sur je ping openbsd.org avec un paquet de 1600 octets ca passe. mais depuis le reseau local niettes :/
Note que ca ne regle le probème que pour TCP. La vraie solution c'est que tout le monde partout sur Internet laisse passer le traffic ICMP indispensable au bon fonctionnement de IP.
En l'occurence là, pas de filtrage :)
Derniere question, comment mettre en place le MSS clamping. Avec IPFilter, ca se fait dans ipnat.conf: map pppoe0 10.0.0.0/24 -> 0/32 portmap tcp/udp 40000:42999 mssclamp 1352 map pppoe0 10.0.0.0/24 -> 0/32 mssclamp 1352
Si on veut faire du MSS clamping sans NAT, il suffit de faire un NAT 1:1 map pppoe0 10.0.0.0/24 -> 0/0 mssclamp 1352
Bon, j'ai mis 1352, on peut monter un petit peu, tout dépend de ce qu'on fait passer comme protocole d'encapsulation.
Avec Packet Filter, c'est scrub qui fait le travail: scrub in all max-mss 1352 no-df
Ca je note :))) Je vias googler pour mieux comprendre comment cela se passe :)
Le thread reste ouvert haha :)
Je vois surtout que je commence à avoir des choses à mettre dans une 3eme edition du cahier de l'admin BSD :)
On peut pas "louer" le deuxieme le temps que le troisième sorte :) ?
Amicalement,
Seb :)
Sebastien Vincent
Arnaud Launay wrote:
Le Tue, 24 Aug 2004 17:16:35 +0400, Sebastien Vincent écrivit:
Bah là en l'occurence, l'architecture c'est Moi(gentoo 2.6.8)
Stooooooooop ! Il est probablement là le problème, essaye de repasser en 2.6.7.
Arnaud.
Testé avec des windows aussi, ca ne marche pas non plus. Le probleme ne viens pas du client.
Amicalement,
Seb :)
Arnaud Launay wrote:
Le Tue, 24 Aug 2004 17:16:35 +0400, Sebastien Vincent écrivit:
Bah là en l'occurence, l'architecture c'est Moi(gentoo 2.6.8)
Stooooooooop ! Il est probablement là le problème, essaye de
repasser en 2.6.7.
Arnaud.
Testé avec des windows aussi, ca ne marche pas non plus.
Le probleme ne viens pas du client.
Le Tue, 24 Aug 2004 17:16:35 +0400, Sebastien Vincent écrivit:
Bah là en l'occurence, l'architecture c'est Moi(gentoo 2.6.8)
Stooooooooop ! Il est probablement là le problème, essaye de repasser en 2.6.7.
Arnaud.
Testé avec des windows aussi, ca ne marche pas non plus. Le probleme ne viens pas du client.
Amicalement,
Seb :)
manu
Miod Vallat wrote:
T'inquiete pas, je ne vais pas en sortir une nouvelle edition tous les 10 mois. Faut quand même avoir un peu plus à rajouter que des precisions et corrections. En fait, tu veux que NetBSD 2.0 sorte avant de publier la prochaine
édition, ce qui laisse effectivement allégrement plus de dix mois.
Faut surtout que le tirage de la 2eme edition soit épuisé...
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Miod Vallat <miod@online.fr> wrote:
T'inquiete pas, je ne vais pas en sortir une nouvelle edition tous les
10 mois. Faut quand même avoir un peu plus à rajouter que des precisions
et corrections.
En fait, tu veux que NetBSD 2.0 sorte avant de publier la prochaine
édition, ce qui laisse effectivement allégrement plus de dix mois.
Faut surtout que le tirage de la 2eme edition soit épuisé...
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
T'inquiete pas, je ne vais pas en sortir une nouvelle edition tous les 10 mois. Faut quand même avoir un peu plus à rajouter que des precisions et corrections. En fait, tu veux que NetBSD 2.0 sorte avant de publier la prochaine
édition, ce qui laisse effectivement allégrement plus de dix mois.
Faut surtout que le tirage de la 2eme edition soit épuisé...
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
