C’est quoi des “connexions internet” ?
Ca devrait fonctionner avec plusieurs IP sur le bridge, non ?
Bon c’est sur qu’avec une interface sans mac, c’est difficile (mea culpa)
C’est quoi des “connexions internet” ?
Ca devrait fonctionner avec plusieurs IP sur le bridge, non ?
Bon c’est sur qu’avec une interface sans mac, c’est difficile (mea culpa)
Des connexions réseau qui fournissent un accès internet (FAI, VPN…). Comme on ne maîtrise qu’un seul bout de la connexion (le sien), on ne peut pas faire n’importe quoi avec, et notamment du pontage ou de l’agrégation de liens.
Le pontage signifie la mise en liaison directe au niveau ethernet des deux FAI, avec mélange des paquets de l’un et de l’autre, ils pourraient ne pas aimer.
Peux-tu préciser ce que tu entends par " UP" et "ROUTE " stp ?
Bonsoireuh,
Du coup, j’ai testé un autre truc, dont voici le code (tricky evidement):
#!/bin/bash
#TODO: change this to match your hardware
MAGIC=/sys/devices/pci0000:00/0000:00:1c.5/0000:05:00.0/net/eth0/carrier
GW=192.168.0.254
isset(){
ip r l | grep -q "default via $GW dev eth0"
return $?
}
plugged(){
isset || /sbin/ip r a default via $GW dev eth0
}
unplugged(){
isset && /sbin/ip r d default via $GW dev eth0
}
while true
do
[ $(<$MAGIC) -eq 1 ] || unplugged
[ $(<$MAGIC) -eq 0 ] || plugged
sleep 1
done
Bon, faudrait intégrer la route pour le subnet (ici: 192.168.0.0/24), m’enfin
Mise en place:
Tu met deux routes, une pour chaque interface, comme ceci par exemple:
4% [root:~]ip r l
default via 192.168.0.254 dev eth0
default via 192.168.0.254 dev wlan0 metric 2
La route avec le metric le plus petit (ici: eth0) passe en priorité.
Tu balances le code ci-dessus en arrière plan, il va supprimer la route eth0 à l’occasion, c’est donc la route la moins bonne (ici, wlan0 avec le metric 2) qui va être utilisé
Le pire, c’est que ca fonctionne :troll:
Salut,
Peux-tu préciser ce que tu entends par " UP" et "ROUTE " stp ?[/quote]
UP => il faut lever l’interface
ROUTE => il faut définir la route par défaut vers cette interface.
Pour être un peu plus clair
Sur les 3 interfaces, seulement 2 sont actives en permanence (eth0 et tun0), la dernière est là en dépannage (ppp0).
@haleth: tu peux expliquer un peu ton script svp ?
Merci.
Boucle infinie:
La détection de l’état du port est faite via sysfs (/sys/class/net/eth0/carrier contient 0 si le port n’est pas monté, 1 si il l’est; /sys/devices/pci0000:00/0000:00:1c.5/0000:05:00.0/net/eth0/carrier est le “vrai” fichier, sans symlink, m’enfin pour mon PC)
J’me demande comment vont les connexions TCP après un changement de route comme ca
Salut,
Après bien des essais, j’ai utilisé le “load balancing” tel qu’indiqué sur cette page: community.ubnt.com/t5/EdgeMAX-Co … a-p/420301
Je me rend bien compte que ce n’est pas si “avancé” que ça comme routage.
Si ma connexion VPN est coupée, certaines applications (web radio par exemple) ne trouvent plus le chemin, sans avoir été arrêtées et redémarrées.
Ça roule, toutes les dix secondes la connexion est testée, si elle tombe, ça passe sur l’autre.
Actuellement, c’est soit ETH0, soit TUN0, du coup une partie de la bande passante n’est pas utilisée (quand TUN0 est définie comme interface par défaut, plus rien ne passe par eth0 alors qu’il y a de la bande passante disponible…)
Est-ce qu’il serait possible d’envisager, de faire du “bonding” (Agrégation de liens) entre une interface physique et un vpn ?