Permettre aux utilisateurs d’agréger plusieurs connexions pour sécuriser leur accès à Internet et démultiplier leur bande passante, tel était l’objectif du projet lancé fin 2014. Durant la phase de R&D, le cahier des charges s’est naturellement étoffé : possibilité d’amalgamer plusieurs technologies (xDSL, fibre, câble, 3/4G), fail-over actif, QoS, chiffrement, protection anti-DDoS… Embarquez dans les coulisses de ce projet en compagnie des développeurs qui y ont contribué, chapeautés par Simon Lelièvre. Ensemble, ils reviennent sur les difficultés rencontrées et justifient leurs choix techniques, en particulier l’utilisation de technologies open source, d’OpenWrt à Multi Path TCP, un protocole développé au sein de l’Université Catholique de Louvain en Belgique.
En tant que promoteur et hébergeur de solutions en SaaS, OVH est bien placé pour savoir combien la connexion à Internet est devenue vitale pour les entreprises. Externaliser l’hébergement de ses outils de travail dans le cloud a des avantages évidents : sécurité accrue, travail collaboratif facilité, économies substantielles… En contrepartie, toute coupure de connexion provoque le chômage technique immédiat d’une partie plus ou moins importante des salariés. En outre, les entreprises ne sont pas toutes égales en matière d’accès au haut débit. Trop nombreuses sont celles dont l’activité est, aujourd’hui encore, bridée par une faible vitesse de connexion au réseau mondial. « Lorsque nous avons étudié les solutions disponibles sur le marché pour agréger plusieurs liens, nous avons été surpris par leur coût élevé, qu’il s’agisse de l’acquisition du boîtier ou de l’abonnement au service. » À l’inégalité territoriale s’ajoutait donc une inégalité entre petites et grandes entreprises. Majoritairement américains, les services d’agrégation existants avaient également en commun d’être particulièrement opaques sur leur fonctionnement. « Cela peut être inquiétant pour une entreprise d’installer un tel équipement, ouvrant la porte de son réseau interne et interceptant son trafic. » Il y avait donc une place à prendre. Restait à développer la technologie, en quelques mois.
Privilégier une solution hardware ou software pour agréger ?
Lorsque l’équipe a commencé à réfléchir à la problématique de l’agrégation de liens, elle s’est logiquement appuyée sur l’expérience et les équipements déployés par OVH sous sa casquette de FAI (une activité initiée en 2011, et circonscrite à la France). Les premières tentatives consistèrent à faire du bonding MLPPP (Multi Link Point to Point Protocol) : « Nous pouvions agréger deux lignes provenant de DSLAM différents, mais reliées à un même LNS appartenant à OVH (L2TP Network server, le routeur qui termine la liaison entre l’utilisateur et le FAI, NDR). Malheureusement, lors des tests, la connexion s’est révélée très instable, et l’offre n’aurait concerné que les lignes xDSL dégroupées par OVH ou gérées en collecte. »
Menée en parallèle, la seconde tentative a nécessité l’accord de l’ARCEP. Il s’agissait d’expérimenter le bonding VDSL, c’est-à-dire la fusion, au sein d’un même DSLAM, de plusieurs lignes, comme cela se pratique pour le SDSL (jusqu’à 4 paires). « Le bonding ADSL est possible, mais peu performant. Avec les équipements disponibles sur le marché, nous pouvions agréger jusqu’à deux lignes VDSL. Néanmoins, même en laboratoire, dans des conditions optimales, nous ne parvenions pas à bénéficier d’une connexion stable. Qui plus est, la cible des clients éligibles était encore plus restreinte qu’avec le bonding MLPPP, puisque seuls les abonnés en dégroupage total chez OVH et situés à proximité d’un DSLAM auraient pu bénéficier de ce service. Or, l’ambition était de proposer une solution qui fonctionne partout, y compris à l’international, là où OVH n’est pas FAI. Par ailleurs, il nous semblait essentiel de parvenir à agréger des accès opérés par des opérateurs différents, et utilisant des technologies variées, ceci pour sécuriser l’accès à Internet des utilisateurs. Nous sommes donc repartis de zéro. »
MPTCP : agréger pour mieux régner
L’équipe s’est mise en quête d’une solution software pour faire de l’agrégation. Soit un service Over The Top, qui s’abstrait des FAI et des technologies sous-jacentes. « Il n’est plus question ici de fusionner physiquement des liens Ethernet, comme dans le cas du bonding. L’agrégation software consiste à dispatcher les paquets entre les différents liens, en tenant compte de leur capacité, avant de les réordonner au sein d’une infrastructure hébergée par OVH. »
Plusieurs logiciels furent testés, avec des résultats mitigés : « Le principal problème rencontré ? L’agrégation était réalisée “par le bas”, c’est-à-dire que la bande passante agrégée était égale à x fois la capacité de la moins puissante des connexions. Ceci en raison de l’algorithme de répartition des paquets entre les liens disponibles (round-robin). Par ailleurs, les applications testées se révélaient gourmandes en CPU/RAM. » Puis l’équipe a découvert Multipath TCP (MPTCP), une extension du protocole TCP disponible sous forme de patch du kernel Linux, sur laquelle travaille l’Université Catholique de Louvain, en Belgique. « En plus de permettre d’agréger jusqu’à huit connexions (1) de latences différentes, MPTCP permet de maintenir une session sur plusieurs liens (fail-over actif). Autrement dit, un téléchargement peut se poursuivre malgré la perte d’un lien, sans repartir de zéro. Et une fois le lien à nouveau opérationnel, la bande passante disponible pour le téléchargement augmente à nouveau. Une véritable prouesse technique ! » Avec MPTCP, la connexion peut atteindre une vitesse proche de la somme des débits de l’ensemble des interfaces réseau disponibles. Les applications n’ouvrent qu’une connexion TCP, mais celle-ci est en fait démultipliée (multipléxée), distribuée sur tous les liens puis démultiplexée. « Un mécanisme complexe, mais totalement transparent pour les applications comme pour l’utilisateur. »
Pas étonnant qu’Apple ait débauché le principal développeur de MPTCP, alors qu’il était encore étudiant et achevait sa thèse au sujet de ce protocole. Implémenté sur iOS (le système d’exploitation mobile des iPhone et iPad), MPTCP est utilisé par l’application de reconnaissance vocale Siri pour maintenir la connexion avec les serveurs de la firme de Cupertino dans le cas où vous sortez, par exemple, de la zone de couverture de votre réseau WiFi, en basculant sur la connexion 3/4G. Une autre exploitation intéressante de MPTCP est le projet Gigapath lancé pendant l’été 2015 par l’opérateur Korean Telecom, qui vise à agréger les connexions 4G et Wi-Fi sur un mobile pour atteindre une bande passante dépassant les… 800 Mbps – Il faut savoir que la Corée a le réseau cellulaire le plus rapide au monde. (2)
OverTheBox : une application open source
Convaincue qu’en maîtrisant le hardware du futur boîtier l’équipe bénéficierait d’une plus grande réactivité dans la correction des bugs, elle s’est rapprochée de différents équipementiers dans le but de designer une OverTheBox sur mesure. « Une fausse bonne idée, car nous ne pouvions pas nous engager sur des volumes comparables à ceux des principaux opérateurs. Résultat : le coût unitaire d’un boîtier aurait été en contradiction avec notre cahier des charges, qui visait à développer une solution très accessible. »
MPTCP étant implémenté au sein du kernel, ce protocole s’avère très peu consommateur de CPU/RAM. Il était donc envisageable de s’orienter vers un matériel standard pour constituer la OverTheBox. Un mini-PC de type NUC d’Intel a été retenu par l’équipe, en raison de ses caractéristiques techniques : processeur Atom(TM) à faible consommation d’énergie, qui ne requiert pas la présence d’un ventilateur, source de bruit et de pannes ; présence d’interface réseau gigabits et d’un port USB 3.0 capable de recevoir une clé 3 ou 4G sans en brider le débit, chiffrement AES matériel, c’est-à-dire réalisé directement par un jeu d’instructions intégré au processeur, et conformité aux normes européennes. Le tout pour un coût raisonnable. Seul problème, a priori, de ce boîtier : la présence d’un seul et unique port Ethernet. « Jusque-là, il semblait assez évident qu’OverTheBox devait collecter physiquement l’ensemble des liens à agréger, et donc disposer d’au moins 4 quatre ports Ethernet. Mais l’un d’entre nous a eu une “révélation” : et si au lieu d’ajouter un nouveau switch, on essayait de réutiliser ceux dont sont d’ores et déjà dotés les box à agréger (des modems-routeurs) ? En connectant les modems en série (daisy chain), on peut réutiliser les services de chacune des box – le WiFi par exemple, dont le NUC est dépourvu. Et on gagne sur tous les plans : OverTheBox consomme moins d’électricité que si elle avait comporté un switch et une puce WiFi, et l’installation est simplifiée, puisqu’il n’est pas nécessaire de toucher à son réseau local (on peut conserver le même plan d’adressage au sein de son LAN).
La conception suivante a été donc retenue : conserver les box en tant que routeurs, tout en partageant le même réseau local. Autrement dit : rassembler les WAN sur un même LAN, dont OverTheBox viendra prendre le contrôle en tant qu’unique serveur DHCP. En pratique, on branche OverTheBox sur la première des box, puis on désactive le service DHCP de cette box après qu’OverTheBox a découvert le réseau. Les box supplémentaires sont ajoutées suivant le même protocole. « Nous souhaitions proposer le système le plus simple possible, « zero pain ». Le résultat est proche de l’auto-configuration. D’ailleurs, on peut aussi tout brancher simultanément. OverTheBox se débrouillera toute seule et vous indiquera les serveurs DHCP à désactiver. Cela fonctionne à condition que deux modems n’aient pas la même IP au sein du LAN. Par précaution, nous préconisons que chaque box soit sur un sous-réseau différent. »
OpenWrt, une distribution légère basée sur un noyau Linux, historiquement développée pour remplacer le firmware des routeurs WRT54G fabriqués par Linksys, a été sélectionné pour fournir le programme de base d’OverTheBox. « Nous avons choisi ce système d’exploitation libre pour bénéficier d’un moteur robuste et éprouvé, supporté par une large communauté, dont le code a déjà été audité. Il aurait été idiot de repartir de zéro, et inutile d’installer sur les boîtiers une distribution lourde telle que Debian. Nous avons donc adapté OpenWrt à nos besoins. Nous avons ensuite souhaité rendre notre travail open source, pour donner la possibilité aux utilisateurs de comprendre comment le service fonctionne, et de contribuer à l’améliorer. » On retrouve ainsi sur Github la version d’OpenWrt modifiée pour OverTheBox . « Nous étudions avec un grand intérêt les pull-requests que nous recevons par l’intermédiaire de Github. Nous y voyons une possibilité d’enrichir rapidement les fonctionnalités d’OverTheBox, grâce à l’apport de la communauté d’utilisateurs. Par ailleurs, le fait que le projet soit open source permet à quiconque d’installer l’image logicielle sur un équipement qu’il possède déjà, ou un matériel mieux adapté à ses besoins. » (3)
Les principales modifications apportées à OpenWrt ont consisté à développer un daemon qui permet d’assurer la communication entre OverTheBox et les infrastructures d’OVH, dès sa première connexion à Internet. Ceci permet au boîtier d’être configuré à distance et mis à jour automatiquement. « Faire en sorte qu’un utilisateur se connecte sur http://overthebox.ovh et soit redirigé vers l’adresse IP privée locale de son OverTheBox, pour accéder à l’interface de configuration sans avoir à chercher par lui-même à quelle adresse l’équipement est joignable, voilà une fonctionnalité triviale qui nous a donné du fil à retordre ! Pour cela, nous avons choisi de conserver la première IP privée depuis laquelle elle se connecte à notre infrastructure, pour permettre la redirection ultérieure. »
La release channel a fait, elle aussi, l’objet d’un soin tout particulier : « Etant donné qu’OverTheBox prend le contrôle de l’accès à Internet de ses utilisateurs, il faut considérer cet équipement comme critique. Aussi, nous avons répartis les boîtiers suivant trois catégories : unstable, testing et stable. La première catégorie est réservée à l’équipe de développement, qui reçoit les mises à jour susceptibles de faire planter OverTheBox. La seconde catégorie est accessible aux utilisateurs volontaires pour tester les nouvelles fonctionnalités en avant-première, en contrepartie de quoi ils encourent le risque de subir quelques bugs. Enfin, la catégorie stable permet de diffuser à l’ensemble du parc les mises à jour en principe exemptes de bugs. »
Tunnellisation et proxy
Si vous avez suivi jusque-là, nous avons donc du côté de l’utilisateur un LAN, sur lequel sont branchés plusieurs WAN. En tant que seul serveur DHCP actif, OverTheBox est maître de ce LAN. Aussi, lorsqu’une connexion est établie entre un membre du LAN et Internet, elle transite via OverTheBox, qui dispatche — grâce au protocole MPTCP — les paquets entre les différents liens fonctionnels disponibles. Autrement, dit, lorsqu’un ordinateur du réseau envoie des éléments à un serveur distant, les paquets transitent sur Internet en partie par le lien du FAI 1, en partie par le lien du FAI 2, en partie par le lien du FAI 3, etc. Ce fonctionnement a un effet collatéral bénéfique sur la sécurité : « Par défaut, les échanges transitant par OverTheBox sont chiffrés selon la méthode AES 256, ce qui constitue une première protection. Le fait que les paquets d’une même connexion empruntent différents chemins constitue, quant à lui, une parade efficace à toute tentative d’interception des données. Seule une partie, aléatoire et donc inexploitable, des échanges pourrait être captée par un dispositif installé sur l’un des chemins. »
Les paquets étant dispatchés entre plusieurs liens et acheminés via différents FAI, il est nécessaire, en bout de chaîne, de les réagréger (packet reordering) pour que l’équipement de l’utilisateur et le serveur distant réceptionnent l’intégralité des messages. C’est précisément la tâche qui est réalisée au sein des infrastructures d’OVH dans le sens « utilisateur vers Internet », tandis qu’OverTheBox s’en charge dans l’autre sens : Internet vers l’utilisateur. Grâce à la partie du dispositif hébergée par OVH, l’utilisateur bénéficie d’une adresse IP publique unique, géolocalisée* et de confiance (IP de FAI) pour sortir sur Internet (4). Ce dispositif permet également aux utilisateurs d’OverTheBox de bénéficier de la protection anti-DDoS développée par OVH, le trafic illégitime étant mitigé par le VAC (5) le cas échéant.
Lorsque ce système a été testé pour la première fois par l’équipe, en laboratoire puis au domicile de plusieurs personnes, il a semblé tout à fait fonctionnel. « OverTheBox permettait de bénéficier de débits montants et descendants cumulés jusqu’à 95 % de la somme des débits offerts par les différentes connexions. Un excellent ratio ! Mais, lorsque nous avons étendu les tests à d’autres collaborateurs, des problèmes sont apparus : l’un d’entre eux rassemblait, grâce à OverTheBox, trois connexions ADSL de 5 Mbps chacune environ, et constatait un débit extrêmement instable, oscillant. Nous nous sommes aperçus que le débit baissait fortement lorsque la bande passante était saturée – une situation que nous n’avions pas provoquée avec un usage classique lors des tests en laboratoire agrégeant des connexions à très haut débit. Nos investigations ont mis à jour qu’en faisant passer une session TCP (gérée par MPTCP) à l’intérieur d’un tunnel TCP (Internet), le mécanisme natif de contrôle de congestion du protocole TCP des deux sessions simultanées dysfonctionne. » En cas de congestion, le mécanisme de la première session télescope celui de la seconde session au sein de laquelle il est encapsulé. Incapables de coopérer, les mécanismes se rendent aveugles l’un l’autre et dégradent la qualité. Un vrai problème, étant donné l’importance du protocole TCP dans les échanges sur Internet (http, mails, etc.).
Il a donc fallu réfléchir à une alternative, en l’occurrence le recours à un proxy : « Au lieu d’encapsuler une session TCP dans une autre (TCP over TCP), nous modifions la session originale grâce à un proxy socks (shadowsocks). » En revanche, l’encapsulation fonctionnant parfaitement pour les autres protocoles tels qu’UDP (utilisé pour la téléphonie sur IP, les visioconférences, les serveurs de jeu, etc.) ou ICMP, celle-ci a été maintenue pour les paquets non TCP. Ce faisant, il était difficile de réfléchir à la QoS comme on le fait d’ordinaire : « Nous avons été pragmatiques : que recouvre bien souvent la demande de QoS chez les utilisateurs ? Dans 99 % des cas, il s’agit de pouvoir prioriser le trafic lié à la téléphonie, de sorte à ne pas dégrader la qualité des appels VoIP en cas de surcharge sur le réseau. Aussi, nous avons donné une priorité absolue aux paquets UDP… avec un résultat qui est encore à améliorer, car il est nécessaire pour certains utilisateurs disposant d’une faible bande passante et/ou générant un gros volume de communications téléphoniques, de faire une distinction parmi les paquets UDP pour ne prioriser que ceux qui sont réellement liés à la VoIP. Nous y travaillons actuellement. Pour ce qui est de la TV par Internet, le problème n’est pas tant la QoS, mais plutôt le fait de pouvoir forcer les connexions à transiter par le réseau de l’opérateur qui fournit la boxTV. Cela concerne les utilisateurs professionnels dont le bureau est situé au sein de leur domicile, et ils ont maintenant la possibilité de spécifier à OverTheBox que les connexions d’un équipement du réseau en particulier doivent passer par l’un des liens uniquement. »
L’infrastructure cloud du service OverTheBox, ou la mise en pratique de la politique « Eat your own food »
L’infrastructure, côté OVH, est répartie sur deux sites pour en assurer la haute disponibilité. « Aujourd’hui, il s’agit des datacentres de Gravelines et Strasbourg, mais notre service comptera certainement parmi les premiers clients des nouveaux centres de données qu’OVH projette de déployer à travers le monde en 2016 et dans les années à venir. Le service OverTheBox est sensible à la latence, il nous faudra donc rapprocher au maximum les infrastructures des utilisateurs. Ou, pourquoi pas, laisser le choix aux utilisateurs du pays depuis lequel ils souhaitent sortir sur Internet. »
Pour chaque utilisateur d’OverTheBox, un container Docker est lancé sur une instance Public Cloud. Au sein de ce container, on retrouve les services nécessaires à la réception et à la réagrégation des paquets (les mêmes que ceux qui tournent dans OverTheBox, à l’autre bout du « tunnel »).
« Le choix de Docker s’est imposé pour sa simplicité de mise en œuvre, et la vitesse avec laquelle on peut redémarrer un container sur le site secondaire en cas de problème sur la machine qui l’héberge. » Chaque container dispose de sa propre adresse IP, qui est basculée sur une machine du site secondaire le cas échéant, grâce à l’API OVH. « Nous nous sommes mis dans la peau d’un client d’OVH, et nous utilisons nos infrastructures comme il pourrait le faire. Cela nous permet de faire progresser les services, en apportant un feedback à nos collègues en charge de Public Cloud par exemple. »
Plus de 50 versions du soft entre la présentation d’OverTheBox au Summit et sa commercialisation
Depuis le lancement du projet, l’équipe avait une échéance en tête : le 24 septembre 2015, date du troisième Summit d’OVH aux Docks de Paris. L’objectif était de profiter de cet événement pour lancer en avant-première le service, et recruter des bêta-testeurs pour la phase de test ouverte au public. Avec pas loin de 300 OverTheBox distribuées le jour J, et presque autant de bêta-testeurs actifs, remontant leur feedback régulièrement, l’opération fut un succès. Et a permis de faire progresser le service d’une manière très rapide : « Entre le Summit et la commercialisation d’OverTheBox, trois mois se sont écoulés. Nous avons corrigé des bugs, amélioré l’interface et constaté avec surprise qu’OverTheBox se prêtait à des usages auxquels nous n’avions pas pensé : par exemple agréger une connexion partagée par un smartphone. »
Le service tel qu’il est commercialisé aujourd’hui va encore beaucoup évoluer. « Nous avons livré les briques essentielles, et nous avons bien entendu des éléments dans la roadmap tels que la compatibilité avec l’IP v6, la surveillance des backdoors internes chez le client, la possibilité d’accéder à un vRack depuis OverTheBox ou de réaliser ses backups sur hubiC, aux moments où le réseau est le moins utilisé… Une autre partie de la roadmap est encore vierge aujourd’hui, et se remplira des fonctionnalités proposées par les utilisateurs, suggérées par les partenaires et revendeurs. » Enfin, l’équipe espère aussi que les fabricants de modems-routeurs s’empareront du service et l’installeront sur leur matériel pour le faire découvrir à leurs clients.
Notes :
(1) Le protocole MPTCP supporte théoriquement l’agrégation jusqu’à 8 liens (tests en laboratoire), mais OverTheBox ne garantit aujourd’hui la stabilité de la connexion sur l’agrégation de 4 liens maximum.
(2) Commercial usage of Multipath TCP , publié sur http://blog.multipath-tcp.org
(3) Les pré-requis recommandés sont : 1 Go de RAM + le chiffrement AES hardware.
(4) Aujourd’hui, seules des IP FR sont disponibles, mais la géolocalisation des IP au sein d’autres pays européens est prévue dans la roadmap.
(5) En savoir plus sur la protection anti-DDoS mise en place par OVH
