Bypasser sa neufbox

De neufbox 4

Cette procédure s'adresse à ceux qui sont clients Neuf fibre optique (FTTH) et qui souhaiteraient « bypasser » (passer outre) leur neufbox pour obtenir un accès plus direct au Net. En d'autres termes, obtenir plus ou moins la même chose que lorsqu'on utilise le mode bridgé avec l'ADSL (sauf que là, on n'a même plus besoin de neufbox !).

Cela peut vous intéresser si vous vous trouvez dans un des cas suivants (liste non exhaustive) :

  • Vous n'avez qu'un seul ordinateur qui accède à Internet et vous n'utilisez ni la TV ni le téléphone, auquel cas la neufbox est un intermédiaire superflu ;
  • Vous avez un serveur personnel chez vous que vous aimeriez utiliser comme passerelle en lieu et place de la neufbox afin de gagner en contrôle et en flexibilité, et également pour éliminer l'intermédiaire inutile que constitue la neufbox.

A noter que du fait de la faible puissance de calcul de la neufbox, cette dernière supporte très mal certaines situations "stressantes" qui peuvent arriver sur une connexion fibre optique, par exemple le routage de centaines de flux TCP simultanément, et qui font fondre le débit total. Bypasser la neufbox peut constituer une solution à ce genre de problèmes.


Edit 1: Ce site http://imil.net/wp/2013/12/28/bypass-neufbox-6-avec-netbsd/ propose une mise à jour du contenu de cette page avec des informations mises à jour au 28/12/2013. Merci d'en prendre connaissance.

Edit 2: D'autres info intéressantes, également technique et surtout beaucoup plus à jour (10/2013), existent aussi sur LaFibre.info. Merci d'en prendre également connaissance.


Notes préliminaires

  • Vous pouvez bypasser votre neufbox tout en conservant le téléphone et la télévision. Ce document vous guidera dans la procédure à suivre pour atteindre cet objectif. Sachez néanmoins que dans ce cas, vous ne pouvez pas (dans l'état actuel de nos connaissances) vous passer de neufbox : elle devra être présente mais sera reléguée en tant que simple client sur votre réseau local.
  • L'infrastructure réseau de Neuf FTTH subit parfois quelques évolutions qui sont susceptibles de casser les solutions présentes dans ce document. Dans la mesure du possible, ce document sera mis à jour pour suivre les évolutions du réseau de Neuf.
  • La procédure est conçue pour une passerelle tournant sous Linux. Elle devrait être adaptable à tout système Unix disposant de fonctionnalités équivalentes. Sous Windows par contre, bonne chance…

Le principe

Accès à Internet

La procédure que suit la neufbox pour obtenir un accès à Internet sur un accès fibré est d'une simplicité déconcertante : elle ne fait que formuler une requête DHCP. Il suffit que votre machine imite cette requête pour obtenir une IP, la route, et les DNS. Simple, non ? Il y a juste un détail qui complique quelque peu les choses : le DHCP ne vous répondra que si vous prenez soin de forger correctement le champ "Vendor class identifier" de la requête DHCP (qui n'est pas transmis en temps normal).

Le "Vendor class identifier"

Ce champ de la requête DHCP, systématiquement transmis par la neufbox, est défini dans le fichier /etc/init.d/rc.wan du firmware de la Neuf Box :

"neufbox5_"$productid"_"$main_version"

Par exemple :

neufbox5_NB5-SER-r1_NB5-MAIN-R2.2.2

On distingue en effet le product ID ("NB5-SER-r1") et la version du firmware ("NB5-MAIN-R2.2.2").

En fait, la règle est simple : pour que le DHCP vous réponde, il faut et il suffit que vous transmettiez un "Vendor class identifier" qui commence par la chaîne "neufbox". Par exemple :

neufboxblahblablah

Néanmoins, dans le souci de faire comprendre clairement à "l'autre côté" qu'il a affaire non pas à une neufbox mais à un truc "fait maison", et ainsi permettre aux techniciens de comprendre ce qui se passe, il est de bon ton de choisir un Vendor class identifier explicite, par exemple :

neufbox-BypassedNeufBox-DirectConnectionToFTTH-votremail@contact.xyz

La Neufbox comme client sur votre réseau local

Il peut être utile de placer votre neufbox sur votre réseau local, non plus en tant que passerelle routeur mais en tant que simple client. C'est même indispensable si vous souhaitez conserver la téléphonie et la télévision. La neufbox « croit » alors que votre réseau local est son accès Internet. Pour cela il faut relier le port WAN de la Neufbox à votre réseau local.

Il y a deux choses à savoir concernant le comportement de la neufbox vis-à-vis de son port WAN :

  • Pour obtenir un accès, la neufbox fait une simple requête DHCP sur son port WAN. Vous pouvez donc utiliser un simple serveur DHCP pour satisfaire cette requête. Cependant, depuis la version 3 du firmware de la Neufbox, cette dernière s'attend à trouver un champ bien précis dans la réponse DHCP : le « NIS domain », dont la sémantique est détournée pour informer la Neufbox de l'infrastructure sur laquelle elle fonctionne (par exemple, FTTH Pau). Il faut que le serveur DHCP fournisse cette donnée, faute de quoi la Neufbox refusera de démarrer.
  • Une fois que la neufbox a obtenu un bail DHCP, elle cherche à obtenir son firmware et sa configuration. Pour cela elle effectue des requêtes HTTP sur des hôtes bien précis (nb5general.neufbox.neuf.fr et des sous-domaines de nb5thd.neufbox.neuf.fr), et obtient en réponse des fichiers XML comportant les informations dont elle a besoin pour fonctionner.

Un point épineux est que la neufbox transmet sa propre adresse IP comme paramètre d'URL lors de ces requêtes HTTP. En temps normal, cette adresse IP est l'adresse Internet publique de l'abonné, mais ce n'est pas le cas ici, vu que la neufbox n'est pas directement connectée à Internet. La neufbox va donc transmettre une adresse IP privée (par exemple, 192.168.5.3) aux serveurs de Neuf, qui vont fort logiquement refuser et renvoyer une erreur de type HTTP 400 Bad Request. Il faut donc intercepter ces requêtes HTTP et réécrire l'adresse IP passée en paramètre pour y mettre la bonne (votre IP publique).

Il faut également noter que comme les ports LAN et WAN de la neufbox sont censés être deux réseaux totalement séparés, vous aurez des problèmes si vous connectez les deux à la fois à votre réseau local. Si vous souhaitez utiliser un port LAN de la neufbox (par exemple pour accéder à l'interface d'administration), vous allez devoir utiliser deux segments Ethernet différents.

EDIT: Methode plus facile citée plus bas

Téléphonie

La neufbox 5 utilise le protocole SIP pour assurer la téléphonie. Malheureusement, le mot de passe SIP utilisé est obfusqué dans la configuration que reçoit la neufbox au démarrage, ce qui rend impossible l'utilisation d'un softphone (par exemple Ekiga). Cette politique est volontaire. La seule solution pour conserver le téléphone est donc d'utiliser la neufbox en tant que client sur le réseau local (voir section précédente), la neufbox servant alors uniquement de client SIP.

SIP et le NAT ne faisant vraiment pas bon ménage, il est nécessaire d'établir une solution de NAT Traversal pour que la communication s'effectue correctement.

Télévision

En théorie, rien ne s'oppose à ce que le décodeur soit branché directement sur votre réseau local. En pratique, lors de son initialisation le décodeur cherche à détecter une neufbox sur le réseau et échouera s'il ne la trouve pas. Ajoutez à ça que la procédure de détection implémentée dans le décodeur est complètement tordue et très sale (mention spéciale à l'adresse 192.168.1.1 codée en dur dans le script), et vous comprendrez que cela complique pas mal la mise en place de la solution. Techniquement c'est possible mais au prix d'une fiabilité douteuse et de contraintes techniques absurdes. Pour cette raison il est préférable de placer le décodeur derrière votre neufbox, qui elle-même est connectée en tant que client sur votre réseau local (voir ci-dessus).

Dans cette situation, la solution fonctionne quasiment « out of the box », à l'exception des flux NeufTV eux-mêmes, qui resteront noirs parce que les paquets multicast utilisés par l'infrastructure NeufTV ne passeront pas la limite de votre passerelle. Pour résoudre ce problème il faut configurer votre passerelle pour router correctement les paquets multicast arrivant du réseau de Neuf vers votre neufbox qui les retransmettra au décodeur TV.

En pratique

Pour commencer, vous devez connecter le Media Converter à votre machine via le câble Ethernet qui était jusqu'à présent branché au port WAN (ou PC3) de la neufbox. Tout le reste se déroule sur la machine ainsi connectée.

La procédure en elle-même est relativement simple, il suffit de configurer le client DHCP. Toutes les commandes décrites doivent être exécutées avec des droits de superutilisateur (root).

Internet

Configurer le client DHCP

Le client DHCP utilisé pour cette procédure est le client "standard" (développé par l'ISC), dont l'utilitaire se nomme dhclient. Il s'agit du client préféré de Debian, dans lequel il est packagé sous le nom dhcp3-client. Il y a de fortes chances pour que votre distribution inclue ce paquetage dans son système de base. Vous pouvez utiliser un client DHCP différent, du moment que celui-ci vous permet de modifier le Vendor class Identifier des requêtes DHCP qu'il envoie.

Pour que le serveur DHCP de Neuf nous réponde, il nous faut modifier le Vendor class identifier utilisé par le client dans sa requête. Pour cela, modifions le fichier /etc/dhcp3/dhclient.conf et ajoutons les lignes suivantes :

interface "eth0" {
        send vendor-class-identifier "neufbox-BypassedNeufBox-DirectConnectionToFTTH-xxx@yyy.zzz";
}

En remplaçant bien entendu eth0 par l'interface appropriée si besoin est, et l'adresse e-mail par la vôtre. Vous pouvez aussi utiliser un Vendor class identifier différent si vous le souhaitez, du moment que celui-ci commence par la chaîne "neufbox".

Tester

Une fois le client DHCP configuré, testons ! La commande suivante va demander au DHCP du Neuf de nous ouvrir le passage (comme d'habitude, remplacez eth0 si approprié) :

dhclient eth0

Si la commande réussit, félicitations ! dhclient devrait avoir configuré vos routes et vos DNS, et votre machine est maintenant pleinement connectée à Internet... sans neufbox entre les deux.

La neufbox comme client sur votre réseau local

Prérequis

Pour utiliser votre neufbox en tant que client sur votre réseau local, vous devez tout d'abord connecter le port WAN de votre neufbox à votre réseau local, et déconnecter (le cas échéant) les ports LAN de ce même réseau.

Configurer le serveur DHCP

EDIT/!\ Pour utiliser sa NB6 comme client dhcp sur votre reseau local ouvrez une fenetre SSH (nécessite un firmware ouvert) et tapez les commandes ci-dessous :

nvram set ftth_nisdomain "*"
nvram commit

Have fun ^^


Comme expliqué précédemment, la Neufbox s'attend à trouver dans la réponse DHCP un champ appellé « NIS domain » contenant un identificateur pour l'infrastructure du réseau. Les clients FTTH à Pau (du moins, certains clients) reçoivent "ftth_axione_omniswitch" comme valeur de ce champ. D'autres clients peuvent avoir des valeurs différentes, mais cela n'a probablement pas beaucoup d'importance vis-à-vis de notre objectif (à confirmer).

Il faut donc configurer votre serveur DHCP pour que ce dernier envoie à la Neufbox le champ NIS Domain avec la bonne valeur. Par exemple, pour le serveur ISC dhcpd :

option nis-domain "ftth_axione_omniswitch";

Intercepter les requêtes HTTP

Comme expliqué précédemment, pour que la neufbox puisse récupérer sa configuration sans encombre, il nous faut intercepter les requêtes HTTP qu'elle effectue et les réécrire.

Commençons par l'interception. Nous allons rediriger les requêtes HTTP effectuées par la neufbox vers un service local, écoutant par exemple sur le port 8080 :

iptables -t nat -A PREROUTING -i <interface lan> -s <adresse IP neufbox> \
         -p tcp --dport www -j REDIRECT --to-ports 8080

Notez qu'il existe d'autres techniques pour faire la même chose (par exemple l'écrasement de la zone neufbox.neuf.fr sur un serveur DNS local). La règle iptables présentée ici est néanmoins la solution la plus simple à mettre en place.

Réécrire les requêtes HTTP

Il faut ensuite configurer un service sur le port 8080 qui recevra les requêtes HTTP effectuées par la neufbox, les réécrira et les renverra. Ce qu'on cherche à faire ici n'est rien d'autre qu'un proxy intercepteur, somme toute très classique si on omet la réécriture d'URLs.

Étant donné que beaucoup de serveurs disposent du serveur web Apache, on va utiliser ce dernier comme proxy et réécrire les requêtes. D'autres solutions existent, par exemple en utilisant Squid.

Voici un exemple de configuration Apache adéquate :

 Listen [adresse IP LAN locale]:8080
 NameVirtualHost *:8080
 
 LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
 LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so
 LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so
 
 # Hôte virtuel par défaut
 <VirtualHost *:8080>
   ServerName [votre nom d'hôte]
   
   RewriteEngine On
   
   # Par défaut, toutes les requêtes sont retransmises telles quelles
   RewriteRule ^.*$ http://%{HTTP_HOST}$0 [proxy]
 </VirtualHost>
 
 # Hôte virtuel utilisé pour les requêtes vers *.neufbox.neuf.fr
 <VirtualHost *:8080>
   ServerName [votre nom d'hôte]
   ServerAlias neufbox.neuf.fr *.neufbox.neuf.fr
   
   RewriteEngine On
   
   # Si la requête comporte les paramètres ip_data=…&ip_voip=…&ip_tv…
   RewriteCond %{QUERY_STRING} ^(.*&)?ip_data=[^&]*&ip_voip=[^&]*&ip_tv=[^&]*(&.*)?$
   # …alors on la réécrit en remplaçant les valeurs par notre IP publique
   RewriteRule ^.*$ http://%{HTTP_HOST}$0?%1ip_data=[votre IP publique]&ip_voip=[votre IP publique]&ip_tv=[votre IP publique]%2 [proxy]
   # NOTE: cette réécriture ne fonctionne que pour un firmware de version 3.x. Pour un firmware 2.x il n'y a qu'un seul paramètre ip=….
   
   # Sinon, on retransmet la requête telle quelle
   RewriteRule ^.*$ http://%{HTTP_HOST}$0 [proxy]
 </VirtualHost>

Tester

Pour tester, allumez votre neufbox : elle devrait démarrer normalement. Si ce n'est pas le cas, le meilleur moyen de diagnostiquer le problème est d'utiliser un sniffer tel que tcpdump ou Wireshark et de regarder ce qu'il se passe sur le réseau. Vérifiez également que vous ne bloquez pas des communications au niveau d'un quelconque pare-feu.

Téléphonie

Pour rappel, pour conserver la téléphonie vous devez connecter votre neufbox en tant que client sur votre réseau local (voir section précédente). Notre principale problématique pour assurer la téléphonie consiste à faire en sorte que le client SIP de la neufbox fonctionne correctement. SIP n'étant pas un protocole « NAT friendly », il nous faut une solution de NAT Traversal pour permettre à la VoIP de fonctionner.

Une solution évidente est d'utiliser Netfilter (iptables) qui dispose d'un module spécialement conçu pour résoudre ce problème : ip_conntrack_sip. Malheureusement, ce dernier fonctionne très mal : un sniffer montre des erreurs SIP intempestives et souvent la voix ne passe que dans un seul sens.

Une solution plus robuste et plus propre consiste à mettre en place un proxy SIP sur votre passerelle. C'est la solution idéale pour permettre à un client SIP de franchir un NAT.

Configuration du proxy SIP

N'importe quel proxy SIP fera l'affaire pour cet usage ; dans le cadre de ce tutorial le logiciel siproxd sera utilisé en raison de sa simplicité. Il est disponible en tant que paquetage Debian.

Voici un exemple de configuration adéquate (siproxd.conf). Cette configuration n'est pas complète : seules les directives qui nous intéressent sont mentionnées.

if_inbound = [votre interface LAN]
if_outbound = [votre interface vers Neuf]
sip_listen_port = 5060
rtp_proxy_enable = 1
# 86.64.181.174 est le proxy SIP de Neuf, du moins au moment de l'écriture de ce document
outbound_proxy_host = 86.64.181.174
outbound_proxy_port = 5060

siproxd dispose de fonctionnalités intéressantes sous forme de plugins, avec notamment la possibilité d'enregistrer les numéros de téléphone entrants et sortants dans le journal système. Cela pourrait vous intéresser étant donné que contrairement à ce que fait la neufbox, le numéro complet est enregistré.

Le problème de « thdsip.fr »

Le registrar SIP utilisé pour la téléphonie est « THDSIP.FR ». En réalité ce nom de domaine n'existe pas : c'est un nom bidon utilisé par Neuf. Cela ne pose pas de problème au client SIP de la neufbox car ce dernier récupère l'adresse IP du registrar dans sa configuration sans résoudre le nom ; en revanche cela va perturber siproxd, qui va tenter de se connecter à thdsip.fr pour retransmettre les requêtes du client SIP, sans succès.

Pour corriger ce problème, il faut associer manuellement l'adresse IP du registrar à THDSIP.FR. La solution la plus simple consiste à modifier /etc/hosts :

86.64.181.174    THDSIP.FR

Attention : selon la configuration de siproxd, il est fort possible que ce dernier s'exécute dans une cage chroot (c'est le cas par défaut sous Debian). Si tel est le cas, il faut ajouter un fichier /etc/hosts dans le répertoire du chroot. Par exemple, sous Debian, par défaut il faut créer le fichier suivant :

/var/lib/siproxd/etc/hosts

Indiquer l'adresse du proxy SIP à la neufbox

Maintenant que notre proxy SIP est en place, il faut faire en sorte que la neufbox l'utilise, faute de quoi elle se connectera directement au serveur SIP de Neuf, passant outre notre proxy.

La neufbox récupère la configuration de son client SIP au démarrage sous forme d'un fichier XML récupéré à l'adresse suivante :

 http://voip.nb5thd.neufbox.neuf.fr/cfgnb5voip.xml

Ce fichier XML comporte, entre autres, les lignes suivantes :

<proxy port="5060" id="1">86.64.181.174</proxy>
<proxy port="5060" id="2">86.64.181.174</proxy>

La solution consiste à intercepter la transmission de ce fichier pour modifier la valeur de ces éléments. Ça tombe bien, si vous avez mis en place le proxy Apache dans le cadre de la section précédente, il suffit d'une petite modification dans votre configuration Apache pour atteindre ce résultat.

Dans la configuration globale :

LoadModule ext_filter_module /usr/lib/apache2/modules/mod_ext_filter.so
ExtFilterDefine neufbox-voip cmd="/bin/sed -r s#<proxy(.*)>.*</proxy>#<proxy\\1>[votre adresse IP LAN locale]</proxy>#g"

Dans le VirtualHost correspondant à neufbox.neuf.fr :

<Location /cfgnb5voip.xml>
  SetOutputFilter neufbox-voip
</Location>

Cette solution utilise l'utilitaire sed pour modifier à la volée la réponse à la requête pour le fichier cfgnb5voip.xml. Il est également possible d'utiliser une solution plus propre qui modifie l'arbre XML lui-même en utilisant xmlstarlet. Pour cela vous devez installer xmlstarlet (un paquetage Debian existe) et remplacer la ligne ExtFilterDefine par la suivante :

ExtFilterDefine neufbox-voip cmd="/usr/bin/xmlstarlet ed --update /voipconf/telephony-services/proxy --value [votre adresse IP LAN locale]"

NOTE : sur certaines distributions, le chemin de xmlstarlet n'est pas /usr/bin/xmlstarlet mais /usr/bin/xml. Vérifiez le chemin sur la vôtre.

Tester

Une fois tout en place, le proxy SIP lancé et Apache redémarré, il vous suffit de redémarrer votre neufbox pour obtenir la téléphonie. Si ce n'est pas le cas, le meilleur moyen de diagnostiquer le problème est d'utiliser un sniffer tel que tcpdump ou Wireshark et de regarder ce qu'il se passe sur le réseau. Lancer siproxd dans un terminal en mode de débuggage (et daemonize désactivé) peut également être d'une grande aide dans la compréhension du problème. Notamment, si vous vous êtes trompé lors de la correction de thdsip.fr, les messages de débuggage de siproxd vous permettront de le savoir.

Télévision

Comme pour la téléphonie, vous devez connecter votre neufbox en tant que client sur votre réseau local (grâce à la procédure ci-dessus) pour que votre décodeur fonctionne. Une fois ceci fait, connectez votre décodeur à un des ports LAN de votre neufbox.

À ce stade le décodeur devrait fonctionner normalement à l'exception des flux NeufTV eux-mêmes, qui nécessitent la mise en place d'un relais multicast sur votre passerelle.

Retransmission des flux multicast

Le logiciel retenu pour cet usage est igmpproxy. Malheureusement il n'existe pas de paquetage Debian, vous allez devoir le compiler à la main. Il existe cependant un port FreeBSD. Si vous désirez intégrer igmpproxy à votre procédure de démarrage, votre serviteur a écrit un script init.d pour Debian.

Voici une configuration adéquate pour igmpproxy :

quickleave

phyint [interface vers Neuf] upstream
       altnet 10.10.0.0/16
       altnet 10.200.0.0/16
       altnet 10.0.0.1/24
       altnet 233.0.0.0/8
       altnet 224.0.0.0/8
       altnet 93.17.149.15
       altnet 93.17.149.158
       altnet 86.65.232.22
       altnet 84.96.146.150
       altnet 86.65.94.9
       altnet 86.65.232.10

phyint [interface LAN] downstream

Tester

Une fois igmpproxy lancé, le décodeur TV devrait fonctionner normalement. Si tel n'est pas le cas, le meilleur moyen de diagnostiquer le problème est d'utiliser un sniffer tel que tcpdump ou Wireshark et de regarder ce qu'il se passe sur le réseau.