J'arrive à créer un VPN/UDP entre eth1 (ADSL) de A et tap0 de B. Un
second VPN/UDP existe entre eth2 (VDSL2) de A et tap1 de B.
De A vers B, le premier VPN plafonne à 1 Mbps. Le second, sur
VDSL2, à 3 Mbps
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
J'arrive à créer un VPN/UDP entre eth1 (ADSL) de A et tap0 de B. Un
second VPN/UDP existe entre eth2 (VDSL2) de A et tap1 de B.
De A vers B, le premier VPN plafonne à 1 Mbps. Le second, sur
VDSL2, à 3 Mbps
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
J'arrive à créer un VPN/UDP entre eth1 (ADSL) de A et tap0 de B. Un
second VPN/UDP existe entre eth2 (VDSL2) de A et tap1 de B.
De A vers B, le premier VPN plafonne à 1 Mbps. Le second, sur
VDSL2, à 3 Mbps
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Le 27/03/2017 à 22:44, JKB a écrit :J'arrive à créer un VPN/UDP entre eth1 (ADSL) de A et tap0 de B. Un
second VPN/UDP existe entre eth2 (VDSL2) de A et tap1 de B.
De A vers B, le premier VPN plafonne à 1 Mbps. Le second, sur
VDSL2, à 3 Mbps
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Extrait de la documentation :
balance-tlb or 5
Adaptive transmit load balancing: channel bonding that
does not require any special switch support. The
outgoing traffic is distributed according to the
current load (computed relative to the speed) on each
slave. (...)
Prerequisite:
Ethtool support in the base drivers for retrieving the
speed of each slave.
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
Pour rappel, les algorithmes de répartition basés sur la vitesse du lien
ne marchent que si c'est la véritable vitesse du lien xDSL, et pas la
vitesse de la liaison ethernet entre la machine et le modem xDSL par
exemple. Même chose pour les algorithmes basés sur le remplissage du
tampon d'émission : se baser sur le tampon d'émission de l'interface
ethernet ne sert à rien puisque c'est celui du modem qui se remplit le
plus vite.
Le 27/03/2017 à 22:44, JKB a écrit :
J'arrive à créer un VPN/UDP entre eth1 (ADSL) de A et tap0 de B. Un
second VPN/UDP existe entre eth2 (VDSL2) de A et tap1 de B.
De A vers B, le premier VPN plafonne à 1 Mbps. Le second, sur
VDSL2, à 3 Mbps
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Extrait de la documentation :
balance-tlb or 5
Adaptive transmit load balancing: channel bonding that
does not require any special switch support. The
outgoing traffic is distributed according to the
current load (computed relative to the speed) on each
slave. (...)
Prerequisite:
Ethtool support in the base drivers for retrieving the
speed of each slave.
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
Pour rappel, les algorithmes de répartition basés sur la vitesse du lien
ne marchent que si c'est la véritable vitesse du lien xDSL, et pas la
vitesse de la liaison ethernet entre la machine et le modem xDSL par
exemple. Même chose pour les algorithmes basés sur le remplissage du
tampon d'émission : se baser sur le tampon d'émission de l'interface
ethernet ne sert à rien puisque c'est celui du modem qui se remplit le
plus vite.
Le 27/03/2017 à 22:44, JKB a écrit :J'arrive à créer un VPN/UDP entre eth1 (ADSL) de A et tap0 de B. Un
second VPN/UDP existe entre eth2 (VDSL2) de A et tap1 de B.
De A vers B, le premier VPN plafonne à 1 Mbps. Le second, sur
VDSL2, à 3 Mbps
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Extrait de la documentation :
balance-tlb or 5
Adaptive transmit load balancing: channel bonding that
does not require any special switch support. The
outgoing traffic is distributed according to the
current load (computed relative to the speed) on each
slave. (...)
Prerequisite:
Ethtool support in the base drivers for retrieving the
speed of each slave.
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
Pour rappel, les algorithmes de répartition basés sur la vitesse du lien
ne marchent que si c'est la véritable vitesse du lien xDSL, et pas la
vitesse de la liaison ethernet entre la machine et le modem xDSL par
exemple. Même chose pour les algorithmes basés sur le remplissage du
tampon d'émission : se baser sur le tampon d'émission de l'interface
ethernet ne sert à rien puisque c'est celui du modem qui se remplit le
plus vite.
Pascal Hambourg écrivait :Le 27/03/2017 à 22:44, JKB a écrit :Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Si c'est de l'UDP qui passe sur le lien, je partais du principe que
le problème de l'ordonnancement des sessions TCP était géré par le
VPN un peu mieux que par les mécanismes TCP classiques.
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
Oui, ça, je sais. Donc pour mon problème, aucune solution ?
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Le 27/03/2017 à 22:44, JKB a écrit :
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Si c'est de l'UDP qui passe sur le lien, je partais du principe que
le problème de l'ordonnancement des sessions TCP était géré par le
VPN un peu mieux que par les mécanismes TCP classiques.
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
Oui, ça, je sais. Donc pour mon problème, aucune solution ?
Pascal Hambourg écrivait :Le 27/03/2017 à 22:44, JKB a écrit :Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Si c'est de l'UDP qui passe sur le lien, je partais du principe que
le problème de l'ordonnancement des sessions TCP était géré par le
VPN un peu mieux que par les mécanismes TCP classiques.
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
Oui, ça, je sais. Donc pour mon problème, aucune solution ?
Le 28/03/2017 à 08:47, JKB a écrit :Pascal Hambourg écrivait :Le 27/03/2017 à 22:44, JKB a écrit :Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Si c'est de l'UDP qui passe sur le lien, je partais du principe que
le problème de l'ordonnancement des sessions TCP était géré par le
VPN un peu mieux que par les mécanismes TCP classiques.
Je ne suis pas sûr de comprendre de quoi tu parles. UDP ne gère pas
l'ordonnancement des paquets. Tu veux parler d'éviter le transport de
TCP dans TCP et les problèmes qui vont avec (latence, retransmission
excessive) ?
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
(...)Oui, ça, je sais. Donc pour mon problème, aucune solution ?
A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
- le driver égaliseur eql et son programme de configuration eql_enslave
qui permet de spécifier le débit de chaque lien, cf.
<https://en.wikibooks.org/wiki/Linux_Networking/EQL_-_multiple_line_traffic_equaliser>
- le routage multipath d'ip route avec l'option weight qui permet de
pondérer l'égalisation ; cela ne s'appliquait pas à un flux unique à
cause du cache de routage, mais la suppression de ce dernier dans les
noyaux récents a peut-être modifié le comportement
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf. <http://lartc.org/howto/lartc.loadshare.html>
Le 28/03/2017 à 08:47, JKB a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Le 27/03/2017 à 22:44, JKB a écrit :
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Si c'est de l'UDP qui passe sur le lien, je partais du principe que
le problème de l'ordonnancement des sessions TCP était géré par le
VPN un peu mieux que par les mécanismes TCP classiques.
Je ne suis pas sûr de comprendre de quoi tu parles. UDP ne gère pas
l'ordonnancement des paquets. Tu veux parler d'éviter le transport de
TCP dans TCP et les problèmes qui vont avec (latence, retransmission
excessive) ?
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
(...)
Oui, ça, je sais. Donc pour mon problème, aucune solution ?
A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
- le driver égaliseur eql et son programme de configuration eql_enslave
qui permet de spécifier le débit de chaque lien, cf.
<https://en.wikibooks.org/wiki/Linux_Networking/EQL_-_multiple_line_traffic_equaliser>
- le routage multipath d'ip route avec l'option weight qui permet de
pondérer l'égalisation ; cela ne s'appliquait pas à un flux unique à
cause du cache de routage, mais la suppression de ce dernier dans les
noyaux récents a peut-être modifié le comportement
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf. <http://lartc.org/howto/lartc.loadshare.html>
Le 28/03/2017 à 08:47, JKB a écrit :Pascal Hambourg écrivait :Le 27/03/2017 à 22:44, JKB a écrit :Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).
En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Si c'est de l'UDP qui passe sur le lien, je partais du principe que
le problème de l'ordonnancement des sessions TCP était géré par le
VPN un peu mieux que par les mécanismes TCP classiques.
Je ne suis pas sûr de comprendre de quoi tu parles. UDP ne gère pas
l'ordonnancement des paquets. Tu veux parler d'éviter le transport de
TCP dans TCP et les problèmes qui vont avec (latence, retransmission
excessive) ?
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
(...)Oui, ça, je sais. Donc pour mon problème, aucune solution ?
A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
- le driver égaliseur eql et son programme de configuration eql_enslave
qui permet de spécifier le débit de chaque lien, cf.
<https://en.wikibooks.org/wiki/Linux_Networking/EQL_-_multiple_line_traffic_equaliser>
- le routage multipath d'ip route avec l'option weight qui permet de
pondérer l'égalisation ; cela ne s'appliquait pas à un flux unique à
cause du cache de routage, mais la suppression de ce dernier dans les
noyaux récents a peut-être modifié le comportement
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf. <http://lartc.org/howto/lartc.loadshare.html>
Pascal Hambourg écrivait :Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
(...)Oui, ça, je sais. Donc pour mon problème, aucune solution ?
A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
Le VPN est OpenVPN.
Je suis contraint d'utiliser OpenVPN et j'ai déjà dû raler pour
obtenir l'ouverture du port 1194/UDP vers cett machine. Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf. <http://lartc.org/howto/lartc.loadshare.html>
Je considère que tc est une immense saleté. J'ai réussi à configurer
des règles de trafic à une certaine époque avec plusieurs litres de
café noir et quelques Actrons, mais je serais bien incapable de les
reprendre. Le fonctionnement est, disons, ésotérique pour rester
poli.
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
(...)
Oui, ça, je sais. Donc pour mon problème, aucune solution ?
A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
Le VPN est OpenVPN.
Je suis contraint d'utiliser OpenVPN et j'ai déjà dû raler pour
obtenir l'ouverture du port 1194/UDP vers cett machine. Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf. <http://lartc.org/howto/lartc.loadshare.html>
Je considère que tc est une immense saleté. J'ai réussi à configurer
des règles de trafic à une certaine époque avec plusieurs litres de
café noir et quelques Actrons, mais je serais bien incapable de les
reprendre. Le fonctionnement est, disons, ésotérique pour rester
poli.
Pascal Hambourg écrivait :Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
(...)Oui, ça, je sais. Donc pour mon problème, aucune solution ?
A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
Le VPN est OpenVPN.
Je suis contraint d'utiliser OpenVPN et j'ai déjà dû raler pour
obtenir l'ouverture du port 1194/UDP vers cett machine. Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf. <http://lartc.org/howto/lartc.loadshare.html>
Je considère que tc est une immense saleté. J'ai réussi à configurer
des règles de trafic à une certaine époque avec plusieurs litres de
café noir et quelques Actrons, mais je serais bien incapable de les
reprendre. Le fonctionnement est, disons, ésotérique pour rester
poli.
Le 29/03/2017 à 09:09, JKB a écrit :Pascal Hambourg écrivait :Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
(...)Oui, ça, je sais. Donc pour mon problème, aucune solution ?
A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
Le VPN est OpenVPN.
Je connais OpenVPN d'assez loin, mais comme il est basé sur le pilote
TUN/TAP du noyau, je suppose que ça dépend du support d'ethtool par ce
dernier. D'après son code source dans le noyau Linux
(drivers/net/tun.c), le pilote TUN/TAP supporte ethtool mais la gestion
de la vitesse du lien semble se limiter à annoncer 10 Mbit/s.
Je suis contraint d'utiliser OpenVPN et j'ai déjà dû raler pour
obtenir l'ouverture du port 1194/UDP vers cett machine. Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf. <http://lartc.org/howto/lartc.loadshare.html>
Je considère que tc est une immense saleté. J'ai réussi à configurer
des règles de trafic à une certaine époque avec plusieurs litres de
café noir et quelques Actrons, mais je serais bien incapable de les
reprendre. Le fonctionnement est, disons, ésotérique pour rester
poli.
Ah, merci de confirmer que ce n'est pas juste moi qui suis bouché.
Le 29/03/2017 à 09:09, JKB a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
(...)
Oui, ça, je sais. Donc pour mon problème, aucune solution ?
A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
Le VPN est OpenVPN.
Je connais OpenVPN d'assez loin, mais comme il est basé sur le pilote
TUN/TAP du noyau, je suppose que ça dépend du support d'ethtool par ce
dernier. D'après son code source dans le noyau Linux
(drivers/net/tun.c), le pilote TUN/TAP supporte ethtool mais la gestion
de la vitesse du lien semble se limiter à annoncer 10 Mbit/s.
Je suis contraint d'utiliser OpenVPN et j'ai déjà dû raler pour
obtenir l'ouverture du port 1194/UDP vers cett machine. Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf. <http://lartc.org/howto/lartc.loadshare.html>
Je considère que tc est une immense saleté. J'ai réussi à configurer
des règles de trafic à une certaine époque avec plusieurs litres de
café noir et quelques Actrons, mais je serais bien incapable de les
reprendre. Le fonctionnement est, disons, ésotérique pour rester
poli.
Ah, merci de confirmer que ce n'est pas juste moi qui suis bouché.
Le 29/03/2017 à 09:09, JKB a écrit :Pascal Hambourg écrivait :Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
(...)Oui, ça, je sais. Donc pour mon problème, aucune solution ?
A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
Le VPN est OpenVPN.
Je connais OpenVPN d'assez loin, mais comme il est basé sur le pilote
TUN/TAP du noyau, je suppose que ça dépend du support d'ethtool par ce
dernier. D'après son code source dans le noyau Linux
(drivers/net/tun.c), le pilote TUN/TAP supporte ethtool mais la gestion
de la vitesse du lien semble se limiter à annoncer 10 Mbit/s.
Je suis contraint d'utiliser OpenVPN et j'ai déjà dû raler pour
obtenir l'ouverture du port 1194/UDP vers cett machine. Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf. <http://lartc.org/howto/lartc.loadshare.html>
Je considère que tc est une immense saleté. J'ai réussi à configurer
des règles de trafic à une certaine époque avec plusieurs litres de
café noir et quelques Actrons, mais je serais bien incapable de les
reprendre. Le fonctionnement est, disons, ésotérique pour rester
poli.
Ah, merci de confirmer que ce n'est pas juste moi qui suis bouché.
Pascal Hambourg écrivait :Le 29/03/2017 à 09:09, JKB a écrit :Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
Ne fonctionne pas. Et le problème du DNS n'en est pas un car le
modem fait relais DNS.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
Là, je ne te suis plus. Ça doit être l'heure tardive.
Les deux chemins possibles entre les deux machines sont deux VPN
utilisant tap0 et tap1 des deux côtés. Comment penses-tu grouper
cela avec EQL ?
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Le 29/03/2017 à 09:09, JKB a écrit :
Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
Ne fonctionne pas. Et le problème du DNS n'en est pas un car le
modem fait relais DNS.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
Là, je ne te suis plus. Ça doit être l'heure tardive.
Les deux chemins possibles entre les deux machines sont deux VPN
utilisant tap0 et tap1 des deux côtés. Comment penses-tu grouper
cela avec EQL ?
Pascal Hambourg écrivait :Le 29/03/2017 à 09:09, JKB a écrit :Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
Ne fonctionne pas. Et le problème du DNS n'en est pas un car le
modem fait relais DNS.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
Là, je ne te suis plus. Ça doit être l'heure tardive.
Les deux chemins possibles entre les deux machines sont deux VPN
utilisant tap0 et tap1 des deux côtés. Comment penses-tu grouper
cela avec EQL ?
Le 29/03/2017 à 23:49, JKB a écrit :Pascal Hambourg écrivait :Le 29/03/2017 à 09:09, JKB a écrit :Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
Ne fonctionne pas. Et le problème du DNS n'en est pas un car le
modem fait relais DNS.
Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
Là, je ne te suis plus. Ça doit être l'heure tardive.
L'interface eql n'est pas bidirectionnelle comme une interface de pont,
VLAN ou tunnel. Elle ne sert que pour l'émission. Elle ne reçoit rien,
les paquets entrants sont reçus directement sur les interfaces des liens
(côté Linux, attention à rp_filter si tu l'utilises).
Les deux chemins possibles entre les deux machines sont deux VPN
utilisant tap0 et tap1 des deux côtés. Comment penses-tu grouper
cela avec EQL ?
Côté Linux, en asservissant les deux interfaces tap à l'interface eql
avec eql_enslave. Côté BSD, n'y connaissant rien du tout, j'ignore s'il
existe un mécanisme équivalent.
Le 29/03/2017 à 23:49, JKB a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Le 29/03/2017 à 09:09, JKB a écrit :
Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
Ne fonctionne pas. Et le problème du DNS n'en est pas un car le
modem fait relais DNS.
Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
Là, je ne te suis plus. Ça doit être l'heure tardive.
L'interface eql n'est pas bidirectionnelle comme une interface de pont,
VLAN ou tunnel. Elle ne sert que pour l'émission. Elle ne reçoit rien,
les paquets entrants sont reçus directement sur les interfaces des liens
(côté Linux, attention à rp_filter si tu l'utilises).
Les deux chemins possibles entre les deux machines sont deux VPN
utilisant tap0 et tap1 des deux côtés. Comment penses-tu grouper
cela avec EQL ?
Côté Linux, en asservissant les deux interfaces tap à l'interface eql
avec eql_enslave. Côté BSD, n'y connaissant rien du tout, j'ignore s'il
existe un mécanisme équivalent.
Le 29/03/2017 à 23:49, JKB a écrit :Pascal Hambourg écrivait :Le 29/03/2017 à 09:09, JKB a écrit :Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
Ne fonctionne pas. Et le problème du DNS n'en est pas un car le
modem fait relais DNS.
Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
Là, je ne te suis plus. Ça doit être l'heure tardive.
L'interface eql n'est pas bidirectionnelle comme une interface de pont,
VLAN ou tunnel. Elle ne sert que pour l'émission. Elle ne reçoit rien,
les paquets entrants sont reçus directement sur les interfaces des liens
(côté Linux, attention à rp_filter si tu l'utilises).
Les deux chemins possibles entre les deux machines sont deux VPN
utilisant tap0 et tap1 des deux côtés. Comment penses-tu grouper
cela avec EQL ?
Côté Linux, en asservissant les deux interfaces tap à l'interface eql
avec eql_enslave. Côté BSD, n'y connaissant rien du tout, j'ignore s'il
existe un mécanisme équivalent.
Pascal Hambourg écrivait :Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
C'est tout à fait cela.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
As-tu un pointeur sur un howto, une documentation adaptée ? J'ai du
mal à voir comment le multipath pourrait être configuré.
Typiquement, chez moi :
Linux :
- eth0 : LAN (192.168.0.128)
- eth1 + eth1:[1-6] : WAN1 ADSL (192.168.254.1)
- eth2 : WAN2 VDSL2 (192.168.253.1)
- tap0 (VPN/TCP) : 192.168.100.1
- tap1 (VPN/UDP) : 192.168.1.1
- tap2 (VPN/UDP) : 192.168.101.1
NetBSD :
- wm0 : WAN Wimax (youpi) sur 192.168.15.14
- agr0 (wm1 + wm2) en 802.3.ad sur 192.168.10.128
- tap0 (192.168.100.2)
- tap1 (192.168.101.2)
En fait, je ne vois pas trop comment faire un truc intelligent de
tout ça.
Donc je crée deux tunnels tap0 et tap1 côté Linux. Je crée là-dessus
une interface EQL et je lui assigne une adresse. Très bien pour
l'émission. Mais je ne vois toujours pas par quel mécanisme se fait
le retour.
En admettant que j'assigne à eql0 10.100.170.1, il me
faut bien une adresse IP côté NetBSD qui soit sur le même sous
réseau, non ?
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
C'est tout à fait cela.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
As-tu un pointeur sur un howto, une documentation adaptée ? J'ai du
mal à voir comment le multipath pourrait être configuré.
Typiquement, chez moi :
Linux :
- eth0 : LAN (192.168.0.128)
- eth1 + eth1:[1-6] : WAN1 ADSL (192.168.254.1)
- eth2 : WAN2 VDSL2 (192.168.253.1)
- tap0 (VPN/TCP) : 192.168.100.1
- tap1 (VPN/UDP) : 192.168.1.1
- tap2 (VPN/UDP) : 192.168.101.1
NetBSD :
- wm0 : WAN Wimax (youpi) sur 192.168.15.14
- agr0 (wm1 + wm2) en 802.3.ad sur 192.168.10.128
- tap0 (192.168.100.2)
- tap1 (192.168.101.2)
En fait, je ne vois pas trop comment faire un truc intelligent de
tout ça.
Donc je crée deux tunnels tap0 et tap1 côté Linux. Je crée là-dessus
une interface EQL et je lui assigne une adresse. Très bien pour
l'émission. Mais je ne vois toujours pas par quel mécanisme se fait
le retour.
En admettant que j'assigne à eql0 10.100.170.1, il me
faut bien une adresse IP côté NetBSD qui soit sur le même sous
réseau, non ?
Pascal Hambourg écrivait :Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
C'est tout à fait cela.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
As-tu un pointeur sur un howto, une documentation adaptée ? J'ai du
mal à voir comment le multipath pourrait être configuré.
Typiquement, chez moi :
Linux :
- eth0 : LAN (192.168.0.128)
- eth1 + eth1:[1-6] : WAN1 ADSL (192.168.254.1)
- eth2 : WAN2 VDSL2 (192.168.253.1)
- tap0 (VPN/TCP) : 192.168.100.1
- tap1 (VPN/UDP) : 192.168.1.1
- tap2 (VPN/UDP) : 192.168.101.1
NetBSD :
- wm0 : WAN Wimax (youpi) sur 192.168.15.14
- agr0 (wm1 + wm2) en 802.3.ad sur 192.168.10.128
- tap0 (192.168.100.2)
- tap1 (192.168.101.2)
En fait, je ne vois pas trop comment faire un truc intelligent de
tout ça.
Donc je crée deux tunnels tap0 et tap1 côté Linux. Je crée là-dessus
une interface EQL et je lui assigne une adresse. Très bien pour
l'émission. Mais je ne vois toujours pas par quel mécanisme se fait
le retour.
En admettant que j'assigne à eql0 10.100.170.1, il me
faut bien une adresse IP côté NetBSD qui soit sur le même sous
réseau, non ?
Le 30/03/2017 à 23:26, JKB a écrit :Pascal Hambourg écrivait :Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
C'est tout à fait cela.
Donc j'imagine que les autres protocoles basés sur UDP comme NTP ou SIP
ne passent pas non plus ?
Si c'est vendu comme de l'accès internet et pas un simple minitel de
luxe, il y a tromperie sur la marchandise.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
As-tu un pointeur sur un howto, une documentation adaptée ? J'ai du
mal à voir comment le multipath pourrait être configuré.
Il y a un paragraphe consacré au routage multipath dans le LARTC howto.
<http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN297>
Typiquement, chez moi :
Linux :
- eth0 : LAN (192.168.0.128)
- eth1 + eth1:[1-6] : WAN1 ADSL (192.168.254.1)
- eth2 : WAN2 VDSL2 (192.168.253.1)
- tap0 (VPN/TCP) : 192.168.100.1
Pourquoi sur TCP plutôt qu'UDP ?
- tap1 (VPN/UDP) : 192.168.1.1
Où est l'autre bout de ce VPN ? Je ne le vois pas sur NetBSD.
- tap2 (VPN/UDP) : 192.168.101.1
NetBSD :
- wm0 : WAN Wimax (youpi) sur 192.168.15.14
- agr0 (wm1 + wm2) en 802.3.ad sur 192.168.10.128
Que sont wm1 et wm2 ?
- tap0 (192.168.100.2)
- tap1 (192.168.101.2)
En fait, je ne vois pas trop comment faire un truc intelligent de
tout ça.Donc je crée deux tunnels tap0 et tap1 côté Linux. Je crée là-dessus
une interface EQL et je lui assigne une adresse. Très bien pour
l'émission. Mais je ne vois toujours pas par quel mécanisme se fait
le retour.
Le retour est du ressort de la machine NetBSD. La machine Linux recevra
ce que la machine NetBSD lui envoie. Si chacun des débits descendants
des liens xDSL est supérieur au débit montant du lien Wimax, il n'est
pas forcément utile de faire de l'agrégation de liens dans ce sens de
transmission.
En admettant que j'assigne à eql0 10.100.170.1, il me
faut bien une adresse IP côté NetBSD qui soit sur le même sous
réseau, non ?
Non, pour quoi faire ? Il suffit que les bonnes routes soient présentes
des deux côtés. Les sous-réseaux, ça ne sert qu'à créer implicitement
des routes. On peut très bien s'en passer et créer directement les routes.
Le 30/03/2017 à 23:26, JKB a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
C'est tout à fait cela.
Donc j'imagine que les autres protocoles basés sur UDP comme NTP ou SIP
ne passent pas non plus ?
Si c'est vendu comme de l'accès internet et pas un simple minitel de
luxe, il y a tromperie sur la marchandise.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
As-tu un pointeur sur un howto, une documentation adaptée ? J'ai du
mal à voir comment le multipath pourrait être configuré.
Il y a un paragraphe consacré au routage multipath dans le LARTC howto.
<http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN297>
Typiquement, chez moi :
Linux :
- eth0 : LAN (192.168.0.128)
- eth1 + eth1:[1-6] : WAN1 ADSL (192.168.254.1)
- eth2 : WAN2 VDSL2 (192.168.253.1)
- tap0 (VPN/TCP) : 192.168.100.1
Pourquoi sur TCP plutôt qu'UDP ?
- tap1 (VPN/UDP) : 192.168.1.1
Où est l'autre bout de ce VPN ? Je ne le vois pas sur NetBSD.
- tap2 (VPN/UDP) : 192.168.101.1
NetBSD :
- wm0 : WAN Wimax (youpi) sur 192.168.15.14
- agr0 (wm1 + wm2) en 802.3.ad sur 192.168.10.128
Que sont wm1 et wm2 ?
- tap0 (192.168.100.2)
- tap1 (192.168.101.2)
En fait, je ne vois pas trop comment faire un truc intelligent de
tout ça.
Donc je crée deux tunnels tap0 et tap1 côté Linux. Je crée là-dessus
une interface EQL et je lui assigne une adresse. Très bien pour
l'émission. Mais je ne vois toujours pas par quel mécanisme se fait
le retour.
Le retour est du ressort de la machine NetBSD. La machine Linux recevra
ce que la machine NetBSD lui envoie. Si chacun des débits descendants
des liens xDSL est supérieur au débit montant du lien Wimax, il n'est
pas forcément utile de faire de l'agrégation de liens dans ce sens de
transmission.
En admettant que j'assigne à eql0 10.100.170.1, il me
faut bien une adresse IP côté NetBSD qui soit sur le même sous
réseau, non ?
Non, pour quoi faire ? Il suffit que les bonnes routes soient présentes
des deux côtés. Les sous-réseaux, ça ne sert qu'à créer implicitement
des routes. On peut très bien s'en passer et créer directement les routes.
Le 30/03/2017 à 23:26, JKB a écrit :Pascal Hambourg écrivait :Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
C'est tout à fait cela.
Donc j'imagine que les autres protocoles basés sur UDP comme NTP ou SIP
ne passent pas non plus ?
Si c'est vendu comme de l'accès internet et pas un simple minitel de
luxe, il y a tromperie sur la marchandise.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
As-tu un pointeur sur un howto, une documentation adaptée ? J'ai du
mal à voir comment le multipath pourrait être configuré.
Il y a un paragraphe consacré au routage multipath dans le LARTC howto.
<http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN297>
Typiquement, chez moi :
Linux :
- eth0 : LAN (192.168.0.128)
- eth1 + eth1:[1-6] : WAN1 ADSL (192.168.254.1)
- eth2 : WAN2 VDSL2 (192.168.253.1)
- tap0 (VPN/TCP) : 192.168.100.1
Pourquoi sur TCP plutôt qu'UDP ?
- tap1 (VPN/UDP) : 192.168.1.1
Où est l'autre bout de ce VPN ? Je ne le vois pas sur NetBSD.
- tap2 (VPN/UDP) : 192.168.101.1
NetBSD :
- wm0 : WAN Wimax (youpi) sur 192.168.15.14
- agr0 (wm1 + wm2) en 802.3.ad sur 192.168.10.128
Que sont wm1 et wm2 ?
- tap0 (192.168.100.2)
- tap1 (192.168.101.2)
En fait, je ne vois pas trop comment faire un truc intelligent de
tout ça.Donc je crée deux tunnels tap0 et tap1 côté Linux. Je crée là-dessus
une interface EQL et je lui assigne une adresse. Très bien pour
l'émission. Mais je ne vois toujours pas par quel mécanisme se fait
le retour.
Le retour est du ressort de la machine NetBSD. La machine Linux recevra
ce que la machine NetBSD lui envoie. Si chacun des débits descendants
des liens xDSL est supérieur au débit montant du lien Wimax, il n'est
pas forcément utile de faire de l'agrégation de liens dans ce sens de
transmission.
En admettant que j'assigne à eql0 10.100.170.1, il me
faut bien une adresse IP côté NetBSD qui soit sur le même sous
réseau, non ?
Non, pour quoi faire ? Il suffit que les bonnes routes soient présentes
des deux côtés. Les sous-réseaux, ça ne sert qu'à créer implicitement
des routes. On peut très bien s'en passer et créer directement les routes.
