PPTP et flux de données égorgé : pb de mtu ??

Le
Thomas
bonjour :-)

(rien à voir avec le post precedent)



j'ai 3 freebox :
- moi
- un ordi seul
- un reseau local derriere un lanbooster (avec un serveur PPTP)

l'ordi seul et moi avons un client PPTP connecté au lanbooster, pour que
tout le monde puisse se parler
le lanbooster oblige toutes les connexions des clients à passer par lui


je peux piloter les ordis du reseau local avec vnc sans pb
je peux piloter l'ordi seul avec vnc sans pb
l'ordi seul peut piloter les ordis du reseau local avec vnc sans pb

les ordis du reseau local *ne peuvent pas* piloter l'ordi seul avec vnc
sans pb, *si* on se connecte *sur l'ip PPTP* de l'ordi seul
les ordis du reseau local *peuvent* piloter l'ordi seul avec vnc sans
pb, *si* on se connecte *sur l'ip directe* (freebox) de l'ordi seul

j'ai remarqué qu'il n'y a pas de pb quand il y a tres peu de données à
faire passer,
mais que ca coince des qu'il y a de grandes quantités de données à faire
passer, qq soit le protocole
c'est comme si, au bout d'une certaine quantité de données, pouf, ca
s'arrete (sauf que c'est pas tres regulier)
je crois que c'est pour chaque connexion tcp


si j'ai bien compris,
quand un ordi du reseau local fait une connexion tcp sur l'ip directe de
l'ordi seul,
- toutes les données qui vont de l'ordi seul à l'ordi du reseau local
passent à l'interieur du tunnel PPTP, et
- toutes les données qui vont de l'ordi du reseau local à l'ordi seul
passent à l'exterieur du tunnel PPTP
meme les paquets tcp ack
c'est bien ca ?


donc si ce qui pose pb c'est les gros flux de données de l'ordi seul à
un ordi du reseau local, c'est que les paquets tcp ack n'arrivent pas à
remonter à l'interieur du tunnel PPTP, mais qu'ils arrivent à remonter
si ils passent à l'exterieur
sauf que ca passe sans pb entre moi et l'ordi seul (n'etant pas derriere
le serveur PPTP, je ne peux pas utiliser son ip directe, je suis obligé
d'utiliser son ip PPTP)

donc moi et un ordi du reseau local, on n'enverrais pas les paquets tcp
ack de la meme maniere, de sorte que
des paquets tcp ack qui doivent aller du reseau local à l'ordi seul, si
ils viennent d'un ordi du reseau local ca passe pas, et si ils viennent
de moi ca passe
??


voilà où j'en suis de mes tests :-)
qqn a une idée ?

ca peut etre un pb de mtu ?
un element du reseau qui en aurait marre trop vite de devoir casser en 2
des paquets tcp ack pour les faire rentrer dans le tunnel ?
mais en meme temps des paquets tcp normaux passent sans pb

--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Antoine ROUCHET
Le #860493
"Thomas" news:
bonjour :-)

(rien à voir avec le post precedent)



j'ai 3 freebox :
- moi
- un ordi seul
- un reseau local derriere un lanbooster (avec un serveur PPTP)

l'ordi seul et moi avons un client PPTP connecté au lanbooster, pour que
tout le monde puisse se parler
le lanbooster oblige toutes les connexions des clients à passer par lui


je peux piloter les ordis du reseau local avec vnc sans pb
je peux piloter l'ordi seul avec vnc sans pb
l'ordi seul peut piloter les ordis du reseau local avec vnc sans pb

les ordis du reseau local *ne peuvent pas* piloter l'ordi seul avec vnc
sans pb, *si* on se connecte *sur l'ip PPTP* de l'ordi seul
les ordis du reseau local *peuvent* piloter l'ordi seul avec vnc sans
pb, *si* on se connecte *sur l'ip directe* (freebox) de l'ordi seul

j'ai remarqué qu'il n'y a pas de pb quand il y a tres peu de données à
faire passer,
mais que ca coince des qu'il y a de grandes quantités de données à faire
passer, qq soit le protocole
c'est comme si, au bout d'une certaine quantité de données, pouf, ca
s'arrete (sauf que c'est pas tres regulier)
je crois que c'est pour chaque connexion tcp


si j'ai bien compris,
quand un ordi du reseau local fait une connexion tcp sur l'ip directe de
l'ordi seul,
- toutes les données qui vont de l'ordi seul à l'ordi du reseau local
passent à l'interieur du tunnel PPTP, et
- toutes les données qui vont de l'ordi du reseau local à l'ordi seul
passent à l'exterieur du tunnel PPTP
meme les paquets tcp ack
c'est bien ca ?


donc si ce qui pose pb c'est les gros flux de données de l'ordi seul à
un ordi du reseau local, c'est que les paquets tcp ack n'arrivent pas à
remonter à l'interieur du tunnel PPTP, mais qu'ils arrivent à remonter
si ils passent à l'exterieur
sauf que ca passe sans pb entre moi et l'ordi seul (n'etant pas derriere
le serveur PPTP, je ne peux pas utiliser son ip directe, je suis obligé
d'utiliser son ip PPTP)

donc moi et un ordi du reseau local, on n'enverrais pas les paquets tcp
ack de la meme maniere, de sorte que
des paquets tcp ack qui doivent aller du reseau local à l'ordi seul, si
ils viennent d'un ordi du reseau local ca passe pas, et si ils viennent
de moi ca passe
??


voilà où j'en suis de mes tests ... :-)
qqn a une idée ?

ca peut etre un pb de mtu ?
un element du reseau qui en aurait marre trop vite de devoir casser en 2
des paquets tcp ack pour les faire rentrer dans le tunnel ?
mais en meme temps des paquets tcp normaux passent sans pb ...


Bonjour,

En effet, l'encapsulation PPTP réduit le MTU de la connexion virtuelle. Le
MTU "standard" d'un lien IP sur Ethernet ou IPoA (l'encapsulation ATM
utilisée par Free) est de 1500. Si on fait passer IP dans un tunnel PPTP (un
tunnel GRE en pratique), le MTU descend en général à 1396.

La commande "ping -l x -f a.b.c.d" (x = taille du paquet et a.b.c.d =
adresse IP) vous permet de déterminer le MTU actuel d'un lien. Essayez là
vers le routeur d'abord pour déterminer le MTU du "support" (qui doit être
de 1500 si tout va bien donc), puis essayer là vers une machine placée
derrière le VPN afin de déterminer le MTU restant après encapsulation GRE
(qui doit être de 1396 si j'ai bonne mémoire, sachant que ça peut sûrement
varier d'une implémentation à l'autre de PPTP).

Une fois le MTU déterminé, les actions à effectuer dépendent des OS
utilisés. Pour Windows, on peut forcer le MTU dans la base de registre mais
en théorie c'est inutile puisque l'OS le détermine lui même par essais
successifs.

Un dernier point: si vous avez moyen de changer de VPN et en fonction de vos
contraintes, je vous conseillerais d'opter plutôt pour OpenVPN qui créé un
tunnel IP over UDP qui conserver un MTU de 1500. En outre, les problèmes de
passage à travers les boites à NAT sont extremement simples.

Bon courage et en esperant vous avoir aidé,
Antoine.

Thomas
Le #860489
In article (Dans l'article) "Antoine ROUCHET"
"Thomas" news:

j'ai 3 freebox :
- moi
- un ordi seul
- un reseau local derriere un lanbooster (avec un serveur PPTP)

l'ordi seul et moi avons un client PPTP connecté au lanbooster, pour que
tout le monde puisse se parler
le lanbooster oblige toutes les connexions des clients à passer par lui


je peux piloter les ordis du reseau local avec vnc sans pb
je peux piloter l'ordi seul avec vnc sans pb
l'ordi seul peut piloter les ordis du reseau local avec vnc sans pb

les ordis du reseau local *ne peuvent pas* piloter l'ordi seul avec vnc
sans pb, *si* on se connecte *sur l'ip PPTP* de l'ordi seul
les ordis du reseau local *peuvent* piloter l'ordi seul avec vnc sans
pb, *si* on se connecte *sur l'ip directe* (freebox) de l'ordi seul

j'ai remarqué qu'il n'y a pas de pb quand il y a tres peu de données à
faire passer,
mais que ca coince des qu'il y a de grandes quantités de données à faire
passer, qq soit le protocole
c'est comme si, au bout d'une certaine quantité de données, pouf, ca
s'arrete (sauf que c'est pas tres regulier)
je crois que c'est pour chaque connexion tcp



ca ne t'es jamais arrivé, à toi ?
t'utilises que openvpn ?
(parce que ca serait "mieux" que ca te sois deja arrivé, pour que tu
puisses savoir exactement comment resoudre le pb :-) )



si j'ai bien compris,
quand un ordi du reseau local fait une connexion tcp sur l'ip directe de
l'ordi seul,
- toutes les données qui vont de l'ordi seul à l'ordi du reseau local
passent à l'interieur du tunnel PPTP, et
- toutes les données qui vont de l'ordi du reseau local à l'ordi seul
passent à l'exterieur du tunnel PPTP
meme les paquets tcp ack
c'est bien ca ?



est ce que j'ai bien compris, là ?



donc si ce qui pose pb c'est les gros flux de données de l'ordi seul à
un ordi du reseau local, c'est que les paquets tcp ack n'arrivent pas à
remonter à l'interieur du tunnel PPTP, mais qu'ils arrivent à remonter
si ils passent à l'exterieur
sauf que ca passe sans pb entre moi et l'ordi seul (n'etant pas derriere
le serveur PPTP, je ne peux pas utiliser son ip directe, je suis obligé
d'utiliser son ip PPTP)

donc moi et un ordi du reseau local, on n'enverrais pas les paquets tcp
ack de la meme maniere, de sorte que
des paquets tcp ack qui doivent aller du reseau local à l'ordi seul, si
ils viennent d'un ordi du reseau local ca passe pas, et si ils viennent
de moi ca passe
??


voilà où j'en suis de mes tests ... :-)
qqn a une idée ?

ca peut etre un pb de mtu ?
un element du reseau qui en aurait marre trop vite de devoir casser en 2
des paquets tcp ack pour les faire rentrer dans le tunnel ?
mais en meme temps des paquets tcp normaux passent sans pb ...



En effet, l'encapsulation PPTP réduit le MTU de la connexion virtuelle. Le
MTU "standard" d'un lien IP sur Ethernet ou IPoA (l'encapsulation ATM
utilisée par Free) est de 1500. Si on fait passer IP dans un tunnel PPTP (un
tunnel GRE en pratique), le MTU descend en général à 1396.

La commande "ping -l x -f a.b.c.d" (x = taille du paquet et a.b.c.d =
adresse IP) vous permet de déterminer le MTU actuel d'un lien. Essayez là
vers le routeur d'abord pour déterminer le MTU du "support" (qui doit être
de 1500 si tout va bien donc), puis essayer là vers une machine placée
derrière le VPN afin de déterminer le MTU restant après encapsulation GRE
(qui doit être de 1396 si j'ai bonne mémoire, sachant que ça peut sûrement
varier d'une implémentation à l'autre de PPTP).


donc si le ping passe on est en dessous ou au maximum, et si il ne passe
pas, on est au dessus ?
bon, faut que je configure mes machines pour accepter le ping
en attendant, est ce que ifconfig ca peut indiquer la valeur ou c'est
pas fiable ?

chez moi :
% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::203:93ff:feaf:45ae%en0 prefixlen 64 scopeid 0x4
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:03:93:af:45:ae
media: autoselect (10baseT/UTP <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
ppp0: flags€51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00

sur l'ordi seul :
% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::20a:95ff:fe7f:797e%en0 prefixlen 64 scopeid 0x4
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:0a:95:7f:79:7e
media: autoselect (100baseTX <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
fw0: flagsˆ22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 2030
lladdr 00:0a:95:ff:fe:7f:79:7e
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>
ppp0: flags€51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1444
inet 192.168.1.202 --> 192.168.1.1 netmask 0xffffff00

sur un ordi du reseau local :
% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::20d:93ff:fe45:7840%en0 prefixlen 64 scopeid 0x4
inet 192.168.1.7 netmask 0xffffff00 broadcast 192.168.1.255
ether 00:0d:93:45:78:40
media: autoselect (100baseTX <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
en1: flagsˆ22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:11:24:22:7d:41
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flagsˆ22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 2030
lladdr 00:0d:93:ff:fe:45:78:40
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>



Une fois le MTU déterminé, les actions à effectuer dépendent des OS
utilisés.


j'ai vu une case pour ca, je vais essayer

et c'est sur les ordis du reseau local qu'il faut reduire le mtu pour
qu'il ne soit pas plus grand que celui du tunnel PPTP ?
plus petit c'est pas genant ?
pas besoin de le changer sur l'ordi seul ?


Un dernier point: si vous avez moyen de changer de VPN et en fonction de vos
contraintes, je vous conseillerais d'opter plutôt pour OpenVPN qui créé un
tunnel IP over UDP qui conserver un MTU de 1500. En outre, les problèmes de
passage à travers les boites à NAT sont extremement simples.


pas pratique de mettre un serveur sur un ordi
ca serait mieux si on pouvait continuer à utiliser un des 3 modes
proposés par le routeur


Bon courage et en esperant vous avoir aidé,


merci :-)

--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf


Antoine ROUCHET
Le #860488
"Thomas" news:
In article (Dans l'article) "Antoine ROUCHET"
"Thomas" news:

j'ai 3 freebox :
- moi
- un ordi seul
- un reseau local derriere un lanbooster (avec un serveur PPTP)

l'ordi seul et moi avons un client PPTP connecté au lanbooster, pour
que
tout le monde puisse se parler
le lanbooster oblige toutes les connexions des clients à passer par lui


je peux piloter les ordis du reseau local avec vnc sans pb
je peux piloter l'ordi seul avec vnc sans pb
l'ordi seul peut piloter les ordis du reseau local avec vnc sans pb

les ordis du reseau local *ne peuvent pas* piloter l'ordi seul avec vnc
sans pb, *si* on se connecte *sur l'ip PPTP* de l'ordi seul
les ordis du reseau local *peuvent* piloter l'ordi seul avec vnc sans
pb, *si* on se connecte *sur l'ip directe* (freebox) de l'ordi seul

j'ai remarqué qu'il n'y a pas de pb quand il y a tres peu de données à
faire passer,
mais que ca coince des qu'il y a de grandes quantités de données à
faire
passer, qq soit le protocole
c'est comme si, au bout d'une certaine quantité de données, pouf, ca
s'arrete (sauf que c'est pas tres regulier)
je crois que c'est pour chaque connexion tcp



ca ne t'es jamais arrivé, à toi ?
t'utilises que openvpn ?
(parce que ca serait "mieux" que ca te sois deja arrivé, pour que tu
puisses savoir exactement comment resoudre le pb :-) )



Avant OpenVPN, j'utilisais le serveur VPN de Windows 2000 Server ou celui de
2003 (les mêmes quoi). Et oui j'ai déjà rencontré ce genre de symptomes, je
ne m'amuse pas à répondre au hasard sur les NG pour passer le temps :-)) .
J'en suis arrivé assez vite à la conclusion suivante: avoir un MTU inférieur
au MTU "standard" (1500) sur une partie du réseau (genre sur une patte d'un
routeur), c'est galère, voilà par exemple pourquoi:

Une ordi du réseau local veut parler à l'ordi seul. Il passe donc
(logiquement) par le tunnel VPN
- Le MTU de l'ordi du réseau local sera de 1500 (logique, c'est un réseau
Ethernet classique).
- Le MTU de la connexion P2P entre l'ordi seul et le lanbooster sera
inférieur (1386 probablement) à cause de PPTP.

Conclusion: soit les paquets > à 1386 octets sont simplement perdus parce
que le routeur ne gère pas la fragmentation (déjà vu une fois), soit la
connexion est super lente parce que le routeur (qui n'est généralement pas
un foudre de guerre en plus) doit découper les paquets trop gros en paquets
plus petits.

La seule solution à ma connaissance pour éviter ça est de forcer sur les
machines du réseau local le MTU à 1386, soit celui de la connexion PPTP.
Mais là bien sûr, on perd en perf sur le réseau local (pas énormément mais
ça peut se sentir quand même, et il faut pouvoir le faire sur le routeur, en
plus).



si j'ai bien compris,
quand un ordi du reseau local fait une connexion tcp sur l'ip directe
de
l'ordi seul,
- toutes les données qui vont de l'ordi seul à l'ordi du reseau local
passent à l'interieur du tunnel PPTP, et
- toutes les données qui vont de l'ordi du reseau local à l'ordi seul
passent à l'exterieur du tunnel PPTP
meme les paquets tcp ack
c'est bien ca ?



est ce que j'ai bien compris, là ?


Ca dépend des tables de routages de l'ordi du réseau local concerné, du
lanbooster et de l'ordi seul.





donc si ce qui pose pb c'est les gros flux de données de l'ordi seul à
un ordi du reseau local, c'est que les paquets tcp ack n'arrivent pas à
remonter à l'interieur du tunnel PPTP, mais qu'ils arrivent à remonter
si ils passent à l'exterieur
sauf que ca passe sans pb entre moi et l'ordi seul (n'etant pas
derriere
le serveur PPTP, je ne peux pas utiliser son ip directe, je suis obligé
d'utiliser son ip PPTP)

donc moi et un ordi du reseau local, on n'enverrais pas les paquets tcp
ack de la meme maniere, de sorte que
des paquets tcp ack qui doivent aller du reseau local à l'ordi seul, si
ils viennent d'un ordi du reseau local ca passe pas, et si ils viennent
de moi ca passe
??


voilà où j'en suis de mes tests ... :-)
qqn a une idée ?

ca peut etre un pb de mtu ?
un element du reseau qui en aurait marre trop vite de devoir casser en
2
des paquets tcp ack pour les faire rentrer dans le tunnel ?
mais en meme temps des paquets tcp normaux passent sans pb ...



En effet, l'encapsulation PPTP réduit le MTU de la connexion virtuelle.
Le
MTU "standard" d'un lien IP sur Ethernet ou IPoA (l'encapsulation ATM
utilisée par Free) est de 1500. Si on fait passer IP dans un tunnel PPTP
(un
tunnel GRE en pratique), le MTU descend en général à 1396.

La commande "ping -l x -f a.b.c.d" (x = taille du paquet et a.b.c.d >> adresse IP) vous permet de déterminer le MTU actuel d'un lien. Essayez là
vers le routeur d'abord pour déterminer le MTU du "support" (qui doit
être
de 1500 si tout va bien donc), puis essayer là vers une machine placée
derrière le VPN afin de déterminer le MTU restant après encapsulation GRE
(qui doit être de 1396 si j'ai bonne mémoire, sachant que ça peut
sûrement
varier d'une implémentation à l'autre de PPTP).


donc si le ping passe on est en dessous ou au maximum, et si il ne passe
pas, on est au dessus ?
bon, faut que je configure mes machines pour accepter le ping
en attendant, est ce que ifconfig ca peut indiquer la valeur ou c'est
pas fiable ?



En effet, si le ping passe, on est en dessous ou au maximum du MTU, sinon on
est au dessus.
Sur les OS UNIX et dérivés je ne sais pas trop comment gerer le MTU et si la
valeur indiquée par ifconfig est fiable, mais j'ai tendance à penser qu'elle
l'est.

chez moi :
% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::203:93ff:feaf:45ae%en0 prefixlen 64 scopeid 0x4
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:03:93:af:45:ae
media: autoselect (10baseT/UTP <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
ppp0: flags€51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00

sur l'ordi seul :
% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::20a:95ff:fe7f:797e%en0 prefixlen 64 scopeid 0x4
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:0a:95:7f:79:7e
media: autoselect (100baseTX <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
fw0: flagsˆ22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 2030
lladdr 00:0a:95:ff:fe:7f:79:7e
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>
ppp0: flags€51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1444
inet 192.168.1.202 --> 192.168.1.1 netmask 0xffffff00

sur un ordi du reseau local :
% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::20d:93ff:fe45:7840%en0 prefixlen 64 scopeid 0x4
inet 192.168.1.7 netmask 0xffffff00 broadcast 192.168.1.255
ether 00:0d:93:45:78:40
media: autoselect (100baseTX <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
en1: flagsˆ22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:11:24:22:7d:41
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flagsˆ22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 2030
lladdr 00:0d:93:ff:fe:45:78:40
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>



Une fois le MTU déterminé, les actions à effectuer dépendent des OS
utilisés.


j'ai vu une case pour ca, je vais essayer

et c'est sur les ordis du reseau local qu'il faut reduire le mtu pour
qu'il ne soit pas plus grand que celui du tunnel PPTP ?
plus petit c'est pas genant ?
pas besoin de le changer sur l'ordi seul ?


En effet c'est sur les ordis du réseau local *ET* sur la ou les interface(s)
ethernet du lanbooster sur lesquelles sont connectés les ordis du réseau
local. Sur l'ordi seul il n'y a pas besoin non puisque le MTU est imposé par
le tunnel PPTP.

Tu peux mettre un MTU plus petit, mais alors il faudra également changer
celui du tunnel PPTP, ce qui devient compliqué.


Un dernier point: si vous avez moyen de changer de VPN et en fonction de
vos
contraintes, je vous conseillerais d'opter plutôt pour OpenVPN qui créé
un
tunnel IP over UDP qui conserver un MTU de 1500. En outre, les problèmes
de
passage à travers les boites à NAT sont extremement simples.


pas pratique de mettre un serveur sur un ordi
ca serait mieux si on pouvait continuer à utiliser un des 3 modes
proposés par le routeur


Bon courage et en esperant vous avoir aidé,


merci :-)


De rien!

Antoine.



Thomas
Le #860327
In article (Dans l'article)
Thomas
chez moi :
% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::203:93ff:feaf:45ae%en0 prefixlen 64 scopeid 0x4
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:03:93:af:45:ae
media: autoselect (10baseT/UTP <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
ppp0: flags€51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00

sur l'ordi seul :
% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::20a:95ff:fe7f:797e%en0 prefixlen 64 scopeid 0x4
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:0a:95:7f:79:7e
media: autoselect (100baseTX <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
fw0: flagsˆ22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 2030
lladdr 00:0a:95:ff:fe:7f:79:7e
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>
ppp0: flags€51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1444
inet 192.168.1.202 --> 192.168.1.1 netmask 0xffffff00

sur un ordi du reseau local :
% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::20d:93ff:fe45:7840%en0 prefixlen 64 scopeid 0x4
inet 192.168.1.7 netmask 0xffffff00 broadcast 192.168.1.255
ether 00:0d:93:45:78:40
media: autoselect (100baseTX <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
en1: flagsˆ22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:11:24:22:7d:41
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flagsˆ22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 2030
lladdr 00:0d:93:ff:fe:45:78:40
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>



bon là j'ai pas le temps de lire ta reponse, désolé,
je poste juste pour donner ce que j'ai sur mon ordi, là je me suis
deplacé juste à coté de "l'ordi seul", derriere la meme freebox


% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::203:93ff:feaf:45ae%en0 prefixlen 64 scopeid 0x4
inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:03:93:af:45:ae
media: autoselect (100baseTX <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
ppp0: flags€51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.202 --> 192.168.1.1 netmask 0xffffff00


il semble que je n'ai aucun pb de transfert de données quand je suis
chez moi (je te le reconfirmerais quand je serais rentré chez moi),
là j'ai le meme pb de transfert de données que l'ordi seul, maintenant
que je suis à coté de lui

les freebox : chez moi en dégroupé, les 2 autres en non dégroupé

--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf

Antoine ROUCHET
Le #860326
"Thomas" news:
In article (Dans l'article)
Thomas

<snip>


bon là j'ai pas le temps de lire ta reponse, désolé,
je poste juste pour donner ce que j'ai sur mon ordi, là je me suis
deplacé juste à coté de "l'ordi seul", derriere la meme freebox


% ifconfig
lo0: flags€49<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags€10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::203:93ff:feaf:45ae%en0 prefixlen 64 scopeid 0x4
inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:03:93:af:45:ae
media: autoselect (100baseTX <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback>
ppp0: flags€51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.202 --> 192.168.1.1 netmask 0xffffff00


il semble que je n'ai aucun pb de transfert de données quand je suis
chez moi (je te le reconfirmerais quand je serais rentré chez moi),
là j'ai le meme pb de transfert de données que l'ordi seul, maintenant
que je suis à coté de lui

les freebox : chez moi en dégroupé, les 2 autres en non dégroupé



Peut-être un indice intéressant: en dégroupé les freebox utilise IPoA qui
donne le même MTU qu'un liens Ethernet classique (1500). En non-dégroupé, le
protocole est celui de FT (PPPoE je crois) et le MTU est probablement
inférieur (à vérifier tout ça).

Antoine.

Dominique ROUSSEAU
Le #860325
Le ven, 20 jui 2007 at 14:35 GMT, Antoine ROUCHET
Peut-être un indice intéressant: en dégroupé les freebox utilise IPoA qui
donne le même MTU qu'un liens Ethernet classique (1500). En non-dégroupé, le
protocole est celui de FT (PPPoE je crois) et le MTU est probablement
inférieur (à vérifier tout ça).


àmha la connexion d'une friboite en non-dégroupé, c'est du PPPoA, donc
sans probleme de MTU

Pascal Hambourg
Le #860324
Salut,


Peut-être un indice intéressant: en dégroupé les freebox utilise IPoA qui
donne le même MTU qu'un liens Ethernet classique (1500). En non-dégroupé, le
protocole est celui de FT (PPPoE je crois) et le MTU est probablement
inférieur (à vérifier tout ça).


En IP/ADSL (non dégroupé), j'ai lu que la Freebox utilisait plutôt
PPPoA, qui permet un MTU à 1500. D'ailleurs je ne vois aucune raison
d'utiliser PPPoE plutôt que PPPoA dans ce contexte ; il n'aurait que des
inconvénients, MTU plus bas et surcharge protocolaire plus importante.

Thomas
Le #860321
In article (Dans l'article)
Thomas
il semble que je n'ai aucun pb de transfert de données quand je suis
chez moi (je te le reconfirmerais quand je serais rentré chez moi),


% rsync -v --partial --progress --stats ~/gc521xcomplete.zip
:~/
gc521xcomplete.zip
524288 100% 95.90kB/s 0:00:05 (1, 100.0% of 1)

Number of files: 1
Number of files transferred: 1
Total file size: 524288 bytes
Total transferred file size: 524288 bytes
Literal data: 524288 bytes
Matched data: 0 bytes
File list size: 37
Total bytes written: 524441
Total bytes read: 40

wrote 524441 bytes read 40 bytes 36171.10 bytes/sec
total size is 524288 speedup is 1.00

sans aucun pb


là j'ai le meme pb de transfert de données que l'ordi seul, maintenant
que je suis à coté de lui

les freebox : chez moi en dégroupé, les 2 autres en non dégroupé


à coté de l'ordi seul, et pareil derriere une autre freebox non
dégroupée :

ca s'arrete sur :

% rsync -v --partial --progress --stats ~/gc521xcomplete.zip
:~/
gc521xcomplete.zip
32768 6% 0.00kB/s 0:00:00

et ca se termine par :

% rsync -v --partial --progress --stats ~/gc521xcomplete.zip
:~/
gc521xcomplete.zip
Read from remote host 192.168.1.2: Operation timed out
rsync: writefd_unbuffered failed to write 32768 bytes: phase "unknown":
Broken pipe
rsync error: error in rsync protocol data stream (code 12) at
/SourceCache/rsync/rsync-14/rsync/io.c(836)


donc c'est clair que le soucis est du au moins en partie aux freebox non
dégroupées, pas uniquement à PPTP
(cela dit je reste perplexe en voyant qu'entre moi et l'ordi seul ca
passe, je vais faire les essais avec le mtu des que je pourrais)

je sais qu'à certains moments il y a eu des pb de saturation du reseau
de collecte FT, j'en ai meme fait les frais chez moi (pour me connecter
aux autres freebox),
mais là c'est pas le cas, c'est une coupure franche au bout d'une
certaine quantité de données

je confirme que le blocage est relatif à chaque connexions tcp :
pendant que rsync est entrain d'essayer d'envoyer des données, dans une
autre fenetre de terminal je fais un ssh sur le meme ordi distant et des
petites choses comme ls

personne d'autre l'a le meme genre de config ?
ca serait interessant si on pouvait faire l'essai avec un client
derriere une freebox non dégroupée et un serveur derriere une freebox
dégroupée :-)

--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf

Thomas
Le #862182
salut :-)


désolé pour le retard,pendant qq jours je manquais de motivation pour me
replonger là dedans à fond

et de toutes facons, l'alim de la freebox coté "ordi seul" etait en
panne, et on en attendait une autre
là on ne l'a pas encore, mais elle est entrain d'etre livrée :-)




In article (Dans l'article) "Antoine ROUCHET"
"Thomas" news:
In article (Dans l'article) "Antoine ROUCHET"
"Thomas" news:

j'ai 3 freebox :
- moi
- un ordi seul
- un reseau local derriere un lanbooster (avec un serveur PPTP)

l'ordi seul et moi avons un client PPTP connecté au lanbooster, pour
que
tout le monde puisse se parler
le lanbooster oblige toutes les connexions des clients à passer par lui


je peux piloter les ordis du reseau local avec vnc sans pb
je peux piloter l'ordi seul avec vnc sans pb
l'ordi seul peut piloter les ordis du reseau local avec vnc sans pb

les ordis du reseau local *ne peuvent pas* piloter l'ordi seul avec vnc
sans pb, *si* on se connecte *sur l'ip PPTP* de l'ordi seul
les ordis du reseau local *peuvent* piloter l'ordi seul avec vnc sans
pb, *si* on se connecte *sur l'ip directe* (freebox) de l'ordi seul

j'ai remarqué qu'il n'y a pas de pb quand il y a tres peu de données à
faire passer,
mais que ca coince des qu'il y a de grandes quantités de données à
faire
passer, qq soit le protocole
c'est comme si, au bout d'une certaine quantité de données, pouf, ca
s'arrete (sauf que c'est pas tres regulier)
je crois que c'est pour chaque connexion tcp



ca ne t'es jamais arrivé, à toi ?
t'utilises que openvpn ?
(parce que ca serait "mieux" que ca te sois deja arrivé, pour que tu
puisses savoir exactement comment resoudre le pb :-) )



Avant OpenVPN, j'utilisais le serveur VPN de Windows 2000 Server ou celui de
2003 (les mêmes quoi). Et oui j'ai déjà rencontré ce genre de symptomes, je
ne m'amuse pas à répondre au hasard sur les NG pour passer le temps :-)) .
J'en suis arrivé assez vite à la conclusion suivante: avoir un MTU inférieur
au MTU "standard" (1500) sur une partie du réseau (genre sur une patte d'un
routeur), c'est galère, voilà par exemple pourquoi:

Une ordi du réseau local veut parler à l'ordi seul. Il passe donc
(logiquement) par le tunnel VPN
- Le MTU de l'ordi du réseau local sera de 1500 (logique, c'est un réseau
Ethernet classique).
- Le MTU de la connexion P2P entre l'ordi seul et le lanbooster sera
inférieur (1386 probablement) à cause de PPTP.

Conclusion: soit les paquets > à 1386 octets sont simplement perdus parce
que le routeur ne gère pas la fragmentation (déjà vu une fois), soit la
connexion est super lente parce que le routeur (qui n'est généralement pas
un foudre de guerre en plus) doit découper les paquets trop gros en paquets
plus petits.

La seule solution à ma connaissance pour éviter ça est de forcer sur les
machines du réseau local le MTU à 1386, soit celui de la connexion PPTP.
Mais là bien sûr, on perd en perf sur le réseau local


merci :-)


il me vient au moins 2 questions :

- si c'est un pb de mtu parce que le routeur ne sait pas gerer la
fragmentation (si c'est lent c'est pas grave),
si on change le mtu des ordis du réseau local, comment ca va se passer,
apres, pour qu'elles communiquent avec l'exterieur (où tous les ordis
ont probablement un mtu à 1500 pour la compatibilité, d'apres ce que tu
dis) ???

- d'apres ce que tu dis, le pb est fort probablement localisé sur le
routeur, et je te crois,
juste, je vois pas dans ce cas, comment ca peut en plus dependre de la
freebox qui est du coté de l'ordi seul ... (puisque d'apres ce que tu
dis, ca ne devrait marcher avec aucune connexion PPTP !)

je vais poster sur pfa pour leur indiquer notre discussion, en esperant
que qqn veuille bien repondre et sache nous expliquer :-)


(il faut pouvoir le faire sur le routeur, en plus).


j'ai vu un reglage pour le faire (meme si on a vu plus pratique ;-) ),
je vais essayer des que possible :-)



si j'ai bien compris,
quand un ordi du reseau local fait une connexion tcp sur l'ip directe
de
l'ordi seul,
- toutes les données qui vont de l'ordi seul à l'ordi du reseau local
passent à l'interieur du tunnel PPTP, et
- toutes les données qui vont de l'ordi du reseau local à l'ordi seul
passent à l'exterieur du tunnel PPTP
meme les paquets tcp ack
c'est bien ca ?



est ce que j'ai bien compris, là ?


Ca dépend des tables de routages de l'ordi du réseau local concerné, du
lanbooster et de l'ordi seul.


sur mon ordi, si je veux pas que toutes mes connexions à internet
passent par le routeur, je dois faire

route delete default 192.168.1.1
route add default 192.168.0.254
route add -net 192.168.1 192.168.1.1

à chaque fois que j'etablis une connexion PPTP
(je ne le fait pas encore sur l'ordi seul, parce que c'est tres delicat
à automatiser)

je sais plus la commande pour juste avoir l'etat des routes,
est ce que ca te suffis pour les deduire ?


quand j'y pense, finalement c'est bizarre que ca marche, sachant qu'on a
une freebox en mode routeur (histoire d'avoir un mur de plus) juste
devant le lanbooster qui fait serveur PPTP

parce que
- une connexion qui est faite d'un ordi du reseau local sur l'ip
publique de l'ordi seul (freebox en mode routeur aussi)
- contacte la freebox de l'ordi seul, en indiquant comme provenance l'ip
publique du reseau local
- elle fait du nat, ce qui permet d'atteindre l'ordi seul
- l'ordi seul repond à destination de l'ip publique du reseau local
- le paquet ip de cette reponse passe par la connexion PPTP (puisque
c'est le passage obligé de toutes les connexions à destination
d'internet en general)
- les freebox ne peuvent pas toucher à ce paquet ip, puisqu'elles ne le
voient pas passer, puisqu'il est enfermé dans le tunnel PPTP
- il sort du tunnel sur le routeur, mais il n'a pas connaissance de l'ip
publique, puisqu'il est derriere la freebox, donc il ne peut pas faire
le nat sur le paquet ip lui meme (ce que je croyais la 1ere fois que
j'ai pensé à tout ca),
donc il envoie ce paquet ip à la freebox, qui ne sait pas faire de nat
de l'interieur, et là ca coince ...
et en plus la provenance est l'ip privée de l'ordi seul, alors que
l'ordi du reseau local attend une reponse de l'ip publique de l'ordi
seul !

donc finalement je ne vois pas comment ca peut marcher ...

si la reponse etait que dans ce genre de circonstances, les reponses ne
sont pas obligées à passer par le tunnel PPTP,
alors pourquoi on ne peut contacter l'ordi seul sur son ip publique que
quand on est sur le reseau local derriere le lanbooster, jamais quand on
est à l'exterieur ??


donc si ce qui pose pb c'est les gros flux de données de l'ordi seul à
un ordi du reseau local, c'est que les paquets tcp ack n'arrivent pas à
remonter à l'interieur du tunnel PPTP, mais qu'ils arrivent à remonter
si ils passent à l'exterieur
sauf que ca passe sans pb entre moi et l'ordi seul (n'etant pas
derriere
le serveur PPTP, je ne peux pas utiliser son ip directe, je suis obligé
d'utiliser son ip PPTP)

donc moi et un ordi du reseau local, on n'enverrais pas les paquets tcp
ack de la meme maniere, de sorte que
des paquets tcp ack qui doivent aller du reseau local à l'ordi seul, si
ils viennent d'un ordi du reseau local ca passe pas, et si ils viennent
de moi ca passe
??


voilà où j'en suis de mes tests ... :-)
qqn a une idée ?





donc finalement, c'est peut etre pas grand chose de tout ca ....

j'aimerais bien comprendre ce qu'il se passe,
en plus ca pourrais aider free à corriger ses freebox nd ...



ca peut etre un pb de mtu ?
un element du reseau qui en aurait marre trop vite de devoir casser en
2
des paquets tcp ack pour les faire rentrer dans le tunnel ?
mais en meme temps des paquets tcp normaux passent sans pb ...



En effet, l'encapsulation PPTP réduit le MTU de la connexion virtuelle.
Le
MTU "standard" d'un lien IP sur Ethernet ou IPoA (l'encapsulation ATM
utilisée par Free) est de 1500. Si on fait passer IP dans un tunnel PPTP
(un
tunnel GRE en pratique), le MTU descend en général à 1396.

La commande "ping -l x -f a.b.c.d" (x = taille du paquet et a.b.c.d > >> adresse IP) vous permet de déterminer le MTU actuel d'un lien. Essayez là
vers le routeur d'abord pour déterminer le MTU du "support" (qui doit
être
de 1500 si tout va bien donc), puis essayer là vers une machine placée
derrière le VPN afin de déterminer le MTU restant après encapsulation GRE
(qui doit être de 1396 si j'ai bonne mémoire, sachant que ça peut
sûrement
varier d'une implémentation à l'autre de PPTP).


donc si le ping passe on est en dessous ou au maximum, et si il ne passe
pas, on est au dessus ?
bon, faut que je configure mes machines pour accepter le ping
en attendant, est ce que ifconfig ca peut indiquer la valeur ou c'est
pas fiable ?



En effet, si le ping passe, on est en dessous ou au maximum du MTU, sinon on
est au dessus.


merci :-)
pareil, j'essaye des que possible



et c'est sur les ordis du reseau local qu'il faut reduire le mtu pour
qu'il ne soit pas plus grand que celui du tunnel PPTP ?
plus petit c'est pas genant ?
pas besoin de le changer sur l'ordi seul ?


En effet c'est sur les ordis du réseau local *ET* sur la ou les interface(s)
ethernet du lanbooster sur lesquelles sont connectés les ordis du réseau
local. Sur l'ordi seul il n'y a pas besoin non puisque le MTU est imposé par
le tunnel PPTP.


merci :-)


Tu peux mettre un MTU plus petit, mais alors il faudra également changer
celui du tunnel PPTP, ce qui devient compliqué.


ah ok, oui sinon on aura le meme pb en sens inverse :-)

--
j'agis contre l'assistanat, je travaille dans une SCOP !




Thomas
Le #862181
In article (Dans l'article) "Antoine ROUCHET"
"Thomas" news:

je poste juste pour donner ce que j'ai sur mon ordi, là je me suis
deplacé juste à coté de "l'ordi seul", derriere la meme freebox

% ifconfig
en0: flagsˆ63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500


Peut-être un indice intéressant: en dégroupé les freebox utilise IPoA qui
donne le même MTU qu'un liens Ethernet classique (1500). En non-dégroupé, le
protocole est celui de FT (PPPoE je crois) et le MTU est probablement
inférieur (à vérifier tout ça).


ben, sur la ligne "en0" de ifconfig, c'est indiqué clairement "mtu 1500",
c'est bien le mtu permis par la freebox, non ?

en plus, derriere une freebox dégroupée ou non dégroupée,
ifconfig donne exactement la meme chose sur presque toutes les lignes
(tres tres peu de differences)

(donc ca conforte ce que disent les autres :-) )

--
j'agis contre l'assistanat, je travaille dans une SCOP !


Publicité
Poster une réponse
Anonyme