Donc pas de SDSL pour du DUAL Wan si je comprend bien ?
Tu fais bien comme tu veux!
Du multi-WAN sur
x SDSL, pourquoi pas?
Du bonding avec
x SDSL via serveur dédié, pourquoi pas?
Dans les deux cas, tu as de la complexité supplèmentaire.
Pour du multi-WAN : - deux IP publiques; chaque connexion TCP ne peut utiliser au maximum que le débit d'un lien, voir moins si deux connexions se retrouvent sur le même lien alors que l'autre est inutilisé (pas évitable en général)
- attention au changement d'IP en cours de session HTTP (cookie ID de session) : certains sites n'aiment pas ça et tu es déconnecté, sur
http://www.journaldufreenaute.fr/forum/ notamment!
+ si tu télécharges un gros fichier, il doit être possible de le télécharger en parallèle sur les deux connexions avec un proxy HTTP en utilisant "range" et avec un proxy FTP avec une pseudo reprise de téléchargement; ftp.free.fr n'aime pas cela et interdit donc la commande de reprise de téléchargement; si tu télé-verses un gros fichier, je ne connais pas de solution en HTTP
+ tu peux intégrer ta connaissance du peering de différents FAI : tel FAI a un peering pourri avec 1e100 => je force toutes les connexions vers 1e100 sur l'autre FAI (config en dur)
+ tu peux faire des choses évoluées en détectant automatiquement les IP inaccessibles d'un coté et diriger certaines connexions uniquement de l'autre coté
+ encore plus évolué : tu peux comparer le débit obtenu vers un même réseau d'un coté et de l'autre et en tenir compte
- si un lien est déconnecté des connexions (TCP ou autre) en cours sont perdues
- NAT obligatoire, même en IPv6 ("mode bridge" impossible)
- accès IPv6 impossible avec FAI IPv4-only; accès IPv4 impossible avec FAI IPv6-only
+ possibilité d'utiliser toujours un FAI pour accéder au réseau de ce FAI (quelques règles de routage à rajouter); p.ex. l'accès non authentifié à smtp.free.fr et à news.free.fr est uniquement possible depuis Free
Pour le bonding de liens via serveur dédié Utiliser un protocole de bonding robuste : détection automatique d'un lien mort, basculement immédiat sur les autres liens.
+ possibilité de redémarrer une box sans aucune interruption de service
+ possibilité d'ajouter un lien avec effet immédiat sur le débit des connexions en cours
- si les MTU sont différents, le MTU du super-lien est le plus petit MTU
+ sérialisation-défragmentation possible sur le dédié coté super-lien : MTU indépendante des MTU des liens locaux (est-ce une bonne idée?)
+ si l'hébergeur du serveur n'est pas aussi le FAI des connexions, latence et risque de saturation supplèmentaire (prendre le même : p.ex. Proxad/Dedibox/Free)
- si la latence des connexions est différente : ré-ordonnancement fréquents de paquets, jerk; mais possibilité de sérialiser les paquets en sortie de bonding (est-ce une bonne idée?)
+ possibilité de rendre sans perte le lien (est-ce une bonne idée?)
+ compression des entêtes possible, voir du flux complet si lien sans pertes
+ chiffrement du contenu d'un lien possible (si défiance envers le FAI => mais reporte le pb sur l'hébergeur)
- tu dépends de la connectivité de réseau de l'hébergeur : aucune redondance à ce niveau
+ défragmentation possible sur le dédié coté WAN : moins de fragments à rapatrier
+ accès IPv6/IPv4 possible avec FAI IPv4-only/IPv6-only
+ mode bridge possible en IPv4 et IPv6 via une box en mode routeur (chaque connexion bondée peut être "partagée" en NAT dans le même temps)
+ possibilité d'utiliser directement l'accès natif d'un FAI au lieu du super-lien pour accéder au réseau de ce FAI (quelques règles de routage à rajouter); p.ex. l'accès à smtp.free.fr port 25 est uniquement possible depuis Free
+ possibilité de pare-feu upstream (sur le dédié) : le trafic bloqué n'occupe pas la boucle locale; blocage de certaines attaques DDoS au niveau du serveur
+ possibilité de shaping des deux coté du lien; possibilité de gérer plusieurs files avec différents niveaux de QoS; possibilité de rendre sans perte (sauf cas exceptionnel) certaines files; possibilité de rendre sans perte et sans jerk (sauf cas exceptionnel) une des files; possibilité d'optimiser pour le débit une file (p.ex. mettre un tunnel TCP compressé (avec shapping pour provoquer des pertes de paquets en cas bourrage du tunnel)) et pour la latence une autre (pas de sérialisation des paquets en cas de perte)
+ possibilité de proxy SOCKS pour protéger le débit TCP des pertes de paquets et de la latence du lien (évite le problème du lien rendu fiable)
+ possibilité de proxy HTTP, FTP... (Squid)
+ possibilité de reverse-proxy pour un hébergement de serveur HTTP (Squid)
+ hébergement de serveurs sur le dédié pour meilleur réactivité (p.ex. DNS) ; migration des serveurs de chez soi vers le dédié en toute transparence (même IP)
Multi-liens + dédiéEnfin, il est aussi possible de combiner les deux approches : avec
n liens, on pourrait :
1) mettre chaque lien en partage de connexion (box en "mode routeur", NAT-routeur, ou autre approche)
2) fabriquer un super-lien en utilisant chaque lien en bonding
3) faire de l'équilibrage multi-lien en fonction de la réactivité de chaque lien, en incluant éventuellement le super-lien
4) utiliser le super-lien comme liaison "sécurisée" pour les serveurs hébergés, et pour les applications ayant besoin d'une QoS précise (p.ex. diffuseur MPEG)
Qu'en pensez-vous?