Sébastien Warin

Suite à l’installation de la fibre Orange à mon domicile  fin décembre, je vous propose ici une découverte de la fibre optique et notamment de la technologie GPON déployée par Orange.

Vous découvrirez aussi comment configurer l’Internet, la TV et la téléphonie sans Livebox, en utilisant votre propre routeur, dans mon cas un Mikrotik RB3011 sous RouterOS.

Une petite découverte de mon réseau local (focus sur la partie réseau et non sur les serveurs/systèmes), de l’IGMP, du serveur de téléphonie Asterisk ainsi que de la solution de supervision Cacti.

J’ai initialement écrit ce guide sur lafibre.info (à lire en intégralité) mais je vous propose ici une version “remasterisée” pour les lecteurs de mon blog.

Même si ce n’est pas tout à fait dans ma ligne éditoriale habituelle (développement, IoT, Constellation & co…), vous découvrirez en fin d’article que Constellation n’est jamais très loin même sur des sujets comme celui-ci

La fibre optique et le fonctionnement du GPON

Avant de se plonger tête baissée dans la configuration d’un réseau domestique basé sur la fibre d’Orange, il est intéressant voire indispensable de comprendre comment fonctionne la fibre optique et notamment celle mise en place par Orange avec la technologie GPON.

La fibre optique

Je passe les généralités sur la FTTB, FTTCab, FTTH, FTTLa & co… En clair tout dépend jusqu’où arrive la fibre et où est-ce que le cuivre prend le relais. En France et pour les particuliers, on a surtout du FFTLa (la fibre jusqu’au dernier amplifier, le reste jusque l’abonné est en coaxial : réseau Numéricable) et la FTTH, c’est à dire une fibre du NRO de l’opérateur (FAI) jusqu’au domicile de l’abonné.

Citons aussi le FTTB (jusqu’au pied de l’immeuble), la FTTC/Cab (au sous répartiteur ou trottoir) ou FTTN (au répartiteur) qui permet ensuite de proposer des offres VDSL ou ADSL (NRA-MeD) à l’abonné.

En FTTH deux solutions principalement :

• Point à point (p2p) : une fibre dédiée du NRO au domicile (= une fibre par abonné)
• Point à multipoint (p2mp) : une fibre du NRO pour plusieurs domiciles (mutualisation d’une même fibre avec l’utilisation de coupleur optique)

 

On peut également citer le « FTTH Active Ethernet », un mix des deux qui consiste essentiellement à éclater le NRO vers les PM (point de mutualisation) de façon à câbler de la même manière qu’un réseau multipoint (= une fibre du NRO au point de mutualisation) avec les avantages d’un réseau P2P (= fibre branchée directement sur le switch, sans mutualisation avec d’autre fibre). L’inconvénient étant le fait d’avoir des équipements actifs (switches) tout au long du réseau de distribution. Tout cela est déjà bien expliqué ici.

Dans ces fibres l’idée est donc de faire passer de la lumière pour véhiculer des informations. Plusieurs familles existent :

• la fibre multi-mode
• la fibre mono-mode

Le « mode » n’a rien à voir avec la longueur d’onde comme on peut le voir parfois sur internet. En fait la fibre multi-mode (à saut d’indice, la plus répandue) a un diamètre relativement grand par rapport à la longueur d’onde de la lumière (dans l’infrarouge).

On a donc plusieurs « chemin » pour une même impulsion lumineuse. De ce fait on obtient une distorsion et dispersion de la lumière ce qui ne va pas aider à reconstituer le signal. Elle est parfaite pour de petite distance (et donc très utilisée dans les datacenters).

La fibre « mono mode » a un diamètre si petit que les angles d’incidence sont quasi inexistant ce qui permet d’envoyer la lumière dans un « seul chemin » (= mono mode), de ce fait la dispersion est quasi-nulle.

Bien entendu cette fibre coûte plus chère mais elle fournit la meilleure qualité. Aussi on est obligé d’utiliser un laser dans de type de fibre (à l’inverse des fibre multi-mode où on utilisera des LED) car le diamètre du cœur est si petit qu’on a besoin d’une grande puissance d’émission.

Les architectures FTTx et notamment les normes du GPON utilisées par Orange imposent la fibre mono-mode.

Une fibre étant bien sur bi-directionnelle car on peut utiliser des lasers réglés sur des longueurs d’onde différentes, c’est un peu comme les fréquences radio. On appelle cela le « multiplexage spatial ». De ce fait on peut avoir une longueur d’onde pour l’émission et une autre pour la réception afin d’obtenir une communication bidirectionnelle dans une seule fibre optique.

Le GPON : Gigabit-capable Passive Optical Network

Pour revenir à la FTTH d’Orange,  on utilise une seule fibre pour faire passer le « downstream » (flux descendant) et le « upstream » (flux montant) en utilisant deux longueurs d’onde différentes (1310 et 1490nm respectivement) pour une bande passante pouvant aller jusqu’à 2.5Gbps dans les deux sens (il y a en fait 7 combinaisons de vitesse de transmission dans la norme mais la plus répandue étant de 1,25Gbps en uplink et 2,5Gbps en downlink).

Côté NRO on a un “OLT”, un Optical Line Termination, un équipement permettant de gérer les trafics descendants et montants d’un arbre PON composé de plusieurs ONT/ONU.

Coté abonné, on a devant le modem/routeur un ONU aussi nommé ONT selon la norme (Optical Network Unit ou Terminaison) :

La fibre partant du domicile (accessible sur la PTO, la prise mural chez l’abonné) rejoint le PBO (point de branchement) sur la voie publie ou sur le palier dans un immeuble et remonte jusqu’au PM (point de mutualisation) qui peut être un PMZ,  point de mutualisation de zone (armoire de rue couvrant un quartier), un PMI (point de mutualisation d’immeuble) ou un PMR (point de mutualisation de rue pour les immeubles de moins de 12 logements).

 

Jusque-là on est en point à point (p2p) et c’est ici que les FAI peuvent se connecter sur notre fibre.

En GPON, « notre » fibre est mutualisée avec d’autre via des coupleurs optiques (équipement passif = non alimenté).

Le ratio de « splittage » des fibres est de 1:64 voire 1:128 (en fonction de la classe GPON utilisée, donc en fonction des spécifications de la puissance du laser utilisé). C’est-à-dire qu’on a 64 (ou 128) fibres qui se rejoignent en une au niveau du point de mutualisation (PM) grâce aux différents niveaux de coupleurs et qui elle remonte jusqu’au NRO pour être connectée à un OLT.

Tout cela est décrit dans la norme G984.1.

Le downstream

En descente, l’OLT « broadcast » le trafic des 64 (ou 128) fibres à tout le monde sur l’arbre (car la fibre est splittée via les coupleurs). En fait l’OLT émet dans la fibre à un intervalle de 125uS des frames contenant des données (payload) précédées d’un « PCBd » (Physical Control Block Downstream), une sorte d’entête qui définit (entre autre) « à qui » est destiné le « payload ».

On trouvera aussi dans le « PCBd » le « Uplink Bandwith Map » qui définit comment se partager la bande passante « Uplink » (on y reviendra après).

Le PCBd est en clair, donc dans chaque foyer, l’ONT/ONU connecté sur la prise optique (PTO) « lit » le signal optique pour sélectionner les « payloads » qui le concerne (défini dans le PCBd).

Question sécurité, une fois le payload récupéré pour un ONT/ONU donné, il faut le déchiffrer car tout le monde reçoit le trafic de tout le monde sur l’arbre GPON. Le payload est donc chiffré en AES 128bits (spec G.984.3).

Pour entrer dans le détail, au moment de l’identification de l’ONU sur l’arbre GPON, l’ONU envoi à l’OLT son S/N pour s’identifier. Si l’ONU est bien reconnu sur le réseau, l’OLT demande (c’est optionnel dans la norme mais utilisé dans le réseau Orange) le mot de passe (Request_Password).

D’après ce que j’ai compris, pour Alcatel on nomme cela le « Subscriber Location ID » ou SLID. On trouve aussi l’acronyme LOID. Ce mot de passe est entré dans l’ONU soit via une interface Web ou telnet par le technicien de l’opérateur. La « box » (routeur) de l’opérateur peut aussi programmer lui même et de manière transparente l’ONT (ce qui semble être le cas avec le nouvel ONT au format SFP  utilisé par la Livebox 4 chez Orange/Sosh).

Si le mot de passe est le bon, l’OLT demande ensuite une clé de chiffrement « Request_Key » et c’est l’ONU qui la choisie et l’envoi à l’OLT. Ainsi les deux parties (ONU & OLT) ont connaissance d’un secret commun qui servira de clé de chiffrement pour les données descendantes.

Notons que cette clé de chiffrement est envoyée en clair à l’OLT, la sécurité étant assurée par le fait qu’avec la typologie du réseau GPON, on ne peut pas snifer le trafic en montée (à moins d’avoir un accès physique à la fibre).

L’upstream

Côté « uplink », comme tous les signaux optiques émis par les ONU sont “fusionnés” dans la même fibre par les coupleurs optiques et comme la norme définie qu’une seule et unique longueur d’onde pour tout le monde, on est obligé de multiplexer par le temps (TDMA), c’est à dire qu’il ne peut y avoir qu’un seul ONU émetteur au même moment : chacun à son temps de parole.

Cette synchronisation est organisée dans le « Upstream Bandwidth Map » qu’on reçoit régulièrement (toutes les 125uS) dans chaque « PCBd » du downstream. Cette « map » contient « l’ordre de passage » des « T-CONT ».

Les T-CONT (Transmission Containers) sont des conteneurs qui « bufferise » les données à envoyer en attendant d’avoir une fenêtre de tir pour les envoyer. L’ONU envoie donc les données dans l’arbre en fonction des slots (on parle de « time slot ») qu’on lui a alloués dans la « Upstream Bandwidth Map ».

Cette « map » d’allocation de la bande passante est négociée dynamiquement via le protocole DBA pour « Dynamic Bandwidth Assignment ».

Le DBA prend en charge une notion de SLA pour allouer le temps de parole.  En effet un  « T-CONT » est associé à un type (video, audio, data, …). On peut donc prioriser du flux montant en fonction des services (par exemple la voix est prioritaire sur les datas). On peut aussi garantir une bande passante minimale et garantie.

Si je suis le seul à vouloir émettre sur mon arbre GPON, alors le DBA m’allouera la quasi-totalité de la bande passante en uplink car il n’y aura que mes « T-CONT » qui seront référencés dans la « Upstream Bandwidth Map » (vu que personnes d’autre n’a de donnée, donc de T-CONT, à envoyer).

De ce fait pour que cela fonctionne, l’ONU envoie également dans les données montantes un « DBA report » (dans les headers des frames Upstream). Ce « rapport » DBA permet à chaque ONU d’informer l’OLT de ce qu’il a à envoyer sur le réseau, c’est à dire combien de « T-CONT » en attente, de quel type et à quelle taille.

En collectant les « DBA report » des différents ONU de l’arbre, et en fonction du type et de la taille de chaque « T-CONT », l’OLT peut donc allouer la bande passante de montée en informant chaque ONU de ses « time-slots » via la  « Upstream Bandwidth Map » contenu dans chaque frame en downlink. Ce mode est appelé SR-DBA pour Status Reporting.

A noter aussi un autre mode de fonctionnement du DBA le NSR-DBA (Non Status Reporting) qui se base le trafic actuel pour calculer le taux d’utilisation et donc prédire et allouer le trafic à venir en tenant compte des limites de l’arbre.

Ainsi on comprend bien que l’ONT/ONU installé chez l’abonné est bien plus qu’un simple “media converter” entre la fibre optique et le cuivre (RJ45).

Pour plus d’info, je vous renvoie vers mon post initial ici.

L’installation de la fibre optique

C’est donc un peu avant noël qu’une équipe arrive à la maison pour tirer une fibre du PBO (Point de Branchement Optique) installé sur ma façade jusque ma cave où j’ai installé ma baie réseau.

On commence donc par installer le PTO (Prise de Terminaison Optique) juste à côté de la baie dans la cave :

Puis on remonte jusqu’à la façade extérieure en passant par le garage. Le travail est simplifié car j’ai installé des goulottes il y a plusieurs années pour passer l’ensemble de mes câbles RJ45/domotique/alarme de la maison.

Arrivé dehors il ne reste plus qu’à amener la fibre dans le PBO et la souder avec la première fibre disponible qui elle remonte jusqu’au PMZ (armoire de rue).

Pour rappel il deux paires de 6 fibres dans chaque PBO (6 logement par PBO + 6 fibres de libre en réserve).

Il y a un code couleur en fonction du numéro de la fibre. Dans mon cas, je suis le 1^er à être connecté sur ce PBO, j’ai donc la fibre de couleur rouge (à gauche les fibres disponibles, à droite les fibres utilisées).

Dernière étape : se rendre au PMZ et vérifier l’atténuation de la fibre pour être sûr que le signal optique est OK de ma cave (PTO) jusqu’au point de mutualisation (ici un PMZ).

Enfin on connecte ma fibre (qui arrive ici en H7 du 1^er module) à l’arrivée la fibre Orange une fois éclatée par les coupleurs optiques.

Voilà, je suis connecté au réseau GPON d’Orange !

J’ai pris ensuite le temps d’installer proprement l’ONT sur le mur et de le connecter sur mon réseau filaire. L’alimentation de l’ONT, comme pour la baie réseau, est assurée par un onduleur APC ici en noir sur la droite de la photo.

On voit ci-dessous l’ONT Huawei en haut avec ses petites LED vertes et la PTO à gauche de la prise téléphonique plus bas. J’ai bien sûr pris soin d’enrouler (ou « lover » pour les intimes) la jarretière entre l’ONT et la PTO.

Cet ONT est ensuite connecté sur mon switch Netgear (un GS724T), le cœur de réseau, lui-même connecté sur mon routeur Mikrotik (un RB3011) :

Avant la fibre : mon réseau avec Numéricâble

Comme dirait la célèbre maxime, « il faut savoir d’où l’on vient pour comprendre où l’on va » ! J‘étais chez Numéricâble depuis plus de 3 ans avec la « La Box » un boitier tout en un avec le décodeur TV, le modem/router et AP Wifi avec d’abord 30 méga de bande passante (et 1 méga en montée) puis début 2015, 200 méga et 20 en montée avec l’arrivée de la fibre dans l’armoire de rue (FTTLa). Bref très correct !

Comme toujours la « box » de l’opérateur n’est pas à la hauteur, partie routage/firewall très ou trop simple, des bugs dans le serveur DHCP, Wifi correct mais sans plus, bref, à peine installée et aussitôt désactivée à son maximum (wifi off et mode bridge activé).

Les services DNS/DHCP/VPN sont assurés par un contrôleur de domaine AD sous Win2012R2, l’AP Wifi par un Netgear R8000 sous DD-WRT, le routage/firewall par un Mikrotik RB3011UAS et un switch Netgear GS724T comme cœur de réseau. Toute la maison étant câblée en Cat6a S-FTP.

Le coaxial NC arrive dans le salon, connecté sur « LaBox » elle-même branchée en HDMI à la TV (pour être exact, tout est branché sur l’ampli home-cinéma lui-même relié à la TV). La partie « TV » de Numéricâble est donc simple à mettre en place car il n’y a qu’à brancher la box en HDMI pour profiter des services TV/VOD.

Pour la partie « Net », la box est configurée en « mode  bridge ». Elle est physiquement connectée sur un petit switch TP-Link 8 ports manageable (un TL-SG108E) dans le meuble TV sur le VLAN nommé « WAN » (PVID 20 dans mon cas). Sur ce switch, il y a aussi d’autre équipement comme la TV, l’ampli ou encore un Intel NUC (média-center) sauf que tous ces devices sont sur le VLAN « LAN » (PVID 10). Pour finir, le dernier port de ce switch est « taggé » (802.1q) et est connectée sur la prise RJ45 murale du salon qui descend jusque dans la cave, brassée sur le GS724T. On a donc un lien « Trunk » entre la cave et le salon pour faire passer les deux VLAN « WAN » et « LAN ».

Sur le GS724T j’ai un port est dédié au « WAN » (VLAN 20) qui sort « non taggé » pour être connecté sur l’ « ether1 » (le 1^er port) du RB3011 sur lequel est configuré un client DHCP pour la connexion Internet via le réseau NC. Une règle de NAT redistribue l’Internet sur le port 6 (ether6, soit le 1^er port du 2^ème switch du routeur) connecté sur le GS724 sur un port PVID10 qui représente le VLAN « LAN ».

De ce fait, même si « LaBox » est dans le salon, on a bien le routeur RB3011 en frontal pour la partie Internet, la Box étant complètement isolée du reste du LAN dans lequel on retrouve la TV, Ampli, Nuc, l’AP R8000 ainsi que mes différents serveurs, PC, laptops, smartphones, box domotique et autre objets connectés de la maison.

Pour résumer (le VLAN « LAN » en bleu, le VLAN « WAN » en vert et en violet le lien trunk) :

Ps : le schéma se focalise sur les équipements autour de la box NC et non sur l’ensemble du réseau résumé par le picto « Réseau LAN ».

Avec la fibre : mon nouveau réseau avec Orange/Sosh

Avec l’installation de la fibre Orange l’idée est de garder la même architecture sauf que maintenant l’arrivée de la fibre est dans la cave (et non le salon), que la LiveBox n’a pas de mode « bridge » (et hors de question de faire du « double NAT») et que la partie TV est gérée par un autre boitier, le décodeur TV.

De ce fait, comme vous l’avez vu dans sur photos ci-dessus de ma cave, la fibre arrive sur l’ONT accroché au mur lui-même connecté en RJ45 sur le GS724T.

Sur ce GS724T j’ai dédié les deux premiers ports aux VLAN 832 (internet), 838 (VOD/Replay) et 840 (multicast pour la TV). Ces deux ports (g1 et g2) étant configurés en «VLAN Only » et « Ingress Filtering », c’est-à-dire qu’il ne peut y avoir que des trames taggées sur ces 3 VLANs là (et seulement ceux-là).

Sur le « g1 » on connecte l’ONT et sur le « g2 », l’ « ether2 » du routeur. Autrement dit l’interface « ether2 » du routeur est connecté à l’ONT avec le GS724T comme intermédiaire. A ce stade j’utilise « ether2 » pour le « WAN » Orange car « ether1 » est toujours utilisé provisoirement par la box NC.

Le fait d’avoir le switch comme intermédiaire entre l’ONT et le routeur est facultatif. Personnellement cela me sert pour le « port mirroring » à des fins d’inspection.

Cela peut servir aussi pour marquer les requêtes DHCP avec le CoS 6 comme expliqué ici car dans certaines zones les requêtes DHCP doivent obligatoirement être encapsulées dans des trames Ethernet marquées avec la priorité 6.

Ceci dit ce marquage « CoS 6 » des requêtes DHCP peut être fait directement par le Mikrotik avec un bridge, j’explique la procédure ici.

Pour ma part Orange m’attribue bien une IP quel que soit la priorité de ma requête. Il semble donc que je sois dans un zone où le marquage « CoS » du DHCP n’a pas d’importance.

Pour continuer la description de l’installation « physique », sur le RB3011 on a toujours l’ « ether6 » pour le LAN et j’utilise le 7^ème port « ether7 » pour la TV. En fait, l’ancien VLAN « WAN » (PVID 20) est renommé en « TV ». J’ai donc un câble qui part de l’ « ether7 » du routeur et entre sur un port du switch pour être taggé « TV » (PVID 20) afin de pouvoir circuler dans le lien trunk jusqu’au salon et ressortir non taggé sur le décodeur TV qui a pris la place de la box NC.

Sur ce point on aurait pu se servir de l’interface « ether6 » qui relie déjà le routeur au switch pour le LAN ET la TV en associant sur cette interface les deux VLANs « LAN » (le 10) et « TV » (le 20). Personnellement, avec le nombre de port sur le GS724 et sur le RB3011, je n’ai pas de besoin particulier à économiser du câble donc j’ai préféré séparer le deux VLANs physiquement. De plus cela présente un avantage car l’écran LCD en façade du routeur permettant d’afficher les stats des interfaces ne fonctionne qu’avec des interfaces physiques et non des VLANs.

Pour le réseau Wifi “Invité”, j’utilise le port 8 (ether8) du routeur et pour finir j’ai, lors de mes tests/installation, utilisé le port 9 « ether9 » pour connecter la LiveBox par son port WAN. Cela m’a permis dans un 1^er temps d’utiliser la TV ou encore le téléphone via cette LB avant de la supprimer complètement comme nous allons le découvrir.

Pour résumer, on a toujours le VLAN « LAN » en bleu, le VLAN « TV » en vert, en violet le lien trunk « LAN/TV » et l’arrivée Orange de l’ONT en « jaune » qui encapsule les VLAN 832/838/840 :

Ps : encore une fois, le schéma se focalise sur les équipements autour des équipements Orange et non sur l’ensemble du réseau résumé par le picto « Réseau LAN ».

Configuration des interfaces

Pour résumer la configuration des interfaces sur mon routeur :

• « ether2-WAN » vers ONT Orange (via le switch mais c’est optionnel)
• « ether6-LAN » vers le switch PVID10 (le réseau LAN)
• « ether7-TV » vers le switch PVID20 (le réseau dédié à la TV)
• « ether8-GUEST » vers le switch PVID11 (le réseau Wifi dédié aux invités)
• « ether9-LB » vers le port WAN de la Livebox (optionnellement)

Tous les autres ports sont désactivés et bien sûr aucune de ces interfaces n’a de « master port » (notion propre à Mikrotik, « sans master port » = chaque interface est indépendante).

Pour les VLANs on a :

• Le VLAN 832 pour Internet, le 838 pour la VOD/Replay et le 940 pour le multicast TV sur l’interface “ether2-WAN” (l’arrivée de la fibre via l’ONT)
• Optionnellement, pour la Livebox, on ajouter le VLAN 832 sur l’interface 9 sur laquelle on pourra connecter la LB (que j’explique ici)

Configurer Internet sans la Livebox

Comme vous l’avez compris j’utilise le VLAN 832 d’Orange pour me connecter sur Internet. Sur ce VLAN on doit se connecter au réseau via DHCP. Il existe aussi une deuxième manière de se connecter sur Internet, en utilisant le PPPoE sur le VLAN 835.

Je n’ai pas trouvé de source « officielle » mais tout le monde sur ce forum s’accorde à dire que le PPPoE est amené à disparaitre ce qui parait d’ailleurs logique. En PPPoE on perd 8 octets dans chaque trame Ethernet (occupé par le protocole PPPoE) ce qui fait baisser le MTU à 1492. De plus en DHCP on n’a pas de mécanisme de déconnexion et en renouvelant le bail DHCP avant son expiration on obtient quasiment une IP « fixe ». Bref, autant partir sur le DHCP pour tous ces avantages.

De ce fait, pour se connecter sur Internet via le VLAN 832, il suffit juste d’utiliser un client DHCP en ajoutant deux options :

• Option 77, le “User-Class” qui doit être « +FSVDSL_livebox.Internet.softathome.Livebox3 »
• Option 90, « Authentication » qui doit être votre login Orange (fti/xxxxxx) en hexa précédé de 22 zéros, par exemple : « 0x00000000000000000000006674692f64656D6F6465736562»

Sur Mikrotik vous pouvez définir les options soit en hexa en commençant par “0x” ou soit en ASCII en entourant votre valeur par des simple quotes « ’ ».

Cependant pour l’option 90, comme il y a 22 zéros devant vous êtes obligés d’utiliser la nomenclature en hexa.

De ce fait, vous prenez votre login Orange, par exemple « fti/demo » que vous convertissez en hexa (via http://www.asciitohex.com/ par exemple) ce qui vous donne « 66 74 69 2f 64 65 6d 6f » et vous ajoutez 22 zéros devant, ce qui revient à ajouter sur votre routeur l’option suivante :

Donc pour résumer sur le Mikrotik on déclare les deux options indispensables pour Orange :

Puis il ne nous reste plus qu’à ajouter un client DHCP sur le vlan 832 de l’interface 2 où nous avons connecté notre ONT en ajoutant ces deux options :

J’envoie également dans la requête les options de base « clientId » et « hostname » de RouterOS.

Et voilà, votre routeur est connecté sur le réseau Internet d’Orange !

N’oubliez pas ensuite d’ajouter une règle de NAT pour distribuer l’internet sur le réseau LAN :

Et libre à vous de configurer votre firewall ou les queues comme bon vous sembles, le Mikrotik est très complet dans ce domaine.

A ce sujet, n’oubliez pas de configurer vos interfaces sur une queue de type FIFO comme la « ethernet-default » :

En effet par défaut les interfaces du Mikrotik sont configurées en « only-hardware-queue ». Les queues gérées en « hardware » sont seulement bénéfiques dans le cas où les paquets qui transitent par l’interface n’ont pas besoin de solliciter le CPU, par exemple dans le cas d’interfaces avec master port (où le routeur ne sert que de commutateur).

Par contre, si vous avez des règles Mangles, firewall ou NAT qui s’appliquent sur une interface, les paquets qui y transitent solliciteront nécessairement le CPU du routeur pour l’exécution de ces règles. Et dans ce cas-là, il faudra utiliser une queue « software », beaucoup plus performante.

Configurer les services TV sans la Livebox

La partie Internet était plutôt facile à mettre en place, pour la TV ça se complique un peu !

Une première solution, la plus facile, est d’utiliser la Livebox pour connecter notre décodeur TV comme expliqué ici. Il suffit en effet de connecter la LiveBox derrière votre routeur pour lui « faire croire » qu’elle est connectée directement sur le réseau Orange (que je détaille ici) puis créer un pont (bridge) pour le VLAN 838 (VOD/Replay) et le VLAN 840 (Multicast TV) entre l’ONT (ether2) et la LiveBox (ether9). Vous pourrez ensuite connecter votre décodeur TV sur l’un des ports LAN de la Livebox afin de profiter des services TV/VoD.

Mais honnêtement c’est un peu l’usine à gaz et si comme moi vous souhaitez économiser la consommation électrique de la Livebox, nous allons configurer le nécessaire pour pouvoir la ranger définitivement dans son carton !

Connecter le décodeur TV au réseau

Comme expliqué ci-dessus, j’utilise l’interface « ether7 » du routeur pour les services TV. Concrètement, il y a un câble réseau entre l’« ether7 » (nommée « ether7-TV » sur le routeur) et le port « g8 » de mon switch GS724T. Ce port est assigné au VLAN « TV » (PVID 20) car je ne souhaite pas connecter le décodeur TV sur mon réseau local, je préfère isoler mon réseau LAN du réseau TV Orange dans lequel on aura le décodeur.

Il y a ensuite un lien trunk du switch GS724T de la cave vers le switch du salon (le TP Link SG108E) pour pouvoir ressortir sur le port n° 2 détagué côté le salon où l’on connecte le décodeur TV.

Pour rappel :

En clair, le décodeur TV est le seul device connecté sur l’interface « ether7 » du routeur avec les deux switches en intermédiaire.

La première étape consiste donc à donner une IP au décodeur dans un réseau propre au VLAN TV. Dans mon cas j’ai choisi le réseau 192.168.42.0/24.

Mon routeur Mikrotik, sur l’interface 7, aura l’adresse IP 192.168.42.254 et l’on ajoutera sur cette interface un serveur DHCP pour fournir une IP au décodeur TV avec les serveurs DNS d’Orange (obligatoire) et l’IP de notre routeur comme passerelle.

Pour configurer l’adresse IP pour l’interface TV (ether7) du routeur :

Puis pour ajouter un serveur DHCP sur cette interface :

Et voilà, votre décodeur est maintenant connecté sur le réseau local 192.168.42.0/24 sur le VLAN local « TV ».

Configurer le firewall pour le décodeur TV

Avant d’aller plus loin configurons tout de suite le firewall pour n’accepter que le strict nécessaire pour consommer les services TV/VoD et autre (Deezer, radios, etc..) depuis le décodeur.

Pour simplifier les règles au niveau du firewall, j’ai créé une liste d’interface propre à la TV qui regroupe donc les vlan 838, 840 et l’interface locale « ether7 » sur laquelle on a connecté notre décodeur :

Pour les règles sur la chaine “input” il faut autoriser :

• Le flux TV (RTP sur les ports UDP 8200 et 8202) depuis le vlan 840
• Le service UDP 5678 depuis les VLAN 838 et 840
• L’IGMP depuis le vlan 840 et l’ « ether7 » (on verra pourquoi un peu plus bas !)

Implicitement on autorise également le DHCP depuis l’« ether7 » pour que le décodeur puisse obtenir son IP mais comme c’est le routeur Mikrotik qui est lui-même le serveur DHCP sur cette interface il n’y a pas besoin de déclarer cette règle (= règle implicite).

En transit sur le routeur (chaine « forward »), on autorisera :

• Les requêtes DNS & NTP depuis « ether7 » vers le VLAN 832 (internet)
• Le trafic http/https toujours depuis « ether7 » vers le VLAN 832 indispensable pour le programme TV, les radios, Deezer, etc…
• Le flux TV (RTP sur les ports UDP 8200 et 8202) depuis le vlan840 vers « ether7 »
• Le flux VOD/replay (udp 5000) depuis « ether7 » vers le vlan 838
• Les services VOD/replay (https et tcp 8554) toujours depuis « ether7 » vers le vlan 838 indispensable pour naviguer dans le catalogue

Le reste du trafic est bloqué. On a bien sûr déjà configuré une règle de NAT pour sortir sur internet via le VLAN 832 précédemment, on ajoutera ici une nouvelle règle NAT pour sortir sur le VLAN 838 afin d’accéder à la VOD :
A ce stade votre décodeur doit pouvoir se connecter sur votre réseau « TV », afficher l’heure (NTP) et se connecter sur des applications comme Deezer, la radio ou encore le programme TV.

Les services VOD et Replay

Tout comme l’internet, votre routeur doit se connecter sur le réseau VoD (VLAN 838) en DHCP. Et comme pour le VLAN 832, il faut spécifier certaines options dans la requête DHCP pour obtenir un bail.

Ces options obligatoires sont :

• Option 60, le “Class Identifier” qui doit être “sagem”
• Option 61, le “Client Identifier” qui doit être l’adresse MAC de la Livebox
• Option 77, le “User-Class” qui doit être « +FSVDSL_livebox.MLTV.softathome.Livebox3»

On ajoute l’option 61 en “hexa” en commençant par “0x01” suivit de l’adresse MAC de votre Livebox (sans les “:”). Vous trouverez votre adresse MAC sous la Livebox.

De ce fait pour ajouter ces options en considérant que la MAC de ma LB est “5E:FF:56:A2:AF:15”, on écrira :

Notez que les noms (name) ne servent qu’à identifier les options sur votre routeur. Tout ce qui est transmis dans la requête DHCP c’est le « code » et la « value » de chaque option. Vous pouvez donc nommer vos options comme bon vous sembles.

Enfin on déclare le client DHCP sur le vlan 838 de l’ONT avec les options créées ci-dessus :

Et voilà, vous obtenez une adresse IP en 10.x.x.x/22 de la part d’Orange et vous pouvez maintenant profiter des services VOD/Replay sur votre décodeur.

Recevoir la TV

Il ne reste plus maintenant qu’à supporter la TV et pour cela il faut d’abord comprendre son fonctionnement.

Multicast et IGMP

Les chaines TV sont « multicastées », c’est-à-dire qu’Orange diffuse le flux de chaque chaine en temps réel (par le protocole RTP) sur des adresses multicast (224.0.0.0/4) distinctes.

Lorsque vous regardez une chaine, vous vous abonnez au groupe multicast de la chaine sélectionnée en utilisant le protocole IGMP (Internet Group Management Procotol). Ainsi les équipements réseaux jusqu’à votre décodeur vous achemineront le flux TV (groupe) pour lequel vous êtes abonnés (c’est-à-dire la chaine que vous regardez). Lorsque vous changez de chaine vous vous abonnez à un nouveau groupe et donc, par la même occasion, vous vous désabonnez du groupe de la chaine précédente.

Pour vous abonner à une chaine, c’est-à-dire à un groupe multicast, le décodeur Orange envoie une requête IGMP de type « Membership Report » au routeur multicast et quand vous quittez un groupe (la chaine précédente par exemple), le décodeur envoie à ce routeur multicast un message IGMP de type « Leave Group » (supporté depuis la version 2 du protocole IGMP).

En plus de cela, le routeur multicast envoie régulièrement des messages de type « Membership Queries » afin de savoir « qui » est dans le groupe. Chaque client/abonné doit répondre aux sollicitations du routeur qui envoi ces « Membership Queries » (que l’on nomme « requérant » ou « Querier ») par des « membership reports » afin de confirmer les abonnements en cours.

Le décodeur TV doit donc répondre à chaque interrogation du routeur pour confirmer sa présence dans le groupe afin de continuer à recevoir le flux vidéo (cela évite de rester abonné à un groupe si par exemple le décodeur n’a pas pu envoyer un message de type « leave » quelle que soit la raison, suite à une coupure réseau ou un arrêt brutal du décodeur par exemple).

Enfin, il faut savoir que le décodeur TV n’est pas directement connecté au routeur multicast d’Orange mais à la Livebox qui opère en tant que « proxy IGMP » sur le réseau local.

Sans Livebox c’est donc à notre routeur d’assurer ce rôle de « proxy IGMP ».

Installer l’IGMP Proxy sur RouterOS

Tout d’abord la fonctionnalité « IGMP Proxy » sur un routeur Mikrotik fait partie du package « multicast » qui n’est pas préinstallé par défaut. Il faudra donc télécharger les « Extra packages » sur la page http://www.mikrotik.com/download.

Comme mon routeur RB3011 est basé sur l’architecture ARM, je télécharge les « Extra packages » pour ARM. Une fois ce ZIP téléchargé vous pourrez retrouver dans son contenu le fichier «multicast-6.XX-arm.npk».

Pour installer le package, il suffit d’uploader le fichier dans la « File List » (fenêtre « Files » sur Winbox) de votre routeur puis le redémarrer. Au démarrage du routeur, les fichiers « npk » présent dans la File List seront automatiquement installés. En vous reconnectant avec Winbox ou via l’interface Web, vous trouverez les fonctionnalités « IGMP Proxy » et « PIM » dans le menu « Routing ».

Configuration du routeur multicast

Nous allons ensuite définir une adresse IP statique pour l’interface VLAN840, par exemple 192.168.255.254 (vous pouvez utiliser n’importe quelle IP privée ça n’a pas d’importance) :

Enfin il ne reste plus qu’à activer le proxy IGMP avec le vlan840 en « upstream » et l’interface « ether7 » en « downstream » :

Et voilà, c’est tout ! Vous pouvez maintenant regarder les différentes chaines TV depuis votre décodeur Orange si et seulement si aucun switch entre le décodeur et votre routeur n’a activé l’IGMP Snooping (voir le chapitre suivant).

Optionnellement, on peut également ajouter une queue pour prioriser le trafic du flux TV sur le routeur. D’abord on marque les paquets en transit (forward) qui entrent sur le vlan 840 et qui sortent sur l’interface « ether7 » :

Puis on crée une queue avec une plus haute priorité que la normale (> à 0) pour chaque paquet marqué « tv » :

En plus de cela, au niveau de mon switch Netgear, l’ « ether7 » est connectée sur le port « g8 » qui est encapsulée dans le VLAN « TV » (PVID 20) avec une priorité (802.1p) fixée à « 5 », soit plus que la normale. Sur le switch du salon, la QoS est également gérée par les entêtes 802.1p.

Ainsi tout le trafic du VLAN « TV » entre le routeur et le décodeur sera prioritaire sur tout le reste du réseau (à l’exception de la VoIP que j’ai configuré avec une priorité encore plus importante chez moi).

Pour aller plus loin et bien comprendre l’IGMP : Snooping & Querier

Comme nous l’avons vu plus haut, pour regarder une chaine on s’abonne à son groupe multicast en envoyant un message IGMP nommé « Membership Report » au routeur multicast, dans notre cas le routeur Mikrotik qui est un proxy vers le routeur multicast d’Orange. Une fois abonné on reçoit donc le flux de chaine en question.

Pourquoi l’IGMP Snooping ?

Les switches (commutateurs) de niveau 2 n’ont pas connaissance de cette notion d’abonnement multicast (l’IGMP est un protocole de niveau 3). Autrement dit, ils considèreront le trafic multicast comme des trames de diffusion (broadcast) et donc répliqueront le trafic sur tous les ports.

Cela peut poser de gros problème de performance car le ou les flux multicast pour lequel vous êtes abonné seront diffusés sur tous les ports de vos switches et donc reçu par tous les équipements connectés à votre réseau !

Pour optimiser ce comportement il existe un mécanisme nommé « IGMP Snooping » permettant à un switch de niveau 2 d’analyser le trafic IGMP afin d’apprendre « qui est abonné à quoi » (= quel port du switch à quel groupe multicast).

Ainsi en scrutant (snoop) les rapports IGMP qui le traverse, le switch peut apprendre et donc construire une table de mapping reliant un port à un groupe afin de répliquer le trafic multicast seulement sur les bons ports pour chaque groupe.

Dans mon architecture c’est optionnel car j’ai fait le choix d’isoler la partie TV dans un VLAN dédié. Dans ce VLAN il n’y a qu’un client : le décodeur TV. Ainsi sans l’« IGMP Snooping » mes deux switches répliqueront bêtement le flux TV multicast en broadcast mais seulement sur les ports du VLAN « TV » ! Et ce VLAN ne contient qu’un port : celui du décodeur TV ! De ce fait, avec ou sans l’IGMP Snooping le trafic sera toujours envoyé sur ce même port !

Par contre, si vous configurez votre proxy IGMP dans le même VLAN que votre réseau LAN ou bien si vous comptez brancher plusieurs décodeurs dans le VLAN « TV », il est important d’activer l’IGMP Snooping afin d’envoyer le bon flux TV au décodeur qui en fait la demande et non de l’envoyer sur tous les ports ! Autrement dit s’il y a plus d’un périphérique sur le réseau/VLAN sur lequel se trouve votre routeur multicast (IGMP proxy) vous devez activer l’IGMP Snooping !

Subtilités dans l’implémentation de l’IGMP Snooping

Dans la réalité, l’« IGMP Snooping » est assez subtile à comprendre car ce n’est pas vraiment une norme. Chaque constructeur peut l’implémenter avec plus ou de moins de liberté créant des différences de fonctionnement et de paramétrage entre les différentes marques voire même entre les différents modèles/versions d’une même marque.

En effet, l’IGMP Snooping est décrit dans la RFC4541 classée dans la catégorie « Informational ». Le document précise bien en entête : « This memo provides information for the Internet community. It does not specify an Internet standard of any kind ».

Dans les grandes lignes, tous les switches et équipements implémentant l’IGMP Snooping fonctionnent de la même manière : ils analysent le trafic IGMP, c’est-à-dire les différents messages IGMP pour déterminer quel port est abonné à quel groupe multicast de façon à acheminer le flux multicast seulement aux ports abonnés et non à tout le monde (broadcast).

Il y a cependant des différences dans l’implémentation de cette fonctionnalité, notamment en ce qui concerne le « report suppression ».

Certain font ce qu’on appelle de l’« IGMP Snooping passif », c’est-à-dire que le « snooping » n’intervient pas dans le trafic IGMP : le switch se contente d’analyser les messages IGMP qui le traverse pour apprendre tout en laissant passer ces messages (d’où le terme « passif »).

D’autre font de l’« IGMP Snooping proxy reporting » aussi nommé « reports suppression » qui en plus d’apprendre du trafic IGMP, filtre (= bloque) certain message IGMP pour réduire ce trafic et la charge du routeur multicast. De ce fait le switch ne se contente pas seulement d’analyser le trafic IGMP de façon passive, il devient « actif » en bloquant certain message !

Le report-suppression

L’idée est simple, si vous avez deux hôtes connectés sur un même switch (avec IGMP Snooping) lui-même connecté sur un routeur multicast. L’un des deux hôtes s’abonne à un groupe multicast en envoyant un « Membership report » au routeur multicast. Le switch analysant le trafic IGMP comprend que cet hôte s’est abonné à un groupe et donc met à jour sa table de mapping de façon à diriger le trafic multicast de ce groupe seulement pour lui. Le deuxième hôte ne recevra donc aucun trafic grâce à l’IGMP Snooping.

Maintenant, le deuxième hôte décide de s’abonner au même groupe multicast, il envoie donc un « Membership report » pour ce groupe au routeur multicast. Mais si notre switch implémente l’IGMP Snooping avec « report suppression », la demande d’adhésion ne parviendra jamais au routeur.

En effet il y a « suppression du report ». Pourquoi ? Tout simplement parce que le switch considère que le routeur n’a pas à avoir connaissance de cette information. En effet, comme le switch reçoit déjà le flux multicast de ce groupe pour le 1^er hôte, il peut tout simplement mettre à jour sa table de mapping pour envoyer ce flux également au 2^ème hôte car il a compris en « snoopant » le message IGMP que ce 2^ème hôte souhaitait également se joindre à ce même groupe.

Le fait d’envoyer cette demande d’adhésion au routeur n’apporte rien car le flux transite déjà du routeur au switch. Ainsi dans l’idée de réduire le trafic et la charge du routeur, le switch « absorbe » ce report.

Il en va de même en cas de désabonnement d’un des deux hôtes. Si le 1^er hôte décide de quitter le groupe, il enverra un message IGMP de type « Leave ». Comme le switch sait d’après sa table de mapping qu’il y a toujours le 2^ème hôte sur ce groupe, il décidera de ne pas communiquer cette information au routeur mais ajustera sa table pour ne plus envoyer ce flux sur le port du 1^er hôte. Ce n’est seulement lorsque le dernier quitte un groupe que le message IGMP « Leave » sera acheminé jusqu’au routeur multicast.

Les messages absorbés le sont sur une période de temps assez courte (une dizaine de seconde) car n’oubliez pas que le routeur multicast, élu « requérant », envoie périodiquement des requêtes de type « Membership Queries » pour savoir « qui est encore dans le groupe ». Les hôtes, pour confirmer leur présence dans le groupe, répondent par des « Membership report ». Or si le switch considère que nos hôtes sont déjà dans le groupe, il bloquera ces reports et donc sans réponse, le routeur multicast coupera le flux.

C’est pourquoi le « reports-suppression » opère donc sur des fenêtres de temps de quelques secondes. Lorsque le requérant envoie les « Membership Queries », les hôtes répondent tous par « Membership report » avec un délai aléatoire de réponse de quelques secondes (pour éviter les pics de réponse simultanées). Le switch décide alors de laisser passer un des reports mais de supprimer les autres. Le routeur sait donc qu’il y a au moins un hôte dans ce groupe via le switch et le flux est maintenu.

L’IGMP Querier et l’IGMP Snooping Querier

S’il y a « IGMP Snooping » sur un réseau il est nécessaire d’avoir également un « IGMP Querier », c’est-à-dire un « requérant IGMP ».

Comme nous l’avons dit plus haut, le requérant (ou « IGMP Querier ») envoie régulièrement des messages de types « Membership Queries » afin de savoir « qui » est (toujours) là pour un groupe donné. Les clients, dans notre cas le décodeur TV, doivent répondre par un « Membership report » sous peine d’être exclus du groupe.

Ces « Queries » sont indispensable pour l’IGMP Snooping car les « Membership report » permettent au switch de maintenir la table de mapping à jour. En effet, lorsque le switch ajoute un port à un groupe il y a un timeout au-delà duquel, sans « report », le switch supprimera le port de sa table. Sur un switch Netgear GS724T il est possible de configurer ce temps d’expiration (paramètre « Host timeout ») par défaut défini à 260 secondes (4min 20s).

En d’autre terme, si pendant plus de 4 min 20 (par défaut avec le GS724T), un hôte n’a pas renvoyé de « Membership report », son ou ses flux multicast seront coupés au niveau du switch par l’IGMP Snooping.

Dans notre cas c’est le Mikrotik qui est le « Querier » sur notre interface locale (downstream) pour confirmer les abonnements en cours auprès du routeur multicast d’Orange via « upstream » sur le VLAN 840.

Pour être exact, c’est le routeur multicast d’Orange qui lance ces « Queries » toutes les 60 secondes pour s’assurer qu’il y a au moins un hôte par groupe multicast. Notre routeur Mikrotik étant un IGMP Proxy relaie les « queries » sur l’interface locale, il est donc le « Querier » local.

Toutefois un commutateur multicast de niveau 2, en l’occurrence mon switch Netgear GS724T, ne prend pas en charge l’IGMP comme nous l’avons dit plus haut et donc ne peut pas envoyer des requêtes par défaut. En activant l’IGMP Snooping sur un commutateur (de niveau 2) dans un VLAN où le trafic multicast doit être commuté et qu’aucun routeur multicast n’est présent, le commutateur agira en tant que “IGMP Snooping Querier” pour envoyer des requêtes IGMP “à la place” du routeur multicast.

Sur certain switch ce rôle est implicite (comme sur lepetit TP-Link SG108E) mais sur des switches plus évolués, comme le Netgear GS724, il faut activer cette option explicitement sur le ou les VLANs souhaités sans oublier définir l’adresse IP du routeur (ou proxy) multicast à qui remonter les rapports.

Pour configurer l’IGMP Snopping & Querier dans le détail sur les switches Netgear GS724T et TP Link SG108E, rendez-vous ici.

Recevoir la TV sur son ordinateur

Si comme moi votre « ordinateur » est dans le réseau (ou VLAN) « LAN » et non dans le VLAN « TV », il faudra ajouter une interface « downstream » sur le proxy IGMP et reconfigurer l’IMGP Snooping sur vos switches pour multicaster également la TV Orange dans le réseau LAN. Je détaille tout cela dans ce post.

La grande majorité des chaines sont malheureusement cryptées (protection DRM) c’est pourquoi on nous envoie une carte à puce à insérer dans le décodeur TV.

En effet ce système de contrôle d’accès nommé « Viaccess » est développé Viaccess Orca qui est ni plus ni moins qu’un filiale d’Orange. On le retrouve bien entendu dans les décodeurs TV d’Orange/Sosh mais aussi chez Canal+ / CanalSat et d’autres opérateurs étrangers.

Ce système permet de « désembrouiller les chaînes ». Le mécanisme se compose d’un protocole permettant de récupérer de façon sécurisé les clés pour déchiffrer un flux, un module d’accès conditionnel (en gros un lecture de carte) et la carte à puce contenant un jeu de clés propre à l’abonné vous permettant de faire valoir vos droits afin de récupérer la clé pour la chaine souhaitée.

Ainsi pour simplifier, quand vous sélectionnez une chaine, le module d’accès conditionnel (intégré dans le décodeur) « va lire » votre clé sur la carte à puce que vous avez insérée et via le protocole Viaccess (PC 5.0 depuis 2012) récupèrera la clé pour déchiffrer le flux TV demandé. Si vous n’avez pas accéder à cette chaine, vous n’obtiendrez pas la clé pour décoder le flux et on vous affichera un joli message pour vous inviter à contacter le service client afin d’ajouter des chaines à votre bouquet.

Viaccess ne s’occupe que de la partie « contrôle d’accès » (pour délivrer les clés de déchiffrement de façon sécurisé). Le chiffrement à proprement parler est basé sur l’algorithme CSA (pour Common Scrambling Algorithm) mixant de l’AES-128 et du XRC (eXtended emulation Resistant Cipher). Le CSA massivement utilisé pour le cryptage des chaines de télévision (standard du consortium DVB).

J’ai trouvé sur ce forum la liste des chaines diffusées par Orange sans DRM.

Par exemple pour visionner Arte en HD+ diffusé sans DRM, on utilisera le groupe multicast à l’adresse : 232.0.3.4. Depuis VLC, ouvrez un « flux réseau» en indiquant l’adresse « rtp://@232.0.3.4:8200 ».

En plus du flux vidéo HD+ (1080p) vous obtiendrez également les différents flux audio, les sous-titres et même la description du programme en cours et à venir.

Un utilisateur du forum a compilé toutes les chaines dans une liste M3U. Ainsi pour les chaines sans DRM vous pouvez télécharger ce fichier ici et ouvrir cette liste.

Vous aurez dans votre interface VLC la liste de toutes les chaines disponibles (incluant C8, Arte, HD1, LCI, i-Télé, etc…).

Configurer la « téléphonie » sans LiveBox

Pour finir notre installation nous allons mettre en place la téléphonie. Pour cela, nous avons trois manières accéder à la téléphonie Orange :

• En utilisant la LiveBox pour y connecter un téléphone DECT ou HD (CAT-iq)
• En utilisant l’application mobile (Android et iOS) « Livebox Phone »
• En utilisant la passerelle SIP « siproxd » avec le plugin « siproxd_orange » qu’on pourra coupler ou non à un serveur de téléphonie (Lync/Skype for Business, Asterisk, etc..).

Utiliser la LiveBox comme passerelle DECT ou CAT-iq

Si vous avez un téléphone DECT ou HD vous pouvez utiliser la LiveBox pour la téléphonie. Il suffira de connecter votre Livebox derrière votre routeur comme expliqué dans l’annexe en fin de document. Une fois connectée, vous pourrez brancher votre téléphone DECT sur la prise « verte » dédiée derrière la Livebox.

Avec des switches manageables et des VLANs vous pouvez également déplacer votre LiveBox dans votre logement pour la placer à l’endroit où vous souhaitez connecter votre téléphone.

Autre solution, apparier un ou plusieurs (4 max) téléphones HD (norme CAT-iq 1.0 ou 2.0) via WPS (voir la procédure).

Contrairement à ce que j’ai pu lire, la Livebox n’est pas une base DECT, il faudra donc utiliser votre propre base DECT connectée via la prise verte de la Livebox. Par contre la Livebox intègre une base CAT-iq 2.0 vous permettant d’apparier des téléphones HD compatibles sans base supplémentaire.

La solution fonctionne très bien mais nécessite de ressortir votre Livebox du carton et reste limitée en terme d’usage.

Utiliser l’application « LiveBox Phone »

Une autre solution qui n’en est pas vraiment une : utiliser l’application « Livebox Phone » sur votre mobile Android ou iOS.

Le problème est que pour émettre ou recevoir des appels il faut être connecté sur le réseau Wifi de sa Livebox or dans notre cas on a justement rangé la Livebox dans son carton !

Si l’application n’est pas connectée au Wifi de sa Livebox on peut juste consulter la messagerie vocale, recevoir des notifications lors des appels entrants (sans pouvoir répondre) et configurer le renvoi d’appel.

Donc au final, l’application est assez limitée car elle ne peut fonctionner que lorsque vous êtes chez vous et en faisant de votre Livebox votre AP Wifi principal ce qui dans mon cas n’est pas envisageable.

Sur la partie renvoi d’appel vous pouvez aussi vous connecter sur votre espace client Orange/Sosh par Internet et configurer le renvoi des appels de votre téléphonie fixe Livebox vers votre mobile par exemple. Cela permettra de recevoir les appels de votre fixe où que vous soyez mais par contre vous ne pourrez pas émettre (plus d’info ici).

Utiliser un proxy SIP

La véritable solution est d’accéder à votre la ligne téléphonique via le protocole SIP (Session Initiation Protocol), un des protocoles les plus courant pour la VoIP. Cela nous permettra de connecter soit une application soit un véritable serveur de téléphonie sur notre ligne tel Asterisk (ou dérivés), Lync (Skype for Business) et bien d‘autre.

Tout cela est possible grâce aux travaux d’un certain « x0r » qui sur son blog explique comment fonctionne l’application « Livebox Phone » présentée plus haut. Il s’agit bien d’une ligne SIP mais avec quelques modifications propres à Orange concernant le mécanisme d’authentification non conforme au standard. De ce fait il n’est pas possible d’utiliser cette ligne directement via le protocole SIP comme c’est le cas chez Free.

Cependant ce même auteur a développé un plugin pour « siproxd » (un serveur proxy SIP) capable de gérer ce mécanisme d’authentification propre à Orange. Le code est publié sur Github. Ainsi ce proxy permet d’exploiter votre ligne téléphonie en SIP standard ce qui nous permettra de brancher ce que l’on souhaite dessus.

Préparer une machine sous Debian

Pour ma part j’ai déployé une petite machine virtuelle x64 sur un de mes hyperviseurs en lui allouant 512 Mo (pas besoin de plus). Sur cette machine j’ai installé un simple Debian 8 nu avec un serveur SSH.

Pour faciliter l’administration je vous conseille d’installer « sudo » en ajoutant votre utilisateur dans le groupe.

Pour installer le proxy, commencez par les prérequis :

Installer « siproxd » et le plugin Orange

Téléchargez, compilez et installez la dernière version en date de « siproxd » (voir http://siproxd.tuxworld.ch/) :

Et faire de même pour le plugin Orange :

Pour la configuration, copiez le fichier d’exemple “/usr/local/etc/siproxd.conf.example” dans “/usr/local/sbin/siproxd” et ouvrez le pour édition:

Ajoutez les lignes suivantes pour charger le plugin de x0r sans oublier de définir le login/password de votre compte Orange :

Dans le fichier, il faut également configurer :

• L’interface d’entrée (if_inbound) et de sortie (if_outbound) de votre proxy. Dans notre cas il s’agit de la même interface « eth0 », interface connectée sur le réseau local
• L’adresse DNS ou IP (host_outbound) qui pointe vers votre adresse IP public. Pour ma part j’ai un nom de domaine avec un hôte (A) qui pointe vers mon IP Orange (mis à jour automatiquement par un script Powershell en cas de changement d’IP). Si vous n’avez pas de domaine, renseignez-vous pour mettre en place un « dyndns » ou entrez l’IP directement (qu’il faudra changer manuellement en cas de changement).
• Définir les hôtes autorisés à s’enregistrer sur le proxy (hosts_allow_reg). Pour ma part il n’y a que le serveur Asterisk (installé sur la même machine) qui sera autorisé à se connecter sur la ligne, donc 127.0.0.1.
• Le port d’écoute SIP pour ce proxy et les ports RTP utiliser pour transporter la voix. On définit le sip_listen_port à 5070 et la plage des ports RTP (rtp_port_low et rtp_port_high) de 7070 à 7089.
• Le mode démarrage (daemon ou non) : daemonize = 1
• Le répertoire des plugins (plugindir) à « /usr/local/lib/siproxd/ » (là où est installé le plugin Orange)

Pour ma part, les lignes ajoutées ou modifiées dans ce fichier :

Utilisation des serveurs DNS Orange

Il faut absolument utiliser le serveur DNS d’Orange pour la résolution des noms de domaine. Si vous avez un adressage fixe et non via DHCP, vous pouvez simplement ajouter le serveur « 81.253.149.1 » (DNS d’Orange) dans le fichier « /etc/resolv.conf ».

Autrement, si votre serveur obtient son IP via un serveur DHCP comme dans mon cas (avec réservation bien évidement), les DNS sont délivrés dans la réponse DHCP ce qui modifiera automatiquement votre configuration « /etc/resolv.conf ».

De ce fait, si votre serveur DHCP utilise les serveurs DNS d’Orange pas de soucis, mais si comme moi vous avez vos propres serveurs DNS qui eux même n’utilisent pas les serveurs d’Orange (forwarders) cela ne marchera pas.

C’est pour cela que j’ai configuré le client DHCP pour le forcer à utiliser le serveur DNS d’Orange :

N’oubliez pas de renouveler votre bail pour que ces options soient prises en compte :

Configurer le routeur

Lorsque qu’un client SIP (dans notre cas le serveur « siproxd », qui est « client SIP » via à vis d’Orange) s’enregistre il communique son adresse, son port SIP (signalisation) et sa plage de port RTP (transport de la voix).

Cela permettra au serveur en face (Orange ici) d’établir la communication à son initiative (par exemple en cas d’appel entrant).

C’est pour cela qu’on a configuré un « host_outbound » dans la configuration du proxy qui doit pointer vers votre IP public.

Bien entendu, il faudra également rediriger les ports RTP et SIP vers votre serveur Debian interne.

Sur le Mikrotik, on commence par ajouter une règle NAT pour rediriger ces ports UDP vers notre serveur siproxd (dans mon cas sur 10.2.4.25) :

Puis on autorise le trafic en transite sur ces ports :

Notez bien que la règle du firewall est sur la chaine « forward » et non « input » car ces ports sont redirigés avec la règle NAT vers la machine interne. Ainsi le trafic n’est pas entrant via à vis du routeur (input) il ne fait que transiter (forward).

Beaucoup font l’erreur, il faut juste se rappeler que dans le « Packet Flow » du Mikrotik le routage a lieu AVANT le firewall. Ainsi le « Destination NAT » est fait dans le « prerouting » qui précède les chaines « input » et « forward ». (Voir http://wiki.mikrotik.com/wiki/Manual:Packet_Flow)

Notez aussi que je restreins (de façon assez large) le trafic sur ces ports aux adresses du réseau Orange en 81.253.0.0/16 car ce proxy ne doit être accessible qu’aux serveurs Orange et non à tout le monde.

Pour finir on peut également optimiser le trafic VoIP sur notre réseau. Pour cela on ajoute une queue pour traiter ce trafic de façon prioritaire sur notre routeur et on élève la CoS de ce trafic pour que nos switches priorisent également ce trafic.

Enregistrement du service et démarrage du proxy SIP

Sur une Debian Jessie, éditez simplement le fichier « /etc/rc.local » et ajoutez la ligne suivante :

Vous pouvez maintenant lancer le proxy :

Et voilà la passerelle vers la « SIP made Orange » est prête, il ne reste plus qu’à se connecter dessus soit avec un client SIP ou soit avec un serveur sur lequel on pourra connecter plusieurs clients et faire beaucoup plus de chose.

Pour aller plus loin… Dans la Constellation

Suivi dans la bande passante dans le dashboard domotique S-Panel

En Juillet 2015 je vous présentais S-Panel, une interface domotique et IoT multi-plateforme avec Cordova, AngularJS et Constellation (relire l’article ici).

Sur cette interface trouve entre autre la consommation actuelle de la bande passante en montée comme en descente :

Pour ce faire rien de plus simple. On commence par déployer le package “SNMP” du catalogue de package gratuit dans votre Console Constellation :

Une fois le package déployé sur une sentinelle de votre Constellation, on configure dans les “settings” de ce package la liste des équipements “SNMP” à interroger. Ici je configure le nom DNS de mon routeur Mikrotik :

Une fois le package lancé, les informations SNMP collectées sont publiées sous forme de StateObjects dans Constellation.

Dans mon dashboard “S-Panel”, qui n’est ni plus ni moins qu’une page Web AngularJS (Javascript), je n’ai qu’à m’abonner aux StateObjects de mon routeur pour recevoir en temps réel toute modification :

A chaque mise à jour, les StateObjects sont envoyés dans le scope Angular avec la ligne :

Il ne reste plus qu’à créer une vue HTML pour afficher les informations du StateObjects. Par exemple :

Et voilà avec quelques lignes d’HTML, on obtient en temps réel la consommation sur l’interface 2, c’est à dire l’interface “ether2-WAN” qui représente l’arrivée de la fibre Orange (de l’ONT pour être exacte) sur notre dashboard domotique !

Un service de téléphonie pour la maison elle-même

Sur lafibre.info, je vous propose aussi d’installer et de configurer un serveur de téléphonie Asterisk connecté à notre ligne Orange via siproxd (à lire ici). Vous découvrirez comment exploiter votre ligne Orange depuis vos smartphones ou ordinateurs avec n’importe quel client SIP ou comment mettre en place un répondeur avec envoie de mail automatique en cas de message.

Dans la 2ème partie de l’article (à lire ici), vous découvrirez également comment mettre en place de la synthèse vocale, faire des transferts d’appels ou du “parcage” d’appels, de l’enregistrement de conversation mais surtout comment utiliser l’AMI et l’AGI pour l’intégrer dans Constellation et la domotique de la maison.

L’AMI (Asterisk Manager Interface) est une interface basée sur TCP permettant de se connecter en tant que « Manager » sur le serveur Asterisk afin dele piloter.

Par exemple, lors d’une alarme la maison initie un appel sur mon compte utilisateur et celui de ma femme. Sans réponse elle utilise le trunk Orange pour appeler nos proches sur les GSM. Lorsque quelqu’un répond, Asterisk met l’interlocuteur avec une extension qui par exemple vient diffuser un message vocal avec le TTS de Google, ou comme dans mon cas, passe l’appel au package « My Brain » où réside l’IA de la maison qui ni plus ni moins qu’un AGI comme nous allons le découvrir ci-après.

L’AGI (Asterisk Gateway Interface) est une interface qui permet d’ajouter des fonctionnalités dans Asterisk. Toutes les applications que vous utilisez pour faire du TTS, jouer un son, avoir un service de messagerie sont des AGI. Ainsi un package Constellation peut exposer une AGI au serveur Asterisk pour interagir avec l’appel. Ainsi “Constellation peut prendre un appel”.

Cela permet par exemple d’appeler la maison pour piloter un objet connecté, la domotique, un serveur, un Arduino ou ce qui vous voulez, Constellation étant une plateforme d’interconnexion où l’on connecte aussi bien des objets connectés du commerce (NetAtmo, Nest, une Tesla ou autre) ou home-made (ESP8266, Arduino, Gadgeteer, …) ou des services et applications divers et variés.

Je vous avez déjà parlé de cela avec “Skype for Business” dans mon article sur S-Opener ce qui me permet d’ouvrir la porte de garage, piloter l’alarme ou le thermostat directement depuis un appel. Relire l’article ici.

La solution Asterisk offre un peu près le même usage mais sans la partie “reconnaissance vocale” mais a l’avantage d’être plus accessible (open source, installation facile, etc..).

Un article sera prochainement publié sur ce sujet pour décrire ce qu’il est possible de faire avec Asterisk & Constellation.

Un monitoring des ressources réseau… et de la maison elle-même

Autre sujet, avec la refonte de mon réseau, j’en ai profité de (re)mettre en place un système de monitoring des ressources réseaux et serveurs avec Cacti, une solution de graph basée sur RRD-tool.

En plus des graphiques, la solution automatise l’envoi de rapport par mail, surveille et alerte en cas de dysfonctionne d’un équipement, etc…

Cela me permet de superviser l’ensemble des ressources réseaux (le routeur Mikrotik, les switches, l’AP Wifi, l’imprimante, etc…) ainsi que mes différents serveurs, machines virtuelles, Raspberry sans oublier mes ressources externes, notamment mes serveurs chez Online.net, mes sites Internet, serveur mail, etc…

Mais plus intéressant encore, Cacti est capable de se connecter sur Constellation pour extraire les informations (=StateObjects) publiées par les différents objets, services ou applications connectés à Constellation.

Il devient ainsi possible de monitorer des sondes NetAtmo, RFXcom, Z-Wave, le chauffage Nest, des capteurs home-made basés sur des Raspberry ou ESP, comme mon capteur de luminosité ou encore S-Energy pour la consommation de l’eau, de l’électricité ou du gaz, l’état de l’alarme, ou encore le nombre de mouvement sur les caméras ZoneMinder, le taux de présence des utilisateurs basés sur la connexion Wifi, ou encore votre gauge d’essence de votre voiture avec un Xee, etc.. etc..

Quelques exemples :

• L’état de l’alarme : Armée, Armée partiellement (mode nuit), désarmée (relire ceci) :

• Le nombre d’évènement détecté sur la caméra de la porte d’entrée par ZoneMinder :

• La consommation d’eau relevée par S-Energy (solution de reconnaissance optique du compteur d’eau par un Raspberry – présentée ici)

• La consommation d’électricité relevée par S-Energy (solution à base d’un opto-interrupteur drivé par un Arduino – présentée ici)

• Les températures relevées par des sondes Oregon (RFXcom), Z-Wave (Vera) et NetAtmo :

• Le taux de CO² mesurés par les sondes NetAtmo :

• La température de consigne et ambiante ainsi que l’état de la chaudière piloté par le thermostat Nest :

Encore une fois tout application, service ou objet, de quelque nature que ce soit, connecté à Constellation, peut être capturé par Cacti pour la génération de graphique sans aucune ligne de code.

De plus, couplé au plugin “Threshold” de Cacti, il sera même possible de configurer des alertes. Très utile par exemple pour surveiller l’état des batteries de vos capteurs, ci-dessous les seuils des sondes NetAtmo :

Je vous avez déjà proposé le même type de sujet avec Graylog/ElectricSearch et Kibana dans mon article : Créez votre “Home Analytics” : l’analyse et le reporting de votre domotique, informatique et objets connectés avec ElasticSearch, Graylog, Kibana et la plateforme Constellation.

A l’image d’Asterisk, Cacti est très léger et très accessible comparé à Graylog/ElasticSearch qui demande plus d’effort pour l’installation et la maintenance. De ce fait aujourd’hui je garde les deux systèmes en parallèle. Graylog/ElasticSearch permet d’aller analyser des évènements très précisément alors que Cacti me donne la tendance globale (mode RRD).

Un article sera prochainement publié sur ce sujet pour décrire comment installer et configurer Cacti et surtout comment le connecter à Constellation pour monitorer vos StateObjects.