Connexion fibre – Remplacer la livebox

En passant d’un accès adsl chez OVH, à un accès fibre chez Sosh, je me suis donc retrouvé avec une livebox sur les bras pour la connexion au réseau. N’étant pas fan de l’interface et disposant déjà d’un routeur entièrement configuré et responsable de la gestion de l’ensemble de mon LAN, j’ai donc rapidement cherché à remplacer la livebox par mon routeur tournant sous Advanced Tomato.

Pour la configuration, je me suis basé sur les deux liens ci-dessous. Le premier sur le forum lafibre.info, réunit toutes les informations nécessaires à la configuration d’un routeur sous Advanced Tomato sur le réseau d’Orange. Le deuxième complète avantageusement le premier lien, en donnant un exemple détaillé de configuration et de nombreuses informations sur le contexte de connexion à la fibre d’Orange.

Génération de l’identifiant de connexion hexadécimal

L’identifiant de la connexion orange est de la forme fti/xxxx, la partie qui nous intéresse est celle qui suit le préfixe fti/, et qu’il faut convertir en hexadécimal pour l’ajouter dans la configuration de l’option 90. Le code JavaScript suivant permet de générer la chaîne nécessaire:

function strToHex(str) {
  let result = '';
  for (let i = 0; i < str.length; i++) {
    result += str.charCodeAt(i).toString(16);
  }
  return result;
}
console.log(strToHex(xxxx));
Mise en place des options 77 et 90

Dans l’interface du routeur sous Advanced Tomato, dans la partie Administration > Scripts, onglet Init, j’ajoute le code suivant en remplaçant les xxxxxx par la chaîne hexadécimale générée précédemment :

cp -R /sbin/ /tmp/sbin
rm /tmp/sbin/udhcpc
echo 'exec busybox udhcpc -O 0x4d -O 0x5a -x 0x4d:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 -x 0x5a:00000000000000000000001a0900000558010341010d6674692fxxxxxx "$@"' > /tmp/sbin/udhcpc
chmod +x /tmp/sbin/udhcpc
mount --bind /tmp/sbin/ /sbin
Priorité et classement du trafic

Pour la suite, on ajoute de la priorité au trafic, cette fois dans l’onglet firewall :

### Version 16 20181010
### https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/

### Priorite / CoS pour Internet

# File 0 (par defaut) pour le DHCP (raw-socket), file 1 pour le reste du trafic
vconfig set_egress_map vlan832 0 6
vconfig set_egress_map vlan832 1 0

### On classe le trafic Internet dans les bonnes files

# Tout le trafic priorite 1 (CoS 0)
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001

# Client DHCP non raw-socket (pas le cas de udhcpc) mais sert aussi pour le renew
iptables -t mangle -A POSTROUTING -o vlan832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0000
Configuration du VLAN 832

Dans la partie Basic Settings > Network, partie WAN Settings, sélectionner DHCP.
Dans la partie Advanced Settings > VLAN, ajouter un VLAN supplémentaire, portant le VID 832. Pour ce VLAN, compléter les colonnes de la façon suivante :

  • WAN Port : Yes
  • Tagged : On (Colonne après WAN Port)
  • Bridge: WAN

Le reste de colonnes restent vides pour le VLAN 832. En cas de doute, se référer à l’image présente sur la page du forum lafibre.info dont le lien figure plus haut.

Conclusion

Une fois cette configuration mise en place, il ne reste plus qu’à redémarrer le routeur, et à croiser les doigts en espérant ne pas avoir fait d’erreurs de recopiage. Dans le cas contraire, il faudrait passer au débug de la configuration, ce qui est une autre paire de manche. Dernier point, s’il m’arrive de perdre la connexion, suite à un changement de configuration, ou plus généralement, après un changement de câblage ayant laisser le router déconnecté de l’ONT plusieurs minutes, je retrouve une connexion fonctionnelle en forçant le renouvellement de la connexion dans l’interface Status > Overview, encart WAN, bouton Renew.

A terme, il n’est pas impossible que je procède au changement de mon routeur R7000. En effet, Advanced Tomato ayant beau être fantastique à utiliser, celui-ci, basé sur Tomato Shibby, n’est plus mis à jour. Il faudrait que j’étudie plus en détails les implications, ou plutôt la vulnérabilité actuelle du composant aux failles de sécurité découvertes ses derniers mois. Quelques internautes semblent utiliser un routeur MikroTik en remplacement de leur livebox avec succès, c’est une piste à creuser, d’autant plus que ce n’est pas la première fois que j’entends parler de cette marque.

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.

Des Headers. En veux-tu ? En voilà !

J’ai commencé à me pencher sur HAProxy et à faire quelques tests, ce qui m’a conduit à m’intéresser aux entêtes de sécurité qu’un serveur Web peut renvoyer. Dans la même veine que SSL Labs, j’ai découvert securityheaders.io qui permet de faire rapidement le point sur les entêtes des réponses http d’un serveur pour une url donnée.

De mon côté, je me suis donc assuré de la présence des entêtes suivantes:

  • Referrer-Policy
  • Strict-Transport-Security
  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection

Configurées de la manière suivante :

http-response set-header Strict-Transport-Security "max-age=63072000;"
http-response set-header X-Content-Type-Options nosniff
http-response set-header Referrer-Policy no-referrer-when-downgrade
http-response set-header X-Frame-Options SAMEORIGIN
http-response set-header X-XSS-Protection 1;mode=block

Par ailleurs, j’en profite pour m’assurer que les informations concernant le serveur répondant à la requête ne soient pas renvoyées :

http-response del-header Server

Du coup, j’obtiens un petit A, étant donné que je n’ai pour l’instant pas intégré l’entête « Content-Security-Policy ».

Source: Securing haproxy and nginx via HTTP Headers.

Du côté du LAN

Après un long week-end de compétition au championnat de France de roller indoor, j’ai profité de la semaine de récupération qui suivait pour commencer à réorganiser mon réseau interne. Une idée que j’avais en tête depuis un moment déjà.

Au niveau de l’existant, je partais donc d’un réseau composé d’un modem-routeur OVH, d’un routeur personnel et de périphériques clients, parmi lesquelles serveur, NAS, téléphone ou encore PC. Mon objectif principal était d’arriver à me passer du matériel du FAI, afin d’exploiter mon routeur au maximum de ses capacités. Il faut préciser que le modem-routeur fournit par OVH, un technicolor TG788v2, n’est pas fantastique. Il fonctionne bien, mais l’interface n’est pas des plus intuitives, l’assignation d’IP fixe côté DHCP est une plaie et je me retrouvais avec un double NAT pas des plus pratiques.

En remplacement du routeur, j’ai donc fait l’acquisition d’un petit modem compatible avec les caractéristiques de ma ligne OVH, à savoir un DM200 de chez Netgear. J’ai configuré ce dernier en mode bridge, pour confier la gestion du réseau à mon routeur. En parallèle, j’ai migré le-dit routeur (un R7000) vers le firmware alternatif AdvancedTomato pour bénéficier de nombreuses nouvelles possibilités de configuration. Il aura fallu quelques heures pour trouver une première configuration satisfaisante, notamment du côté de la redirection de ports qui ne voulait pas fonctionner à cause d’un paramètre particulier de la configuration WAN.

Par la suite, j’ai cherché à configurer le serveur OpenVPN disponible avec Tomato. Après plusieurs essais, j’ai enfin réussi à me connecter au VPN depuis mon téléphone et à écouter avec satisfaction un fichier de musique en provenance de mon NAS. Les fichiers Flac ont malheureusement du mal à passer, la faute au peu de débit montant des connexions internet traditionnelles. Cela permettra au moins d’éviter l’explosion de la consommation de données du forfait mobile. Restait encore le problème de la ligne téléphonique. Après ajout d’un petit boîtier Cisco nommé SPA112 et connexion d’un téléphone sur l’un de ses ports RJ11, le problème était résolu.

Tous ces changements m’ont obligé de ressortir un switch inutilisé pour disposer de plus de ports, pouvoir connecter un Raspberry Pi, et commencer la suite des opérations à savoir : étudier les possibilités offertes par Ansible et par LXC dans leur domaine respectif. Le WakeOnLan figure lui aussi en bonne position sur la liste des choses à tester pour une éventuelle intégration dans l’architecture globale du réseau.

En bref, de nombreuses idées, de nombreuses pistes à explorer et une structure de réseau à valider par l’usage quotidien des prochaines semaines !