De retour chez OVH

Article du samedi soir qui devrait rester court, simplement pour informer qu’Unicoda est de retour chez OVH depuis quelques heures. Cette fois, le serveur s’éloigne de moi de plusieurs centaines de kilomètres, alors qu’il était longtemps à moins de 15 kilomètres de mon domicile. Bref, retour en France, après un court passage chez Hetzner à Falkenstein en Allemagne. Tout a l’air de bien fonctionner. Vérification demain matin que le processus de sauvegarde quotidien s’est exécuté comme prévu et avec succès.

Au passage, j’en ai profité pour ajouter une sauvegarde distante supplémentaire. Le site est donc à présent sauvegardé vers deux services de stockage différents: Backblaze B2 (déjà évoqué ici) et désormais également dans le Cloud IBM. Je suivrai les sauvegardes vers ce nouveau dépôt dans les prochains jours afin de valider définitivement son bon fonctionnement.

J’ai profité de cette nouvelle migration pour jeter un œil du côté des logs Apache, pour la journée du 19 mars, en utilisant GoAccess, découvert pour l’occasion, et qui permet d’avoir quelques données agrégées directement accessible dans le terminal. Je note au passage l’option --ignore-crawlers permettant de filtrer les robots et autres bots. Difficile par contre de se faire une idée précise du nombre de lecteurs quotidiens, mais le flux RSS semble être appelé régulièrement: tant mieux !

C’est vraiment un point que je souhaite améliorer, à savoir la surveillance du serveur, en termes d’utilisation de ressources et d’analyse du trafic. Loin de moi l’idée de mettre en place du Google Analytics, mais quelque chose basé sur l’analyse des logs Apache devrait suffire et permettre, par exemple sur une durée d’un mois, de distinguer le trafic « réel », du trafic des bots, crawlers et autres spammers automatisés, et de savoir comment se comporte le serveur.

Pour finir, quelques données en vrac concernant les proportions de chaque système d’exploitation et les navigateurs pour cette journée du 19 mars. Pour les systèmes d’exploitation, je note environ (arrondi à la valeur inférieure):

  • 36% Windows
  • 25% GNU/Linux
  • 18% Android
  • 11% Macintosh
  • 1% iOS

Pour les navigateurs:

  • 37% Chrome
  • 26% Firefox
  • 19% Safari
  • 2% MSIE

Sur ces quelques chiffres, amis lecteurs, bonne nuit !

SPA112 et ligne VoIP OVH

En début d’année 2018, je m’attelais à l’amélioration de mon réseau LAN, en cherchant à en maîtriser le plus de composants possibles. À l’époque, j’étais chez OVH pour ma connexion au réseau internet, et je disposais à ce titre, d’une ligne téléphonique. Afin de pouvoir me passer du modem OVH, j’avais donc commandé un petit boîtier Cisco SPA112, afin de pouvoir brancher mon téléphone et d’être en mesure de passer et de recevoir des appels. Voici quelques notes prises au moment de la mise en place et que je publie ici pour référence.

Sur le SPA112, le couple login/mot de passe par défaut est admin/admin. Avant même de m’attaquer à la configuration de la ligne, j’avais commencé par mettre à jour le firmware. Celui-ci est à récupérer directement sur le site de Cisco, je note d’ailleurs qu’une nouvelle version du firmware a été publié en avril de cette année. Dans mes souvenirs, le processus de mise à jour ne présente aucune difficulté, dans l’onglet dédié, il suffit de sélectionner le zip sur son disque, puis de valider pour démarrer la mise à jour. Évidemment, dans l’idéal, on prendra quelques minutes pour vérifier la somme de contrôle du fichier récupéré.

Pour ce qui est de la configuration de la ligne, je me suis inspiré de la page Cisco SPA112 du wiki VoIP.ms qui fournit une documentation très complète sur le boîtier. Toujours en fouillant dans ma mémoire, je crois me souvenir d’avoir effectué la configuration via la page « Quick Setup », et n’avoir eu qu’à remplir les champs proxy, display name, user id et password avec les informations de ma ligne OVH. Il ne me semble pas avoir eu besoin de mettre en place une configuration particulière pour le dial plan. Voici donc un extrait de ma configuration:

  • Proxy: sip3.ovh.fr
  • Display Name: 0033900000000
  • User ID: 0033900000000
  • Password: <mot de passe>
  • Dial Plan: (*xx|[3469]11|0|00|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx.)

A ce stade, les propriétaires d’un accès internet OVH s’étonneront peut-être du fait que je disposais des informations de connexions à la ligne téléphonique incluse dans mon abonnement. En effet, il faut savoir qu’OVH ne fournit pas ces informations dans le cadre de l’offre d’abonnement internet. Le seul moyen d’avoir ces informations via OVH, consiste à demander l’envoi contre caution d’un SPA112 déjà configuré, ou de s’abonner spécifiquement à une offre de ligne téléphonique sur IP.

Une autre solution, celle que j’ai choisi, consiste à ruser pour obtenir le mot de passe de la ligne. D’après ce que j’avais pu lire sur les forums OVH, il faut savoir que cette manière de faire vient avec quelques limitations d’usage comparée à une véritable solution VoIP. En effet, OVH vérifie que cette ligne n’est utilisée qu’à partir de votre réseau domestique. Il n’est à priori pas possible d’utiliser sa ligne depuis une application Android en étant connecté au réseau 4G. Les utilisateurs ayant tentés l’opération, ont vu les informations de connexion de leur ligne VoIP être réinitialisées, les obligeant ainsi à refaire la procédure de récupération des identifiants de connexion. En revanche, il est tout à fait possible d’utiliser la ligne depuis une application Android, avec son téléphone connecté à son réseau local. Du point de vue d’OVH, l’appel est passé depuis l’IP associée à la connexion internet et cela ne pose donc aucun problème. Si vous disposez donc d’un VPN vous permettant de vous connecter à votre réseau local, il devient alors possible d’utiliser la ligne téléphonique depuis l’extérieur, comme par exemple, depuis un pays étranger dans lequel vous n’auriez pas de réseau, mais simplement un accès à internet non restreint.

Passons maintenant à l’exposition succincte et non détaillée du processus de récupération des identifiants de connexion. À partir d’un modem OVH configuré et disposant de la ligne téléphonique activée et fonctionnelle, on commence par configurer un service dyndns pointant vers un nom de domaine en notre possession et sur lequel on fait tourner un petit bout de code ayant pour seul rôle de logger les informations provenant des requêtes entrantes. Une fois le service configuré, on sauvegarde la configuration du modem dans un fichier via la page prévue dans l’interface. Dans le fichier de configuration, on cherche la ligne correspondant aux identifiants de la ligne VoIP et on récupère le hash du mot de passe associé. On remplace ensuite le hash du mot de passe associé à la configuration de notre service dyndns par le hash du mot de passe de la ligne VoIP récupéré à l’étape précédente. Une fois le fichier modifié de cette manière, on procède à la restauration de la configuration du modem à partir du fichier que l’on vient de modifier. Une fois la nouvelle configuration en place, le modem va faire un appel vers notre service dydns pour l’informer de la configuration IP actuelle et utilisera dans la requête les informations d’authentification, à savoir, le mot de passe de la ligne VoIP. Il ne reste plus qu’à aller consulter les logs du service dyndns que nous avons mis en place pour y découvrir le mot de passe VoIP en clair. Une fois en possession de cette information, on peut alors configurer une application Android ou un SPA112 pour se connecter à la ligne téléphonique.

Sur ce point, je trouve dommage qu’OVH ne fournisse pas directement les informations de connexion, même en précisant par exemple, que la ligne téléphonique n’est utilisable que depuis l’adresse IP associée à la connexion internet fournie. Au passage, je remercie toutes les personnes qui ont échangé autour du processus à suivre et dont les discussions, posts après posts m’ont permis de reconstituer une solution fonctionnelle, et de profiter de la ligne téléphonique au sein de mon LAN comme je l’entendais.

Création d’un accès à l’API OVH

Afin de pouvoir générer un certificat wildcard via Let’s Encrypt pour un domaine géré par OVH, il est nécessaire de créer un accès à l’API OVH sur la page de création de token.

Les autorisations à accorder sont les suivantes:

GET /domain/zone/*
PUT /domain/zone/*
POST /domain/zone/*
DELETE /domain/zone/*

Une fois l’ensemble des informations renseignées et validées, la page nous génère les clés d’API que l’on prendra soin d’enregistrer dans son gestionnaire de mot de passe favori.

S’il doit être possible de lister les accès accordés et de les gérer quelque part dans les interfaces d’administration OVH, je n’ai pour l’instant pas trouvé une telle page (mais je n’ai pas non plus pris le temps d’aller à sa recherche).