Depuis quelques jours, le soir, je rencontre de grosses difficultés de connexion à internet. En effet j'ai des pings à 6000ms avec 50% de pertes de paquets. J'ai remarqué que le fait d'éteindre mon serveur @home permettait de résoudre le problème, ce qui est un peu étrange car j'imagine mal comment on peut mettre à genoux une connexion de 100Mbps. Plus étrange encore, le fait de désactiver les services nginx et postfix permettait également de résoudre les problèmes. En revanche la lecture des logs de ces services et ceux du système n'indiquait rien d'anormal.

Je m'orientais donc soit vers un ddos, soit un bug de lxc car la version proposée sur Debian est obsolète et on peut très bien imaginer des problèmes avec le bridge menant à des tempêtes de broadcast ou autres joyeusetés du genre. Désespéré, j'ai upgradé mon serveur en Jessie. Exit le kernel 3.2 et bonjour au 3.16, exit lxc 0.8 et bonjour lxc1.0. Suite à cela j'ai remarqué un retour à la normale et même une hausse de la réactivité du serveur. Je pensais donc le problème résolu.

Mais ce soir, rebelotte. Ping à 6000ms, 50% de pertes de paquets, et encore une fois le fait de couper mon serveur faisait disparaitre le problème. Cette fois j'ai donc fait tourner une analyse wireshark sur l'interface réseau du serveur.

Capture du trafic avec wireshark

Côté serveur (remote)

Installer tcpdump :

# apt-get install tcpdump

Côté PC portable

Installer Wireshark puis exécuter les commandes suivantes :

# mkfifo /tmp/wshark
# ssh root@192.168.0.1 "tcpdump -s 0 -U -n -w - -i eth0 not port 22" > /tmp/wshark

Puis, dans un autre onglet :

 # wireshark -k -i /tmp/wshark

Wireshark doit s'ouvrir et commencer à afficher le traffic du serveur :

Analyse des résultats

J'ai donc observé que pour deux IP, les trames suivantes inondaient le serveur :

3	0.023193000	5.39.90.132	192.168.0.2	TCP	66	[TCP Port numbers reused] 80→25 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

Sans connaître tous les détails il semble que ce soit donc bien une attaque. Apparemment c'est du SYN flood.

Actions

A l'aide d'iptables, j'ai bloqué les deux adresses IP en cause :

# iptables -I FORWARD -s 5.39.90.132 -j DROP
# iptables -I FORWARD -s 37.187.112.166 -j DROP

Note : j'utilise FORWARD car j'ajoute cette règle sur l'hôte alors que les paquets sont à destination d'un container LXC qui dispose d'une autre adresse IP. INPUT doit être mis à la place si ce n'est pas le cas, ou dans le doute, les deux.

Miracle, après avoir bloqué ces deux IP, ma connexion à internet est revenue à la normale.

Ma deuxième action fut d'exécuter un whois sur ces deux IP pour en apprendre un peu plus. Elles appartiennent à des serveurs dédiés OVH, j'ai donc rempli le formulaire abuse sur leur site pour leur signaler que ces serveurs ont un comportement étrange.

Conclusion

Mon interprétation est la suivante : deux serveurs m'ont inondé de requêtes, qui arrivent sur nginx et postfix puisqu'elles sont destinées aux ports 25/80/443 d'après Wireshark. Si mon container LXC est éteint, elles finissent dans le vide. En revanche s'il est allumé, elles aboutissent et se multiplient jusqu'à saturer la BBox (le routeur en amont), ce qui provoque les ralentissements. Wireshark m'a beaucoup aidé à diagnostiquer ce problème, c'est maintenant mon meilleur ami.

iptables a pour instruction de "droper" (DROP) les paquets en provenance de ces deux adresses, ce qui revient donc à reproduire le comportement du serveur éteint. Le signalement à OVH permettra, j'espère, de faire couper ces deux serveurs probablement compromis.

En 4 ans d'auto-hébergement c'est la première fois que je suis confronté à un tel problème. On en revient aux raisons qui m'ont poussé à externaliser le blog maniatux.fr sur un VPS OVH, à savoir que si des attaques doivent avoir lieu, autant que ce ne soi pas chez moi. Mais il me reste un serveur @home que je pensais suffisamment "discret" pour ne pas se faire attaquer. J'espère que cela ne se reproduira pas à l'avenir...

Fin 2013 j'ai publié un article expliquant comment se faire facilement une "IPv6 Box" sous Debian, c'est à dire un serveur qui donne accès à l'IPv6 à toutes les machines de votre réseau, en exploitant deux choses : un tunnel qui encapsule l'IPv6 dans de l'IPv4 (vous permettant ainsi d'en profiter alors que votre FAI ne le propose pas) et radvd un daemon qui présente votre passerelle au reste du réseau (les périphériques se génèrent eux-même une IPv6 complète par la suite).

Avec ce nouvel article, voici comment faire la même chose sur FreeBSD !

Pré requis

Pour la théorie et la présentation du mode de fonctionnement, je vous redirige vers l'article Se faire une IPv6 Box dans lequel il y a les schémas et tout ce qui va avec. Ce que vous devez avoir, c'est :

• Un tunnel chez Hurricane Electric en /48
• Un serveur FreeBSD bien entendu, relié au même LAN que les machines que vous voulez desservir

Montage du tunnel

A ajouter au /etc/rc.conf.local :

#IPV6 HE tunnel
ipv6_gateway_enable="YES"
ipv6_interfaces="auto"
ipv6_activate_all_interfaces="YES"
ipv6_cpe_wanif="gif0"
ifconfig_re0_ipv6="inet6 2001:470:c851:192::1 prefixlen 64"
cloned_interfaces="gif0"
ifconfig_gif0="tunnel 192.168.0.10 216.66.84.42"
ifconfig_gif0_ipv6="inet6 2001:470:c851:10::1 2001:470:c851::1 prefixlen 128"
ipv6_defaultrouter="2001:470:c851::1"
rtadvd_enable="YES"
rtadvd_interfaces="re0"

A remplacer par les éléments dont vous disposez :

• ifconfig_re0_ipv6 : Adresse IPv6 que vous donnez à votre interface de LAN (attention votre interface ne s'appelle pas forcément re0)
• ifconfig_gif0 : Adresse du LAN et adresse du serveur chez HE (Server IPv4 Address)
• ifconfig_gif0_ipv6 : Adresse IPv6 que vous donnez au gif0 et adresse du serveur chez HE (Server IPv6 Address)
• ipv6_default_router : Adresse du serveur chez HE (Server IPv6 Address)

Ensuite redémarrez votre système (la commande netif ne monte pas les tunnels IPv6).

Configuration de rtadvd

Rtadvd va faire du router advertisement c'est à dire qu'il va signaler sa présence sur le LAN aux autres machines. Vos périphériques vont donc pouvoir se générer une adresse IPv6 à partir du préfixe dont ils disposent. Donc créez et éditez le fichier /etc/rtadvd.conf :

re0:\
        :addrs#1:addr="2001:470:c851:192::":prefixlen#64:tc=ether:

Comme vous l'avez deviné ce fichier contient le préfixe du LAN.

Prenez soin de démarrer rtadvd :

# service rtadvd start

Vérification

Sur une autre machine de votre LAN, reconnectez le réseau. Vous devez maintenant voir que vous récupérez une IPv6 :

Vous pouvez aussi utiliser le site test-ipv6.com

Note : J'ai masqué mon IPv6 en rouge sur la capture, par contre j'ai laissé tout ce qui est IPv4, car soit c'est du LAN, soit c'est l'adresse IP de maniatux que tout le monde peut déjà voir ;)

Ressources

• http://www.freebsd.org/doc/handbook/network-ipv6.html
• https://www.sixxs.net/faq/connectivity/?faq=ossetup&os=freebsd
• http://test-ipv6.com/

Suite au rachat de SFR par Numéricable la grande question porte sur la stratégie de déploiement de la fibre qui sera utilisée. En effet Numéricable pose de la fibre dans les quartiers mais ne va pas jusqu'aux logements. La fibre s'arrête à un boitier, et les raccordements aux abonnés sont faits en utilisant le câble coaxial déjà en place (qui historiquement servait uniquement pour la diffusion de la télévision). C'est ce qu'on appelle le FTTLa, Fiber To The Last amplifier. Numéricable est le seul à faire du FTTLa parce qu'il dispose d'un réseau coaxial historique déjà en place. Les autres - Orange, SFR, Free - font parvenir la fibre optique jusqu'au logement de l'abonné, c'est ce qu'on appelle le FTTH, Fiber To The Home. L'opérateur Bouygues se contente jusqu'à présent de louer le réseau Numéricable, donc FTTLa.

Dans cette analyse on remarque que SFR déploie du FTTH alors que Numéricable préfère le FTTLa. La question est donc de savoir quelle technologie va être retenue ou privilégiée. D'un côté j'imagine mal Numéricable abandonner son réseau coaxial, sachant qu'il compte 1 million d'abonnés, plus 363 000 locataires Bouygues. De plus, pourquoi priver les personnes desservies par le coaxial d'un raccordement au FTTLa afin de booster leurs débits ? D'un autre côté, il ne semble pas envisageable de miser éternellement sur cette technologie. On imagine mal en 2014 une entreprise miser sur un réseau de cuivre, dont on connaît les limitations (atténuation avec la distance, usure...), et on imagine encore moins demander aux propriétaires de faire poser du câble coaxial dans leur logement neuf en plus de la fibre sous peine de ne pas être éligible. La force du FTTLa c'est avant tout le réseau coaxial historique.

Je ne parle pas des débits dans mon analyse. En effet à l'heure actuelle la FTTH est plus intéressante (1Gbps descendant, 500Mbps montants) que la FTTLa (200Mbps descendant, 10Mbps montants) mais il est probable que d'ici 2 ans cet écart soit réduit voir nul. En effet Numéricable prépare l'arrivée de débits plus importants, allant jusqu'à 1Gbps, et même de diffusion de tv en 4K (qui en plus n'empiète pas sur le débit internet). La question des débits est donc académique, le débat porte sur la technologie et la mutualisation.

J'espère donc que le FTTLa ne sera qu'un réseau de transition, tout comme le VDSL qui redonne de la vigueur à la paire de cuivre historique, en attendant le déploiement du FTTH, véritable réseau fibre ayant un avenir.

Et voilà l'aventure ADSL OVH c'est fini. Voici un résumé de mon parcours :

• En mars 2013 je déménage et m'oriente vers le fournisseur d'accès Bouygues car j'ai la possibilité d'avoir du 100Mbps par câble coaxial (offre "fibre").
• Fin Juin 2013 je souscrit à l'ADSL OVH (en plus de la connexion fibre Bouygues), afin de pouvoir exploiter l'IPv6, une IP fixe, et m'amuser à monter mon infrastructure réseau avec un routeur pfsense à coup de vlan.
• Il faudra presque 1 mois pour avoir une connexion fonctionnelle, ma ligne n'étant physiquement pas raccordée.
• Une fois la connexion active j'ai pu m'amuser avec pfsense, et l'ensemble fonctionnait plutôt bien, mais cela ne m'a pas apporté ce que je souhaitais.
• J'ai rebranché le serveur derrière la BBox, à coup de NoIP et de tunnel IPv6 pour palier les manques
• J'ai décidé de résilier.

Voici en vrac les raisons qui m'ont poussé à résilier :

• Débit insuffisant, 11Mbps annoncés pour moi sur le site, 4Mbps réels (difficile à tenir quand on est deux à l'utiliser, et c'est encore pire pour l'upload)
• Modem officiel décevant, interface inutilement complexe, bruyant (sifflement), pas de support de l'IPv6
• Espace client labyrinthique, il y a 2 managers et demi différents, je n'arrive pas à trouver ce que je veux.
• Tarifs pas vraiment intéressants par rapport à la concurrence (surtout qu'il faut payer l'ouverture de ligne par FT)
• Très peu de NRA dégroupés (pas de VDSL)
• Bien qu'on soit chez OVH on continue à payer Orange ou SFR indirectement car la collecte passe par chez eux
• Possibilité d'avoir la même "neutralité" du net chez les autres, si on excepte les mauvais élèves : par exemple avec Bouygues j'ai accès au port 25 sortant et aucun site ne semble bridé.
• Plus de possibilité d'avoir internet seul (c'est stupide)
• Contrat avec engagement alors que chez d'autres ce n'est pas systématique

Je salue quand même la compétence du service technique, on a vraiment l'impression de parler à des techniciens, et pas des opérateurs qui lisent un script.

La résiliation ne se fait pas dans la joie, il faut payer des frais de résiliation ainsi que les frais d'envoi :/ soit une somme relativement importante à débourser. Au final si on me demande conseil sur le choix d'une connexion ADSL, je ne recommanderai pas OVH. Si vous êtes un geek, il y a d'autres fournisseurs qui correspondront à vos besoins.

Dans un article précédent j'ai cité un moyen d'utiliser IPv6 à travers un tunnel IPv4. Or il faut répéter la manipulation sur chaque machine, ce qui n'est pas très pratique, encore moins pour les appareils mobiles (Android).

Est-il possible de "déporter" cette passerelle sur une machine (serveur) et pousser automatiquement la configuration aux machines du réseau ? Oui ! Nous allons voir comment mettre en place une "IPv6 Box".

Comme le montre le schéma ci-dessus, la passerelle ne nécessite pas de structure particulière du réseau, elle se branche simplement sur le routeur (*box) comme n'importe quel autre périphérique. Aucune configuration ne sera nécessaire (c'est la magie de l'IPv6) sur les autres machines du réseau.

Le serveur

Il peut être physique ou virtuel (réseau bridge). Il n'y a besoin que d'une interface réseau ce qui simplifie amplement les choses. Ce serveur va :

• Établir et maintenir une connexion au tunnel IPv6
• Faire office de passerelle pour les machines du réseau
• Utiliser le daemon RADVD pour manifester sa présence sur le réseau (les machines s'auto configureront)

Le tutoriel est fait avec Debian, mais devrait fonctionner sur Ubuntu.

Demander un préfixe /48

Commencez par vous inscrire sur le site de Hurricane Electric, et créer un nouveau tunnel. Vous allez pouvoir choisir votre point de sortie (Paris) et spécifier votre adresse IP. Par la suite demandez un préfixe /48 en cliquant sur le bouton Assign, sur la page qui récapitule les paramètres de votre tunnel.

Voici ce que vous devriez obtenir :

Configuration de Debian

Le serveur dispose d'une interface réseau eth0 avec les paramètres suivants :

• Adresse IP fixe, 192.168.0.10/24
• Passerelle IPv4 (*Box) : 192.168.0.254
• Adresse IPv6 du tunnel : 2001:470:c851:10::1/64
• Adresse IPv6 eth0 : 2001:470:c851:192::1/64

Les adresses IPv6 choisies font partie du préfixe /48 attribué (2001:470:c851::). Aidez-vous du calculateur IPv6 Calculator si besoin.

Ouvrez et modifiez /etc/network/interfaces comme ceci :

auto lo

iface lo inet loopback



# The primary network interface

allow-hotplug eth0

iface eth0 inet static

        address 192.168.0.10

        netmask 255.255.255.0

        gateway 192.168.0.254

iface eth0 inet6 static

        address 2001:470:c851:192::1

        netmask 64



auto he-ipv6

iface he-ipv6 inet6 v4tunnel

        address 2001:470:c851:10::1

        netmask 64

        endpoint 216.66.84.42

        ttl 255

        gateway 2001:470:c851::1

Puis relancez le réseau avec la commande suivante (ou redémarrez le serveur) :

# service networking restart

Pour vérifier que le tunnel est bien en place, tapez la commande suivante :

# ping6 google.com

Ou alors :

# apt-get update

(Si vous utilisez les dépôts Debian par défaut, ils sont accessibles en IPv6...).

Radvd

Un réseau en IPv6 n'a pas besoin de serveur DHCP. En effet, le routeur va manifester sa présence sur le réseau, et les machines vont s'auto-configurer (Stateless Address Autoconfiguration, SLAAC). On va donc installer Radvd :

# apt-get install radvd

Créez le fichier /etc/radvd.conf et ajoutez :

interface eth0 {

        IgnoreIfMissing on;

        AdvSendAdvert on;

        MinRtrAdvInterval 30;

        MaxRtrAdvInterval 60;

        prefix 2001:470:c851:192::/64 {

                AdvOnLink on;

                AdvAutonomous on;

                AdvRouterAddr on;

        };

};

Lancez ensuite le service :

# service radvd start

Vérifications

Redémarrez une des machines de votre réseau, et vérifiez si elle récupère bien une IPv6. Attention, si cette machine utilise network-manager, il se peut que l'IPv6 soit désactivé par défaut ! Dans ce cas, éditez votre connexion réseau, et dans l'onglet "Paramètres IPv6" sélectionnez "Automatique". La capture d'écran ci-dessous montre le paramétrage sur CentOS6 + Gnome2 mais reste similaire sur Fedora et KDE.

Allez sur le site test-ipv6.com. Si vous obtenez un 10/10, c'est bon !