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 :-)
(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 :-)
(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 ...
"Thomas" wrote in message
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
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 ...
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.
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é,
"Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message
news:fantome.forums.tDeContes-8BBDE1.04470819072007@news-2.proxad.net...
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 ...
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.
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é,
"Thomas" wrote in message
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
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 ...
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.
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é,
In article (Dans l'article) <469f249c$0$11788$,
"Antoine ROUCHET" wrote (écrivait) :"Thomas" wrote in message
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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00
sur l'ordi seul :
% ifconfig
lo0: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<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: flags51<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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:11:24:22:7d:41
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flags22<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 :-)
In article (Dans l'article) <469f249c$0$11788$426a74cc@news.free.fr>,
"Antoine ROUCHET" <news.4872@gabuzomeu.org> wrote (écrivait) :
"Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message
news:fantome.forums.tDeContes-8BBDE1.04470819072007@news-2.proxad.net...
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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00
sur l'ordi seul :
% ifconfig
lo0: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<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: flags51<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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:11:24:22:7d:41
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flags22<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 :-)
In article (Dans l'article) <469f249c$0$11788$,
"Antoine ROUCHET" wrote (écrivait) :"Thomas" wrote in message
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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00
sur l'ordi seul :
% ifconfig
lo0: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<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: flags51<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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:11:24:22:7d:41
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flags22<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 :-)
chez moi :
% ifconfig
lo0: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00
sur l'ordi seul :
% ifconfig
lo0: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<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: flags51<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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:11:24:22:7d:41
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flags22<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>
chez moi :
% ifconfig
lo0: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00
sur l'ordi seul :
% ifconfig
lo0: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<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: flags51<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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:11:24:22:7d:41
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flags22<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>
chez moi :
% ifconfig
lo0: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00
sur l'ordi seul :
% ifconfig
lo0: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<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: flags51<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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags22<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:11:24:22:7d:41
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flags22<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>
In article (Dans l'article)
,
Thomas wrote (écrivait) :
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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags51<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é
In article (Dans l'article)
<fantome.forums.tDeContes-323FA1.14454019072007@news-1.proxad.net>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote (écrivait) :
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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags51<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é
In article (Dans l'article)
,
Thomas wrote (écrivait) :
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: flags49<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: flags10<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags63<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: flags51<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).
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).
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).
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).
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).
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).
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é
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é
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é
"Thomas" wrote in message
news:In article (Dans l'article) <469f249c$0$11788$,
"Antoine ROUCHET" wrote (écrivait) :"Thomas" wrote in message
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
(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.
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é.
"Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message
news:fantome.forums.tDeContes-323FA1.14454019072007@news-1.proxad.net...
In article (Dans l'article) <469f249c$0$11788$426a74cc@news.free.fr>,
"Antoine ROUCHET" <news.4872@gabuzomeu.org> wrote (écrivait) :
"Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message
news:fantome.forums.tDeContes-8BBDE1.04470819072007@news-2.proxad.net...
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
(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.
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é.
"Thomas" wrote in message
news:In article (Dans l'article) <469f249c$0$11788$,
"Antoine ROUCHET" wrote (écrivait) :"Thomas" wrote in message
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
(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.
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é.
"Thomas" wrote in message
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: flags63<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).
"Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message
news:fantome.forums.tDeContes-692298.15275520072007@news-3.proxad.net...
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: flags63<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).
"Thomas" wrote in message
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: flags63<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).