Acheminement du trafic avec des connexions peu fiables


10

J'ai un groupe de bureaux qui sont tous connectés au bureau principal via des liaisons DSL à l'autre bout pour économiser des coûts. (Nous sommes à but non lucratif, ne demandez pas)

Historiquement, nous avons eu des problèmes notables avec la liaison entre le FAI qui gère nos sites distants et le FAI qui gère les lignes T1 sur lesquelles OpenVPN s'exécute, de sorte que ces liens tombent fréquemment en panne.

L'interface publique de notre serveur de messagerie est sur le réseau du 1er fournisseur, donc cela fonctionnait très bien, mais c'est beaucoup plus lent car c'est aussi DSL.

Pour résoudre les problèmes de non-fiabilité du réseau en amont, j'avais écrit un script qui modifie simplement les enregistrements DNS sur les sites distants pour pointer vers l'IP interne si le tunnel est en hausse ou l'IP publique si le tunnel VPN vers le site principal est en panne.

Comment puis-je le faire d'une manière plus élégante qui sera instantanée (au lieu de mes scripts cron) et transparente pour les utilisateurs?

Edit: Bureaux distants: serveurs Ubuntu 9.10 LTSP exécutant divers Actiontecs fournis par le fournisseur et Motorola et quelques-uns avec le pare-feu Netgears et Linksys. Bureau principal: Presque 100% Linux (CentOS, dans ce cas) avec plusieurs pare-feu de la série Netgear FVS318 / 338 avec des pare-feu individuels pour chaque IP sur notre / 27. (un autre ne demande pas, c'était avant mon arrivée)


pouvez-vous fournir des détails sur les systèmes d'exploitation impliqués, etc.?
Zapto

Sheesh. Désolé. Cerveau mort d'être debout toute la nuit.
Magellan

Réponses:


3

OpenVPN devrait être en mesure d'exécuter des commandes lors de la création et de la fermeture des tunnels. Au lieu d'exécuter ce travail dans un cron, vous pouvez déclencher le brassage des enregistrements DNS déclenché par ces événements. Ensuite, il vous suffit de surveiller quelque chose sur le lien non fiable pour savoir quand redémarrer le tunnel VPN.


1

Cela dépend de votre budget. IP SLA de Cisco (et certainement d'autres) fait exactement cela. Voici un excellent point de départ

Vous pourrez peut-être retirer cela sans autre chose. Je suppose que le DNS de vos utilisateurs pointe vers le routeur de votre site distant. Dans le routeur de votre site distant, vous pouvez ajouter le DNS principal de votre 1er fournisseur et le DNS secondaire de votre 2e fournisseur. La plupart des routeurs de nos jours sont suffisamment intelligents pour échouer vers le secondaire une fois que le primaire échoue.

EDIT: Pour être juste en fonction de votre DSL, vous pouvez trouver un routeur Cisco d'occasion à partir de 60 $. Étant donné que les SLA IP sont pris en charge depuis 12.3 (14) T


Oui, ils ne peuvent pas encore vraiment se permettre de l'équipement Cisco. Peut-être qu'un jour, ils découvriront que l'achat d'équipements Cisco est moins cher que les nouveaux effectifs, mais ils ne l'ont pas encore compris.
Magellan

Et un +1 pour le lien plein de trucs Cisco intéressants pour moi.
Magellan
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.