Réseau – Unicoda

Adieu Netgear… Ou pas.

Avant de commencer

Petite histoire de mise à jour Netgear imposant la création d’un compte utilisateur pour l’utilisation de certains des produits.

Ou comment éviter de dire n’importe quoi, en procédant à quelques vérifications.

Adieu Netgear

Pour la gestion de mon réseau, j’avais fait le choix de m’équiper avec de l’équipement de la marque Netgear, switchs et routeurs. Envisageant de faire l’acquisition d’une switch 24 ports une bonne fois pour toutes, j’envisageais d’en choisir un de la même marque que les autres, n’ayant pas eu de problème avec les précédents.

À compter d’aujourd’hui, il y a peu de chance que ce soit encore le cas à l’avenir. En effet, avec la version 1.0.5.4 de son firmware pour le modèle de switch GC108P / GC108PP, il est nécessaire de créer un compte Netgear Cloud pour avoir accès à toutes les fonctionnalités de l’appareil en termes de configuration. Netgear, dans un élan de bonté, permet néanmoins 3 connexions sans compte. Par contre, difficile de savoir si cette obligation s’étendra à terme à tous les appareils de la marque ou non, mais une l’ajout d’une telle obligation est un signal d’alerte à considérer.

Donc en résumer, pour configurer un produit pouvant fonctionner sur un réseau interne non connecté à internet, Netgear me force à m’inscrire et utiliser un compte utilisateur chez eux. Merci, mais non merci. J’ajoute donc Netgear à la liste des marques dont je n’achèterais pas de produits à l’avenir.

Je vais aller regarder ce que propose Mikrotik, dont j’ai entendu de bons retours. Pour la partie routeur, j’utilise du matériel Netgear, mais avec un firmware alternatif; je suis donc tranquille de ce côté-là pour l’instant (sinon, je m’orienterai vers Mikrotik ou un Turris Omnia).

Adieu Netgear !

La note de mise à jour Netgear incriminée.
La discussion liée sur HackerNews.

Ou pas

Après avoir écrit ces quelques lignes, et avant de publier, je me suis forcé à effectuer quelques recherches supplémentaires. Il semble donc que ces limitations de connexion soient propres à une gamme de switchs vendus spécifiquement avec du « Cloud Management » et souvent nommé « Smart Pro » dans la gamme de produits Netgear.

Une recherche google avec les bons filtres permet d’isoler la liste des produits concernés, liste qui reste limitée. Faut-il en déduire que le fabricant déploiera cette obligation sur l’ensemble de ses produits ? L’avenir nous le dira.

Il n’y a donc finalement pas d’obligation à éviter Netgear, mais seulement la nécessité de se renseigner correctement sur le produit dont on souhaite faire l’acquisition, afin de vérifier que celui-ci conviendra pour l’usage que nous souhaitons en faire.
Comme souvent.

FreshTomato v2020.2

J’ai migré mon router vers la version 2020.2 de FreshTomato. Quelques sueurs froides en essayant de me reconnecter à l’interface d’admin. Le couple login/mot de passe à utiliser cette fois est : root/password.

Idem, si vous n’avez pas changer le nom du compte dans votre configuration, après restauration, il faudra utiliser root à la place de admin.

À première vue, toutes les fonctionnalités que j’utilise semblent fonctionner correctement. Toutefois, comme sur la version précédente, la tentative de création d’une interface sans fil virtuelle, pour la mise en place d’un réseau wifi invité séparé du réseau principal, ne fonctionne pas, car celle-ci conduit à rendre inutilisable l’ensemble des réseaux wifi configurés.

[Routeur] Firmware alternatif: passage à FreshTomato

Au début de l’année 2018, j’avais effectué de nombreuses transformation du côté de mon LAN, transformations que j’avais évoqué brièvement dans « Du côté du LAN« , s’en prendre le temps de rentrer dans les détails. A ce moment là, j’avais effectué un changement de firmware sur mon routeur R7000, afin d’utiliser AdvancedTomato. Interface moderne, gain en fonctionnalités et en personnalisation, il m’est difficile d’envisager un retour en arrière.

Petit bémol à l’horizon, il n’y a pas eu de mise à jour effectuée sur ce firmware depuis novembre 2017. C’est pourquoi, en ce début d’année 2019, j’effectue une nouvelle migration, cette fois vers FreshTomato. Le projet est actif depuis plusieurs mois déjà et semble globalement plutôt stable, d’après les retours que j’ai pu lire sur la toile. Le projet est un fork de TomatoByShibby, système qui constituait déjà la base de AdvancedTomato, AdvancedTomato apportant surtout une refonte graphique de l’interface.

Pour l’installation de AdvancedTomato, je m’étais aidé de la vidéo « Netgear R7000 – How to install Tomato-ARM » dont je retiens les étapes d’installation suivantes:

Remise à zéro de la configuration du système du routeur.
Installation de l’image initiale du firmware.
Installation de l’image AIO (All In One) du firmware.
Suppression du contenu de la NVRAM.
Redémarrage

Par ailleurs, j’avais noté cette discussion explorant les moyens de désactiver l’allumage des différentes LEDs du routeur et éviter l’effet sapin de Noël la nuit. Possibilité maintenant offerte directement dans l’interface web du firmware.

Parmi les autres informations à noter, les informations de connexion des deux images « initial » et « AIO » de FreshTomato sont les suivantes :

Initial image : admin/password
AIO image : admin/admin

Ayant eu besoin de davantage d’informations dans les logs, j’ai cherché comment augmenter le niveau de verbosité, la commande à utiliser est donc nvram set mwan_debug=8 suivie d’un nvram commit , 8 étant le niveau maximal et 0 le niveau minimal.

Après maintenant plusieurs jours d’utilisation, je n’ai pas détecté de problèmes particuliers une fois la connexion établie. J’ai toutefois rencontré quelques problèmes à l’établissement de la connexion, car celle-ci ne s’effectue pas correctement lors du premier échange de récupération des paramètres IP auprès du DHCP du fournisseur d’accès. Le routeur reçoit bien une IP (172.16.77.155) et un masque de réseau (255.255.255.255), mais pas de passerelle (0.0.0.0), donc pas de connexion WAN. Déclencher immédiatemment une demande de renouvellement du bail DHCP via le bouton renew de l’interface permet de recevoir une configuration valide. Il me semble donc que la première négociation effectué au démarrage ou après application d’une nouvelle configuration du réseau, n’envoie pas les options d’authentification 77 et 90 requises par le serveur DHCP.

Pour palier à ce problème, j’ai ajouté le script suivant dans l’onglet « WAN Up (main) », qui vérifie la présence d’une passerelle valide une fois la connexion WAN établie. Dans le cas contraire, la connexion est réinitialisée afin de forcer une nouvelle requête DHCP, valide cette fois.

if [ "$(nvram get wan_gateway)" = "0.0.0.0" ]; then
  service wan restart
fi

Afin de parer à toutes éventualités, j’ai également configuré la vérification périodique de l’IP de la passerelle, via le service de cron proposé par le firmware.

[[ "$(nvram get wan_gateway)" = "0.0.0.0" ]] && service wan restart

Reste maintenant à profiter de ce nouveau firmware et à croiser les doigts, pour que celui-ci soit aussi stable que son prédécesseur !

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.