Surveiller et redémarrer une Freebox à distance

Il existe un bugg (https://dev.freebox.fr/bugs/task/22818) bien gênant sur la Freebox (Révolution et 4K) en mode bridge, toujours pas résolu par Free au fil du temps. Pour faire court, en cas de déconnexion FTTH/xDSL, le routeur qui lui est adossé ne voit plus la box qui joue ici un rôle de modem. Redémarrer le routeur ne sert à rien, c’est la Freebox qu’il faut redémarrer.

Redémarrer une Freebox peut se faire en coupant sauvagement l’alimentation, depuis la face avant avec le petit afficheur (quant il n’est pas HS) ou via Freebox OS (auquel dans ce vas on n’aura pas accès localement). Il existe une autre option avec l’API Freebox OS qui prend tout son sens si l’on supervise la Freebox à distance, dans notre cas avec PRTG Network Monitor installé dans un VPS et qui est gratuit jusqu’à 100 sensors (il existe bien d’autres solutions). PRTG envoie des notifications, mais permet également de lancer des scripts PowerShell, et c’est l’objet de cet article.

Script PowerShell permettant de rebooter une Freebox

Petit didacticiel aussi simple que couper une tomate mûre en tranches avec une sandale...

L'application PS dont ce didacticiel traite s'appelle "Remote Control". Elle permet de rebooter une Freebox depuis un script PowerShell et/ou de récupérer un flux JSON avec les informations temps réel de la Freebox, par exemple pour disposer d'un monitoring depuis une page HTML (il peut être modifié afin d'obtenir d'autres informations disponibles via l'API).

  1. Fichiers accompagnant ce didacticiel

L'archive ZIP dans laquelle se trouve ce didacticiel contient les fichiers suivants :

  • Adresse_Freebox_Locale.ps1 est un script PowerShell qui retourne l'URI de la Freebox installée sur le réseau local. Cet URI est utilisable depuis un navigateur internet situé dans ou hors du réseau local, si elle est autorisée.
  • Autoriser_Remote_Control.ps1 est un script PowerShell à lancer sur un PC du réseau local, attribuant une autorisation à l'application "Remote Control" afin qu'elle puisse contrôler la Freebox locale.
  • Freebox ECC Root CA.cer est l'un des deux certificats requis pour accéder à la Freebox en HTTPS.
  • Freebox Root CA.cer est l'autre certificat.
  • Remote_Control.ps1 est le script PowerShell qui servira à faire rebooter la Freebox ou à récupérer ses informations.
  1. Principe de fonctionnement

La Freebox peut être contrôlée de manière locale ou distante via une API pouvant être appelée en respectant l'architecture REST. Afin d'éviter que des commandes permettent la prise de contrôle d'une box par un tiers malintentionné, un ensemble de sécurités est mis en œuvre :

  1. Attribution d'un droit à prendre le contrôle, requérant une action physique sur la box,
  2. Attribution d'autorisations quant aux actions possibles lors de la prise de contrôle,
  3. Fourniture d'un jeton lors de cette attribution, lequel ne sera jamais transmis lors des appels à l'API, mais remplacé par une donnée cryptée.

L'API de la box peut être appelée en HTTP ou en HTTPS. Cependant la documentation indique que la possibilité d'utiliser HTTP sera retirée dans une version prochaine, et qu'il est fortement conseillé de n'utiliser que HTTPS. Afin de respecter cette consigne, "Remote Control" fonctionne par défaut en HTTPS, même s'il est possible de le faire fonctionner en HTTP moyennant une ou deux modifications du script et pas mal de simplifications dans le processus indiqué ci-dessous.

Afin de pouvoir utiliser "Remote Control" pour dialoguer avec une Freebox locale ou distante, il faut donc réaliser les opérations suivantes :

  1. Installer les certificats nécessaires pour pouvoir causer HTTPS.
  2. Autoriser l'application "Remote Control" sur la Freebox
  3. Installer "Remote Control" sur une machine du réseau local ou sur une machine distante (non testé), et le paramétrer correctement pour qu'il puisse interagir avec la Freebox.

L'installation et l'utilisation de "Remote Control" nécessite l'utilisation d'un PC situé sur le réseau local derrière la Freebox, un opérateur capable d'appuyer sur un bouton de la Freebox, et un PC de contrôle situé sur le réseau local derrière la Freebox ou distant via l'internet.

  1. Installation des certificats

Lorsqu'une connexion HTTPS est réalisée avec la Freebox, cette dernière nécessite un certificat attribué à Freebox ECC Root CA ou Freebox Root CA. Les fichiers correspondants sont fournis dans le zip. Il faut les installer sur le PC qui va permettre d'autoriser l'application "Remote Control" sur le réseau local derrière la Freebox ET sur le PC qui va prendre le contrôle de la Freebox.

Pour les installer, double-cliquer sur les fichiers dans l'explorateur Windows, demander à installer les certificats dans le dépôt des certificats racine. Afin de tester la bonne mise en place des certificats, ouvrez un navigateur internet et entrez dans la zone d'adresse https://mafreebox.freebox.fr, si vous accédez à l'interface de Freebox OS, c'est OK. Conservez le navigateur ouvert, on en aura besoin au point numéro 6 de ce didacticiel.

Si vous avez une page d'erreur ou une indication SEC_ERROR_UNKNOWN_ISSUER, c'est raté. Lancez MMC et le plug-in Certificats, cherchez dans le bazar les deux certificats Freebox, supprimez-les et recommencez tout depuis le début en maudissant l'auteur de ce didacticiel pour son manque de précision.

  1. Autoriser l'application "Remote Control"

Cette opération doit être réalisée depuis un PC situé dans le réseau local derrière la Freebox, selon la documentation du SDK. Il n'est pas possible d'autoriser une application depuis un PC extérieur. Dixit la doc. Il faut aussi avoir sous la main une personne physique capable d'appuyer sur un bouton sur la Freebox.

Double cliquez sur le script PowerShell Autoriser_Remote_Control.ps1 puis suivez les indications à l'écran, vous demandant d'appuyer sur le bouton "Flèche vers la droite" sur la façade de la Freebox alors que cette dernière demande si elle doit autoriser l'application "Remote Control". Appelez la personne physique devant la Freebox et expliquez-lui ce qu'elle doit faire. Une fois le bouton de la Freebox appuyé, le script devrait afficher que l'autorisation a été donnée, accompagné de l'URI de la Freebox et d'un identifiant d'application (de la bouillie en Base64). Copiez-coller l'URI de la Freebox et l'identifiant d'application dans un coin.

Nous n'aurons désormais plus besoin du fichier Autoriser_Remote_Control.ps1. L'autorisation a été donnée à l'application et sauvée dans la Freebox ad vitam aeternam, sauf :

  • Si vous supprimez l'autorisation depuis les paramètres de la Freebox (voir point 6)
  • Si vous faites une réinitialisation usine de la Freebox,
  • En cas d'échange de la Freebox, par exemple si elle venait à tomber en panne,
  • En cas d'erreur non répertoriée dans les documentations,
  • Ou si vous passez chez Bouygues et renvoyez la box chez Free.
  1. Attribuer les droits nécessaires à l'application "Remote Control"

Toujours depuis le PC situé dans le réseau local, reprenez le navigateur internet que vous aviez utilisé pour le point numéro 3, qui doit toujours afficher la page d'accueil de Freebox OS de la Freebox qui vous intéresse. Si vous l'avez bêtement fermé, collez-vous une baffe, puis relancez un navigateur internet et allez sur https://mafreebox.freebox.fr

Identifiez-vous, puis sélectionnez successivement :

  • "Paramètres de la Freebox",
  • "Gestion des accès",
  • "Applications" (en haut de la fenêtre).

Recherchez dans la longue liste des applications autorisées celle que vous venez d'ajouter : "Remote Control (demande)". Cliquer sur le bouton "Editer" à droite et modifiez les autorisations pour activer "Modification des réglages de la Freebox". Vous pouvez d'ailleurs désactiver tout le reste qui a été activé par défaut mais qui n'est pas utile. Évitez de cliquer sur la dernière icône, en forme de poubelle, qui retire l'autorisation de l'application et vous forcerait à tout recommencer depuis l'étape 4 ci-dessus.

  1. Paramétrer le script de contrôle à distance

Nous allons maintenant modifier le contenu du fichier Remote_Control.ps1 pour y insérer les paramètres de fonctionnement correspondant à la Freebox qui nous intéresse. Si vous souhaitez contrôler plusieurs Freebox, vous pouvez bien entendu copier le fichier, renommer sa copie comme vous l'entendez et la modifier. Cette opération doit être réalisée sur le PC local ou distant qui devra prendre le contrôle de la Freebox pour la rebooter. Ce PC devant de plus disposer des certificats racine, installés comme décrit au point 3 de ce didacticiel.

Il faut modifier deux lignes dans le script :

  • Ligne 43, remplacer [Insérer l'URI ici] par l'URI retournée par le script d'autorisation de l'application Autoriser_Remote_Control.ps1, URI que vous avez copié dans le bloc-notes, un email ou taggué en fin du point n°4 de ce didacticiel :

Avant :

$AdresseFreebox = "[Insérer l'URI ici]"

Après (par exemple) :

$AdresseFreebox = "https://vivalasvegas.fbxos.fr:12345"

Faites gaffe avec les guillemets, ils doivent être présents après modification de la ligne.

  • Ligne 46, remplacer [Insérer l'identifiant d'application ici] par le jeton de l'application, noté avec l'URI de la Freebox au point 4 :

Avant :

$JetonAppli = "[Insérer l'identifiant d'application ici]"

Après (par exemple) :

$JetonAppli = "M0nqsaiDup0ul3tMfgtyhbut0risaTi0nTyT0uch3pa5"

Faites gaffe avec les guillemets, comme précédemment. Sauvez le script, fermez l'éditeur, c'est prêt.

  1. Tester l'installation

Ouvrez une ligne de commande PowerShell sur le PC qui doit prendre le contrôle, PC local sur le réseau local ou PC distant (non testé) puis entrez la commande suivante sans oublier le ./ :

./Remote_Control.ps1 –Info

Bien entendu, il faut être dans le dossier contenant le fichier, sinon vous aurez une erreur indiquant que la commande est inconnue, mais bon, je suppose que vous ne vous ferez avoir qu'une seule fois. Si tout va bien, la fenêtre de PowerShell va vous afficher une longue liste d'informations sous la forme d'un flux JSON avec en vrac la température du CPU, la vitesse du ventilo, la durée de fonctionnement depuis le dernier reboot, l'âge du capitaine, toussa-toussa.

Dans la fenêtre PowerShell, entrez maintenant :

./Remote_Control.ps1 –Reboot

Ça devrait vous répondre que la Freebox est en train de rebooter, et là, paf, plus d'internet si vous êtes en local. Tout qui s'allume en rouge dans les superviseurs de tous poils, les utilisateurs du réseau local qui gueulent, le drame quoi.

Patientez quelques minutes puis rafraîchissez la fenêtre de votre navigateur internet qui était toujours en train d'afficher les infos de la box. Vous devrez sûrement retaper le mot de passe. Rendez-vous dans "État de la Freebox" et normalement, si tout va bien, derrière "allumée depuis", il devrait y avoir une valeur en secondes ou en minutes, preuve que votre Freebox a bien redémarré, que le script PowerShell a bien fait son boulot et que l'auteur de ces lignes n'est pas si con que ça.

  1. Conclusion

Il ne vous reste plus qu'à entourer tout ça d'un ruban rose, de mettre en place tout ce qu'il faut pour que ça bosse automatiquement sans vous faire ch... à chaque fois que la Freebox décroche, puis il vous faudra penser à reprendre ce didacticiel pour renuméroter les titres car le crétin qui a écrit ce document a sauté le point 5.

Lequel crétin remercie Emin, auteur de l'article Piloter sa freebox, disponible ici : ainsi que Mika-NT28 auteur du plugin Freebox OS pour Jeedom qui permet de superviser la box depuis Jeedom, lequel a également été une source d'inspiration. Et moi je remercie mon collègue FredV qui a passé une nuit sur ce petit projet !

Download

https://github.com/mycanaletto/Reboot-Freebox

Release : Reboot_Freebox_01.zip

Bonus

Comme indiqué dans le bug la collection de buggs de la Freebox, la nouvelle version du Compagnon Freebox, mais également tout ce qui accède localement à l'url sécurisée de la Freebox, ne parvient plus à trouver la Freebox en mode bridge et donc à générer une nouvelle association. Il existe une solution ici.

Sources 

https://lafibre.info/routeur/free-usg-mode-bridge-down-apres-desync/ 
https://dev.freebox.fr/bugs/task/22818 
https://kb.paessler.com/en/topic/18963-how-can-i-use-powershell-scripts-with-prtg-s-execute-program-notification 
https://p0w3rsh3ll.wordpress.com/2013/07/04/piloter-sa-freebox/ 
https://github.com/DjMomo/ClassePhpFreebox 
https://wiki.deimos.fr/Rebooter_sa_Freebox_Server_6_en_ligne_de_commande.html 
https://forum.universfreebox.com/viewtopic.php?t=55120 
https://dev.freebox.fr/bugs/task/12939 
https://dev.freebox.fr/sdk/os/

Cloud Storage

Mise à jour août 2019

Les NAS c’est bien, mais ça reste faillible et ce n’est pas extensible à l’infini. Donc on finit par acheter un second NAS pour faire la sauvegarde du premier, ou de nouveaux disques. C'est sans fin. Plutôt que d’entretenir des NAS de prod et des NAS de sauvegarde et continuer à acheter des disques regardons le cloud. Il s’agit de stocker des fichiers exploitables ou des sauvegardes. Mais on verra que l’on peut aussi s’en servir de disque. Je vais vous livrer mes réflexions, dans un cadre DIY adaptable en mode professionnel. Ce sont des notes, donc c’est un peu en vrac et je vous invite à commenter vos expériences.

Les fournisseurs possibles

  • OneDrive Business. Ils peuvent les offrir leurs 5 TO, car ce n’est pas très rapide et surtout le débit est très aléatoire,
  • Même réflexion pour OneDrive, Dropbox, ce n’est pas vraiment fait pour ça. Amazon Drive était intéressant en illimité, mais c’est terminé. Et ne me parlez pas de Hubic ou je vois rouge !
  • Google Drive. C'est la bonne surprise. Les débits sont bons, voire très bons et en prenant une GSuite Business on se retrouve avec un stockage illimité (théoriquement à partir de 5 users, mais dans la pratique c'est OK avec un seul).
    • Attention, il existe une limite de 750 GO en upload, mais il est possible de la contourner en partageant un "Drive partagé" avec d'autres comptes Google
    • Google Drive est reconnu par Synology Hyper Backup et Cloud Sync ce qui offre des perspectives.
    • Attention lors des scan avec Plex ou Emby qui peuvent conduire à des ban temporaires. Il existe des contournements et astuces avec PlexDrive et autres astuces (1 | 2 | 3 | 4)
    • Attention à localiser dès le départ les données en Europe afin de limiter la latence. Il est possible de le faire plus tard mais le processus sera alors très long s'il y a beaucoup de données.
  • Online c’est coûteux et techniquement pas adapté (iSCSI par exemple), Depuis 2019 il existe une offre S3 hébergée en France pour 10 € le TO.
  • OVH en OpenStack Swift revient à 10 € / le TO + le trafic sortant au même prix, en espérant que ça ne ressemble pas à Hubic… Ça peut être intéressant car c’est en France si on veut être full RGPD.
  • Azure Storage on n’en parle même pas dans ce cadre car trop coûteux.
  • Amazon S3 est top et plus abordable pour de la sauvegarde avec Glacier, mais ça reste coûteux.
  • C’est Wasabi qui m’a poussé vers le Storage cloud. C’est très abordable. Il n’y a pas de frais de de transfert, c’est donc le plus intéressant. Leurs Data center sont aux Etats-Unis, mais l’ouverture en 2019 d’un site aux Pays Bas les rends conformes RGPD. Et rien n’empêche un petit chiffrage à la volée… Leur tarification est très simple : 1 TO c’est $ 4.99 / mois, sans frais annexes.

J'avais donc le choix Wasabi, puis GSuite Business en 2019. il faut maintenant tester et trouver les bonnes solutions logicielles pour y transférer les différents types de données et les utiliser. Il existe plusieurs usages possibles, de la sauvegarde pure s’un serveur ou d’un NAS, voire d’une sauvegarde secondaire hors site pour des questions de sécurité ou de données qu’il faudra pouvoir exploiter en direct. Pour une reprise après incident il faudra prendre en compte le temps de téléchargement pour rapatrier rapidement un gros volume de données. Ce temps est bien sur étroitement lié à la bande passante disponible sur le site. Donc oubliez ces solutions si vous devez vous contenter d’une ligne internet famélique et que vous avez un gros volume à traiter.

Comme Wasabi est compatible S3 on peut jouer avec tous les outils initialement proposés pour AWS S3, j’en ai testé des douzaines mais je n’en citerais ici que quelques un.

Transfert et exploration de fichiers

  • RClone : C'est le couteau suisse. Et combiné à RClone Explorer c'est la solution idéale qui répond à quasiment tous les besoins en ligne de commande.
  • Synology Cloud Sync : Idéal avec un NAS de la marque. Sauf qu'il oublie parfois des fichier, notament sur OneDrive.
  • DragonDisk : Un explorateur gratuit mais lent qui peut dépanner.
  • CyberDuck : Un peu plus rapide mais impose un MD5 lent. Evolutions à évaluer.
  • Filezilla Pro : Compatible S3 et autres clouds c’est une bonne solution qui ne changera pas les habitudes.
  • Bvckup : le must pour de la synchronisation locale n’est pas adapté à ce genre de situation (uniquement SMB et pour l’instant mais des évolutions sont prévues).
  • CloudBerry Explorer : Ça c’est la bonne surprise : 30/70 MB/sec en up sur Wasabi en S3, un peu moins sous OVH en OpenStack, et encore moins sur OneDrive Business mais ça reste le plus rapide. Autant dire que ça change tout car dans tous les cas c’est la solution la plus rapide pour faire du UP, quel que soit la destination !

Sauvegardes

Plusieurs combinaisons existent et si l’on dispose d’un NAS Synology on peut sauvegarder les serveurs et PC avec Active Backup, ou Veeam et ensuite uploader tout ça vers le cloud avec Cloud Sync ou Hyper Backup…

  • Pour sauvegarder directement un PC, un Mac ou un serveur vers du S3 j’ai trouvé ARQ Backup particulièrement efficace et simple. Mais il existe plein solutions comparables.
  • Pour sauvegarder des NAS Synology j’avais testé Synology C2. C’est bien emballé et pas très cher avec historisation, cryptage et déduplication. Si on cherche à restaurer sur un nouveau Synology c’est très bien et on peut restaurer avec une bonne granularité (fichier, ou arbo, ou sous arbo à une date donnée. Sauf qu’en cas de crash on a rarement un second NAS sous la main avec les bons disques et on peut avoir besoin rapidement de certains fichiers. Synology à donc prévu une interface web de restauration qui hélas ne permet que de restaurer individuellement les fichiers, et d’après leur support ils n’ont pas de plans à court terme pour faire mieux. Et ça se comprend, leur recommandation étant d’acheter un nouveau NAS, d’en avoir deux et surtout d’utiliser C2 Disaster Recovery qui permettra de virtualiser le NAS sauvegardé dans leur DC. C’est top mais là on ne joue plus dans la même cour coté tarifs. Mon alternative consiste à sauvegarder vers Wasabi avec HyperBackup. En cas de besoin on peut restaurer avec Hyperbackup et si ce n’est pas possible on peut toujours accéder aux données via un CloudDrive et de lancer HyperBackup Explorer sur PC pour restaurer et décrypter ce que l’on veut depuis Windows, MacOS ou Linux.

Synchronisation

La synchronisation va permettre de disposer sur le cloud de données directement exploitables, contrairement à la sauvegarde qui chiffre et historise les données. C’est un usage différent pour des données bien souvent différentes. Si certaines solutions comme CloudBerry sont utilisables de façon interactive, CloudSync sur Synology est ce que j’ai trouvé de plus efficace pour maintenir un volume de données conséquent synchronisé entre un NAS et S3. CloudSync sait utiliser pratiquement tous les fournisseurs. On peut également s’en servir en mode transfert pour uploader des répertoires que l’on supprimera ensuite, il y a beaucoup d’options possibles. Et bien sur il ne faut pas oublier RClone !

Utilisation en direct

Au-delà des sauvegardes dont la restauration est ponctuelle et des transferts de fichiers que l’on pourra effectuer avec les logiciels vus plus haut, il peut être intéressant d’accéder directement aux fichiers comme s’il s’agissait d’un simple volume sur le réseau local. Et c’est là qu’interviennent les « cloud drive ». Contrairement aux clients OneDrive, Google drive ou Dropbox, les « cloud drive » ne font pas de synchronisation locale mais rendent disponible directement les fichiers distants.

  • ExpandDrive : des gens du Mac qui font du Windows, joli mais ça déconnecte, la fille du support est très gentille et doit savoir faire du bon café…
  • NetDrive : j’avais acheté et eu des résultats mitigés. La mise à jour coûte le prix de ce que j’avais alors payé.
  • StableBit : je le cite car parfait et très intéressant pour créer un volume sécurisé dans un cloud, mais ça ne correspond pas au besoin.
  • MountainDuck : c’est ce que j’ai trouvé de plus solide en S3 sur Wasabi,  OpenStack Swift, mais aussi en WebDav. En plus on peut facilement partager des liens de fichiers depuis l’explorateur Windows qui seront téléchargeables depuis la source en https sur un temps limité.  La licence est abordable et permissive, elle permet d’utiliser le logiciel sur plusieurs machines des lors que c’est le même utilisateur.
  • CloudBerry Drive S3 : à tester, mais il n’est compatible que S3 ce qui peut être restrictif. Si les performances sont aussi bonnes que CloudBerry Explorer les 79$ de la version serveur peuvent être un bon investissement pour utiliser Veeam sur Wasabi en attendant une solution intégrée.
  • RClone : Il permet de monter un volume distant directement sur Linux, sous Windows il faudra ajouter WinFSP et on pourra également servir de RClone Tray.
  • Pour Google Drive le plus simple, efficace et gratuit consiste à utiliser Google File Stream qui travaille online / offline et conserve un cache et un index. 

Je ne conseille pas trop de faire des travaux complexe directement sur les fichiers ainsi accessible. Mais en lecture ou en streaming direct ou via Emby ou Plex c’est parfait.

Débits

J’ai fait quelques tests ponctuels en upload pour me donner une idée (CloudSync, CloudBerry, etc.). En download les débits sont à minima identiques mais bien souvent plus importants.

  • Up Online DC vers Wasabi S3 : 30/90 MB/sec
  • Up Online DC vers OVH OpenStack : 30/40 MB/sec
  • Up Online DC vers Google Drive : 80/100 MB/sec (RClone)
  • Up Online DC vers OneDrive Business : 3/30 MB/sec (par beau temps) ce n’est pas non plus sur le papier une solution comparable, juste un détournement.

Réflexions

  • SMB 3. On n’y pense pas toujours, mais on peut utiliser SMB 3 via Internet afin de permettre à un PC ou serveur d’accéder à un NAS avec d’excellents résultats entre un NAS (j’ouvre le port 445 sur le NAS et via le firewall je limite la connexion à l’IP de la machine cliente). Ça peut aussi être une bonne solution pour du backup.
  • Cloudberry Labs à des solutions de sauvegarde Cloud qui peuvent être intéressantes car ils savent très bien gérer le débit sur le cloud.
  • Veeam propose une solution packagée nec plus ultra de sauvegardes de VM. OVH est partenaire. C’est très bien, mais rapidement coûteux. (15 € VM à 1 TO max). Depuis le 9.5 U4 on peut également exporter les anciennes sauvegarde vers du S3.
  • Veeam (9.5 update 4) est en 2019 compatible S3 et OpenStack ce qui va changer la donne…
  • NetBalancer est une découverte intéressante pour voir ce qui se passe sur un serveur exposé. La version freeware est suffisante.
  • Google Drive comme OneDrive convertissent les vidéos de façon à ce qu'elles soient lisibles sur les clients web, sans altérer les originaux (à vérifier).
  • De façon générale je recommande RClone pour transférer de gros volumes...

Voilà, vos réflexions et observations sont bienvenues...

Surtension POE sur AP Unifi

Le POE c’est très pratique, mais il ne faut pas perdre du vu qu’il y a plusieurs normes, actif et passif, 24 V et 48 V, pour faire simple (plus d'infos ici). Si certains switches peuvent détecter l’équipement et son besoin en alimentation, certains plus anciens ont juste une config 24 V ou 48 V, et ne conviendront pas à certains équipements récents.

Donc si comme j’en ai fait l’expérience vous branchez un AP Unifi LR conçu pour fonctionner en 24 V sur un POE 48 V, c’est le drame. Ensuite il clignotera rapidement et le code d’erreur correspondant (A12) indique un retour SAV, ce qui équivaut à la corbeille pour cet équipement un peu ancien.

Heureusement il y a Internet et en cherchant un peu on découvre que cet équipement (comme bien d’autres) et pourvu d’une diode Zener de protection contre les surtensions qui jouera un rôle de fusible (en fait ce n’est pas vraiment le même principe). Et l’on apprend qu’en supprimant cette diode notre équipement redevient fonctionnel ! L’idéal serait bien sûr de la remplacer par une équivalence du genre 1N4749A (1W, 24V). On peut aussi uniquement la dessouder, n’étant pas un as du fer à souder je me suis contenté de dessouder une patte afin de ne pas créer de surchauffe, mais dans ce cas je n’aurais pas droit à une seconde chance !

Sources :

https://elio3c.wordpress.com/reparar-ubiquiti-nanostation-picostation-bullet-m-y-mas/
https://community.ubnt.com/t5/UniFi-Wireless/AP-broken-by-owerpowering-with-48V/td-p/1734879

SSL mi amor… & pfSense

On ne vantera jamais assez les mérites d’un reverse proxy en termes de sécurité. Mais au-delà de la sécurité, un reverse proxy peut aussi nous faciliter la vie pour la publication de services web en mode sécurisé, et donc la gestion des certificats.

Si selon le niveau de protection et d’assurance il faudra continuer à acheter des certificats hors de prix, dont la sécurité a parfois été corrompue même chez les soi-disant plus sérieux fournisseurs, pour bien des services l’utilisation de certificats Let’s Encrypt fera parfaitement l’affaire.

Au passage vous noterez que si j’étais fan de Sophos XG, je suis en train de m’orienter vers pfSense que je trouve bien plus simple et mieux documenté par la communauté.

Il y a plusieurs façons d’utiliser Let’s Encrypt :

  • Via un script ou un logiciel installé sur le backend (le serveur web) qui génère le certificat, il faudra ensuite l’exporter manuellement ou via un script vers le reverse proxy si on en utilise un en frontal, mais on peu aussi passer en direct, en NAT ou une simple redirection de ports.
  • Via un script géré par le firewall / reverse proxy. C’est ce que je vais décrire ici en utilisant pfSense ou j’installerais les paquets Acme et HAProxy.

Acme

Automated Certificate Management Environment, for automated use of LetsEncrypt certificates.

Cette implémentation très complète va nous permettre de générer et renouveler automatiquement des certificats Lets’s Encrypt (Standard, Wilcard ou San) et de les installer dans pfSense. Cette implémentation sait s’appuyer sur les API des principaux DNS, ce qui nous évitera d’avoir à ouvrir un port 80 comme cela était nécessaire auparavant. Le plus simple sera de générer un wilcard : *.domaine.tld.

Il sera également possible d’exporter ces certificats, manuellement, ou via un script vers un serveur web si nécessaire (par exemple, un script PowerShell sur un serveur Exchange pour récupérer les certificats, les installer et les activer).

Dans notre exemple on n’exporte rien car on va se servir de HA Proxy comme Frontend, c’est à lui qu’incombera la gestion du SSL (le SSL Offloading consiste à déporter la gestion du SSL sur le reverse proxy / load balancer, et donc sur le serveur web on ne laisse que le service HTTP, les sessions HTTPS n'étant cryptées qu'entre l'internaute et le reverse proxy qui peut également jouer un rôle d’équilibreur de charge si nécessaire).

HA Proxy

The Reliable, High Performance TCP/HTTP(S) Load Balancer.

Il s’agit ici d’un reverse proxy moderne qui permet également d’équilibrer la charge vers plusieurs Backends.

On aurait pu utiliser le paquet Squid, mais je lui reproche de ne pas gérer SNI (à vérifier) et donc de ne pouvoir servir plusieurs domaines en SSL. Squid est toutefois plus simple et fera l’affaire pour une installation simple ou domestique. A noter également que tant HA Proxy que Squid permettent de publier un serveur Exchange, et donc de remplacer avantageusement de vieux ISA ou TMG que Microsoft nous a tant vanté avant de les oublier…

Je ne vais pas reprendre un fastidieux steep by steep de publication il y en a de très bien faits… mais juste résumer :

  1. Installation de pfSense (il y a des VM toutes prêtes) avec un lien WAN et un lien LAN. On peut éventuellement ajouter des IP virtuelles (VIP) coté WAN si on en dispose.
  2. On crée une règle sur le firewall ou on autorise le port 443 (HTTPS) en entrant sur le WAN.
  3. Sur HA Proxy on crée un Backend avec l’IP interne sur le port 80 (ou autre) et sans SSL (sans car on pourrait également sécuriser le flux interne). Dans les options de LoadBalancing on choisit None si on a qu’un Backend, et dans ce cas on n’oublie pas de choisir également None au niveau Health checking. Et c’est tout, le reste si on ne sait pas, on ne touche pas.
  4. Sur HA Proxy on crée un Frontend qui écoute sur le port WAN (ou VIP), on coche SSL Offloading et plus bas dans SSL Offloading on choisit le certificat lié au domaine que l’on va utiliser (une règle Frontend par domaine géré). Dans Default backend, access control lists and actions on va gérer nos serveurs en utilisant l’expression Host Matches et la valeur, par exemple canaletto.fr que l’on nomme www (inutile si on n’a qu’un seul serveur à sécuriser). Ensuite plus bas dans Actions on va dire que la condition www est redirigée vers le Backend idoine. Ici aussi, c’est tout, le reste si on ne sait pas, on ne touche pas, car comme vous pourrez l’observer HA Proxy dispose d’une multitude d’options qui ne seront utiles que dans certains cas.

Test

Pour tester ce genre de configuration l’idéal est de disposer une machine connectée sur l’internet en dehors de votre réseau. La machine d’un ami en remote (TS, TeamViewer, NoMachine ou AnyDesk) ou encore une machine connectée en 4G.

Comme à ce stade on n’a probablement pas encore renseigné le DNS public, le plus simple est de créer une entrée dans le fichier hosts (sous Windows le plus simple est d’utiliser HostMan). 

Ensuite on lance une session dans le navigateur et on vérifie que c’est vert et que le certificat est valide et correspond bien à celui utilisé. Si c’est le cas il n’y a plus qu’à s’occuper du DNS public.

Info

Vous imaginez bien que je n’ai pas creusé ce sujet uniquement pour publier un Jeedom. Au départ il s’agissait de publier des serveurs Microsoft Exchange avec des certificats SAN classiques et couteux, et quand on publie de l’Exchange on peut faire à peu près tout. Ensuite j’ai trouvé la gestion Let’s Encrypt tellement simple dans pfSense que je me suis dit que finalement cet outil embarqué dans une VM ou un petit Appliance pouvait d’adapter à toutes les situations, même les plus simples. Du coup je vais probablement remplacer Sophos XG et pourquoi pas également chez moi à la place ou à côté de l’USG qui est très bien pour le trafic sortant mais n’évolue pas trop et ne permet pas de faire du reverse proxy.

Sources

https://pixelabs.fr/installation-configuration-pfsense-virtualbox/https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-vmware-vsphere-esxi.html

https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://pixelabs.fr/installation-role-transport-edge-2016-partie-2/
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://www.supinfo.com/articles/single/6326-mise-place-serveurs-web-haute-disponibilite-avec-haproxy-pfsense
https://www.itwriting.com/blog/9592-publishing-exchange-with-pfsense.html
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://forum.netgate.com/topic/99804/squid-reverse-proxy-for-multiple-internal-hosts
https://tecattack.ch/index.php/2018/12/10/pfsense-2-4-4-haproxy-reverse-proxy-multiple-http-server-ubuntu-16-04/
https://all-it-network.com/pfsense-reverse-https/
https://blog.devita.co/pfsense-to-proxy-traffic-for-websites-using-pfsense/

Zerotier VPN / SDN et sécurité et DNS

Dans le précédent article on a vu comment créer facilement un SDN avec Zerotier qui de part ses possibilités explose les deux autres possibilités dont j’avais parlé. Un VPN SDN c’est un réseau étendu qui peu s’intégrer dans un LAN existant ou être totalement virtuel. Dès lors se pose la question de la sécurité des accès et il convient de considérer principalement à deux niveaux :

  • Sécurité d’accès aux ressources au niveau machine assurée par celle-ci ou une solution globale comme Active Directory. Dans un petit réseau local les utilisateurs ont tendance à laisser pas mal de choses ouvertes, voire très peu protégées. Dès lors que l’on ouvre un réseau à un SDN il conviendra de renforcer la sécurité des équipements.
  • Sécurité d’accès au niveau IP. Sur un LAN ou plusieurs LAN interconnectés via des VPN cette sécurité est assurée au niveau des routeurs et des switches afin d’isoler les départements, entremises, etc…

Dès lors que l’on étend un réseau à un SDN comme Zerotier on va se retrouver avec des devices isolés et il faudra définir ce que ces devices auront le droit de faire. Cela est rendu possible de façon centralisée via un système de règles relativement puissant qui se base sur l’ID de chaque client ZT qui va interagir avec des règles basées sur des tags, les adresses IP ZT ou internes aux réseaux, les ports et les protocoles. Je vais me contenter de donner ici quelques exemples que chacun adaptera à ses besoins.

On se base principalement sur 3 expressions

  • DROP, on supprime le paquet et on termine l’évaluation de la règle.
  • BREAK, on termine l’évaluation de la règle mais on accepte l’évaluation par une autre capacité.
  • ACCEPT, on autorise.

On va se servir de la règle de base et l'améliorer

Pour autoriser uniquement les trames Ethernet IPv4, IPv4 ARP.

drop
    not ethertype ipv4
    and not ethertype arp
    and not ethertype ipv6;

Pour éviter toute forme d’IP spoofing, mais ça bloque également les IP non ZT. Donc à exclure si on utilise des ponts vers des réseaux existants.

drop
    not chr ipauth;

Pour autoriser à tout le monde par exemple SSH, HTTP et HTTPS

accept
    ipprotocol tcp
    and dport 22 or dport 80 or dport 443;

Ici on va créer un TAG “department” que l’on va associer à des clients, et à partir de là on définira des possibilités. Ces TAG peuvent permettre de faire communiquer ensemble des clients d’un même service en comparant leur niveau (tdiff department 0 ou 0 est la différence acceptable entre deux clients pour être valide), mais on peut aussi utiliser ces TAG avec TSEQ pour affecter des droits.

tag department
    id 1000 #ID est arbitraire mais unique
    enum 100 Archi
    enum 200 Dev
    enum 300 Services
    enum 400 Finances
    enum 500 Ventes;

Autoriser Windows CIFS et Netbios aux clients d'un même groupe (différence = 0)

accept
    ipprotocol tcp
    and tdiff department 0
    and dport 139 or dport 445;

Autoriser les clients tagués 300 (to_LAN1_LAN2) à accéder à des réseaux internes spécifiques via un pont :

accept tseq department 300 and ipdest 192.168.1.0/24;
accept tseq department 300 and ipdest 192.168.2.0/24;

Pour supprimer les paquets TCP SYN,!ACK qui ne sont pas explicitement autorisés

break
  chr tcp_syn             # TCP SYN (TCP flags will never match non-TCP packets)
  and not chr tcp_ack     # AND not TCP ACK;

Pour interdire les destinations qui ne sont pas explicitement autorisées ci-dessus

break ipdest 192.168.1.0/24;
break ipdest 192.168.2.0/24;
break ipdest 192.168.3.0/24;

Si restreindre les IP est utilisé pour contrôler l’accès à des machines accessibles via un bridge, Il faut également pouvoir rendre inaccessibles certains clients ZT sensibles. Le modèle utilisé pour le contrôle d'accès ressemble à la façon dont les organisations militaires classifient les données. Les informations sont considérées classifiées et seules les personnes disposant du niveau de classification requis sont autorisées à y accéder. Il ne s'applique hélas pas aux clients non ZT

Au départ, les membres se verront attribuer un tag classified par défaut de 0 ("no"). Ceux-ci peuvent communiquer puisque leur étiquette de classification sera zéro. Pour restreindre l'accès à un membre, définissez son tag de classification sur secret (1) ou top (2). (Dans cet exemple, il n'y a pas de différence, mais deux niveaux sont inclus au cas où vous voudriez mettre en œuvre une sorte de segmentation plus détaillée basée sur ceux-ci.). Ainsi, la première correspondance (not tor classified 0) sera vraie et le paquet sera abandonné, à moins que les deux membres en communication aient au moins un flag (équipe) en commun grâce au bit clearance (tand clearance 0). (et si vous n’avez pas compris allez voir la doc en anglais…).

# Is this member classified?
tag classified
  id 2
  enum 0 no
  enum 1 secret
  enum 2 top
  default no
;

# Clearance flags (a bit like groups)
tag clearance
  id 1
  default 0
  flag 0 staging
  flag 1 production
  flag 2 financial
  flag 3 security
  flag 4 executive
;

# If one party is classified, require at least one overlapping clearance bit
break
  not tor classified 0
  and tand clearance 0
;

Pour ne pas être en reste, on va bien sur se créer une capacité "superuser" que l’on pourra affecter à des clients ZT pour passer outre les interdictions…

cap superuser
  id 2000
  accept;

Et enfin on accepte ce qui n’est pas interdit….

accept;

Ce ne sont que quelques exemples et en parcourant la documentation disponible on s’apercevra que les possibilités sont énormes. Je vais essayer de compléter cet article au fil de l'eau, et vos commentaires sont comme toujours les bienvenus.

DNS

A partir de la version 1.6 il est possible d'activer le DNS pour les clients ZT, ce qui veut dire que pour un ou plusieurs domaines spécifiques on pourra faire appel à un ou plusieurs serveurs DNS. On commence par renseigner l'IP du serveur DNS dans l'interface d'administration :

Ensuite au niveau du client il va falloir entrer la commande suivante (en mode admin) et ou $networkID sera l'ID de votre réseau.

zerotier-cli set $networkID allowDNS=1

Il faut bien avoir à l'esprit qu'on agit sur NRTP (Name Resolution Policy Table) sous Windows et que l'on ne verra rien avec un IPConfig... Je suppose que sur MacOS ou Linux  il existe une équivalence. Ce qui compte c'est que ça fonctionne et qu'il est désormais inutile d'encombrer vos DNS publics avec des adresses privées pour palier à ce manque !

Sources

 

Zéro VPN !

On va parler aujourd’hui d’une approche un peu différente des VPN (Virtuel Private Network).

Le principe d'un VPN est de créer un tunnel de données sécurisé dans lequel on routera des réseaux privés en IPV4 ou IPV6. On peu aborder les VPN en plusieurs usages :

  • VPN Remote : il s’agit pour un utilisateur itinérant de se connecter au réseau de son entreprise ou de son domicile depuis un terminal itinérant. On configure généralement ce service au niveau du routeur ou du firewall, plusieurs protocoles sont possibles selon le niveau de sécurité souhaité (PPTP, OpenVPN, L2TP, SSL VPN, etc). Ensuite on utilise soit le logiciel intégré à l’OS client, soit un logiciel spécifique, le tout étant plus ou moins compliqué à mettre en œuvre selon les protocoles. PPPT est le plus simple, c’est aussi le moins sécurisé.
  • VPN Site to Site : il s’agit ici d’interconnecter deux réseaux d’entreprise (le siège et un bureau distant par exemple) afin de rendre transparent l’accès aux équipements. C’est souvent fait en IPSec, mais il est possible d’utiliser d’autres protocoles (SSL VPN, OpenVPN, etc.), ça reste une affaire de spécialistes réseaux et ça se complique quand les deux extrémités utilisent des équipements hétérogènes.
  • VPN Internet : il s’agit ici de masquer son adresse IP afin de se cacher ou simplement laisser croire au service distant qu’on se situe sur une autre partie du globe. Il suffit généralement de contracter un abonnement et d’installer le logiciel fourni.

Tous ces VPN utilisent peu ou prou les mêmes technologies et commencent dater. Vu qu’elles sont massivement utilisées par les entreprises elles sont sures et fiables dès lors qu’elles sont mises en œuvre par de vrais spécialistes. Vous l’aurez compris, la chose n’est pas toujours des plus simples. Si le grand public amateur de DIY parviendra généralement à mettre en œuvre ces solution avec un peu de perspicacité et quelques nuits blanches, il existe des solutions alternatives qui peuvent s’avérer plus simple.

ZERO !

Zéro, comme zéro configuration. Un nouveau type de logiciels voit le jour depuis quelques temps, ils comportent généralement un petit client propriétaire à installer sur les devices (Windows, Mac, Linux, mobiles, etc…) et une interface de gestion quelque part dans un cloud privé ou public. Au niveau du device on ne fait que se connecter, alors que depuis l’interface de gestion on décidera de qui voit quoi. Cela va permettre la création de réseaux point à point et multipoints en mode peer to peer, les échanges se faisant toujours de point à point, le site central ne servant qu’à la gestion. Je vais en citer 3 selon les usages, mais il en existe d’autres et Google est votre ami !

Wirelends

C’est le plus simple, il fonctionne en deux clics mais il offre out of the box la possibilité de se connecter à l’ensemble des équipements du réseau distant, voire même d’accéder à Internet via le réseau distant. Cependant c’est du point à point et uniquement entre deux points en même temps. C’est la solution la plus simple que je n’ai jamais trouvée et bien sûr c’est gratuit. Je ne l’ai testé que sous Windows, mais il est possible d’installer le service Linux sur un équipement existant afin de s’en servir de passerelle. C’est gratuit, mais pas Open Source, donc quid possible au niveau sécurité. Dans le même genre très facile et sous Windows seulement on trouve également RAdmin VPN.

NeoRouter

Celui là je l’utilise depuis quelques années, pour par exemple donner accès à des serveurs aux développeurs. Il comporte deux parties, un client multi plateformes très basic et un peu daté, et un logiciel d’administration que l’on peu installer n’importe ou si on ne choisit pas la version commerciale ou ce service peut être fourni par l’éditeur. On peu définir des utilisateurs et des autorisations par machines et par utilisateurs. Chaque client obtiendra une adresse IP privée supplémentaire qui lui permettra de joindre les autres machines de ce réseau privé multipoint. C’est simple, basic et ça fait le job mais ce n’est pas Open Source et il sera pour certains usages nécessaire de passer à la caisse. Impossible également de bridger un client qui pourrait servir de passerelle pour accéder aux autres équipements du réseau.

Zerotier

Et enfin, celui qui me semble le plus intéressant, Zerotier. Ici on est face à un projet Open Source sous licence GPL. Si la philosophie rappelle celle de NeoRouter, le projet semble bien plus moderne et aboutit. Je me suis contenté au départ de créer un tunnel entre deux PC, en fait je l’ai fait entre trois postes et ça c’est très simple à mettre en place. C’était l’objectif de mon test et c’est réussi. Il est cependant possible de créer des réseaux multipoints complexes et de grande ampleur avec des possibilités de routage vers d’autres réseaux grâce à des bridges et de gérer très finement les autorisations, mais là il va falloir y passer un peu de temps. On est face à un produit intégrable en entreprise, mais il existe une version communautaire avec très peu de restrictions qui est disponible gratuitement.

Pour faire du point à point c’est donc simple et facile, il suffit de se créer un compte, de créer un réseau et de choisir un range d’IP, installer le client, sous Windows il n’y a qu’à cliquer et se connecter ou rentrer la clé API. A partir de là les deux points communiquent, le ping est ok.

Pinging 10.147.20.28 with 32 bytes of data:
Reply from 10.147.20.28: bytes=32 time=32ms TTL=64
Reply from 10.147.20.28: bytes=32 time=31ms TTL=64
Reply from 10.147.20.28: bytes=32 time=30ms TTL=64
Reply from 10.147.20.28: bytes=32 time=30ms TTL=64

Mais là ou ce logiciel devient intéressant c’est qu’il est possible de le configurer une machine du LAN en passerelle. Entendons par là qu’une machine sur mon LAN servira de passerelle et rendra accessible toutes les autres machines.

Sous Windows

On part du principe que Zerotier est installé et fonctionne entre deux points comme vu ci-dessus. Sur la console d’administration on coche Do Not Auto-Assign IPs sur l’interface virtuelle de la machine qui va servir de passerelle et on lui affecte une IP fixe dans le range choisit, ici 10.147.20.28. 

Sur cette même console on défini une Managed Routes pour définir que le LAN 192.168.210.0/24 sera accessible via 10.147.20.28.

EDIT : en fait il vaut mieux faire du /23 ce qui permettra de voir le réseau local quand on est localement connecté sur un réseau appartenant à une route managée.

Il faut ensuite activer le routage IP entre les interfaces, routage qui n'est pas actif par défaut. Pour ça on lance regedit et on cherche la clé IpEnableRouter qui se trouve sous:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

On la passe la valeur de 0 à 1 pour activer le TCP/IP forwarding pour toutes les connections actives sur la machine. Et surtout on relance la machine. A partir de là on peu depuis la machine distante faire un ping sur l’IP LAN de la machine passerelle.

Pinging 192.168.210.28 with 32 bytes of data:
Reply from 192.168.210.28: bytes=32 time=63ms TTL=64
Reply from 192.168.210.28: bytes=32 time=36ms TTL=64
Reply from 192.168.210.28: bytes=32 time=30ms TTL=64
Reply from 192.168.210.28: bytes=32 time=30ms TTL=64

Si l’on veut rendre accessible d’autres machines, il faudra bien sur définir une route statique sur celles-ci (avec un -p si on veut que cette route soit persistante :

C:\route add 10.147.20.0 mask 255.255.255.0 192.168.210.28 -p

Et on pourra depuis la machine distante faire un ping sur l’IP LAN de la machine située sur le LAN en passant par la passerelle.

Pinging 192.168.210.24 with 32 bytes of data:
Reply from 192.168.210.24: bytes=32 time=33ms TTL=127
Reply from 192.168.210.24: bytes=32 time=31ms TTL=127
Reply from 192.168.210.24: bytes=32 time=30ms TTL=127
Reply from 192.168.210.24: bytes=32 time=30ms TTL=127

Sous Linux

Une VM linux deviendra une bonne passerelle. Mais on peu aussi installer ça sur un Raspberry ou une autre machine existante, un Jeedom par exemple... On part du principe que Linux est installé avec une IP LAN fixe et que vous êtes connecté en root.

Pour installer Zerotier on se servira de ce script (et on hésite pas à aller lire les informations disponible sur le site de Zerotier, notamment les faqs et leur communauté et aussi sur Redit) :

[root@zero /]# curl -s https://install.zerotier.com/ | sudo bash

Ça va nous retourner une ID client que l’on rentre manuellement dans le manager.

Ensuite on découvre quelques commandes

[root@zero /]# /usr/sbin/zerotier-one -d < pour faire un bind, mais pas toujours utile…
[root@zero /]# /usr/sbin/zerotier-cli join 8044c2551c550881 < ID Réseau que l’on trouve dans le manager
[root@zera /]# /usr/sbin/zerotier-cli listnetworks

Pour activer la passerelle

On édite le fichier /etc/sysctl.conf (avec nano par exemple) pour supprimer le # devant la ligne net.ipv4.ip_forward=1

Avec un ip a on repère le nom de l’interface virtuelle Zerotier (ici : zt7erf5fdc)

Ensuite on édite le fichier /usr/local/sbin/firewall.sh et on lui colle ce qui suit en renseignant correctement le nom de l’interface virtuelle (attention, selon les configurations il faut parfois remplacer eth0 par ensXX)

/usr/local/sbin/firewall.sh

# !/bin/sh
# A very basic IPtables / Netfilter script /etc/firewall/enable.sh
# PATH='/sbin'
# service networking restart > /dev/null 2>&1

# Flush the tables to apply changes
iptables -F

# Default policy to drop 'everything' but our output to internet
iptables -P FORWARD ACCEPT
iptables -P INPUT   ACCEPT
iptables -P OUTPUT  ACCEPT

# Allow established connections (the responses to our outgoing traffic)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow local programs that use loopback (Unix sockets)
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -t nat -A POSTROUTING -o ens32 -j MASQUERADE
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i zt7erf5fdc -o ens32 -j ACCEPT

sleep 4
service networking restart

sleep 4
service ssh restart

exit 0

Un petit reboot et on peut maintenant depuis la machine distante faire un ping vers n’importe quelle machine du LAN dont la route idoine aura été renseignée.

Pour activer le pont (mode Bridge)

Pour l’instant on parlait de routage, ce qui implique que les machine à joindre aient une route statique vers celle qui va servir de routeur vers le réseau Zerotier. Mais il y a une autre option expliquée ici, faire un bridge. Comme vu plus haut on prépare une petite machine Linux sur laquelle on installe Zerotier, on y colle une IP Zerotier fixe + l’option Bridge et on la définie dans Managed Route en tant que celle qui va nous permettre de joindre le réseau local. On édite le fichier /etc/sysctl.conf (avec nano par exemple) pour supprimer le # devant la ligne net.ipv4.ip_forward=1 et un sysctl -p pour recharger la configuration. Avec un ip a on repère le nom de l’interface virtuelle Zerotier (ici : zt7erf5fdc) et on lance les commandes suivantes :

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o zt7nnf5jtx -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i zt7nnf5jtx -o eth0 -j ACCEPT

Pour rendre ces commandes persistantes (j'apprends Linux en même temps...) :

apt-get install iptables-persistent

Et si tout ça se passe dans une VM autant installer les Open VMware Tools (ça aidera notamment pour les sauvegardes) :

apt-get install open-vm-tools
reboot

Voilà comment depuis une machine itinérante ou un VPS je peux joindre n'importe quelle machine de mon réseau local de façon simple et sécurisée. Et si ce réseau comporte d'autres routes, il sera également possible d'y accéder, pour peu qu'on les définisses dans la manager... Ce qui veut concrètement dire que je peux me passer des routeurs IPSec qui gèrent des VPN entre plusieurs sites et les remplacer par un bête Raspberry à deux balles...

 

Sur un routeur....

J'ai parlé ici de Windows et Linux, mais ça existe aussi pour Mac, IOS et Android, mais on peu aussi faire un bridge sur un routeur, un Edge Router par exemple. Dans ces cas je vous sugère de suivre ces deux tutos (1 | 2), une fois Zerotier installé c'est du pareil au même, sauf qu'ici notre passerelle c'est le Switch...

sudo iptables -t nat -A POSTROUTING -o switch0 -j MASQUERADE
sudo iptables -A FORWARD -i switch0 -o zt7nnf5jtx -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i zt7nnf5jtx -o switch0 -j ACCEPT

Par contre pas d'iptables-persistent ici, donc on crée un fichier avec vi (oui et les commandes sont ici) :

sudo vi /config/scripts/post-config.d/myfwd

et on y colle la config qu'il exécutera au démarrage :

#!/bin/bash
iptables -F
iptables -F -t nat
iptables -t nat -A POSTROUTING -o switch0 -j MASQUERADE
iptables -A FORWARD -i switch0 -o zt7nnf5jtx -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i zt7nnf5jtx -o switch0 -j ACCEPT

Et si le routeur est sur une IP publique il faut également configurer le firewall car avec nos bricolages il n'ets plus géré par le firewall interne au routeur... Donc on ajoute quelques règles à notre fichier :

  • On ferme tout le trafic entrant sur le port Ethernet WAN (ici eth0)
  • On ouvre le port 9993 en tcp et udp (le port Zerotier)
  • On autorise le management distant via certaine IP et sur certains ports (ici 22, 80 et 443)
  • Et on peut aussi rerouter des ports vers des services internet (ici en sollicitant l'ip publique sur le port 2222 je joint le port 22 d'un serveur interne).
iptables -A INPUT -i eth0 -j DROP
iptables -I INPUT -i eth0 -p tcp --dport 9993 -j ACCEPT
iptables -I INPUT -i eth0 -p udp --dport 9993 -j ACCEPT

iptables -I INPUT -i eth0 -p tcp -m multiport -s 69.69.69.69 --dports 22,80,443 -j ACCEPT

iptables -t nat -A PREROUTING -p tcp -d  62.63.64.65 --dport 2222 -j DNAT --to 192.168.1.10:22 -s 69.69.69.69

Ensuite on rend le fichier exécutable :

chmod +x /config/scripts/post-config.d/myfwd

Et pour terminer on teste avec NMAP qu'il ne reste pas de portes ouvertes... Pour tester tous les ports (0-65534) ou seulement quelques uns en restreignant ce range...

nmap -Pn -p 0-65534 69.69.69.69

Qu'en faire ?

En substance Wirelends rendra service dans un cadre DIY, NeoRouter, un peu daté se situe entre les deux, en revanche Zerotier (ou Wireguard dont on reparlera) propose une approche d’entreprise décentralisée intéressante. Traditionnellement les collaborateurs travaillent dans l’entreprise et accèdent aux ressources locales ou distantes vie des VPN point à point. Quant ils sont itinérants on colle sur leur terminal un client VPN configuré localement par l’IT qui devra repasser si des modifications sont à effectuer.

L’idée des VPN, je dirais plutôt SDN, tels que Zerotier est d’installer un client générique, pas incompatible avec d’autres clients, et entièrement configurable d’un point central. De plus, contrairement à NeoRouter, l’approche de Zerotier est multi réseaux, l’utilisateur pourra ainsi faire partie de plusieurs réseaux privés en même temps. Certains sur des forums on même imaginé qu’il découle de cette approche une standardisation car il n’est pas impossible que de plus en plus d’internautes auront besoin d’accéder simultanément à plusieurs réseaux privés correspondant à plusieurs activités à sécuriser… Et ici on va justement parler sécurité autour de Zerotier.

Sources

https://gist.github.com/ort163/787000d371dae49a4a399b0f6a7aab56 
https://www.digitalocean.com/community/tutorials/getting-started-software-defined-networking-creating-vpn-zerotier-one 
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7536656/Running+ZeroTier+in+a+Docker+Container 
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7438339/Layer+2+Bridging+with+LEDE+OpenWRT 
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7471125/Layer+2+Bridging+of+Ethernet+and+ZeroTier+Networks+on+Linux 
https://www.reddit.com/r/zerotier/ 
https://news.ycombinator.com/item?id=16329046 
https://blog.reconinfosec.com/build-a-private-mesh-network-for-free/ 
https://github.com/cormacrelf/terraform-provider-zerotier 
https://0wned.it/2017/12/04/building-a-zerotier-bridged-network/ 
https://mangolassi.it/topic/8566/zerotier-bridging-configuration 
http://espressobin.net/ 
https://gist.github.com/adamierymenko/7bcc66b5f7627699236cda8ac13f923b 
https://ngrok.com/ (pas exploré mais ça peut être intéressant dans certains contextes)

 
 

 

 

MPTCP vs Dual WAN

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/

Télécoms : Fiabiliser et économiser

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 !

USG et Dual WAN

 

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

Jeedom : SSL avec Cloudflare

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 :