Meilleure pratique pour un site à double hébergement avec deux FAI?

Je suis abonné à deux FAI, un rapide et cher et un bon marché mais plus lent. Ils utilisent différentes technologies, câble et ADSL, donc il n'y a pas beaucoup de point de défaillance unique, et tout mon équipement de communication est alimenté par un onduleur.

Les FAI au Royaume-Uni connaissent une tendance assez aléatoire. Depuis de nombreuses années, je n'ai pas encore rencontré de moment où mes deux FAI ont baissé simultanément, donc clairement la stratégie à deux FAI est utile si vous voulez un accès net ininterrompu ici.

Le problème est cependant de savoir comment organiser la mise en réseau de votre site pour profiter de cette disponibilité améliorée. De nombreux FAI ne vous permettent pas d'exécuter votre propre AS et vos protocoles de routage, vous êtes donc principalement coincé avec la répartition de votre routage statique sur vos deux canaux de sortie par destination. C'est moins que brillant et nécessite une intervention manuelle lorsqu'un FAI tombe de la surface de la planète. Avec l'aide de nombreux scripts, je gère les pannes des FAI avec un succès raisonnable et peu d'efforts, et c'est devenu le business as usual. Ce n'est pas génial cependant. Il semble que certaines technologies manquent.

1. Y a-t-il une meilleure façon, généralement?
2. Existe-t-il un meilleur moyen pour IPv6 uniquement (j'ai une double pile sur un FAI et je peux tunneler sur l'autre)? Ce serait une aubaine claire pour IPv6.

Quel type d'équipement avez-vous connecté aux fournisseurs? S'il s'agit d'un périphérique Cisco, vous pouvez utiliser IP SLA pour envoyer une requête ping à une destination telle que 8.8.8.8 sur le FAI principal. Dès que vous n'obtenez pas de basculement de réponse vers l'autre route statique. Exemple de configuration:

! ISP1
ip route 0.0.0.0 0.0.0.0 x.x.x.x track 1
! ISP2
ip route 0.0.0.0 0.0.0.0 y.y.y.y 250
ip sla 1
icmp-echo 8.8.8.8 source-interface <ISP1_interface>
frequency 3
timeout 1000
ip sla schedule 1 life forever start-time now

Vous devrez peut-être mettre un itinéraire statique pour 8.8.8.8 sur ISP1 pour qu'il quitte toujours ce chemin. Évidemment, si vous utilisez vraiment 8.8.8.8, choisissez une autre IP, sinon vous ne pourrez pas y accéder si ISP1 tombe en panne.

!x.x.x.x is next-hop to ISP1
ip route 8.8.8.8 255.255.255.255 x.x.x.x

Vous voudrez peut-être vérifier si un fournisseur LISP est disponible. LISP est un protocole qui peut rendre un site indépendant des FAI en amont auxquels il se connecte. Vous obtenez une ou plusieurs adresses IP du FAI LISP et ils les acheminent vers l'endroit où vous êtes connecté. C'est une technique de tunneling, mais avec beaucoup de fonctionnalités intéressantes. Vous pouvez contrôler à la fois l'équilibrage de charge entrant et sortant sur les liens, vous pouvez faire du multihébergement IPv6 sans avoir à recourir à des hacks comme NPT66 (traduction de préfixe). Vous pouvez même vous déplacer de l'autre côté de la planète sans changer d'adresse IP ;-)

J'utilise LISP moi-même et mon réseau de bureau a un bloc d'adresses IPv4 / 26 et un bloc d'adresses IPv6 / 48 qui sont indépendantes des amonts (une connexion par câble UPC avec une adresse IPv4 dynamique et une connexion DSL Solcon avec à la fois une adresse IPv4 statique et un bloc statique d'adresses IPv6). Un Cisco 1841 exécute LISP au bureau et utilise le lien disponible pour se connecter au reste d'Internet. Tant qu'un lien fonctionne, mon bureau est connecté à l'aide de ses propres adresses.

Divulgation complète : je dirige mon propre FAI basé sur LISP aux Pays-Bas, donc je suis partial. LISP est quand même un protocole sympa :-)

Dans le multi-hébergement IPv6 avec des adresses agrégées de fournisseurs, chaque hôte du réseau recevra un préfixe d'adresse de chacun des fournisseurs. La sélection de l'adresse source de la pile hôte / application (RFC6724) et le choix de la paire SA / DA (RFC6555) déterminent quelle sortie est utilisée.

C'est-à-dire que le choix par l'hôte / l'application de l'adresse source sélectionne le lien de sortie utilisé. Diverses implémentations le font de différentes manières, et aucune ne le fait très bien pour le moment.

Le réseau utilise un routage dépendant de l'adresse source pour transférer le trafic vers la sortie correcte. (Sinon, BCP38 (filtrage d'entrée) aurait abandonné un paquet envoyé avec l'adresse source d'ISP B à ISP A). Voir http://tools.ietf.org/html/draft-troan-homenet-sadr-01 Nous avons une implémentation dans OpenWRT. Mais il peut également être mis en œuvre raisonnablement bien sur n'importe quel routeur prenant en charge le routage basé sur des règles.

Une application doit être suffisamment intelligente pour changer de connexion (choisissez une autre paire SA / DA) lorsque la connexion actuelle échoue. Ça ne l'est pas. En attendant, notre recommandation est de définir la durée de vie du préfixe d'adresse du lien défaillant à 0, ce qui signifie que les nouvelles connexions n'utiliseront pas cette adresse.

Q1. Vous pouvez installer un routeur / pare-feu qui prend en charge le multihébergement. En termes de logiciels libres, pfSense fait l'affaire. http://www.pfsense.org/ . Les documents pfSense appellent cela Multi-WAN. http://doc.pfsense.org/index.php/Multi-WAN_2.0

Utilement, pfSense a un basculement automatique et un équilibrage de charge.

Ce que j'ai trouvé, c'est qu'un petit nombre d'applications Web ne fonctionnent pas lorsque vous êtes multi-hôte. Les applications Web sont généralement des sites financiers, comme les banques. Pour une raison quelconque, les programmeurs d'applications Web pensent parfois qu'il est OK de tester la sécurité sur la base de l'adresse IP. Pour les utilisateurs qui ont besoin de cet accès, vous pouvez réserver une adresse IP pour leur ordinateur et créer une "règle LAN" dans pfSense pour toujours utiliser une certaine passerelle et non l'autre pour cette adresse IP.

Je trouve que cela fonctionne assez bien pour la combinaison du modem câble et du modem ADSL.

Q2. Il n'y a aucune raison pour que le multihébergement ne fonctionne pas aussi bien en IPv6 qu'en IPv4. Cela dit, pfSense ne dispose pas d'une version entièrement prise en charge qui gère correctement IPv6. La version actuelle de pfSense est 2.0x. Une fois la version 2.1 publiée, pfSense aura un bon support IPv6 et inclura le multihébergement.

Vous pouvez configurer un serveur distant / VPS dans un centre de données fiable, puis vous pouvez configurer des tunnels VPN de votre routeur vers le serveur distant via chaque FAI. Maintenant, votre routeur à la maison peut acheminer des paquets sur ces tunnels en fonction d'un rapport de bande passante, puis le serveur distant peut acheminer le trafic entre le reste d'Internet.

L'inconvénient est que vous encourrez des coûts supplémentaires de processeur, de stockage et de bande passante pour le serveur distant.

L'avantage est que vous pouvez utiliser toute la bande passante fournie par les deux fournisseurs tout en ayant une option de basculement pour la fiabilité.

J'ai utilisé OpenWRT avec Multiwan ( http://wiki.openwrt.org/doc/uci/multiwan ) pendant un certain temps à la maison pour le multihome entre mon DSL et mon FAI par câble. Cela a très bien fonctionné. Je ne le conseillerais pas comme une solution d'entreprise, mais c'est correct pour les configurations SOHO et à domicile.