Deux connexions Internet: Routage avancé

Support Debian
#1

Salut,
J’ai un petit problème à régler, mais je ne sais pas par quel bout le prendre…

Je dispose sur un serveur de deux connexions: une 3g par clef et une sur eth1.
Le fichier /etc/network /interfaces se présente ainsi:

[code]auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.0.10.1
netmask 255.255.252.0
network 10.0.8.0
broadcast 10.0.11.255
dns-nameservers 10.0.10.1

auto eth1
iface eth1 inet manual
hwaddress ether xx:xx:xx:xx:xx:xx

auto ppp0
iface ppp0 inet wvdial[/code]

La connexion lancée au démarrage est celle sur la clef 3g (ppp0: c’est la connexion préférée)
Pour passer sur l’autre connexion (eth1) il suffit de lancer dhclient eth1.

Je souhaite tester la connexion ppp et passer sur eth1 en cas de coupure. Ça c’est plutôt facile…

Maintenant uns fois levée l’interface eth1 et connecté sur la deuxième connexion, je souhaite tester régulièrement si la première connexion redevient valide et la lancer.
Mais je craint que ça ne coupe le connexion via eth1…

Et j’ai du coup peur d’avoir un soucis de route si eth1 et laissé actif…

Pour tout dire la machine est loin, j’ai seulement un accès ssh (en plus un reverse ssh tunnel passant pas un dédié) je n’ai pas envie de scier la branche sur laquelle je suis assis…

Je ne suis pas certain d’avoir été clair, si vous avez besoin de plus d’explication, n’hésitez pas…

#2

Problème classique de la route par défaut. J’écris bien “la”, car comme chacun sait (n’est-ce pas ?) il ne peut y avoir qu’une seule route par défaut active sur une machine, quel que soit le nombre d’interfaces réseau ou de connexions internet.

Plusieurs options, pouvant être combinées, peuvent être envisagées.

  • Lorsque tu remontes la connexion PPP pour la tester, ne pas créer de route par défaut associée. Créer éventuellement une route vers une destination de test qui seule pourra être atteinte par cette connexion, le reste étant routé par eth1. Ainsi si la connexion PPP monte mais n’est pas opérationnelle, seule la destination de test sera injoignable.

  • Utiliser du routage avancé, de plusieurs façons :

  • simple : routage basé sur l’adresse source : si un paquet a une adresse source définie, alors on le route par l’interface qui a cette adresse. C’est de toute façon nécessaire car les FAI bloquent probablement les paquets envoyés avec la “mauvaise” adresse source.

  • plus compliqué : routage des réponses par l’interface d’entrée des requêtes. Il faut utiliser iptables.

  • routage par une interface basé sur un critère quelconque (adresse, protocole, port…) grâce au marquage de paquets par iptables.

pppd est très pratique pour mettre en place ce genre de chose car il permet de lancer des scripts lors de l’établissement ou de la terminaison d’une connexion auxquels il passe les paramètres de la connexion (adresses IP locale et distante, nom de l’interface…). Je suppose que dhclient a la même possibilité, mais je ne connais pas.

Tout ça est un peu fouillis, mais c’est pour te donner des idées.

#3

Salut,
Oui, une seule route par défaut. Les paquets ne trouvent pas la sortie tout seuls (et c’est dommage…).
Pour corser mon affaire, la machine est une passerelle, il faut des règles NAT, qui doivent évidemment changer en fonction de l’interface.
Pour être franc j’ai plutôt envie de faire simple (c’est de mon niveau…).
Je ne me vois pas faire du routage “avancé” je ne maîtrise pas encore assez (c’est dommage, je sais).

Il n’est pas question pour l’instant de faire du “bonding” (mais je vais quand même jeter un œil, ce serait sympa de tester)

Est-ce que finalement avoir les deux interfaces levées au démarrage et jouer avec les routes et DNS (en fonction d’une bête réponse à un ping) ne serait pas le plus facile dans mon cas ?
Dans ce cas, il faut que je vérifie que resolv.conf n’est pas installé car il va falloir que le remplisse moi-même.

Pour mon DHCP je ne donne aux clients comme DNS que celui de la passerelle et le tour est joué.

Je ne comprend pas quand tu dis [quote=“PascalHambourg”]si la connexion PPP monte mais n’est pas opérationnelle[/quote]Cela signifie que je pourrais avoir un ppp0 dans ifconfig, mais que la connexion n’est pas opérationnelle (sans ip) ?

En ayant ppp qui tente de temps en temps de se connecter, ce serait facile de couper la route vers eth1 en cas de succès.

Ça non plus je ne comprend pas:

[quote=“PascalHambourg”]routage des réponses par l’interface d’entrée des requêtes. Il faut utiliser iptables.[/quote]Les paquets arrivent tous par eth0, puis ils sont routés soit vers ppp0 soit vers eth1.

Merci de tes remarques, ça m’a un peu éclaircie les idées.

#4

Si ça peut t’aider à configurer ta machine à 3 pattes:
tldp.org/HOWTO/Adv-Routing-H … links.html

#5

Ça c’est la partie plutôt facile, les règles iptables pouvant tenir compte de l’interface d’entrée ou de sortie.

De toute façon on ne peut pas faire du bonding sur des accès internet.

Oui. Il y a deux niveaux possibles :

  • la connexion PPP n’est pas encore établie mais l’interface pppX existe ; elle n’est pas UP, n’a pas de configuration IP… donc cela ne devrait pas être gênant pour le routage.
  • la connexion PPP est établie, l’interface pppX est active et configurée mais le trafic IP ne passe pas ou pas bien pour une raison quelconque (panne en amont, saturation, la liaison PPP est coupée mais pppd ne l’a pas détecté…).

[quote=“lol”]Ça non plus je ne comprend pas:
"routage des réponses par l’interface d’entrée des requêtes. Il faut utiliser iptables."
Les paquets arrivent tous par eth0, puis ils sont routés soit vers ppp0 soit vers eth1.[/quote]
Je pensais plus au cas des connexions entrantes provenant d’internet, comme l’accès SSH.

#6

Salut,
Merci Piratebab, ça m’a l’air intéressant.

[quote=“PascalHambourg”]Ça c’est la partie plutôt facile, les règles iptables pouvant tenir compte de l’interface d’entrée ou de sortie.[/quote]Si les deux interfaces sont up sinon ça génère une erreur, non ?
Donc il me suffirait de prévoir dés le lancement les règles de FORWARD sur les deux interfaces. Très bien.

[quote=“PascalHambourg”]De toute façon on ne peut pas faire du bonding sur des accès internet.[/quote]J’avais commencé à écrire “load balancing” mais je n’étais plus sur. Ça n’a pas l’air si sorcier finalement, je vais surement me diriger vers cette solution.

[quote=“PascalHambourg”]Oui. Il y a deux niveaux possibles [/quote]Dans l’un comme l’autre, une solution de “load balancing” est donc ce qu’il faudrait.

[quote=“PascalHambourg”]Je pensais plus au cas des connexions entrantes provenant d’internet, comme l’accès SSH.[/quote]Je me connecte avec l’IP qui n’est pas la même, c’est donc moi qui choisi l’interface d’entrée. Je peux rentrer facilement en ssh sur une des deux interfaces, sur l’autre il me faut un “reverse tunnel” permanent.

Je vais faire un essai sur ma machine “locale” avec une autre clef 3G. une fois fignolé les srcipts je tenterais ma chance en live… :confused:

Merci pour ton aide.

PS: le lien de piratebab est à jour concernant les commandes (Revision 1.1 - 2002-07-22) ?
J’ai trouvé le même ailleurs, les papiers diffèrent un peu: lartc.org/howto/lartc.rpdb.multiple-links.html

Et une petite dernière pour la route…
Je peux me faire la main avec le load balancing sur deux connexions passants par la même interface ? (genre eth0 et opnvpn) ?

#7

jeux de mot volontaire ? :stuck_out_tongue:

#8

Non. Contrairement à ip route/rule, iptables ne se préoccupe pas de savoir si les interfaces existent et sont actives ou pas. Cela se comprend assez facilement :

  • Si on doit router un paquet dont la destination correspond à une route avec une interface de sortie qui n’existe pas ou est inactive, on fait quoi ? On est coincé. C’est pourquoi quand une interface est désactivée ou supprimée, toutes les routes associées sont effacées.
  • En revanche une règle iptables fait une simple correspondance, c’est-à-dire vérifie si l’interface d’entrée ou de sortie du paquet en cours de traitement correspond à l’interface mentionnée dans l’option -i ou -o. C’est une bête comparaison de texte.

L’équilibrage de charge sur deux connexions internet indépendantes n’est pas trivial. On ne peut pas se contenter de balancer un paquet sur deux sur chaque connexion. L’équilibrage ne peut se faire que sur la base de “flux” (exemple : connexions TCP), tous les paquets appartenant à un même flux devant être routés par la même connexion internet. L’aiguillage doit donc se décider avec le premier paquet du flux, or il est difficile de savoir à l’avance quelle bande passante un flux utilisera.

Mais c’est le serveur qui choisit l’interface de sortie pour renvoyer les paquets retour, et il vaut mieux qu’il choisisse la bonne. D’où le routage avancé basé sur l’adresse source (qui est l’adresse de destination sur laquelle tu t’es connecté).

A ta place, dans un premier temps je me contenterais de faire du fail over, sans load balancing. C’est déjà assez compliqué comme ça.

#9

hello,

[quote=“piratebab”]jeux de mot volontaire ?[/quote]Bien sur… :wink:

Merci PascalHambourg pour toutes ces précisions, je vais potasser un peu et faire des tests en local.
je peux changer le titre en Deux connexions Internet: routage avancé ?

#10

Re,
j’ai fait un premier essai:

Avant mes modifs:

netstat -anr Table de routage IP du noyau Destination Passerelle Genmask Indic MSS Fenêtre irtt Iface 0.0.0.0 10.10.9.5 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 10.10.10.254 0.0.0.0 UG 0 0 0 eth0 10.9.8.0 10.10.9.5 255.255.252.0 UG 0 0 0 tun0 10.10.9.0 10.10.9.5 255.255.255.0 UG 0 0 0 tun0 10.10.9.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 41.188.26.xxx 10.10.10.254 255.255.255.255 UGH 0 0 0 eth0 128.0.0.0 10.10.9.5 128.0.0.0 UG 0 0 0 tun0

Les modifs: dans /etc/iproute2/rt_tables

1 via_vpn 2 via_fo

Dans /etc/rc.local

[code]ip route add 10.10.10.0/24 dev eth0 src 10.10.10.2 table via_fo
ip route add default via 10.10.10.254 dev eth0 table via_fo

ip route add 10.10.9.0/24 dev tun0 src 10.10.9.5 table via_vpn
ip route add default via 10.10.9.5 dev tun0 table via_vpn

ip route add 10.9.8.0/22 dev tun0 src 10.10.9.5 table via_vpn
ip route add default via 10.10.9.5 dev tun0 table via_vpn

ip route add default scope global nexthop via 10.10.10.254 dev eth0 weight 1 nexthop via 10.10.9.5 dev tun0 weight 1[/code]

Et j’ai redémarré. Et ben… je vois pas la différence et j’ai l’impression que mes tables ne sont pas prises en compte…

# netstat -anr Table de routage IP du noyau Destination Passerelle Genmask Indic MSS Fenêtre irtt Iface 0.0.0.0 10.10.9.5 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 10.10.10.254 0.0.0.0 UG 0 0 0 eth0 10.9.8.0 10.10.9.5 255.255.252.0 UG 0 0 0 tun0 10.10.9.0 10.10.9.5 255.255.255.0 UG 0 0 0 tun0 10.10.9.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 41.188.26.xxx 10.10.10.254 255.255.255.255 UGH 0 0 0 eth0 128.0.0.0 10.10.9.5 128.0.0.0 UG 0 0 0 tun0

ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default
La sortie de la dernière commande ne devrait pas me montrer les tables ?
Quand les interfaces sont levées, ça écrase mes commandes dans rc.local ?

Merci.

#11

est ce que tu n’ aurais pas oublié ces 2 commandes ? je me souviens de m’ être cassé les dents sur ce genre de routage et malgrè que je ne suis pas un expert, cela avait résolu.

/sbin/ip rule add from 10.10.10.2 table via_fo /sbin/ip rule add from 10.10.9.5 table via_vpn

pour montrer les tables, les commandes sont:

ip route show table via_fo ip route show table via_vpn

je ne peux pas t ’ aider plus que cela si cela ne fonctionne toujours pas, ces infos ne sont pas dues à une lourde réflexion mais simplement un retour d’ expérience lorsque je devais faire passer la connexion d’ une application par eth0 à la place de tun0, j’ avais aussi utilisé la table mangle d’ iptables.

#12

Laurent n’a pas forcément oublié ces deux commandes-là exactement, mais il est clair que sans règles de routage, ses tables de routage alternatives ne servent à rien.

Laurent : les routes des tables alternatives ne sont pas affichées par netstat -r ni route. Même la route multipath (avec les nexthop) n’est pas affichée intégralement (seulement la première passerelle), car ces commandes ne connaissent pas ce type de route spéciale qui n’est géré que par ip route.

A propos des routes multipath, il faut savoir que la répartition se fait au niveau du cache de routage et donc se base sur les couples adresses source et destination. Cela implique que tant que la route est dans le cache, toutes les connexions ayant les mêmes source et destination seront routées de la même façon. Cela ne peut donc pas faire de répartition de charge pour de multiples connexions entre un même client et un même serveur. Bref, c’est loin d’être aussi souple que le routage avancé.

#13

Salut,

[quote=“nykoos”]est ce que tu n’ aurais pas oublié ces 2 commandes ?[/quote]Oui ça va tout de suite mieux avec les règles de routage, merci.ip rule show 0: from all lookup local 32764: from 10.10.9.5 lookup via_vpn 32765: from 10.10.10.2 lookup via_fo 32766: from all lookup main 32767: from all lookup default

[quote=“PascalHambourg”] tant que la route est dans le cache, toutes les connexions ayant les mêmes source et destination seront routées de la même façon. Cela ne peut donc pas faire de répartition de charge pour de multiples connexions entre un même client et un même serveur. Bref, c’est loin d’être aussi souple que le routage avancé[/quote]Ok
On en revient donc au début:[quote=“PascalHambourg”]A ta place, dans un premier temps je me contenterais de faire du fail over, sans load balancing. C’est déjà assez compliqué comme ça.[/quote]

Je vais donc potasser un peu plus… J’ai du mal à trouver des papiers qui développent le sujet, je dois mal chercher.

Merci.

#14

Re,

[quote=“lol”]c’est loin d’être aussi souple que le routage avancé[/quote]Ok, je viens de piger. Les paquets passent toujours par la même route. Si on donne un poids plus important à une route, elle est choisie en priorité (sauf si les paquets sont destinés à un IP particulière).

je suis tombé sur un script qui utilise les tables de routages tel que dans mon post précédent.
Le but est de faire un ping sur un ip extérieure et de changer les routes en fonction de la réponse du ping.

Cela présente un intérêt selon vous ?

#15

[quote=“lol”]Re,

[quote=“lol”]c’est loin d’être aussi souple que le routage avancé[/quote]Ok, je viens de piger. Les paquets passent toujours par la même route. Si on donne un poids plus important à une route, elle est choisie en priorité (sauf si les paquets sont destinés à un IP particulière).

je suis tombé sur un script qui utilise les tables de routages tel que dans mon post précédent.
Le but est de faire un ping sur un ip extérieure et de changer les routes en fonction de la réponse du ping.

Cela présente un intérêt selon vous ?[/quote]

C’est très utile pour forcer la connexion sur un proxy en particulier dès que possible par exemple :wink: ou favoriser la connexion via tor … avec un peu ajustement cela peu permettre d’utiliser uniquement un VPN pour certains protocoles :whistle: :033 :083 :005

#16

ce routage est aussi très utile pour que les serveurs restent accessibles normalement avec un client vpn lancé sur la même machine.

#17

Salut,
OK, merci de vos précisions.
Maintenant, il faut que je fasse un script, mais je suis loin d’être à la hauteur…

J’arrive à vérifier mes trois (oui, j’ai ajouté un peu de piment…) sorties:
ETH0
TUN0
PPP0

Je pense à une chaine de test comme ça:

PPP0 UP? --OUI-- ETH0 UP? --OUI-------------------- TUN0 UP? --OUI-- KILL PPP0 & ROUTE TUN0 & SORTIE | | | NON NON NON | | | | ROUTE PPP0 OK? --OUI-- SORTIE ROUTE ETH0 OK? --OUI-- KILL PPP0 & SORTIE | | | | NON NON | | | | ROUTE PPP0 & SORTIE KILL PPP0 & ROUTE ETH0 & SORTIE | | | ETH0 UP? --OUI---------------- TUN0 UP? --OUI------ ROUTE TUN0 OK? --OUI-- SORTIE | | | NON NON NON | | | LANCER PPP0 ET SORTIE ROUTE ETH0 ET SORTIE ROUTE TUN0 & SORTIE

J’aimerai bien que quelqu’un qui soit à l’aise avec les if/then m’aide un peu pour construire mon script, parce que là je galère, ça va me prendre des jours… :017

#18

Re,
Je vais finir pas poster dans programmation…
Je ne veux pas abuser, alors j’ai quand même bossé un peu:

[code]if [ $PING3G = “0” ]; then
if [ $PINGVPN = “0” ]; then
if [ $PINGFO = “0” ]; then
echo "KILL PPP0 & ROUTE TUN0 & SORTIE"
exit 1
else
if [ $ROUTEFO = “0” ]; then
echo "KILL PPP0 & SORTIE"
exit 1
else
echo "KILL PPP0 & ROUTE ETH0 & SORTIE"
exit 1
fi
fi
else
if [ $ROUTE3G = “0” ]; then
echo "sortie"
exit1
else
echo "ROUTE PPP0 & SORTIE"
exit 1
fi
fi

else
if [ $PINGFO = “0” ]; then
if [ $PINGVPN = “0” ]; then
if [ $ROUTEVPN = “0” ]; then
echo "SORTIE"
exit 1
else
echo "ROUTE TUN0 & SORTIE"
exit 1
fi
else
echo "ROUTE ETH0 & SORTIE"
exit 1
fi
else
echo "LANCER WVDIAL & SORTIE"
exit 1
fi
fi[/code]

Est-ce que mon script tient la route ?

#19

Hyper compliqué ton truc …

J’te propose un truc qui devrait fonctionner, et qui est bien plus simple.
Tu balances les eth1 et ppp0 dans un bridge (br0)

Tu met une forte priorité sur le port “par defaut” (eth1 ?)

Tu fais tout fonctionner avec le bridge (dans iptables etc)
Lorsque le lien prioritaire tombe, ca passe par l’autre. Quand il revient, il reprend la main.

Seul bémol (à test), t’as plusieurs IP (une privé pour eth1, une publique pour ppp0, j’imagine ?)
J’me demande si ca passe en mettant les deux IP sur le bridge (ip a a IP/mask dev br0)

#20

Plus simple peut-être, mais qui ne marche pas.
On ne peut ponter que des interfaces de type ethernet. On ne peut pas ponter une interface PPP, ou tout type d’interface “routée” (sans couche MAC). On ne peut pas ponter des connexions internet même avec des interfaces ethernet, ça ne marche pas. Les connexions internet sont indépendantes, avec chacune son adresse IP. Ce n’est pas compatible avec le pontage où seul le pont a une adresse IP, les interfaces servant de ports n’ont pas d’adresse.

Quant à mettre une priorité sur un port d’un pont, cela n’a de sens que dans l’utilisation du STP (spanning tree protocol) qui sert à la détection et l’élimination des boucles.

Laurent : je regarderai tes élucubrations à tête reposée quand j’aurai du temps au calme.