L’inconvénient des routeurs Dual/Multi WAN est de présenter plusieurs adresses publiques. Cela peut poser des problèmes d’identification sur certains schémas d’authentification en mode client mais également un casse-tête pour les connections entrantes. Pour y remédier tout le monde (dans notre monde…) a entendu parler de la solution OTB proposée par OVH, qui n’est jamais que l’intégration de technologies existantes mais qui permet de travailler avec une IP publique unique. Depuis la mise en production commerciale le projet semble assez stable, il ne bouge plus trop, par contre les tarifs ont explosés.

Il existe une alternative, openMPTCProuter qui s’appuie sur les mêmes technologies mais en version open et va permettre l’agrégation de 8 liens (xDSL, fibre et 4G) tout en utilisant une seule IP, celle du serveur VPS sur lequel elle s’appuie. Il faut bien comprendre que pour utiliser cette solution vous aurez besoin d’un serveur VPS pour supporter le serveur de relai et votre nouvelle IP publique. Il existe des VPS à partir de quelques euros (OVH, Online), ce qui sera important ici c’est d’une part la latence, il faut donc un VPS proche, et d’autre part que la bande passante du VPS soit supérieure à la bande passante agrégée, tout du moins si vous cherchez à atteindre un débit supérieur. Mais cette tecno peut aussi être déployée dans le but de sécuriser un site, auquel cas le débit importe moins…

Déploiement

On va commencer à installer le serveur sur un VPS ou une VM Linux disposant d’une IP publique, je ne vais pas recopier, tout se trouve ici. Attention à bien respecter les versions minimales des distributions.

Ensuite on passe du côté du routeur. J’ai bêtement beaucoup galéré en voulant installer le routeur dans une VM ESXi, il semblerait que cette image comporte quelques bugs non résolus.(voir plus bas). Le plus simple pour tester est donc de le faire sur un Raspbery, dans mon cas un PI3, j’ai gravé l’image que l’on trouve ici avec Etcher et configuré en me laissant guider avec les infos du VPS, le tout en 10 minutes avec un résultat parfait. Attention toutefois à penser de désactiver le DHCP des box pour ne laisser actif que celui du routeur MPTCP.

En mode production la question du DHCP pourra se poser si l’on dispose déjà d’un DHCP sur un serveur ou un NAS, mais on peut aussi envisager plusieurs modes de fonctionnement, dont un qui consisterait à faire fonctionner le routeur MPTCT en mode bridge et le coller sur le port WAN du routeur existant sur le site. Ainsi on ne perdrait pas les bénéfices de son routeur préféré, un USG dans mon cas, tout en m’affranchissant des contraintes du Dual WAN.

On notera que cette solution fonctionne dans les deux sens, il sera ainsi possible d’utiliser la nouvelle IP publique pour publier des services et ainsi résoudre la problématique de ceux qui ne disposent pas d’une IP fixe.

Pour l’instant openMPTCProuter n’est qu’une succession de betas, la mise en production semble donc hasardeuse. La solution semble stable, les débits en download sont très bons par contre l’upload reste en retrait. Des tests plus approfondis s’imposent et la mise en commun des expériences de tous est bienvenue ! 

Remarques et astuces

ESXi : Pour que le routeur (coté client) puisse fonctionner sur ESXi, il faut simplement accepter le mode Promiscuous dans les options de sécurité du vSwitch0 dans la configuration réseau du serveur ESXi. Par contre rien de spécial à faire si le VPS est sur un serveur ESXi. Coté VPS sur ESXi, il est possible d'installer les VM-Ware tools.

DHCP : Il est tout à fait possible de désactiver le serveur DHCP sur le LAN du routeur openMPTCP si on a déjà un tel serveur (AD ou Synology par exemple).

DNS : Si on veut bénéficier des dérogation pour certains protocoles (Netflix...), il faut que les clients utilisent le DNS d'openMPTCP (quitte à chaîner celui d'AD au dessus).

IPV6 : Si pas d'IPV6 sur le VPS ou IPV6 mal configuré il vaut mieux désactiver, surtout pour les premiers tests.

Performances : Sur un Raspberry 3 qui n'a qu'une interface Ethernet 100 : 85 Mb/s Max. Sur un ESXi j'ai fait 150 Mb/s avec deux lignes vDSL.

Sources

_{https://www.multipath-tcp.org/
https://openwrt.org/
https://github.com/Ysurac/openmptcprouter/wiki
http://blogwifi.fr/openmptcprouter-vs-overthebox/}

Alors que le marché télécom des particuliers jouit d’une concurrence effrénée, qui tourne globalement à l’avantage du consommateur, le marché des professionnels reste lui bien souvent sous la coupe de l’opérateur historique ou de quelques alternatifs qui pratiquent les mêmes méthodes tarifaires.

Exemple vu récemment : 1 ligne analogique pour l’ADSL : 31.29 € + 1 ADSL Pro : 107.00 € + 1 formule fourre-tout pour deux canaux fixe sur RNIS à 142.95 € auquel il fallait ajouter les frais d’un prestataire pour installer et maintenir le PBX local (on parle de factures mensuelles hors taxes).

Quelle est la différence entre la ligne ADSL d’un particulier et celle d’un professionnel dite Pro ? Techniquement aucune. Ah si, une IP fixe chez Orange car ils ne la fournissent pas aux particuliers, et surtout ils imposent des abonnements Pro dont le tarif est au minimum le double pour les professionnels, aux motif d’une GTR. Une garantie souvent illusoire car en cas de panne elle jouera peut être mieux sur un incident local mais pas vraiment pour un incident généralisé ou la pression du grand public est généralement plus importante et forcera l’opérateur à réagir rapidement. Quant aux compensations…

Bref, le budget des télécoms est un budget récurent, un poste important dans une petite structure. Donc soyez malins et surtout fuyez les abonnements tout compris qui n’ont d’autre but que d’enfermer le client dans un package plus difficile à migrer.

Attention toutefois, il n’y a pas de règles toutes faites, en matière de télécoms chaque situation est un cas unique. Je cite des exemples mais il faudra s’adapter à chaque situation particulière (ville, campagne, contraintes, taille de l’entreprise, volumes échangés, sécurité, etc…).

Internet

Pour n’importe quel professionnel Internet est devenu stratégique. Alors que faire ? Croire un opérateur qui va vous dire qu’il est meilleur que l’autre ou organiser sa propre continuité de service ? Personnellement je ne leur fait pas confiance et je préfère m’organiser. La bonne stratégie consiste à mon sens à utiliser deux médias, l’un filaire (Adsl ou fibre, 30 €) et l’autre radio (4G). Sauf quand on n’a pas le choix (pas de 4G) on évitera deux medias filaires car il y a des chances qu’ils partagent des infrastructures communes, ce qui risque de les rendre tous deux inopérants vis-à-vis de de certaines pannes. Quant au secours en 4G il faudra bien sur opter pour l’opérateur qui dispose d’un bon réseau sur le site, Free propose de l’illimité, mais à condition de se trouver à proximité d’un de ses relais. Ce n’est pas très important car on parle de secours, et 20 ou 50 GO seront suffisants dans la majorité des contextes professionnels pour assurer cette fonction. Ce qui compte c’est la qualité de la 4G sur le site, et pour le savoir il n’y a pas d’autre solution que de tester avec 4 abonnements différents avant de choisir.

Une fois ce choix effectué il faudra adapter le matériel et opter pour un routeur Dual WAN. Certains proposent le support natif d’une SIM de secours en 4G alors que d’autres disposent de plusieurs ports WAN sur lesquels on connectera les divers modems (TP-Link, Cisco RV, Unifi, etc… auquel on ajoutera un modem 4G Ethernet, Netgear ou Zyxel par exemple). On peut également opter pour une solution de type MPTCP (OTB d’OVH en version commerciale) ou le but premier est l’agrégation mais qui gère également le secours.

Dans tous les cas l’objectif est double. Faire des économies sur les abonnements et assurer une continuité de service immédiate. Je parle d’immédiateté car la meilleure des GTR imposera toujours le passage par un call center pour signaler l’incident et un temps de réaction. Donc du temps de perdu qui peut rapidement couter très cher à un professionnel.

La téléphonie

Pendant longtemps France Télécom a déployé du RNIS chez les professionnels en louant des lignes et des PBX. L’arrivée d’une timide concurrence n’a pas changé grand-chose, l’objectif premier des opérateurs étant avant tout d’assurer leurs marges. On ne va pas le leur reprocher, c’est le principe de l’économie de marché, il faut juste être plus malin.

Si le téléphone fixe d’un pro a longtemps été stratégique, cela s’est un peu atténué à l’heure où tous les collaborateurs disposent d’un mobile.

La solution pour un professionnel, et surtout pour un petit professionnel, est de s’affranchir de cette artillerie lourde d’un autre âge et d’opter pour de la téléphonie IP ou l’infrastructure est hébergé par le fournisseur. On trouve sur le marché plusieurs offres, je prendrais ici l’exemple de l’offre d’OVH ou l’on peut facilement remplacer un PBX et sa ligne RNIS par une offre à 5 à 15 € / mois pour deux communications simultanées sur 6 postes DECT (Gigaset N510IP) et une importante valeur ajoutée en terme de services inclus. Pour une installation plus conséquente, il est également possible de déployer de postes d’entreprises et un standard. Un poste téléphonique IP n’est pas lié à un lieu, ainsi le télétravailleur pourra disposer d’un poste d’entreprise à son domicile en toute transparence.

La téléphonie sur IP fonctionne via le réseau Internet qui sera sécurisé grâce au Dual WAN. Quant à savoir si ces solutions sont mures, la réponse est oui, pour preuve, Orange a récemment décidé de ne plus installer de lignes classiques mais uniquement de la VOIP.

Vos idées et vos expériences sont bien sur les bienvenues !

L’USG d'Ubiquiti est un routeur qui offre de nombreuses possibilités. De versions en versions il se bonifie, mais il reste encore pas mal de choses à faire à la main. Si le Dual WAN en sortie répartit bien la charge entre les deux ports ou utilise le second en secours, il reste encore des choses simples, qui se font par l’interface de gestion sur la plupart des routeurs, mais qui nécessiteront ici de se plonger dans Linux comme on le ferait sur un vieux gros Cisco… Tant qu’à se plonger dans le CLI, il serait peut-être temps d’en finir avec les techniques de Dual WAN et de s’orienter vers des implémentations libres de MPTCP (et je ne parle pas de l’OTB d’OVH qui s’avère au final une solution commerciale coûteuse, bugs compris !). De par son architecture il y a d’ailleurs plus de chances que cette technologie intéresse d’autres opérateurs que des constructeurs.

Mais revenons à l’USG. Les développeurs avancent mais il reste pas mal de choses qui ne sont pas implémentées dans leur magnifique interface. C’est le cas par exemple si l’on veut qu’un trafic spécifique (ports, ip, source, destination) passe par une liaison spécifique, comme par exemple forcer le flux TV vers le port WAN sur lequel est installée la ligne Free, alors qu’au premier abord on aurait pu penser qu’une simple route statique dans cette magnifique interface de gestion aurait suffit, et bien non :

configure
set protocols static table 5 route 0.0.0.0/0 next-hop WANx_IP_Gateway
set firewall modify LOAD_BALANCE rule 2500 action modify
set firewall modify LOAD_BALANCE rule 2500 modify table 5
set firewall modify LOAD_BALANCE rule 2500 destination address 212.27.38.0/24
set firewall modify LOAD_BALANCE rule 2500 protocol all
commit;exit

Un autre "piège" se situe au niveau de port forwarding. Dans l’interface on configure cela facilement et ça crée automatiquement les règles de firewall associés. Normal, sauf qu’à l’utilisation on s’aperçoit que ça ne fonctionne que pour le WAN1. Et c’est repartit pour un peu de SSH… Attention toutefois, l’interface WAN2 peut aussi être PPPOE1 selon votre connexion…

configure
set service nat rule 4000 description "WAN2 tcp 80"
set service nat rule 4000 destination address WAN2_IP
set service nat rule 4000 destination port 80
set service nat rule 4000 inbound-interface pppoe1
set service nat rule 4000 inside-address address 192.168.210.18
set service nat rule 4000 inside-address port 80
set service nat rule 4000 protocol tcp
set service nat rule 4000 type destination
commit;exit

Pensez aussi à noter les règles ainsi crées (on peut aussi les retrouver avec un show service nat et les effacer avec un delete service nat rule RULE_NUMBER). Il va falloir rendre cette configuration pérenne au reboot grâce à un fichier config.gateway.json, le sujet a été largement abordé dans la communauté Unifi et ailleurs (voir les liens ci-dessous).

Il me reste à explorer le comportement des liens VPN IPSEC en cas de passage en mode secours sur le WAN2, mais ça sera pour une autre fois, à moins que vous ayez des idées et astuces, elles sont bienvenues dans les commentaires !

Sources

_{https://help.ubnt.com/hc/en-us/articles/235723207-UniFi-USG-Port-Forwarding-Configuration-and-Troubleshooting
https://help.ubnt.com/hc/en-us/articles/215458888-UniFi-How-to-further-customize-USG-configuration-with-config-gateway-json
https://help.ubnt.com/hc/en-us/articles/360005460813-UniFi-USG-Advanced-Policy-Based-Routing
https://help.ubnt.com/hc/en-us/articles/360002668854-UniFi-Verifying-and-Troubleshooting-IPsec-VPN-on-USG}

Tous les possesseurs de Freebox 4K le savent, ce n’est pas le pied ! Avec sa télécommande indomptable, ses bugs audio à répétitions. Même avec la dernière mise à jour, cette box TV ne cesse d’être capricieuse. Mais il parait que c’est bien mieux que la box Android TV de son conçurent BT. Bref, même les box génériques chinoises font mieux, mais je ne conseillerais pas ces produits pour qui veut un bon player Android TV.

En fait à mon sens il y a deux produits qui tiennent la route sous Android TV. La Nvidia Shield est la reine ou même la v1 est toujours excellente et mise à jour régulièrement, l’outsider étant la Mi Box 3 de Xiaomi en attendant le v4 annoncée il y a un mois avec des améliorations qui semblent cosmétiques. Il y a deux alternatives viables, un ChromeCast ou un Apple TV pour ceux qui ne se sentent bien qu’avec les produits d’Apple, mais ce n’est pas le propos ici.

Pour revenir à Android TV, et si l’on ne dispose pas d’un HD HomeRun ou l’intégration est parfaite, il va se poser le problème de l’intégration des chaines TV de son opérateur en IPTV à partir du fichier .M3U fournit par les FAI. Si l’on exclut certaines applications douteuses, il existe une solution qui permet une intégration parfaite : TVIrl. TVIrl est une application Android TV qui va permettre d’utiliser la playlist fournie par le FAI ainsi qu’un lien vers une source EPG. Le soucis c’est que si les FAI fournissent bien le fichier de leurs chaines en IPTV, il n’en est rien pour l’EPG et les logos.

Internet fourmille de fournisseurs d’EPG dans différents formats, notamment XMLTV ou même des acteurs comme Télérama s’y sont mis, ou encore ça, internet est vote ami). Mais la vraie question sera d’agréger ces informations avec les chaines dans la bonne numérotation avec leur EPG et leurs logos. Si la première solution, notamment pour comprendre est Notepad, on atteindra rapidement ses limites en matière de patience. Il existe des logiciels plus ou moins bugées et des sites. Pour ma part j’ai testé avec X.Tream qui a l’inconvénient d’être payant mais l’avantage de fournir un résultat impeccable et durable. On peut tester avec un trial de 7 jours et ensuite partager les frais à plusieurs.

Le principe est simple, on insère son fichier .m3u, ici freebox.m3u et ensuite on va faire le tri dans les chaines afin d’écarter celles qui ne nous intéressent pas, les versions SD ou certaines chaines étrangères par exemple. On les trie dans l’ordre souhaité pour finir dans le section EPG afin de faire coller une source EPG à chacune des chaines retenues (il y a un doc ici qui décrit le processus. Le menu Picons servira à associer les logos de façon automatique.

Dans la section downloads de X.Tream Editor on obtiendra deux url, la première sera la playlist formatée et la seconde l’EPG. Il va falloir coller ces deux url dans TVIrl sous Android TV. Sachant que TeamViewer ne fonctionne pas très bien sous Android TV, le plus simple sera de se servir de la télécommande Android pour faire un copié / collé. Une fois l’opération terminée on va dans les options de Chaines en direct pour sélectionner les canaux souhaités. L’avantage de cette solution c’est qu’elle est pérenne. A tout moment on peut aller dans X.Tream Editor et y faire des modifications qui seront répercutées dans les Chaines en direct d’Android TV via TVIrl.

Unifi et dual WAN

Il reste un cas particulier qui n’a rien à voir avec ce que j’exposais précédemment. Si on utilise un routeur dual WAN avec deux FAI (ADSL, fibre et 4G) il va falloir indiquer au routeur par ou doit passer le ou les flux TV. En effet le flux Free ne sera accessible que via la ligne Free tout comme le flux Orange devra passer par la ligne Orange. Si sur certains routeurs le réglage est accessible dans l’interface de configuration il n’en est bizarrement rien pour l’USG d’Unifi ou il va falloir y aller en dur via SSH :

configure
set protocols static table 5 route 0.0.0.0/0 next-hop 1.2.3.4
set firewall modify LOAD_BALANCE rule 2500 action modify
set firewall modify LOAD_BALANCE rule 2500 modify table 5
set firewall modify LOAD_BALANCE rule 2500 destination address 212.27.38.0/24
set firewall modify LOAD_BALANCE rule 2500 protocol all
commit;exit

Ou 1.2.3.4 est l’ip de la passerelle de la ligne Freebox que l’on peut retrouver avec un show ip route. Il va falloir rendre cette configuration pérenne au reboot grace à un fichier config.gateway.json, le sujet a été largement abordé dans la communauté Unifi et ailleurs (voir les liens ci dessous).

Si vous avez d'autres idées et astuces, elles sont bienvenues dans les commentaires !

Sources

_{https://help.ubnt.com/hc/en-us/articles/360005460813-UniFi-USG-Advanced-Policy-Based-Routing 
https://help.ubnt.com/hc/en-us/articles/215458888 
https://matthijs.hoekstraonline.net/2017/10/29/configuring-source-address-based-routing-on-my-unifi-usg/ 
https://www.reddit.com/r/AndroidTV/comments/6oo99t/guide_to_setting_up_live_channels_for_android_tv/ 
https://www.reddit.com/r/IPTV/comments/83keyw/tvirl_or_alternatives_android_tv_love_channels_w/}

Pour sécuriser un site en SSL il y a plusieurs façons de faire, comme je l’avais expliqué ici. Si on passe outre les modèles payants, Let’s Encrypt qui impose l’ouverture du port 80 pour son renouvellement, il nous reste la passerelle OVH qui ne permet pas facilement une sécurisation de bout en bout. On va voir aujourd’hui comment utiliser l'alternative Cloudflare pour sécuriser de bout en bout en utilisant le certificat qu’ils fournissent gratuitement et qui ont la bonne idée d’avoir une durée de vie très longue (auto-renouvellement pendant 15 ans). Ce tuto est fait pour Jeedom sur Debian, mais on peut tout à fait utiliser cette technique sur un autre serveur, IIS sur Windows par exemple.

L’utilisation de Cloudflare sous-entend que le DNS du domaine soit géré par le Cloudflare. Ça peut paraître gênant mais au final c’est pas mal du tout car leurs DNS sont pratique et des plus rapides, notamment en réplication. Quand on va créer un domaine sur Cloudflare, celui-ci va aspirer notre ancienne configuration DNS et en créer une copie. Il n’y aura plus ensuite qu’à se laisser guider pour changer les serveurs de nom sur son registrar (Gandi, OVH, etc…), ce qui peut prendre un peu de temps avant d’être activé.

Une fois le domaine géré par Cloudflare il y a deux onglets qui nous intéressent ici, DNS et Crypto (allez fouiller car il y a plein d’autres choses intéressantes à explorer).

Sur DNS on va créer un enregistrement A (et AAAA si on veut être compatible IPV6) qui va pointer sur l’IP publique de notre serveur (ou un CName vers un DynDNS, je n’ai pas testé mais ça peut marcher, auquel cas ça deviendrait intéressant pour ceux qui n’ont pas d’IP fixe).

Ensuite on passe sur Crypto et on va créer un certificat que l’on prendra soin de récupérer (attention à bien stocker également la clé privée en .key). Voilà, pas besoin de CSR, le certificat est un willcard, ce qu’il veut dire qu’il pourra être utilisé pour d’autres sous-domaines (jeddom.domaine.tld, cam.domaine.tld …). C’est possible car son usage est conditionné par le transit via Cloudflare qui joue un rôle de reverse proxy. Donc ce certificat n’est pas utilisable (quoique...) sans Cloudflare et il ne sert qu’à sécuriser le flux entre Cloudflare et votre serveur.

Il suffira alors d’installer le certificat, facile sous IIS après une conversion en PFX, là c’est mon monde et j’ai l’habitude. Sous Jeedom, donc le couple Linux et Apache, j’ai un peu plus tâtonné car je ne suis pas dans mon domaine de compétence, mais Google est mon ami et j’ai fini par trouver en compilant plusieurs sources.

Activer SSL et installer le certificat sur le serveur Jeedom

Il va falloir se connecter en « root » sur le serveur Jeedom. Pour y parvenir il faut commencer par autoriser le SSH sur le user « root ». J’utilise BitWise SSH Client, mais on trouve d’autres alternatives et ce n’est pas très important. 

• Login en SSH avec l’utilisateur « pi » + le mot de passe « raspberry » que vous avez j’espère changé au début de l’installation..
• Edition du fichier de configuration avec la commande « sudo nano /etc/ssh/sshd_config.
• Ici on change la ligne #PermitRootLogin without-password (ou un autre attribut) en en PermitRootLogin yes.
• On ferme (ctrl + X) et on sauvegarde (Y) + validation.
• Enfin on active avec sudo /etc/init.d/ssh restart.

On en profite pour changer le mot de passe « root » avec sudo passwd root (idem pour le user « pi » si on ne l’a pas fait).

On se déconnecte et on se reconnecte avec le user « root ».

A l’aide du gestionnaire de fichiers on va copier le certificat et sa clé privée quelque part (dans /etc/apache2 pour cet exemple).

Ensuite on va aller ajouter un serveur virtuel et dire à apache ou sont les certificats en ajoutant une section <VirualHost * :443> dans le fichier /etc/apache2/sites-enabled.conf (possible également depuis le gestionnaire de fichiers si on n'est pas fan de Nano).

<VirtualHost *:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog /var/www/html/log/http.error
SSLEngine      on
SSLCertificateFile        /etc/apache2/domain.tld.pem
SSLCertificateKeyFile     /etc/apache2/domain.tld.key
</VirtualHost>

On sauvegarde et on active le SSL avec un sudo a2enmod ssl. On peut aussi faire un apachectl configtest. En l’état ça ne doit nous retourner que l’erreur AH00558, ce qui veut juste dire qu’on n’a pas renseigné le bon hostname et qu’on l’attaque en local. Pas important dans notre usage.

On relance Apache avec systemctl reload apache2.

On se connecte pour tester depuis le PC avec « https://ip-du-pi » et on by-pass l’erreur qui est normale car un certificat est toujours lié à un domaine et non une iP. A ce stade on va renseigner nos infos dans Jeedom sur l’onglet « réseaux ». Mais là ça ne sert que d’information à Jeedom, par exemple pour appliquer la bonne config au client mobile.

Sur le routeur, le firewall ou là box on crée une règle qui va accepter une connexion externe sur le port 2053 et la renvoyer sur le port 443 de l’ip du Pi. Pourquoi 2053, simplement parce que Cloudflare n’accepte pas toutes les ports et qu’on va éviter d’utiliser le 443 (mais c’est possible).

Maintenant on va tester depuis l’extérieur (un mobile en 4G par exemple) et vérifier que la connexion est bien SSL de bout en bout.

That’s all folks !

Utiliser un certificat Cloudflare en local

Peut-on utiliser les certificats Cloudflare en dehors de leur DNS ? Par exemple pour l’installer sur des équipements locaux qui ne sont accessibles qu’en HTTPS (routeurs par exemple) et ne plus avoir les erreurs de sécurité des navigateurs. En fait la réponse est oui, mais il va falloir tricher un peu.

D’abord le certificat est lié au domaine, donc il ne fait plus appeler l’équipement par son IP mais par une url https://routeur.mondomain.tld . Pour y parvenir il faudra soit avoir un DNS interne et tricher en donnant à Cloudflare un CNAME local monrouteur.domain.local mais c’est contraignant), soit tricher avec le fichier HOSTS (et là je vous conseille cette petite merveille, Hostmanager), c’est parfait car en général cette utilisation ne concernera qu’une seule machine qui sert à l’administration.

Ensuite il faudra aussi truster le certificat RSA de Cloudflare que l’on trouvera ici. Sous Windows, par exemple, il faut le convertir en PKCS#7 (on peu aussi le faire en local avec OpenSSL) avant de l’importer dans les autorités trustées (On peut utiliser MMC + certificats, ou l'outil Digicert, ou encore Keystore Explorer qui fonctionne sur toutes les plateformes..

Et le tour est joué !

Sources :

La qualité du WI-FI revient souvent sur la table et on me demande souvent ce qu’il faut changer pour améliorer la situation. 

Un WI-FI de qualité devient la base de toute installation. Pour les équipements mobiles (smartphone, tablettes, laptops), multimédia (Apple TV, Android TV) mais également les objets connectés ou certains utilisent le WI-FI. D’aucuns parlent de routeurs de plus en plus puissants et évolués, mais il ne faut pas perdre de vue que le routeur (ou la box) n’est généralement pas placé au meilleur endroit pour assurer une couverture optimale des lieux, simplement parce que la ligne n’arrive généralement pas au bon endroit. Bref, la box au fond du garage ne couvre pas toute la maison, et si je la remplace par un routeur avec douze antennes mais toujours au fond du garage ça ne changera pas grand-chose. C’est pourquoi je dénigre généralement cette approche. 

Voyons les options possibles

• Pour les petites surfaces et un usage modéré, généralement les dernières générations des box proposées par les fournisseurs suffisent. Les Freebox Révolution et 4K dont l’électronique est similaire assurent toutes les fonctions utiles. Si les autres box sont un peu moins geek, elles font pour autant ce qu’on attend d’elles.
• Si on est un peu geek un bon routeur WIFI bien placé peut être une alternative intéressante, dans ce cas on passe la box en mode bridge (on perd souvent la TV, mais pas toujours). On peut aussi envisager un modem / routeur. Dans tous les cas cette solution sera équivalente à la box des FAI avec plus ou moins de fonctionnalités et parfois des régressions (TV, téléphone).
• Une solution professionnelle du genre routeur / firewall et des bornes WI-FI indépendantes. C’est une configuration de type entreprise que j’ai déployée dans mon home lab. Ca nécessite quelques connaissances de base, mais c’est illimité en termes de possibilités. Après avoir longtemps travaillé avec des routeurs de la gamme RV de Cisco j’ai basculé vers de l’Unifi avec un USG à la place du routeur et des bornes WI-FI de la même marque. L’USG gère deux accès ADSL en mode répartition de charge ce qui assure également une tolérance aux pannes et j’envisage une option 4G. La Freebox et le modem du second opérateur sont en mode bridge. Si j’avais de la fibre je pourrais me passer du modem en connectant directement le port WAN sur l’ONT. Et pour revenir au WI-FI, si une seule borne AC Pro placée au centre de la maison assure une bonne couverture, je pourrais en chainer plusieurs, ce que l’on fait aisément sur de plus grandes surfaces.
• Enfin, les solutions de maillage pour le grand public avec plusieurs bornes WI-FI. C’est la solution à la mode proposée par plusieurs constructeurs dans des packs avec généralement 3 bornes. Personnellement je conseillerais Google WI-FI ou Amplifi d’Unifi qui se configurent en quelques minutes avec un simple smartphone. Mais les Netgear & co ont aussi les leurs. Dans ce cas on ne fait qu’étendre le WI-FI sans toucher au routage. On désactivera donc la fonction WI-FI de la box ou du routeur pour configurer à la place la solution maillée. Si on avait déjà un SSID personnalisé, autant reprendre la même configuration et mot de passe afin de ne pas avoir à ré authentifier tous les équipements. On peut également en profiter pour créer un réseau pour les invités qui n’auront accès qu’a Internet et non aux équipements locaux.

Le réglage des canaux

Dans un contexte saturé on évitera les canaux encombrés. Les équipements disposent généralement de réglages automatiques mais on pourra affiner avec une application sur smartphone qui permettra de visualiser la situation avec les équipements des voisins sur lesquels on ne pourra pas agir. Dans une maison isolée il peut y avoir d’autres équipements à contourner qui ont leur propre WI-FI direct (TV, imprimantes) ou des réseaux cachés comme celui de Sonos. Pour améliorer le débit on choisir une largeur de bande de 40 Mhz pour peu qu’il y ait de la place… 

Les normes

Ces normes sont définies par l’IEEE. Actuellement on parle de 802.11n et 802.11ac. Pour faire simple la plus répandue est le 802.11n ou les appareils assurent également la compatibilité b et g. Le 802.11ac travaille sur des fréquences plus hautes, sa portée est moindre mais son débit est plus important. Le minimum à ce jour est de disposer de 802.11bgn et un nouvel investissement devra inclure le 802.11ac. Le 802.11ax arrive mais il n’y a pas d’urgence car peu d’équipements terminaux sont disponibles. Enfin, le marketing s’empare de la chose et pour plus de clarté ces normes vont être renommées WI-FI 1 2 3 4 5… Pour comprendre tout ça il y a plein d’articles sur la toile, comme ici par exemple.

Enfin, n’oubliez jamais que le WI-FI ne remplacera jamais le câble Ethernet. D’ailleurs pour brancher des bornes aux bons endroits il faut du câble. Donc dans une construction ou un contexte de rénovation il ne faut pas hésiter à passer des câbles dans tous les sens et les ramener vers un point central (câblage en étoile). Ne pas perdre de vue que l’endroit idéal pour poser un point d’accès se situe généralement en hauteur, un peu comme un détecteur de fumée dont la forme est souvent reprise.

Le passage en SSL d’un serveur peut être une opération fastidieuse si on ne connait pas le système cible ou qu’il n’est pas aisé d’y mettre les doigts. Ou simplement si le système ne le supporte pas HTTPS. De plus les certificats sont souvent onéreux et ils nécessitent un renouvèlement régulier. On va voir ici comment sécuriser un site ou un équipement disposant d’une interface web en utilisant la passerelle SSL d’OVH qui est gratuite pour un usage personnel ou d’association.

La première chose à faire est de disposer d’un compte OVH. C’est gratuit aussi et si on vous demande un moyen de de paiement rien ne sera débité pour ce service. Une fois que le compte OVH est validé on se connecte sur l’interface client et on cherche Sunrise et SSL Gateway :

Ensuite on valide le bon de commande à 0 € comme s’il s’agissait d’une transaction payante et on attend le mail de confirmation (on peut consulter l’état d’avancement de la commande dans le compte OVH sur le menu Facturation). Une fois la confirmation reçue il va falloir reconfigurer l'entrée DNS correspondant au sous-domaine. Attention, tout au long de ce processus il faut être patient car la passerelle va communiquer avec le DNS et le DNS met généralement un peu de temps à se répliquer…

On va donc commencer par rediriger le sous-domaine vers la passerelle en modifiant l’enregistrement A (et AAAA si on veut de l’PV6) sur le DNS. Cela permettra de valider l’utilisation du domaine qui ici n’est pas enregistré chez OVH mais chez Gandi. C’est expliqué dans le second mail reçu avec les adresses IP.

il ne reste plus qu’à retourner sur l’interface de gestion de la passerelle et on clique sur l’entrée idoine. On attend que le DNS se réplique et on en profite pour configurer le service. L'option qui nous intéresse est bien sur la redirection HTTPS (seules certains options sont disponibles en version gratuite, mais c’est suffisant).

Une fois que toutes les vérifications sont faites par la passerelle, le service est configuré on doit se retrouver avec quelque chose qui ressemble à ça. L’IPV6 est en rouge car je n’ai pas ajouté les enregistrements AAAA. A ce stade si l’IP du serveur cible est bien configurée dans l’onglet Serveurs, le service est fonctionnel. A noter que l’onglet Taches permet de suivre les différentes étapes alors que l’onglet Graphique fournira quelques statistiques.

Attention, le serveur cible est toujours configuré en HTTP et reste accessible sans SSL via son IP. Si l’on souhaite verrouiller cet usage il suffira de le configurer afin qu’il n’accepte que les IP de sorties de la passerelle (à ce jour les réseaux 213.32.4.0/24 et 144.217.9.0/24).

Si le serveur n’est pas directement exposé mais installé derrière un firewall, un routeur ou une box, il conviendra bien sûr de faire une redirection de ports et le cas échéant d’ouvrir ces ports sur le firewall, mais là on est déjà hors sujet…

Pérennité : OVH fait partie de sponsors de Let’s Encrypt, autorité de certification sur laquelle s’appuie ce service. Au risque de me tromper, je pense que la version gratuite de ce service fait partie de leur engagement. Si ce service devait cesser ou devenir payant, cela ne se fera pas du jour au lendemain et il sera bien temps de chercher une alternative.

Au-delà des sites qu’il faut absolument protéger dès lors qu’il y a des transactions, bientôt les sites non SSL seront tous pointés du doigt.

Pour passer un site en SSL il y a plusieurs options plus ou moins complexes. Si le site est protégé par un firewall il faudra généralement exporter le certificat vers celui-ci ou simplement l’installer sur le firewall si l’on considère que le trafic entre le firewall / reverse proxy et le serveur n’a pas à être protégé.

On trouve des certificats plus ou moins couteux selon les garanties offertes, mais pour protéger un simple site un certificat à une dizaine d’euros sera suffisant car il s’agit de sécuriser la transaction et non de valider l’origine du site. (GoGetSSL par exemple ou même Gandi)

Let's Encrypt est une solution gratuite avec ses limitations et contraintes. Les certificats sont ici valables que 3 mois et les maintenir à jour est fastidieux. En gros c'est parfait s'il s'agit d'un Synology, par exemple, ou la gestion du renouvèlement est intégrée (elle impose tout de même l'ouverture du port 80), mais moins pratique sur certains serveurs ou équipements s’il faut faire les mises à jours manuellement. Sur IIS (et ailleurs) des solutions permettent cette automatisation, comme Certify the web ou Lets’Encrypt Win Simple.

Attention, si les versions récentes de IIS supportent plusieurs sites en SSL via SNI, il n’en est pas de même pour des versions plus anciennes.

Enfin, pour les fainéants comme moi il y a SSL Gateway d’OVH. C'est basé sur du Let’s Encrypt et gratuit. En gros OVH fait le boulot et ça permet de passer en SSL n'importe quel site ou équipement. Il n’y a rien à faire sur le serveur à protéger. On redirige l’enregistrement DNS du serveur vers le serveur d'OVH et ensuite sur le serveur protégé on n'accepte que les requêtes en provenance de la passerelle d'OVH. Attention les statistiques peuvent êtres faussées, mais c’est prévu et il y a bien une astuce pour ça. Vous trouvez un pas à pas ici.

La solution d’OVH à ses limites et dans certains cas cette passerelle ne fera pas l’affaire. Le certificat est sur la passerelle et le trafic entre la passerelle et le serveur passe en clair. Ça peut être satisfaisant d’un point de vue sécurité car on aura pris soin de n’accepter que les requêtes de la passerelle OVH, mais le serveur à protéger sera en HTTP et non HTTPS. Dans certains cas l’url vue par le serveur est importante, notamment en .net ou le serveur va retourner http://serveur et non https://serveur et créer des dysfonctionnements avec du code imbriqué qui s’appuie sur cette url, sur ce site par exemple avec Disqus. Alors bien sûr on pourrait aller tripatouiller le code mais ce ne serait qu’une rustine. Pour bien faire il faudrait qu’OVH fournisse un certificat que l’on installerait sur le serveur et ainsi on serait en SSL de bout en bout.

Alors en cherchant un peu on trouve la solution Cloudflare qui va faire la même chose en mieux et pour pas un sous tant qu’il s’agit d’un trafic raisonnable. Cloudflare fourni un certificat que l’on pourra aisément installer sur le serveur à protéger et le cas échéant sur le firewall intermédiaire. Les explications sont ici. Même si on peut le contourner, la solution la plus simple consiste à rediriger ses DNS vers ceux de Cloudflare.

On parle souvent de PF Sense et d’autres firewalls plus ou moins gratuits, moi je vais vous parler de Sophos XG dont la version Home est une version logicielle gratuite qui est parfaite pour un environnement de test ou un home lab. C'est le même logiciel que l'on retrouve sur les appliances du constructeur à ceci près qu'il faudra le faire tourner sur une petite machine ou une VM.

Il offre une protection complète de votre réseau, notamment anti-malware, filtrage Web et sécurité Web, contrôle des applications, IPS, gestion du trafic, VPN, rapports et surveillance, et bien plus encore. Le pare-feu Sophos XG Free Home Use contient son propre système d'exploitation, par conséquent, un ordinateur dédié distinct est nécessaire, qui deviendra une Appliance de sécurité entièrement fonctionnelle. Parfait pour un NUC ou une VM. Si Sophos est utilisable pour protéger les services entrants (mail, web) en direct ou en reverse proxy, il prend en compte très finement le trafic sortant afin de lisser et hiérarchiser le trafic des applications sur votre connexion Internet et même vous abonner à plusieurs FAI pour obtenir davantage de bande passante ou de résilience en cas de panne de l'un d'eux. Il est possible de surveiller et contrôler la navigation web, d'utiliser le filtrage Web pour empêcher les sites de vous infecter de virus et de logiciels espions, empêchez vos enfants de surfer sur des sites malveillants et d'obtenir un rapport complet sur l'activité de votre maison. On peut également configurez des horaires d’accès ou des quotas d’utilisation pour les membres de la famille qui perdent peut-être trop de temps en ligne. C'est également un serveur VPN pour accéder à votre réseau à distance depuis n'importe où dans le monde. Sophos étant également un fournisseur notoire d'antivirus, cette fonctionnalité est intégrée. Les moteurs d'analyse Dual AV bloquent les virus dans les téléchargements de fichiers, les pièces jointes aux e-mails et les sites web malveillants. Sophos les stoppe sur la passerelle avant qu'ils ne puissent attaquer vos ordinateurs. Et bien plus encore ...

Ce dont vous avez besoin,  simplement un ordinateur compatible Intel avec deux interfaces réseau ou une VM. (Tout système d'exploitation précédent ou tous les fichiers présents sur l'ordinateur seront écrasés lors de l'installation de XG Firewall Home Edition.) L'édition familiale et gratuite est limitée à 4 cœurs et à 6 Go de RAM. L'ordinateur peut en avoir plus que cela, mais XG Firewall Home Edition ne pourra pas l'utiliser. Mais c'est déjà largement suffisant dans bien des cas d'exploitation.

Ah si, j'oubliais, dans le cadre d'un usage familial il vaut mieux que l'un des membres de la famille soit un bon geek, car ne nous y trompons pas, Sophos XG est un vrai produit d'entreprise qui ne s'installe pas en un clic...