SwordArMor : des trucs à propos du hacking et du DIY

Mise en place d’un NanoKVM sur mon routeur

2026-03-07T14:34:14+01:00

J’ai récemment fait l’acquisition d’un NanoKVM Full afin de pouvoir reprendre la main sur mon routeur (qui est une machine ARM sans IPMI intégré) si jamais je foire sa configuration réseau alors que je ne suis pas chez moi. Je n’avais jusqu’alors jamais eu d’OOB sur mon routeur à la maison, bien que j’ai un backup 4G en cas de défaillance de ma FTTH (principalement dû à des écrasements/rebranchements). Ce qui fait que je suis peu ou prou protégé contre la bêtise de l’infra FTTH, mais pas contre ma propre bêtise.
Mon setup est fait de telle façon que le routeur 4G n’est pas là pour complètement prendre la main du routeur de la FTTH, mais pour servir de support à des tunnels wireguard qui ont un cost OSPF plus élevé que le PPP sur la FTTH. De cette façon, j’ai fallback transparent (modulo le MTU) entre les connexions. Par contre, si jamais le routeur FTTH tombe, la 4G tombe avec. Je prévoie d’avoir une redondance complète le jour où j’aurai une deuxième fibre, mais ça viendra dans un second temps.
Histoire de pouvoir prendre la main sur mon NanoKVM même en cas de coupure de fibre je veux avoir la main dessus par la 4G, mais aussi directement via mon LAN pour éviter de bouffer mon forfait 4G pour rien lorsque je l’utilise depuis chez moi (par exemple quand j’installe une nouvelle machine et que j’ai la flemme de brancher un écran dessus).

La configuration de base de mon routeur 4G est de nater tout ce que va vers l’interface 4G. Le plus propre serait d’avoir du routage dynamique, mais la flash n’est pas assez grosse pour installer ce daemon en plus ; après avoir installé snmpd et tcpdump dessus, il ne reste que 1.2M libres sur la flash. De plus, bird n’est pas packagé et frr n’est pas particulièrement léger.
J’ai donc dessus une route par défaut sur la 4G (qmimux0), mes IPs en more-spec sur l’interco avec mon routeur FTTH (br-lan), et un /30 dédié au NanoKVM (br-ifLan1). J’ai gardé la configuration en DHCP côté NanoKVM comme ça je peux facilement le brancher ailleurs si besoin, d’où le besoin de /30 (pour avoir l’IP de broadcast) au lieu d’un classique /31. Et avec ça, je peux accéder au NanoKVM depuis chez moi et en même temps faire monter le VPN wireguard par la 4G.

root@Teltonika-RUT950:~# ip r
default dev qmimux0 proto static scope link src 10.222.240.167 metric 1
10.0.0.0/8 via 10.0.4.1 dev br-lan proto static metric 3
10.0.4.0/31 dev br-lan proto static scope link metric 3
10.0.4.64/30 dev br-ifLan1 proto kernel scope link src 10.0.4.65
10.222.240.167 dev qmimux0 proto static scope link metric 1
45.91.126.0/24 via 10.0.4.1 dev br-lan proto static metric 3
172.16.0.0/12 via 10.0.4.1 dev br-lan proto static metric 3
192.168.0.0/16 via 10.0.4.1 dev br-lan proto static metric 3
root@Teltonika-RUT950:~# grep -C2 nanokvm /etc/config/dhcp
config host
	option mac '48:da:35:6f:a0:73'
	option name 'nanokvm'
	option ip '10.0.4.66'

alarig@x280 ~ % ping nanokvm.int.no.swordarmor.fr
PING nanokvm.int.no.swordarmor.fr (10.0.4.66) 56(84) bytes of data.
64 bytes from nanokvm.int.no.swordarmor.fr (10.0.4.66): icmp_seq=1 ttl=62 time=1.71 ms
64 bytes from nanokvm.int.no.swordarmor.fr (10.0.4.66): icmp_seq=2 ttl=62 time=1.59 ms
^C
--- nanokvm.int.no.swordarmor.fr ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.591/1.649/1.707/0.058 ms

Arrivé ici je vais naturellement sur l’interface web (le port ssh n’était pas ouvert par défaut) pour voir si je peux activer le SSH, et on peut !
Une fois loggué en root, je commence à regarder ce que j’ai sous la main, par simple curiosité, mais je pense que vous me comprendrez. Nous avons donc affaire à un Linux (pas surprenant) qui tourne sur un RISC-V 64-bit (malin pour avoir une faible conso) dont je connais pas le modèle exact parce que lscpu n’est pas dispo. Il s’agît d’une disto custom, /etc/os-release parle de Buildroot 2023.11.2, mais on a tout le userland habituel et même htop ainsi que 6.4G encore disponibles sur la partition principale.
Pour les curieux, voici le dmesg.

Puisque je suis root, et bien que l’interface web ne propose pas ces options, mon premier réflexe est d’apporter quelques finitions au système afin de l’intégrer au mieux au reste de mon infra. Cela commence donc par utiliser mon propre résolveur DNS et serveur NTP et aussi exporter les logs.
Pour les deux premiers c’est très facile, les fichiers de configuration habituels sont déjà là, il suffit donc de les éditer afin d’avoir les valeurs que je veux puis ensuite de redémarrer les services.
Par contre pour les logs, je n’en ai pas trouvé. Je suis donc allé voir comment le syslogd est lancé afin de savoir si je pouvais utiliser un fichier de configuration absent par défaut ou bien des variables d’environnement. Mon premier réflexe a été de lister les units systemd mais la commande n’existe pas.

root@kvm-a073 ~ # systemctl list-units
bash: systemctl: command not found

C’est somme toute assez logique puisque nous sommes tout de même sur une petite machine, et systemd est tout sauf léger. L’étape suivante est donc de fouiller /etc/init.d à l’ancienne, et bingo !

root@kvm-a073 ~ # find /etc/init.d/ -iname '*log*'
/etc/init.d/S02klogd
/etc/init.d/S01syslogd
root@kvm-a073 ~ # cat /etc/init.d/S01syslogd
#!/bin/sh

DAEMON="syslogd"
PIDFILE="/var/run/$DAEMON.pid"

SYSLOGD_ARGS=""

# shellcheck source=/dev/null
[ -r "/etc/default/$DAEMON" ] && . "/etc/default/$DAEMON"

# BusyBox' syslogd does not create a pidfile, so pass "-n" in the command line
# and use "-m" to instruct start-stop-daemon to create one.
start() {
	printf 'Starting %s: ' "$DAEMON"
	# shellcheck disable=SC2086 # we need the word splitting
	start-stop-daemon -b -m -S -q -p "$PIDFILE" -x "/sbin/$DAEMON" \
		-- -n $SYSLOGD_ARGS
	status=$?
	if [ "$status" -eq 0 ]; then
		echo "OK"
	else
		echo "FAIL"
	fi
	return "$status"
}

stop() {
	printf 'Stopping %s: ' "$DAEMON"
	start-stop-daemon -K -q -p "$PIDFILE"
	status=$?
	if [ "$status" -eq 0 ]; then
		rm -f "$PIDFILE"
		echo "OK"
	else
		echo "FAIL"
	fi
	return "$status"
}

restart() {
	stop
	sleep 1
	start
}

case "$1" in
	start|stop|restart)
		"$1";;
	reload)
		# Restart, since there is no true "reload" feature.
		restart;;
	*)
		echo "Usage: $0 {start|stop|restart|reload}"
		exit 1
esac

Le script d’init parle donc de la variable SYSLOGD_ARGS sourcée depuis le fichier /etc/default/syslogd. Un file nous apprend qu’il s’agît de l’implémentation busybox (/sbin/syslogd: symbolic link to ../bin/busybox. On peut ainsi aller lire le man de busybox pour savoir quelles options on peut utiliser pour avoir le droit au bonheur.

root@kvm-a073 ~ # ps aux | grep log
  224 root     /sbin/syslogd -n
  237 root     /sbin/klogd -n
 1671 root     grep log
root@kvm-a073 ~ # cat /etc/default/syslogd 
SYSLOGD_ARGS="-R msi.no.swordarmor.fr -L"
root@kvm-a073 ~ # /etc/init.d/S01syslogd restart
Stopping syslogd: OK
Starting syslogd: OK
root@kvm-a073 ~ # ps aux | grep log
  237 root     /sbin/klogd -n
 1935 root     /sbin/syslogd -n -R msi.no.swordarmor.fr -L
 1941 root     grep log

Tout cela est très sympathique mais ce que j’aimerais quand même à un moment c’est avoir un wireguard dessus pour prendre la main via la 4G, sinon on va encore dire que je me disperse. Malheureusement l’interface web ne parle que de tailscale mais pas d’un simple wireguard comme je l’aimerais. Qu’à cela ne tienne je suis root, je vais trouver un arrangement.
Le classique /etc/rc.local pour ~~configurer le réseau sous debian~~ lancer des commandes au boot n’est pas vide mais parle de fichiers qui n’existent pas. Dans le doute je me dis que ça risque d’être écrasé lors d’une mise à jour. Je ne peux pas non plus lancer un cron @reboot car le daemon est installé mais n’est pas lancé.

root@kvm-a073 ~ # cat /etc/rc.local
#!/bin/sh

echo "HELLO WORLD"

if [ -e /boot/maixcam ]
then
	/maixapp/apps/launcher/launcher &
fi
root@kvm-a073 ~ # file /boot/maixcam
/boot/maixcam: cannot open `/boot/maixcam' (No such file or directory)
root@kvm-a073 ~ # file /maixapp/apps/launcher/launcher
/maixapp/apps/launcher/launcher: cannot open `/maixapp/apps/launcher/launcher' (No such file or directory)
root@kvm-a073 ~ # which crond
/usr/sbin/crond
root@kvm-a073 ~ # ps aux | grep cron
 1384 root     grep cron

Donc il ne me reste plus qu’à faire les choses proprement : écrire un script d’init. Je me dis que c’est une bonne idée de se mettre au même niveau de priorité que sshd, puisqu’il a également besoin que le réseau soit up avant de démarrer. Je ne m’embête pas avec la gestion du PID vu que c’est un module kernel que je lance, ni avec les commandes pour faire tomber le VPN vu que j’ai pas prévu de le faire, mais ça serait assez trivial à ajouter.

root@kvm-a073 ~ # find /etc/init.d/ -iname '*ssh*'
/etc/init.d/S50sshd
root@kvm-a073 ~ # vim /etc/wireguard/wg0.conf
root@kvm-a073 ~ # sed 's/PrivateKey.*/PrivateKey = blah/' /etc/wireguard/wg0.conf
[Interface]
PrivateKey = blah

[Peer]
#Endpoint = ovpn.fr.swordarmor.fr:10017
Endpoint = 89.234.186.219:10017
PublicKey = ZzPmmpKns18Q6lpJ5V+T6MenBXjMEx2qDDj58yaIzTo=
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
root@kvm-a073 ~ # vim /etc/init.d/S50wireguard
root@kvm-a073 ~ # cat /etc/init.d/S50wireguard
#!/bin/sh
case "$1" in
	start)
		echo "Start ovpn.fr connection"
		ip link add dev wg0 type wireguard
		wg setconf wg0 /etc/wireguard/wg0.conf
		ip addr add 10.0.1.9/31 dev wg0
		ip link set up dev wg0
		ping -c1 10.0.1.8
		#ip route add 0.0.0.0/0 dev wg0
		;;
	stop)
		;;
	restart|reload)
		"$0" stop
		"$0" start
		;;
	*)
		echo "Usage: $0 {start|stop|restart}"
	exit 1
esac
exit $?
root@kvm-a073 ~ # chmod +x /etc/init.d/S50wireguard
root@kvm-a073 ~ # /etc/init.d/S50wireguard start
root@kvm-a073 ~ # ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 48:da:35:6f:a0:73 brd ff:ff:ff:ff:ff:ff permaddr c2:e8:e7:a3:16:80
    inet 10.0.4.66/30 brd 10.0.4.67 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4ada:35ff:fe6f:a073/64 scope link
       valid_lft forever preferred_lft forever
3: ip6tnl0@NONE:  mtu 1452 qdisc noop state DOWN group default qlen 1000
    link/tunnel6 :: brd :: permaddr 8aa8:c467:33d4::
4: usb0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 48:da:35:6e:a0:73 brd ff:ff:ff:ff:ff:ff
    inet 10.160.115.1/24 scope global usb0
       valid_lft forever preferred_lft forever
    inet6 fe80::4ada:35ff:fe6e:a073/64 scope link
       valid_lft forever preferred_lft forever
5: wg0:  mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.1.9/31 scope global wg0
       valid_lft forever preferred_lft forever

Donc on a bien un tunnel wireguard en plus du LAN, avec la MTU par défaut qui semble être fonctionnelle désormais ; même si lorsque j’avais monté les tunnels pour redonder ma FTTH avec la 4G j’avais dû abaisser le MTU à 1340.

root@kvm-a073 ~ # tracepath ovpn.fr.swordarmor.fr
 1?: [LOCALHOST]                      pmtu 1500
 1:  Teltonika-RUT950.com                                  2.881ms 
 1:  eth0.105.rut950.int.no.swordarmor.fr                  2.950ms 
 2:  no reply
 3:  192.168.8.62                                         59.745ms asymm  2 
 4:  192.168.255.22                                       47.473ms asymm  7 
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  ovpn.fr.as208627.net                                 87.731ms reached
     Resume: pmtu 1500 hops 16 back 13

La configuration de mon routeur wireguard est de nater tout ce qui va vers un tunnel. L’utilité première est de prendre la main sur des machines nomades à distance pour lesquelles je dois assurer la maintenance (celles de la famille quoi) et sur lesquelles je ne maîtrise pas forcément le routage de leur LAN.
Ici ça m’arrange parce que du coup j’ai pas besoin de gérer des tables de routage différentes sur le NanoKVM entre le LAN et le wireguard. L’IP source vue par le KVM sur le wireguard sera forcément celle sur la route directement connectée et le LAN pourra continuer à utiliser la default, donc la réponse ira au bon endroit.
Le mtr montre bien que je fais le tour de mon réseau pour revenir chez moi. Je ne distribue pas d’IP publique dans le VPN parce que je ne vois pas spécialement de cas d’usage où je ne pourrais pas monter mon propre VPN pour y accéder.

alarig@x280 ~ % mtr -bzwe nanokvm-wg.int.no.swordarmor.fr
Start: 2026-03-07T15:44:08+0100
HOST: x280.int.no.swordarmor.fr                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???         enp3s0.101.core02-rennes.fr.as208627.net (192.168.5.254)   0.0%    10    1.1   1.1   0.8   1.2   0.1
  2. AS???         ppp0.edge01-th2lf.swordarmor.fr (10.0.4.16)                0.0%    10    6.9   7.0   6.3   8.4   0.7
  3. AS???         eno1.104.regis.swordarmor.fr (10.0.4.24)                   0.0%    10   13.6  13.9  13.1  15.7   0.8
  4. AS204092      ovpn.fr.as208627.net (89.234.186.219)                      0.0%    10   14.1  13.9  13.1  15.2   0.6
  5. AS???         nanokvm-wg.int.no.swordarmor.fr (10.0.1.9)                 0.0%    10   57.4  79.0  53.0 119.6  19.3

Et maintenant qu’on a tout ça, on peut enfin regarder si la fonction de KVM est bien remplie. Donc déjà premier test : est-ce qu’il reste bien allumé si je redémarre le routeur ? (si jamais il prenait l’alimentation électrique depuis l’USB qui sert à envoyer les I/O clavier).
Et c’est bien le cas, l’uptime du KVM est supérieur à celui du routeur.

alarig@x280 ~ % ssh root@nanokvm.int.no.swordarmor.fr
root@nanokvm.int.no.swordarmor.fr's password:
# uptime
 11:57:12 up 23 min,  load average: 5.30, 5.57, 4.10
#

alarig@x280 ~ % ssh root@core01-rennes.fr.swordarmor.fr
Linux core01-rennes.fr.swordarmor.fr 6.18.12-gentoo-core01-arm #1 SMP PREEMPT_DYNAMIC Fri Feb 20 00:23:04 CET 2026 aarch64 GNU/Linux
Last login: Sat Mar  7 11:28:15 CET 2026 from 192.168.5.1 on pts/1
core01-rennes ~ # uptime
 12:57:32 up 8 min,  1 user,  load average: 0.17, 0.12, 0.07
core01-rennes ~ #

J’ai bien les logs dmesg qui me disent que l’émulation de clavier/souris est présente. J’ai même le /data du NanoKVM qui est exposé.

core01-rennes ~ # dmesg | grep -i NanoKVM
[    3.190596] usb 16-1: Product: NanoKVM
[    3.274675] input: sipeed NanoKVM as /devices/platform/PNP0D10:09/usb16/16-1/16-1:1.2/0003:3346:1009.0001/input/input1
[    3.426555] hid-generic 0003:3346:1009.0001: input,hidraw0: USB HID v1.01 Keyboard [sipeed NanoKVM] on usb-PNP0D10:09-1/input2
[    3.427383] input: sipeed NanoKVM as /devices/platform/PNP0D10:09/usb16/16-1/16-1:1.3/0003:3346:1009.0002/input/input2
[    3.427588] hid-generic 0003:3346:1009.0002: input,hidraw1: USB HID v1.01 Mouse [sipeed NanoKVM] on usb-PNP0D10:09-1/input3
[    3.428332] input: sipeed NanoKVM as /devices/platform/PNP0D10:09/usb16/16-1/16-1:1.4/0003:3346:1009.0003/input/input3
[    3.428452] hid-generic 0003:3346:1009.0003: input,hidraw2: USB HID v1.01 Mouse [sipeed NanoKVM] on usb-PNP0D10:09-1/input4
[    4.537290] scsi 0:0:0:0: Direct-Access     NanoKVM  USB Mass Storage 0520 PQ: 0 ANSI: 2
core01-rennes ~ # fdisk -l /dev/sda
Disk /dev/sda: 21.49 GiB, 23076012032 bytes, 45070336 sectors
Disk model: USB Mass Storage
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Et quand je vais sur l’interface web, j’ai bien la sortie tty et je peux taper des trucs dedans sans avoir des caractères bizarres comme sur les IPMI supermicro quand il y a un mix qwerty/azery.

La puissance du CPU ne semble pas être très élevée, puisque quand j’ai téléchargé l’ISO d’arch (qui fait 1.4Go) ça a pris un peu plus de vingt minutes, soit un débit de ~10Mbps. Pendant ce temps le CPU était à 100% tout du long. Mais c’est largement suffisant pour afficher la sortie console et je ne compte pas passer mon temps à télécharger plein d’ISO différents.
Donc à voir sur la durée si mes bricoles résistent aux upgrades, mais ça me semble être un produit de qualité tout à fait respectable et largement hackable.

Essai d’un routeur ARM

2026-02-03T21:38:49+01:00

Dans la mesure où ARM prend de plus en plus d’ampleur, ça faisait quelques temps que je voulais voir ce que ça donnait de router avec, notamment par rapport à la gestion des IRQ et de la fréquence.
En effet, pour router il n’y a pas besoin d’avoir un CPU avec beaucoup de fioritures, mais plutôt un CPU très rapidement cadencé. Un paquet ne demande pas beaucoup de calcul, par contre ça en demande souvent. Il est également connu qu’il vaut mieux avoir un nombre carré de cœurs, pour que les drivers puissent plus facilement s’y retrouver pour leurs queues de traitement.

À cause d’un affreux influenceur IRC je me suis retrouvé en possession d’un Minisforum MS-R1. Il a tout ce que je demande à un routeur : deux ports réseau. Par contre en terme de CPU cadencé et carré c’est une autre histoire. Il y a deux CPUs différents, et les cœurs eux-même ont des fréquences différentes, pour un seul nœud NUMA. Je ne sais pas comment ça fonctionne, et je ne sais pas trop à quel CPU les drivers réseau sont branchés.
Mais après tout, c’est pour router chez moi, où je fais à peine 250Mbps le vent dans le dos, donc pourquoi pas.

core01-rennes ~ # lscpu --all --extended
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
  0    0      0    0 0:0:0:0          yes 2600.0000 800.0000  800.0000
  1    0      0    1 1:1:1:0          yes 2600.0000 800.0000  800.0000
  2    0      0    0 2:2:2:0          yes 1800.0000 800.0000 1722.5800
  3    0      0    1 3:3:3:0          yes 1800.0000 800.0000 1722.5800
  4    0      0    2 4:4:4:0          yes 1800.0000 800.0000 1800.0000
  5    0      0    3 5:5:5:0          yes 1800.0000 800.0000 1800.0000
  6    0      0    2 6:6:6:0          yes 2300.0000 800.0000  800.0000
  7    0      0    3 7:7:7:0          yes 2300.0000 800.0000  800.0000
  8    0      0    4 8:8:8:0          yes 2200.0000 800.0000  800.0000
  9    0      0    5 9:9:9:0          yes 2200.0000 800.0000  800.0000
 10    0      0    6 10:10:10:0       yes 2500.0000 800.0000  800.0000
 11    0      0    7 11:11:11:0       yes 2500.0000 800.0000 1133.1300
core01-rennes ~ # lscpu
Architecture:                aarch64
  CPU op-mode(s):            64-bit
  Byte Order:                Little Endian
CPU(s):                      12
  On-line CPU(s) list:       0-11
Vendor ID:                   ARM
  BIOS Vendor ID:            Cix Technology Group Co., Ltd.
  Model name:                Cortex-A520
    BIOS Model name:         CIX P1 CP8180   CPU @ 2.6GHz
    BIOS CPU family:         258
    Model:                   1
    Thread(s) per core:      1
    Core(s) per socket:      4
    Socket(s):               1
    Stepping:                r0p1
    Frequency boost:         disabled
    CPU(s) scaling MHz:      44%
    CPU max MHz:             1800.0000
    CPU min MHz:             800.0000
    BogoMIPS:                2000.33
    Flags:                   fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha
                             3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull sve
                             bitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh bti mte ecv afp mte3 wfxt
  Model name:                Cortex-A720
    BIOS Model name:         CIX P1 CP8180   CPU @ 2.6GHz
    BIOS CPU family:         258
    Model:                   1
    Thread(s) per core:      1
    Core(s) per socket:      8
    Socket(s):               1
    Stepping:                r0p1
    CPU(s) scaling MHz:      42%
    CPU max MHz:             2600.0000
    CPU min MHz:             800.0000
    BogoMIPS:                2000.33
    Flags:                   fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha
                             3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull sve
                             bitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh bti mte ecv afp mte3 wfxt
Caches (sum of all):
  L1d:                       640 KiB (12 instances)
  L1i:                       640 KiB (12 instances)
  L2:                        4 MiB (12 instances)
  L3:                        12 MiB (1 instance)
NUMA:
  NUMA node(s):              1
  NUMA node0 CPU(s):         0-11
Vulnerabilities:
  Gather data sampling:      Not affected
  Ghostwrite:                Not affected
  Indirect target selection: Not affected
  Itlb multihit:             Not affected
  L1tf:                      Not affected
  Mds:                       Not affected
  Meltdown:                  Not affected
  Mmio stale data:           Not affected
  Old microcode:             Not affected
  Reg file data sampling:    Not affected
  Retbleed:                  Not affected
  Spec rstack overflow:      Not affected
  Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:                Mitigation; __user pointer sanitization
  Spectre v2:                Mitigation; CSV2, BHB
  Srbds:                     Not affected
  Tsa:                       Not affected
  Tsx async abort:           Not affected
  Vmscape:                   Not affected

J’ai voulu bêtement tenter l’installation en PXE comme d’habitude, mais l’UEFI ne sait pas faire ça dans les menus, et j’ai pas trouvé la commande pour le faire depuis le shell UEFI (j’ai pas beaucoup cherché non plus). J’ai donc profité d’avoir récupéré des clés USB FRNIX au récent aPEERo de Rennes pour la dd et booter dessus, ça ne m’était pas arrivé depuis bien longtemps.
La machine a bien booté correctement sur le live gentoo, mais je n’avais pas de réseau. En effet les NICs realtek 10G étaient trop récentes pour le kernel LTS du moment (6.12). J’ai profité d’avoir un port PCI pour mettre une carte broadcom qui traînait chez moi et affaire réglée.
J’ai donc ensuite suivie la procédure classique d’installation de gentoo, mais en UEFI (une première pour moi, j’ai toujours activé la rétrocompat BIOS par flemme de changer mes habitudes).
Une fois l’installation faite je suis passé sur un kernel 6.18 (en estimant que ça sera celle là qui deviendra la prochaine LTS, on verra bien) afin de profiter des drivers ajoutés en 6.16. J’ai donc maintenant 4 cartes réseau et une carte Wi-Fi sur mon routeur, avec des noms toujours aussi prévisibles, merci la convention de nommage systemd.

core01-rennes ~ # lspci -k
00:00.0 PCI bridge: Cadence Design Systems, Inc. Device 0100
	Kernel driver in use: pcieport
	Kernel modules: cdns3_pci_wrap, cdnsp_udc_pci
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 8127 (rev 05)
	Subsystem: Realtek Semiconductor Co., Ltd. Device 0123
	Kernel driver in use: r8169
	Kernel modules: r8169
30:00.0 PCI bridge: Cadence Design Systems, Inc. Device 0100
	Kernel driver in use: pcieport
	Kernel modules: cdns3_pci_wrap, cdnsp_udc_pci
31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 8127 (rev 05)
	Subsystem: Realtek Semiconductor Co., Ltd. Device 0123
	Kernel driver in use: r8169
	Kernel modules: r8169
60:00.0 PCI bridge: Cadence Design Systems, Inc. Device 0100
	Kernel driver in use: pcieport
	Kernel modules: cdns3_pci_wrap, cdnsp_udc_pci
61:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
	Subsystem: MEDIATEK Corp. Device c616
	Kernel driver in use: mt7921e
	Kernel modules: mt7921e
90:00.0 PCI bridge: Cadence Design Systems, Inc. Device 0100
	Kernel driver in use: pcieport
	Kernel modules: cdns3_pci_wrap, cdnsp_udc_pci
91:00.0 Non-Volatile memory controller: Kingston Technology Company, Inc. OM8TAP4 PCIe 4 NVMe SSD (QLC) (DRAM-less)
	Subsystem: Kingston Technology Company, Inc. OM8TAP4 PCIe 4 NVMe SSD (QLC) (DRAM-less)
	Kernel driver in use: nvme
	Kernel modules: nvme
c0:00.0 PCI bridge: Cadence Design Systems, Inc. Device 0100
	Kernel driver in use: pcieport
	Kernel modules: cdns3_pci_wrap, cdnsp_udc_pci
c1:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe
	Subsystem: Broadcom Inc. and subsidiaries Device 2003
	Kernel driver in use: tg3
	Kernel modules: tg3
c1:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe
	Subsystem: Broadcom Inc. and subsidiaries Device 2003
	Kernel driver in use: tg3
	Kernel modules: tg3
core01-rennes ~ # ip l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp49s0:  mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 38:05:25:33:e2:30 brd ff:ff:ff:ff:ff:ff
3: enp193s0f0:  mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:0a:f7:63:93:ca brd ff:ff:ff:ff:ff:ff
4: enp1s0:  mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 38:05:25:33:e2:2f brd ff:ff:ff:ff:ff:ff
5: enp193s0f1:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:0a:f7:63:93:cb brd ff:ff:ff:ff:ff:ff
6: wlp97s0:  mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether b0:6b:11:11:48:e8 brd ff:ff:ff:ff:ff:ff

J’ai ensuite mis une IP sur chaque interface realtek, un PC au bout et j’ai activé le routage. Le but est de savoir si la machine tient le routage au giga (même si c’est un débit que j’atteins uniquement en pic, ça serait dommage de ne pas l’avoir).

core01-rennes ~ # ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo
       valid_lft forever preferred_lft forever
2: enp49s0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 38:05:25:33:e2:30 brd ff:ff:ff:ff:ff:ff
    inet 10.0.22.1/24 scope global enp49s0
       valid_lft forever preferred_lft forever
    inet6 fe80::3a05:25ff:fe33:e230/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
3: enp193s0f0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0a:f7:63:93:ca brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.6/24 brd 192.168.5.255 scope global enp193s0f0
       valid_lft forever preferred_lft forever
    inet6 2a0e:f42:0:3::6/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:f7ff:fe63:93ca/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
4: enp1s0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 38:05:25:33:e2:2f brd ff:ff:ff:ff:ff:ff
    inet 10.0.35.1/24 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::3a05:25ff:fe33:e22f/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
5: enp193s0f1:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:0a:f7:63:93:cb brd ff:ff:ff:ff:ff:ff
6: wlp97s0:  mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether b0:6b:11:11:48:e8 brd ff:ff:ff:ff:ff:ff
core01-rennes ~ # ip r
default via 192.168.5.254 dev enp193s0f0 metric 3
10.0.22.0/24 dev enp49s0 proto kernel scope link src 10.0.22.1
10.0.35.0/24 dev enp1s0 proto kernel scope link src 10.0.35.1
192.168.5.0/24 dev enp193s0f0 proto kernel scope link src 192.168.5.6

Et les deux PCs de tests sont configurés de la même façon, en échangeant juste les IPs.

roucool ~ # ip r
default via 10.0.22.1 dev enp0s25 
10.0.22.0/24 dev enp0s25 proto kernel scope link src 10.0.22.2 
127.0.0.0/8 via 127.0.0.1 dev lo 
roucool ~ # ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1f:16:1e:f2:bd brd ff:ff:ff:ff:ff:ff
    inet 10.0.22.2/24 scope global enp0s25
       valid_lft forever preferred_lft forever
    inet6 fe80::21f:16ff:fe1e:f2bd/64 scope link 
       valid_lft forever preferred_lft forever
roucool ~ # mtr -bzwe 10.0.35.2
Start: 2026-02-03T21:35:40+0100
HOST: roucool.swordarmor.fr          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    10.0.22.1               0.0%    10    0.1   0.2   0.1   0.3   0.1
  2. AS???    10.0.35.2               0.0%    10    0.3   0.3   0.3   0.4   0.0

En lançant un iperf3 j’ai bien du giga :

roucool ~ # iperf3 -c 10.0.35.2
Connecting to host 10.0.35.2, port 5201
[  5] local 10.0.22.2 port 46398 connected to 10.0.35.2 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   947 Mbits/sec    0    462 KBytes       
[  5]   1.00-2.00   sec   112 MBytes   937 Mbits/sec    0    486 KBytes       
[  5]   2.00-3.00   sec   112 MBytes   942 Mbits/sec    2    402 KBytes       
[  5]   3.00-4.00   sec   112 MBytes   935 Mbits/sec    1    345 KBytes       
[  5]   4.00-5.00   sec   111 MBytes   934 Mbits/sec    2    390 KBytes       
[  5]   5.00-6.00   sec   111 MBytes   932 Mbits/sec    0    447 KBytes       
[  5]   6.00-7.00   sec   112 MBytes   940 Mbits/sec    3    389 KBytes       
[  5]   7.00-8.00   sec   111 MBytes   933 Mbits/sec    0    448 KBytes       
[  5]   8.00-9.00   sec   112 MBytes   937 Mbits/sec    0    455 KBytes       
[  5]   9.00-10.00  sec   112 MBytes   940 Mbits/sec    0    457 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec    8            sender
[  5]   0.00-10.01  sec  1.09 GBytes   936 Mbits/sec                  receiver

iperf Done.

Donc la machine semble suffisamment taillée pour faire office de CPE. En lançant un htop pendant le test, j’ai remarqué que l’IRQ était à 80% sur un seul cœur (en même temps j’ai fait le test avec un seul flux), mais la question est de savoir s’il y a assez de marge en ayant un PPP en plus dans l’équation. Je n’ai pas encore testé ce cas de figure car je n’ai pas encore remplacé mon ancien routeur, mais ça devrait se faire assez rapidement.

Verdict post-migration, avec un iperf vers « Internet » (la machine qui me sert de LNS) j’ai :

400M en up sur un seul flux
800M en up sur deux flux
800M en down sur un flux

Et j’ai dû mettre de l’irqbalance sinon ça ne dépassait pas les quelques centaines de Mbps. Je n’explique pas du tout pourquoi j’ai des débits différents en up et en down, et surtout pourquoi mettre deux flux ça change quelque chose en up mais pas en down.
Après quelques jours de réflexions j’ai fini par adopter une autre technique : je force les deux cœurs les plus rapides à rester à 2.6 Ghz, je change l’affinité de pppd dessus, je les renice à -10 et du coup j’ai viré l’irqbalance. Avec ça j’ai 800-900Mbps symétriques pour une consommation de 20W.

	echo 'performance' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
	echo 'performance' > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
	for pppd in $(pgrep pppd); do renice -10 -p $pppd; taskset -cp 0-1 $pppd; done

Installer des optiques 10G ZR directement dans une carte réseau PCI

2025-06-29T12:34:23+02:00

Dans un contexte de FAI associatif comme grifon on cherche à vraiment limiter les coûts. Cela nous amène à des architectures où des machines peuvent faire à la fois routeur et serveur. C’est le cas de la machine que nous avons à TH2 : grifon la partage avec stolon afin de diviser par deux le prix du U (qui est trois fois celui de Rennes, mais c’est normal c’est pas les mêmes DCs non plus). Cette machine a donc deux fonctions :

recevoir les liens des différents FAIs
héberger les routeurs virtualisés des dits FAIs

À titre d’exemple, la machine a actuellement quatre liens :

un 10G BiDi pour une porte de collecte qui sert à recevoir les FTTH de stolon et grifon et un L2 vers Pau pour Stolon
un 10G LR qui porte un transit pour stolon et grifon et un L2 vers Rennes pour grifon
un 1G cuivre qui sert à avoir un peering intra-baie vers un autre réseau sans perdre de précieux ports 10G
un 10G ZR qui portera un autre transit et un autre L2 vers Rennes pour grifon afin de redonder celui déjà en place

Ici c’est ce dernier lien qui nous intéresse. La première question qui viendra aux habitués du réseau est : pourquoi diable du ZR sur une machine à TH2 ? Parce que nous n’avons pas envie de payer une cross-connection tous les mois, nous passons donc par une cross-connection déjà en place mais muxée. Comme il est très rare de vouloir muxer des liens locaux, la très très grande majorité des optiques DWDM sont en ER ou ZR ; je n’ai d’ailleurs pour ma part jamais vu de DWDM LR. Nous n’avons évidemment pas non plus envie d’acheter des optiques 10G DWDM (on parle de ~1000 € la paire). Donc comme d’habitude dans ce genre de cas, on compte sur l’alignement des planètes, et ça passe ! Nous avons pu trouver des optiques canal 29 et ce canal était disponible sur les MUX que nous allions utiliser, la seule contrainte est d’avoir des atténuateurs 10 dB pour éviter d’éblouir nos optiques, mais ça c’est 1 € l’unité ou pas loin.
Donc en gros : on arrive à avoir une cross-co dans TH2 à 2 € au lieu de devoir payer les FAS et le récurrent si nous avions utilisé du LR ou du BiDi.

Tout cela est bien joli sur le papier, mais il faut maintenant insérer ces optiques 10G DWDM ZR dans une carte qui en veut bien. En effet, les optiques classiques de datacenter (donc SR ou LR) consomment moins d’un watt, et les cartes ont donc un refroidissement qui va avec. Quand on branche une optique ZR qui consomme trois watts sur une bien connue X510, même avec les options kernel pour autoriser tout le monde, le driver dit non avec ce message très reconnaissable :

[  389.330803] ixgbe 0000:03:00.0: failed to initialize because an unsupported SFP+ module type was detected.
[  389.330805] ixgbe 0000:03:00.0: Reload the driver after installing a supported module.

Alors qu’une optique ER sur le port d’à côte fonctionne :

[  389.330813] ixgbe 0000:03:00.1 enp3s0f0: detected SFP+: 65535

Si on regarde très rapidement le code d’ixgbe, on remarque que ça supporte les DAC, le SR, le LR et basta ; par contre pourquoi l’optique ER n’a pas été rejetée ça je ne sais pas.
Ici on peut donc être arrangeant et re-coder l’EEPROM de l’optique DWDM pour faire croire à la carte que c’est du LR et ça fonctionnerait, au moins dans l’immédiat. Mais comme je ne sais pas à quel point refroidir trois fois plus de puissance que prévu va endommager la carte ou l’optique, j’ai préféré trouver une carte qui supporte bien ces optiques.

Je me suis donc penché sur les documentations techniques des cartes les plus connues du marché afin d’en trouver qui sont prévues pour le ZR, c’était le grand fun. Mais j’ai fini par en ressortir deux :

Mellanox ConnectX-3 Pro (MCX312B-XCCS)
QLogic 57810

Lors de mon premier essai avec la carte Mellanox je me suis retrouvé avec ce message fort peu plaisant : mlx4_core 0000:03:00.0: MLX4_CMD_MAD_IFC Get Module ID attr(ff60) port(1) i2c_addr(50) offset(0) size(1): Response Mad Status(21c) - operation not supported for this port (the port is of type CX4 or internal). Mes recherches sur le web concordaient toutes vers des situations où des gens tentaient de mettre en place du SR-IOV. Il n’y a aucune chance que nous en ayons besoin ici, je l’ai donc désactivé et là nous avons un dmesg vachement plus engageant :

[    6.714162] pci 0000:03:00.0: [15b3:1007] type 00 class 0x020000 PCIe Endpoint
[    6.724165] pci 0000:03:00.0: BAR 0 [mem 0x92700000-0x927fffff 64bit]
[    6.730723] pci 0000:03:00.0: BAR 2 [mem 0x91000000-0x917fffff 64bit pref]
[    6.740902] pci 0000:03:00.0: ROM [mem 0xfff00000-0xffffffff pref]
[    8.147183] pci 0000:03:00.0: ROM [mem 0xfff00000-0xffffffff pref]: can't claim; no compatible bridge window
[    8.304334] pci 0000:03:00.0: ROM [mem size 0x00100000 pref]: can't assign; no space
[    8.313109] pci 0000:03:00.0: ROM [mem size 0x00100000 pref]: failed to assign
[   15.769296] mlx4_core: Mellanox ConnectX core driver v4.0-0
[   15.769334] mlx4_core: Initializing 0000:03:00.0
[   21.746373] mlx4_core 0000:03:00.0: DMFS high rate steer mode is: disabled performance optimized steering
[   21.746692] mlx4_core 0000:03:00.0: 63.008 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x8 link)
[   22.167339] mlx4_en: Mellanox ConnectX HCA Ethernet driver v4.0-0
[   22.167586] mlx4_en 0000:03:00.0: Activating port:1
[   22.173307] mlx4_en: 0000:03:00.0: Port 1: Using 32 TX rings
[   22.173315] mlx4_en: 0000:03:00.0: Port 1: Using 16 RX rings
[   22.173522] mlx4_en: 0000:03:00.0: Port 1: Initializing port
[   22.173925] mlx4_en 0000:03:00.0: registered PHC clock
[   22.174825] mlx4_en 0000:03:00.0: Activating port:2
[   22.178881] mlx4_en: 0000:03:00.0: Port 2: Using 32 TX rings
[   22.178889] mlx4_en: 0000:03:00.0: Port 2: Using 16 RX rings
[   22.179045] mlx4_en: 0000:03:00.0: Port 2: Initializing port
[   22.179318]  mlx4_ib_probe: mlx4_ib: Mellanox ConnectX InfiniBand driver v4.0-0
[   22.180991]  mlx4_ib_probe: counter index 2 for port 1 allocated 1
[   22.180997]  mlx4_ib_probe: counter index 3 for port 2 allocated 1
[   22.191166] mlx4_core 0000:03:00.0 enp3s0: renamed from eth0
[   22.191452] mlx4_core 0000:03:00.0 enp3s0d1: renamed from eth1
[ 3112.382336] mlx4_core 0000:03:00.0: MLX4_CMD_MAD_IFC Get Module ID attr(ff60) port(2) i2c_addr(50) offset(0) size(1): Response Mad Status(31c) - cable is not connected
[ 3224.605811] mlx4_en: enp3s0: Steering Mode 1
[ 3224.632338] mlx4_en: enp3s0: Link Down

Le fait que le lien soit down est normal, il n’y avait rien de branché au bout au moment de l’insertion de l’optique, forcément. Mais j’ai testé et le lien monte. Et l’optique est bien détecté :

asbr-th2 ~ # ethtool -m enp3s0
	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x07 (LC)
	Transceiver codes                         : 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Transceiver type                          : 10G Ethernet: 10G Base-ER [SFF-8472 rev10.4 onwards]
	Encoding                                  : 0x06 (64B/66B)
	BR, Nominal                               : 10300MBd
	Rate identifier                           : 0x00 (unspecified)
	Length (SMF,km)                           : 80km
	Length (SMF)                              : 25500m
	Length (50um)                             : 0m
	Length (62.5um)                           : 0m
	Length (Copper)                           : 0m
	Length (OM3)                              : 0m
	Laser wavelength                          : 1554nm
	Vendor name                               : FLEXOPTIX
	Vendor OUI                                : 00:00:00
	Vendor PN                                 : P.1696.23.29
	Vendor rev                                : A
	Option values                             : 0x00 0x1a
	Option                                    : RX_LOS implemented
	Option                                    : TX_FAULT implemented
	Option                                    : TX_DISABLE implemented
	BR margin, max                            : 0%
	BR margin, min                            : 0%
	Vendor SN                                 : F78GJ6W
	Date code                                 : 170511
	Optical diagnostics support               : Yes
	Laser bias current                        : 96.464 mA
	Laser output power                        : 1.2225 mW / 0.87 dBm
	Receiver signal average optical power     : 0.1017 mW / -9.93 dBm
	Module temperature                        : 50.74 degrees C / 123.34 degrees F
	Module voltage                            : 3.2214 V
	Alarm/warning flags implemented           : Yes
	Laser bias current high alarm             : Off
	Laser bias current low alarm              : Off
	Laser bias current high warning           : Off
	Laser bias current low warning            : Off
	Laser output power high alarm             : Off
	Laser output power low alarm              : Off
	Laser output power high warning           : Off
	Laser output power low warning            : Off
	Module temperature high alarm             : Off
	Module temperature low alarm              : Off
	Module temperature high warning           : Off
	Module temperature low warning            : Off
	Module voltage high alarm                 : Off
	Module voltage low alarm                  : Off
	Module voltage high warning               : Off
	Module voltage low warning                : Off
	Laser rx power high alarm                 : Off
	Laser rx power low alarm                  : On
	Laser rx power high warning               : Off
	Laser rx power low warning                : On
	Laser bias current high alarm threshold   : 120.000 mA
	Laser bias current low alarm threshold    : 30.000 mA
	Laser bias current high warning threshold : 110.000 mA
	Laser bias current low warning threshold  : 35.000 mA
	Laser output power high alarm threshold   : 5.0119 mW / 7.00 dBm
	Laser output power low alarm threshold    : 0.6310 mW / -2.00 dBm
	Laser output power high warning threshold : 3.9811 mW / 6.00 dBm
	Laser output power low warning threshold  : 0.7943 mW / -1.00 dBm
	Module temperature high alarm threshold   : 90.00 degrees C / 194.00 degrees F
	Module temperature low alarm threshold    : -15.00 degrees C / 5.00 degrees F
	Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
	Module temperature low warning threshold  : -10.00 degrees C / 14.00 degrees F
	Module voltage high alarm threshold       : 3.6000 V
	Module voltage low alarm threshold        : 3.0000 V
	Module voltage high warning threshold     : 3.5000 V
	Module voltage low warning threshold      : 3.0500 V
	Laser rx power high alarm threshold       : 0.1585 mW / -8.00 dBm
	Laser rx power low alarm threshold        : 0.0013 mW / -28.86 dBm
	Laser rx power high warning threshold     : 0.1259 mW / -9.00 dBm
	Laser rx power low warning threshold      : 0.0016 mW / -27.96 dBm

La QLogic 57810 n’a posé absolument aucun souci. La seule surprise est que le driver utilisé est le bnx2x normalement pour les cartes Broadcom. Je suppose qu’il s’agît d’un rebranding.

[    2.799491] pci 0000:08:00.0: [14e4:168e] type 00 class 0x020000 PCIe Endpoint
[    2.807461] pci 0000:08:00.0: BAR 0 [mem 0xd5000000-0xd57fffff 64bit pref]
[    2.815432] pci 0000:08:00.0: BAR 2 [mem 0xd5800000-0xd5ffffff 64bit pref]
[    2.823432] pci 0000:08:00.0: BAR 4 [mem 0xd77e0000-0xd77effff 64bit pref]
[    2.831431] pci 0000:08:00.0: ROM [mem 0xdb000000-0xdb07ffff pref]
[    2.838495] pci 0000:08:00.0: PME# supported from D0 D3hot D3cold
[    2.845560] pci 0000:08:00.1: [14e4:168e] type 00 class 0x020000 PCIe Endpoint
[    2.853460] pci 0000:08:00.1: BAR 0 [mem 0xd6000000-0xd67fffff 64bit pref]
[    2.861432] pci 0000:08:00.1: BAR 2 [mem 0xd6800000-0xd6ffffff 64bit pref]
[    2.868432] pci 0000:08:00.1: BAR 4 [mem 0xd77f0000-0xd77fffff 64bit pref]
[    2.876433] pci 0000:08:00.1: ROM [mem 0xdb000000-0xdb07ffff pref]
[    2.883492] pci 0000:08:00.1: PME# supported from D0 D3hot D3cold
[    4.831134] pci 0000:08:00.1: ROM [mem 0xdb000000-0xdb07ffff pref]: can't claim; address conflict with 0000:08:00.0 [mem 0xdb00000]
[    4.932854] pci 0000:08:00.1: ROM [mem 0xdb080000-0xdb0fffff pref]: assigned
[    5.662873] pci 0000:08:00.0: Adding to iommu group 19
[    5.668763] pci 0000:08:00.1: Adding to iommu group 19
[    7.216257] bnx2x 0000:08:00.0: msix capability found
[    7.228769] bnx2x 0000:08:00.0: part number 0-0-0-0
[    7.843878] bnx2x 0000:08:00.0: 32.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x8 link)
[    7.853509] bnx2x 0000:08:00.1: msix capability found
[    7.859503] bnx2x 0000:08:00.1: part number 0-0-0-0
[    7.993891] bnx2x 0000:08:00.1: 32.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x8 link)
[    8.063617] bnx2x 0000:08:00.0 enp8s0f0: renamed from eth0
[    8.077124] bnx2x 0000:08:00.1 enp8s0f1: renamed from eth1
[  127.745440] bnx2x 0000:08:00.0 enp8s0f0: using MSI-X  IRQs: sp 47  fp[0] 49 ... fp[2] 51
[  127.877574] bnx2x 0000:08:00.0 enp8s0f0: Warning: Unqualified SFP+ module detected, Port 0 from OEM              part number SFP-10G-SR-CO
[  135.314517] bnx2x 0000:08:00.1 enp8s0f1: using MSI-X  IRQs: sp 53  fp[0] 55 ... fp[2] 58
[  190.032144] bnx2x 0000:08:00.1 enp8s0f1: Warning: Unqualified SFP+ module detected, Port 0 from FLEXOPTIX        part number P.1696.23.29
[  625.652691] bnx2x 0000:08:00.1 enp8s0f1: NIC Link is Up, 10000 Mbps full duplex, Flow control: ON - receive & transmit
[ 2751.353848] bnx2x 0000:08:00.1 enp8s0f1: NIC Link is Down

Et le DOM fonctionne également :

root@hv-infra:~# ethtool -m enp8s0f1
	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x07 (LC)
	Transceiver codes                         : 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Transceiver type                          : 10G Ethernet: 10G Base-ER [SFF-8472 rev10.4 onwards]
	Encoding                                  : 0x06 (64B/66B)
	BR, Nominal                               : 10300MBd
	Rate identifier                           : 0x00 (unspecified)
	Length (SMF,km)                           : 80km
	Length (SMF)                              : 25500m
	Length (50um)                             : 0m
	Length (62.5um)                           : 0m
	Length (Copper)                           : 0m
	Length (OM3)                              : 0m
	Laser wavelength                          : 1554nm
	Vendor name                               : FLEXOPTIX
	Vendor OUI                                : 00:00:00
	Vendor PN                                 : P.1696.23.29
	Vendor rev                                : A
	Option values                             : 0x00 0x1a
	Option                                    : RX_LOS implemented
	Option                                    : TX_FAULT implemented
	Option                                    : TX_DISABLE implemented
	BR margin, max                            : 0%
	BR margin, min                            : 0%
	Vendor SN                                 : F78GJ6X
	Date code                                 : 170513
	Optical diagnostics support               : Yes
	Laser bias current                        : 84.782 mA
	Laser output power                        : 1.1501 mW / 0.61 dBm
	Receiver signal average optical power     : 0.0887 mW / -10.52 dBm
	Module temperature                        : 48.47 degrees C / 119.25 degrees F
	Module voltage                            : 3.2206 V
	Alarm/warning flags implemented           : Yes
	Laser bias current high alarm             : Off
	Laser bias current low alarm              : Off
	Laser bias current high warning           : Off
	Laser bias current low warning            : Off
	Laser output power high alarm             : Off
	Laser output power low alarm              : Off
	Laser output power high warning           : Off
	Laser output power low warning            : Off
	Module temperature high alarm             : Off
	Module temperature low alarm              : Off
	Module temperature high warning           : Off
	Module temperature low warning            : Off
	Module voltage high alarm                 : Off
	Module voltage low alarm                  : Off
	Module voltage high warning               : Off
	Module voltage low warning                : Off
	Laser rx power high alarm                 : Off
	Laser rx power low alarm                  : Off
	Laser rx power high warning               : Off
	Laser rx power low warning                : Off
	Laser bias current high alarm threshold   : 120.000 mA
	Laser bias current low alarm threshold    : 30.000 mA
	Laser bias current high warning threshold : 110.000 mA
	Laser bias current low warning threshold  : 35.000 mA
	Laser output power high alarm threshold   : 5.0119 mW / 7.00 dBm
	Laser output power low alarm threshold    : 0.6310 mW / -2.00 dBm
	Laser output power high warning threshold : 3.9811 mW / 6.00 dBm
	Laser output power low warning threshold  : 0.7943 mW / -1.00 dBm
	Module temperature high alarm threshold   : 90.00 degrees C / 194.00 degrees F
	Module temperature low alarm threshold    : -15.00 degrees C / 5.00 degrees F
	Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
	Module temperature low warning threshold  : -10.00 degrees C / 14.00 degrees F
	Module voltage high alarm threshold       : 3.6000 V
	Module voltage low alarm threshold        : 3.0000 V
	Module voltage high warning threshold     : 3.5000 V
	Module voltage low warning threshold      : 3.0500 V
	Laser rx power high alarm threshold       : 0.1585 mW / -8.00 dBm
	Laser rx power low alarm threshold        : 0.0013 mW / -28.86 dBm
	Laser rx power high warning threshold     : 0.1259 mW / -9.00 dBm
	Laser rx power low warning threshold      : 0.0016 mW / -27.96 dBm

Je ne sais pas pourquoi le DOM remonte les optiques comme étant des ER dans les deux cas, mais en tous cas les liens montent avec des atténuateurs 10 dB et ce sont bien des étiquettes ZR. Donc j’aurais tendance à dire que c’est juste une affaire de recodage d’EEPROM pour qu’elles soient acceptées par des routeurs tatillons (ces optiques ont déjà eu une autre vie).
En tous cas, si vous avez besoin d’avoir du ZR sur un serveur, mettez y une carte Mellanox ConnectX-3 Pro ou une QLogic 57810. Par acquis de conscience j’ai également testé des Chelsio que j’avais chez moi, mais aucune n’a accepté les optiques ZR. J’ai également testé une Mellanox ConnectX-4 Lx 25G qui accepte aussi des optiques 10G. Le LR fonctionnait mais pas le ZR, alors que le 25G consomme plus que le 10G.

Sécurisation du routage BGP en utilisant ASPA avec routinator et bird (cas de Breizh-IX)

2025-01-22T22:35:11+01:00

Le BGP est un protocole de routage dynamique qui se base historiquement sur la confiance. En théorie, n’importe qui peut plus ou moins annoncer n’importe quoi, et ça sera pris en compte. En pratique, les peerings BGP sont protégés par des prefix-lists afin de ne propager que ce qui est réellement voulu. Mais cela implique que chaque opérateur soit extrêment consciencieux, et cela étant bien sûr impossibles, nous pouvons recenser de nombreux incidents. De nombreuses techniques de préventions ont donc été mises en place au fur et à mesure, et l’ASPA est complémentaires à celles déjà en place. C’est discuté en paragraphe 9 « Comparison to Other Technologies ».

Nous avons vu arriver en février 2012 l’une de ces technique : les Route Origin Authorizations (ROAs) par la RFC 6482. En se basant la Resource Public Key Infrastructure (RPKI) nous pouvons cryptographiquement signer la relation entre un préfixe et le (ou les) AS source ; ainsi, un préfixe annoncé par erreur par un AS se verra très fortement filtré. Cela ne protège par contre pas des attaques volontaires car il suffit de prepend le bon AS lors de l’annonce afin de faire correspondre la source avec le ROA et tout se passera comme si de rien n’était. Petit aparté sur les chiffres : à la fin janvier 2025 je vois 519213 ROAs sur 1001519 annonces (en IPv4), soit un peu plus de la moitié. Je n’ai pas de métriques sur les ASes qui vérifient ou non les ROAs, mais il est clair qu’un transitaire qui ne le fait pas en 2025 est à fuir comme la peste.

Depuis 2019 une discussion est actuellement ouverte à l’IETF afin de pouvoir étendre la RPKI à la vérification de l’AS path au lieu d’uniquement l’AS source, c’est l’ASPA (Autonomous System Provider Authorization). L’idée est qu’un AS va publier quels sont ses fournisseurs, et si un préfixe (signé en ROA évidemment) est vu avec un chemin qui n’a rien à voir avec la choucroute, l’annonce sera rejetée. C’est un peu à voir comme la version 2 des IRRs que l’on trouve dans les whois d’AS.
Tout ceci étant encore en draft, il n’est pas encore possible de publier des entrées ASPA depuis une CA hébergée directement par un RIR, il faut l’héberger soi-même (par exemple avec krill). Cela limite donc grandement l’adoption, ce qui fait que nous avons une table comprenant seulement 81 entrées. Du côté de la vérification, le support a été ajouté avec bird 2.16, et pour la diffusion des entrées, le support via RTR a été ajouté avec routinator 0.14.1. Ce n’est pas un hasard si je suivais l’évolution de ces deux logiciels, car ils font partie de la stack du second serveur de routes de Breizh-IX.

Breizh-IX est un point d’échange rennais dont je m’occupe. Comme l’immense majorité des points d’échange nous proposons des serveurs de route, et comme j’aime les choses bien faites je préfère éviter d’annoncer des routes fallacieuses aux membres de l’IX. Pour se faire nous avions déjà mis en place les choses de base comme la vérification des ROAs et la génération de listes de préfixes pour chaque membre, mais aussi des choses moins connues comme la vérification de l’attribut Only to Customer (OTC). Aujourd’hui un pas de plus est fait avec l’ajout d’ASPA.

La mise en place de la partie validation est très simple, il suffit de compiler routinator en version 0.14.1, d’installer les binaires, d’ajouter enable-aspa = true dans le fichier de configuration et de redémarrer le daemon.
Maintenant que notre serveur RTR (ici routinator) supporte ASPA, il ne reste plus qu’à dire à bird de le prendre en compte.
Après avoir également compilé et installé la version 2.16, il faut créer une table en plus qui servira à stocker les entrées ASPA (en plus de celles pour les ROAs IPv4 et IPv6), et de l’ajouter au protocole RPKI qui correspond au routinator :


roa4 table r4;
roa6 table r6;
aspa table at;

protocol rpki rpki_conan {
	remote "conan.grifon.fr";

	roa4 { table r4; };
	roa6 { table r6; };
	aspa { table at; };
}

Ensuite au reload, le protocole devrait être négocié en version 2 et la nouvelle table va se remplir :


[root@rs2 ~]# birdc
BIRD 2.16 ready.
bird> show protocols all rpki_conan
Name       Proto      Table      State  Since         Info
rpki_conan RPKI       ---        up     20:59:54.811  Established
  Cache server:     89.234.186.8
  Status:           Established
  Transport:        Unprotected over TCP
  Protocol version: 2
  Session ID:       12256
  Serial number:    19
  Last update:      before 504.687 s
  Refresh timer   : 648.312/1153
  Retry timer     : ---
  Expire timer    : 6695.312/7200
  Channel roa4
    State:          UP
    Table:          r4
    Preference:     100
    Input filter:   ACCEPT
    Output filter:  REJECT
    Routes:         519235 imported, 0 exported, 83 preferred
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:         519247          0          0          0     519247
      Import withdraws:           12          0        ---          0         12
      Export updates:              0          0          0        ---          0
      Export withdraws:            0        ---        ---        ---          0
  Channel roa6
    State:          UP
    Table:          r6
    Preference:     100
    Input filter:   ACCEPT
    Output filter:  REJECT
    Routes:         126571 imported, 0 exported, 31 preferred
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:         126589          0          0          0     126589
      Import withdraws:           18          0        ---          0         18
      Export updates:              0          0          0        ---          0
      Export withdraws:            0        ---        ---        ---          0
  Channel aspa
    State:          UP
    Table:          at
    Preference:     100
    Input filter:   ACCEPT
    Output filter:  REJECT
    Routes:         81 imported, 0 exported, 81 preferred
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:             81          0          0          0         81
      Import withdraws:            0          0        ---          0          0
      Export updates:              0          0          0        ---          0
      Export withdraws:            0        ---        ---        ---          0

Nous pouvons maintenant utiliser les données de cette table dans les filtres d’entrée, grâce à la fonction intégrée aspa_check :


	# https://www.ietf.org/archive/id/draft-ietf-sidrops-aspa-verification-20.html#name-algorithm-for-upstream-path
	case aspa_check(at, bgp_path, true) {
		ASPA_INVALID:
			igp_metric = 12;
			reject "Invalid ASPA:", net, bgp_path;
		ASPA_VALID:
			igp_metric = 10;
		ASPA_UNKNOWN:
			igp_metric = 11;
	}

Le premier paramètre de la fonction est la table depuis laquelle nous tirons les informations, le second est l’AS path à évaluer et la dernière est l’algorithme de vérification à utiliser. Les deux premiers étant assez évidents, je vais uniquement m’attarder sur le dernier.
Dans la version actuelle d’ASPA (draft v20), il existe deux algorithmes : un pour évaluer des routes upstream, et un autre pour les routes downstream. Il est explicitement écrit qu’un serveur de route doit utiliser l’algorithme upstream :

The upstream verification algorithm described here is applied when a route is received from a Customer or Peer, or is received by an RS from an RS-client, or is received by an RS-client from an RS.

6.2. Algorithm for Upstream Paths

Les routes ayant un seul AS sur le chemin sont automatiquement considérées comme valides, et bird respecte bien cela :


bird> show route all where igp_metric = 10
Table master4:
45.94.17.0/24        unicast [bgp_20766_185_1_89_28 21:04:43.510] * (100) [AS20766i]
	via 185.1.89.28 on vtnet1
	Type: BGP univ
	igp_metric: 10
	BGP.origin: IGP
	BGP.as_path: 20766
	BGP.next_hop: 185.1.89.28
	BGP.local_pref: 100
	BGP.community: (20766,1)
	BGP.ext_community: 
	BGP.large_community: (206165, 100, 0)
45.67.83.0/24        unicast [bgp_207910_185_1_89_26 21:04:43.617] * (100) [AS207910i]
	via 185.1.89.26 on vtnet1
	Type: BGP univ
	igp_metric: 10
	BGP.origin: IGP
	BGP.as_path: 207910
	BGP.next_hop: 185.1.89.26
	BGP.local_pref: 100
	BGP.ext_community: 
	BGP.large_community: (206165, 100, 0)
185.204.199.0/24     unicast [bgp_211733_185_1_89_39 21:04:45.785] * (100) [AS211733i]
	via 185.1.89.39 on vtnet1
	Type: BGP univ
	igp_metric: 10
	BGP.origin: IGP
	BGP.as_path: 211733
	BGP.next_hop: 185.1.89.39
	BGP.local_pref: 100
	BGP.ext_community: 
	BGP.large_community: (206165, 100, 0)
193.222.128.0/24     unicast [bgp_34019_185_1_89_36 21:04:48.454] * (100) [AS34019i]
	via 185.1.89.36 on vtnet1
	Type: BGP univ
	igp_metric: 10
	BGP.origin: IGP
	BGP.as_path: 34019
	BGP.next_hop: 185.1.89.36
	BGP.med: 75
	BGP.local_pref: 100
	BGP.community: (34019,34019)
	BGP.ext_community: 
	BGP.large_community: (206165, 100, 0)
37.157.128.0/21      unicast [bgp_57943_185_1_89_19 21:04:43.486] * (100) [AS57943?]
	via 185.1.89.19 on vtnet1
	Type: BGP univ
	igp_metric: 10
	BGP.origin: Incomplete
	BGP.as_path: 57943
	BGP.next_hop: 185.1.89.19
	BGP.local_pref: 100
	BGP.ext_community: 
	BGP.large_community: (206165, 100, 0)
[…]

Nous n’avons pas de route invalide et les autres routes ont bien le statut inconnu :


bird> show route all filtered where igp_metric = 12
bird> 
bird> show route all where igp_metric = 11
Table master4:
37.60.157.0/24       unicast [bgp_34019_185_1_89_36 21:04:44.346] * (100) [AS201080i]
	via 185.1.89.36 on vtnet1
	Type: BGP univ
	igp_metric: 11
	BGP.origin: IGP
	BGP.as_path: 34019 201080
	BGP.next_hop: 185.1.89.36
	BGP.med: 75
	BGP.local_pref: 100
	BGP.community: (34019,20108) (34019,64512) (65512,20001)
	BGP.ext_community: 
	BGP.large_community: (206165, 100, 0)
195.190.3.0/24       unicast [bgp_34019_185_1_89_36 21:04:48.670] * (100) [AS47612i]
	via 185.1.89.36 on vtnet1
	Type: BGP univ
	igp_metric: 11
	BGP.origin: IGP
	BGP.as_path: 34019 35600 47612
	BGP.next_hop: 185.1.89.36
	BGP.med: 75
	BGP.local_pref: 100
	BGP.community: (34019,35600) (34019,64512)
	BGP.ext_community: 
	BGP.large_community: (206165, 100, 0)
45.67.83.0/24        unicast [bgp_204092_185_1_89_13 21:04:43.555] (100) [AS207910i]
	via 185.1.89.13 on vtnet1
	Type: BGP univ
	igp_metric: 11
	BGP.origin: IGP
	BGP.as_path: 204092 207910
	BGP.next_hop: 185.1.89.13
	BGP.local_pref: 100
	BGP.community: (64496,200)
	BGP.ext_community: 
	BGP.large_community: (204092, 100, 200) (206165, 100, 0)
                     unicast [bgp_34019_185_1_89_36 21:04:44.684] (100) [AS207910i]
	via 185.1.89.36 on vtnet1
	Type: BGP univ
	igp_metric: 11
	BGP.origin: IGP
	BGP.as_path: 34019 207910
	BGP.next_hop: 185.1.89.36
	BGP.med: 75
	BGP.local_pref: 100
	BGP.community: (34019,20791) (34019,64512) (65512,20001)
	BGP.ext_community: 
	BGP.large_community: (206165, 100, 0)
185.20.5.0/24        unicast [bgp_34019_185_1_89_36 21:04:47.976] * (100) [AS56648i]
	via 185.1.89.36 on vtnet1
	Type: BGP univ
	igp_metric: 11
	BGP.origin: IGP
	BGP.as_path: 34019 35600 56648
	BGP.next_hop: 185.1.89.36
[…]

Si nous étions en train de vérifier les annonces d’un fournisseur, nous aurions dû appliquer l’algorithme downstream. Pourquoi avoir deux algorithmes ? Car lors d’une relation client-fournisseur il n’est pas possible de savoir si le fournisseur a appris la route sur un peering ou via l’un des transits de l’AS source (qu’ils auraient en communs). Nous ne pouvons donc pas strictement rechercher si l’un des ASes dans l’entrée ASPA est dans l’AS path, et on se contente alors d’estimer le statut de la route par rapport à longueur de l’AS path.
Par exemple, si on prend une route vers telenor (AS2119) du point de vue de gitoyen (AS20766)

Pour un ordinateur il n’est pas possible de deviner quels sont les chemins légitime ou pas. En tant qu’humain, comme j’ai géré le peering de gandi avant que ça ne tourne au FullBullshit™ et que je connais le peering manager de ielo, je sais que ces deux ASes ont un peering avec telenor, et donc que ces deux chemin sont fiables. Cette théorie se confirme avec un mtr vers l’une des IPs du range qui montre que ça passe par l’AMS-IX :


grifon@gitoyen01:~$ mtr -bzwe 148.122.1.1
Start: 2025-01-22T23:16:35+0000
HOST: gitoyen01.ring.nlnog.net                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS20766  x-ray.probe.gitoyen.net (80.67.163.243)              0.0%    10    0.3   0.2   0.2   0.3   0.0
  2. AS20766  vodka.gitoyen.net (80.67.168.7)                      0.0%    10    0.9   0.6   0.4   1.3   0.3
  3. AS20766  gandi-pa3.gitoyen.net (80.67.168.149)                0.0%    10    0.7   0.7   0.5   1.5   0.3
  4. AS???    ti9000b400.ti.telenor.net (80.249.209.192)           0.0%    10   10.7   9.9   9.3  13.0   1.2
  5. AS2119   ti3003c400-ae13-0.ti.telenor.net (146.172.105.37)    0.0%    10   29.1  29.7  29.1  31.3   0.9
       [MPLS: Lbl 9197 TC 0 S u TTL 1]
  6. AS???    ???                                                 100.0    10    0.0   0.0   0.0   0.0   0.0
  7. AS2119   ti0001b400-ae0-0.ti.telenor.net (146.172.105.49)     0.0%    10   29.0  29.9  28.9  38.0   2.8
  8. AS2119   148.122.9.50                                         0.0%    10   30.2  29.4  29.2  30.2   0.3
  9. AS2119   tix01c01-fge1-17.tix.telenor.net (148.122.2.81)      0.0%    10   29.2  29.3  29.2  29.6   0.1
       [MPLS: Lbl 29 TC 0 S u TTL 1]
       [MPLS: Lbl 648 TC 0 S u TTL 1]
 10. AS2119   tix01d01-fge7-1.tix.telenor.net (148.122.2.66)       0.0%    10   29.3  29.6  29.2  32.1   0.9
       [MPLS: Lbl 648 TC 0 S u TTL 1]
 11. AS2119   148.122.205.225                                      0.0%    10   30.0  29.9  29.3  32.7   1.0
 12. AS2119   tix01d01-ec2-v100.tix.telenor.net (148.122.205.25)   0.0%    10   31.2  29.6  29.1  31.2   0.6
 13. AS2119   part1.online.no (148.122.1.1)                        0.0%    10   29.3  29.4  29.3  29.8   0.1

L’IRR de l’AS2119 nous dit que les deux upstreams connus sont telia et level3 et dtag est censé être un peering :

alarig@x280 ~ % whois AS2119 | grep 'accept ANY'
import:         from AS1299 action pref=100; accept ANY
import:         from AS3356 action pref=100; accept ANY
alarig@x280 ~ % whois AS2119 | grep 3320
import:         from AS3320 action pref=100; accept AS3320:AS-DTAG
export:         to AS3320 announce AS-TELENOR

Si telenor publiait une entrée ASPA, elle contiendrait a priori les ASes 1299 et 3356. La route que nous voyons ici via telia aurait alors le statut valide. Les deux routes par gandi ou ielo auraient le statut inconnu. Nous pouvons par contre légitimement nous demander si le chemin via Hopus et DTAG est entièrement légitime ou non ; mais les IRRs étant principalement là à titre indicatif, nous ne pouvons pas nous baser dessus à 100%. Bien que DTAG soit un tier 1 de piètre qualité, il serait tout de même étonnant qu’ils réannoncent les préfixes d’un opérateur national sans que ce ne soit l’un de leur clients, même si ce n’est jamais à exclure non plus. En effet, dans ce cas présent la politique tarifaire d’Hopus fait que DTAG gagne de l’argent sur le trafic qui rentre dans son réseau sur ce port. Afin d’augmenter le volume dudit trafic, ils peuvent très bien ré-annoncer leurs peers en plus de leurs clients, bien que ça soit contraire aux pratiques communes.

mautrix-signal ⚠ Your message may not have been bridged: 110: Verification failure in zkgroup

2024-05-29T11:45:56+02:00

Pour éviter d’avoir plein d’applications de messagerie instantanée sur mon téléphone, je bridge tout dans matrix et je n’utilise directement que matrix. Ma machine matrix était sur une infra d’hypervision que je n’ai plus vraiment envie d’utiliser, et j’ai depuis une plus grosse infra en propre. J’ai donc décidé de migrer cette machine chez moi, en passant au passage d’une technologie Xen à KVM. Je ne voulais donc pas déplacer le disque d’un bloc, puisqu’il y aurait eu des chances pour que je doive réparer plein de trucs un peu particuliers. Je me suis donc lancé dans la réinstallation complète de la VM.

Jusque là tout va bien, mais à l’utilisation je me suis rendu compte que je ne pouvais plus envoyer de messages sur les groupes signal, alors que les messages privés fonctionnaient. Et cerise sur le gâteau : un moteur de recherche ne donne aucun résultat pertinent quand je cherche l’erreur.
Dans les logs j’avais ERR ReceiveAuthCredentialWithPni error error="110: Verification failure in zkgroup" action="get authorization for today" $blahblah.

J’ai essayé tous les trucs de base tels que /discardsessions, !signal discard-megolm-session, re-linker le bridge à signal, re-linker le bridge à matrix, etc. mais rien n’y faisait. Je suis donc allé sur le chan matrix du projet et @frank:matrix.ps-ef.net m’a rappelé que la version de la lib signal supportée était libsignal-ffi-0.44.0 et rien d’autre. Hors, l’ebuild dans le repo communautaire de gentoo (guru) ne force pas la version. Et la 0.46.0 a été packagée depuis.
En ré-installant la machine, j’ai donc compilé mautrix-signal en me basant sur la mauvaise version de la lib. J’ai forcé la version 0.44 en mettant >=dev-libs/libsignal-ffi-0.45.0 dans /etc/portage/package.mask/mautrix-signal et depuis tout fonctionne.

J’ai contacté le mainteneur pour savoir s’il était d’accord pour que je fixe l’ebuild, donc ça devrait être réglé pour tout le monde sous gentoo assez rapidement.

Le concept d’empty non terminal (ENT) en DNS, et son interaction avec les wildcards

2023-05-19T21:08:11+02:00

Cet article est écrit en collaboration avec Axel Viala. Tout au long de l’article nous parlons de serveurs faisant autorité, les révolveurs n’ayant pas ce cas à gérer.

Sur un nom de domaine, on peut se retrouver avec des sous-domaines vides mais ayant des enfants. Nous appelons cela un ENT (empty non terminal). Ceci peut rentrer en conflit avec deux autres mécanismes du DNS : le qname-minimisation et le wildcard.
Sur cet article nous allons partir d’une zone sans aucune fioriture, puis en rajouter au fur et à mesure afin de voir comment un ENT peut invalider un wildcard. Prenons pour exemple une zone sans piège mais contenant un ENT :

$ORIGIN alarig.example.
@			10800	IN	SOA	ns hostmaster 2023051900 14400 3600 604800 86400
@			10800	IN	NS	ns
ns			10800	IN	A	192.0.0.8
ns			10800	IN	AAAA	2001:db8::35

www.ent			10800	IN	AAAA	2001:db8::1bb

Ici nous avons un seul NS, son A/AAAA associé et un enregistrement pour le serveur web du sous-domaine ent.
Pourquoi est-ce un ENT ? Car le domaine ent ne contient rien en lui-même, et pourtant www.ent existe. Nous avons donc affaire à un sous-domaine www d’un domaine vide ent. Ceci est défini dans la section 2.2.2 de la RFC 4592. Les serveurs DNS doivent alors répondre avec un status NOERROR et une section de réponse vide (on appelle cela NODATA).
En soit ici, d’un point de vue de la compréhension de la zone, comprendre le concept d’ENT n’est pas forcément essentiel. On voit assez bien où on veut arriver ; tout ce qui est resolvable étant explicitement écrit dans la zone, à l’inverse d’un wildcard qui permet implicitement une infinité de labels.

Par contre maintenant, si je pars d’une zone avec un wildcard mais sans ENT, toutes les requêtes au niveau du wildcard auront une réponse correspondant à ce que j’ai défini :

$ORIGIN alarig.example.
@			10800	IN	SOA	ns hostmaster 2023051901 14400 3600 604800 86400
@			10800	IN	NS	ns
ns			10800	IN	A	192.0.0.8
ns			10800	IN	AAAA	2001:db8::35

*			10800	IN	CNAME	example.com.

Ici, une requête sur ent.alarig.example. répondra le CNAME vers example.com.

Mais si je veux ajouter un sous-domaine par rapport au wildcard, je vais créer un ENT et je vais donc invalider le wildcard du domaine parent :

$ORIGIN alarig.example.
@			10800	IN	SOA	ns hostmaster 2023051902 14400 3600 604800 86400
@			10800	IN	NS	ns
ns			10800	IN	A	192.0.0.8
ns			10800	IN	AAAA	2001:db8::35

*			10800	IN	CNAME	example.com.
www.ent			10800	IN	AAAA	2001:db8::1bb

Ici, une question sur ent.alarig.example. aura une réponse vide, alors que c’était précédemment le contenu du CNAME.
Pourtant, un humain lisant la zone saurait trouver la réponse, car nous sommes capables de lever l’ambigüité nous-mêmes. Mais ce n’est pas aussi évidement pour un ordinateur. Pour quelle raison me direz-vous ? Car il faut gérer une consistance. Lorsque l’on définit quelque chose déjà couvert par un wildcard, il en prend la précédence, pour des questions de cohérence. On peut appeler ça la règle du plus spécifique. Sans cela nous ne pourrions pas garantir au sens du protocole un comportement prévisible entre les différentes implémentations.
Concrètement, cela veut dire qu’un label à un niveau couvert par un wildcard sera utilisé au lieu du wildcard. Donc ici, bien qu’ent ne soit pas explicitement défini, il existe quand même pour que www.ent puisse exister, mais il est vide ; ce qui provoque une réponse vide pour les questions sur ce domaine.

Si on veut continuer à avoir les réponses que l’on avait avant, il faut le déclarer explicitement, ce qui donnera donc cette zone :

$ORIGIN alarig.example.
@			10800	IN	SOA	ns hostmaster 2023051903 14400 3600 604800 86400
@			10800	IN	NS	ns
ns			10800	IN	A	192.0.0.8
ns			10800	IN	AAAA	2001:db8::35

*			10800	IN	CNAME	example.com.
ent			10800	IN	CNAME	example.com.
www.ent			10800	IN	AAAA	2001:db8::1bb

Dans cette version de la zone, le domaine ent n’est finalement plus un ENT, nous avons un enregistrement directement dessus. Ceci est nécessaire afin que le CNAME original soit toujours utilisable.

Faire tenir la charge à une instance mastodon malgré Musk

2022-11-16T11:29:29+01:00

Si vous lisez ce blog, vous savez sûrement qu’un riche mégalomane étasunien a racheté twitter, et qu’on en attendait pas moins de son mode de gestion. Cela a entraîné un exode vers mastodon, qui ronronnait tranquillement dans son coin jusqu’ici.
Je vais ici partager les différentes actions que j’ai dû entreprendre ces derniers jours afin de maintenir hostux.social à flots. Avant toutes choses, il convient de remercier Leonora Tindall d’avoir écrit Scaling Mastodon in the Face of an Exodus, car cet article m’a beaucoup aidé, pour la configuration sidekiq notamment.

Afin de contextualiser ce billet, hostux.social hébergeait environ 4000 personnes (pour moins de 1000 actives) avant la vague d’arrivées. Le tout tenait sur une VM avec 8 vCPU et 12 Go de RAM.
Je précise également que gérer des serveurs n’est pas mon métier, je suis dans le réseau à la base. Alors même si ça reste « de l’informatique », ce n’est pas quelque chose avec lequel je suis forcément à l’aise, ni qui me fait particulièrement plaisir. (Proposer une alternative libre et décentralisée, même à mon échelle, ça me fait plaisir, par contre.)

La première action afin de gérer l’afflux de personnes a simplement été de fermer les inscriptions, et ce pour une raison totalement non technique, mais par manque de temps pour traiter toutes les demandes. Nous réouvrions les vannes de temps en temps, quand la vague précédente était passée.

Ensuite, quelque chose qui avait l’air d’être une bonne idée mais qui en fait n’en est pas une : supprimer les anciens comptes inactifs afin d’alléger un peu la base de données. Ce n’est en fait pas une bonne idée car celà crée plein de tâches dans le sidekiq et ralenti considérablement l’instance le temps que ça soit traité. Nous sommes monté à plus de deux millions de tâches en attente à cause de ça alors que même durant les périodes de charge dépasser les 100 000 reste rare.

L’étape suivante qui me venait naturellement à l’esprit a été de séparer la VM de base de données des autres services afin qu’il ait de la RAM dédiée qu’il puisse utiliser en cache. Et ceci a été efficace puisque l’intégralité de la RAM a directement été utilisée à cet effet, permettant de dépiler plus vite le sidekiq.

Arrivé ici, l’interface web a commencé a devenir de plus en plus lente, en raison de nombre de requêtes en parallèle à traiter. Nous avions à ce moment déjà plus ou moins doublé le nombre de comptes actifs. J’ai donc augmenté le nombre de threads de puma à 5 et le nombre de processus par thread à 8.

Environment="WEB_CONCURRENCY=8"
Environment="MAX_THREADS=5"

Cela a augmenté le nombre de connexions à la base de données, je suis donc passé de 100 à 500 connexions maximum dans PostgreSQL (histoire d’avoir un peu de marge, changer cette valeur nécessitant de redémarrer le service).

La charge continuant d’augmenter, tous les soirs la queue sidekiq montait à plus de 10 000 tâches avec parfois des pics aux alentours des 20 000, induisant une latence énorme sur la réception de messages d’autres instances. Là j’ai commencé à regarder comment optimiser sidekiq, et le moins que l’on puisse dire, c’est que la littérature n’est pas très fournie. Dans le doute, j’ai décidé de mettre redis dans sa VM à lui, ça ne pouvait pas faire de mal… C’est préconisé dans la doc de mastodon, mais je ne suis pas sûr que ça ait réellement changé grand chose.

Je suis ensuite tombé sur PGTune qui m’a permis d’ajuster quelques paramètres de PostgreSQL, évitant ainsi à sidekiq d’attendre les réponses au lieu de travailler. Ceci a été très efficace, la taille de la queue a été divisée par deux en quelques minutes, mais je restais pourtant à environ un millier de tâches en attente.
Cela a par contre considérablement augmenté la charge de cette VM. Là où elle tournait avec un load average d’environ 5 avant, il a doublé désormais.

Valère (sur IRC) m’a partagé l’aricle de Leonora Tindall cité en introduction qui explique comment configurer son sidekiq de manière efficace (enfin !). J’ai adapté leurs conseils à ma configuration (je n’utilise pas docker mais des units systemd directement) et j’ai ajouté une target systemd afin de ne pas avoir besoin de démarer les six services sidekiq à la main, ce qui nous donne donc ceci :

root@hostux:~# cat /etc/systemd/system/mastodon-sidekiq.target 
[Unit]
Description=mastodon-sidekiq
After=network.target
Wants=mastodon-sidekiq-default-push-pull.service mastodon-sidekiq-mailers.service mastodon-sidekiq-pull-default-push.service mastodon-sidekiq-push-default-pull.service mastodon-sidekiq-scheduler.service mastodon-sidekiq-default-pull-push.service

[Install]
WantedBy=multi-user.target


root@hostux:~# cat /etc/systemd/system/mastodon-sidekiq-default-pull-push.service 
[Unit]
Description=mastodon-sidekiq
After=network.target
PartOf=mastodon-sidekiq.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/opt/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=25"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2"
ExecStart=/opt/mastodon/.rbenv/shims/bundle exec sidekiq -c 25 -q default -q pull -q push
TimeoutSec=15
Restart=always

[Install]
WantedBy=mastodon-sidekiq.target


root@hostux:~# cat /etc/systemd/system/mastodon-sidekiq-default-push-pull.service 
[Unit]
Description=mastodon-sidekiq
After=network.target
PartOf=mastodon-sidekiq.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/opt/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=25"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2"
ExecStart=/opt/mastodon/.rbenv/shims/bundle exec sidekiq -c 25 -q default -q push -q pull
TimeoutSec=15
Restart=always

[Install]
WantedBy=mastodon-sidekiq.target


root@hostux:~# cat /etc/systemd/system/mastodon-sidekiq-mailers.service 
[Unit]
Description=mastodon-sidekiq
After=network.target
PartOf=mastodon-sidekiq.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/opt/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=25"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2"
ExecStart=/opt/mastodon/.rbenv/shims/bundle exec sidekiq -c 25 -q mailers -q scheduler
TimeoutSec=15
Restart=always

[Install]
WantedBy=mastodon-sidekiq.target


root@hostux:~# cat /etc/systemd/system/mastodon-sidekiq-pull-default-push.service 
[Unit]
Description=mastodon-sidekiq
After=network.target
PartOf=mastodon-sidekiq.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/opt/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=25"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2"
ExecStart=/opt/mastodon/.rbenv/shims/bundle exec sidekiq -c 25 -q pull -q default -q push
TimeoutSec=15
Restart=always

[Install]
WantedBy=mastodon-sidekiq.target


root@hostux:~# cat /etc/systemd/system/mastodon-sidekiq-push-default-pull.service 
[Unit]
Description=mastodon-sidekiq
After=network.target
PartOf=mastodon-sidekiq.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/opt/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=25"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2"
ExecStart=/opt/mastodon/.rbenv/shims/bundle exec sidekiq -c 25 -q push -q default -q pull
TimeoutSec=15
Restart=always

[Install]
WantedBy=mastodon-sidekiq.target


root@hostux:~# cat /etc/systemd/system/mastodon-sidekiq-scheduler.service 
[Unit]
Description=mastodon-sidekiq
After=network.target
PartOf=mastodon-sidekiq.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/opt/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=25"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2"
ExecStart=/opt/mastodon/.rbenv/shims/bundle exec sidekiq -c 25 -q scheduler
TimeoutSec=15
Restart=always

[Install]
WantedBy=mastodon-sidekiq.target

Avec tout ceci l’instance fonctionne de nouveau aussi bien que mastodon le permet. On verra donc sur la durée. Pour donner un ordre de grandeur des ressources utilisées, voici ce que j’ai :

VM « web » : 12 Go de RAM disponibles, 6 Go utilisés par les applications, le reste en cache. 8 vCPU disponibles, 2 utilisés
VM de DB : 12 Go de RAM disponibles, tout est utilisé en cache, 8 vCPU disponibles, 3 utilisés
VM ES : 4 Go de RAM disponibles, 3 utilisés, quasi pas de CPU utilisé
VM redis : quelques Mo de RAM utilisés et une utilisation CPU négligeable

L’instance comporte environ 2 500 comptes actifs et génère environ 20 Mbps de trafic. Je suis toujours sur la branche 3, passer en 4 nécessiretra de revoir la configuration sidekiq car une queue supplémentaire a été ajoutée.

Si vous avez des questions, je vous invite à me contacter sur mastodon : @alarig@hostux.social.

Avoir une sorte de flowspec sous linux avec ipset

2022-04-10T16:45:38+02:00

Internet étant truffé de machines plus ou moins vérolées qui scannent le monde entier, j’ai eu envie de les bloquer à l’échelle complète de mon réseau ; un genre de fail2ban2bgp.
Avec netfilter il n’existe pas de mécanisme pour avoir des règles dynamiques, et donc pas de moyen d’avoir facilement des règles flowspec dans son firewall. Par contre, il est possible d’utiliser un ipset comme source dans une règle. Et avec exabgp il est possible d’utiliser un script shell pour transformer une annonce bgp en ipset. J’ai donc utilisé ceci pour implémenter une sorte de flowspec sur des routeurs soft linux.

Voici le schéma global de la solution que j’ai mise en place :

Envoyer les logs à une machine (avec rsyslog)

Les faire traiter par fail2ban

Lui faire créer des routes locales sur la machine (avec une banaction)

Annoncer ces routes en BGP (avec bird)

Envoyer ces routes à tous mes routeurs (avec des RRs)

Transformer ces routes en règles netfilter (avec exabgp, ipset et un script shell)

À noter : pour me besoin je n’ai besoin que de bloquer des IPs sources, je n’ai donc pas du tout regardé pour aller plus finement dans le filtrage (au port, à la taille de paquet, etc.). Je n’ai pas non plus implémenté la suppression des routes en cas de withdrawn bgp, parce que j’ai envie que les règles soient persistantes. J’ai utilisé ipset pour pouvoir plus facilement le mettre en place si besoin, mais on pourrait simplifier en écrivant directement des règles iptables. Je me suis également contenté d’IPv4, parce que je n’ai vu personne pourrir mes logs en IPv6 pour le moment, mais le code est très facilement adaptable.

Je ne vais pas aborder les configurations rsyslog et fail2ban ici, ce n’est pas mon but.

La récupération des routes générées par fail2ban se passent très classiquement avec de la conf bird relativement simple. J’ai un filtre d’import sur le protocol kernel qui ajoute une communauté sur les routes unreachables, et un filtre d’export bgp qui utilise cette communauté. Cette machine là peere avec mes RRs pour que les routes soient redistribuées dans mon réseau.

protocol kernel kernel_grt_ipv4 {
	learn;
	persist;

	ipv4 {
		import filter {
			if (dest = RTD_UNREACHABLE) then {
				bgp_large_community.add((208627,666,666));
				accept;
			}
			else {
				reject;
			}
		};
		export none;
	};
}

protocol bgp ibgp_core02_ipv4 from t_ibgp_ipv4 {
	neighbor 10.0.4.4 as 208627;

	ipv4 {
		import none;
		export filter {
			if (bgp_large_community ~ [(208627,666,666)]) then {
				accept;
			}
			else {
				reject;
			}
		};
	};
}

Ensuite, sur les routeurs j’envoie les routes avec celle communauté sur un exabgp en localhost. La version que j’utilise (4.2.17) a un bug, toutes les commandes de cli finissent en timeout… Donc si vous comptez utiliser un truc du genre en prod, tentez les versions plus anciennes ou faites chier les devs pour qu’ils pissent du code utilisable. Quand j’ai remonté le souci, on m’a dit d’utiliser master, ce que je n’ai pas envie de faire, ça me semble plus sain de vivre avec ce bug pour le moment.

# /etc/bird.conf
protocol bgp bgp_drop_v4 from iBGP_IPv4 {
	description "locahost exabgp";
	neighbor 127.0.0.1 port 1179 as myasn;
	local 127.0.0.1;
	rr client;

	ipv4 {
		import none;
		export filter {
			if ((208627,666,666) ~ bgp_large_community) then {
				accept;
			}
			else {
				reject;
			}
		};
	};
}

# /etc/exabgp/exabgp.env
[exabgp.tcp]
bind=127.0.0.1
port=1179

# /etc/exabgp/exabgp.conf
process acl {
	run /usr/local/libexec/acl.sh;
	encoder text;
}

template {
	neighbor fw_v4 {
		family {
			ipv4 unicast;
		}
		api speaking {
			processes [ acl ];
			receive {
				parsed;
				update;
			}
		}
	}
}

neighbor 127.0.0.1 {
	inherit fw_v4;
	router-id 127.0.0.1;
	local-address 127.0.0.1;
	local-as 208627;
	peer-as 208627;
}

# /usr/local/libexec/acl.sh
#!/bin/sh

exec 2>&1> /tmp/exa

while read stdin; do
	net="$(echo $stdin | awk '/announced/ { print $6 }')"
	if [ -n "${net}" ]; then
		neigh="$(echo $stdin | awk '/announced/ { print $2 }')"
		if [ "${neigh}" = '127.0.0.1' ]; then
			sudo ipset add firewall_v4 $net
		elif [ "${neigh}" = '::1' ]; then
			sudo ipset add firewall_v6 $net
		fi
	fi
done < /dev/stdin

J’ai hardcodé le nom de l’ipset utilisé parce que ce code n’est pas voué à être générique, mais vous pouvez lancer le script avec des arguements depuis exabgp. J’utilise sudo parce l’utilisateur exabgp n’a pas le droit de lancer ipset par défaut (ce qui se comprend assez bien).
Le code part du principe que l’ipset existe déjà (ipset create firewall_v4 hash:net family inet counters).

Ensuite, dans iptables j’utilise l’ipset ainsi peuplé pour bloquer les IPs qui sont dedans

iptables -A INPUT -m set --match-set firewall_v4 src -j DROP
iptables -A FORWARD -m set --match-set firewall_v4 src -j DROP
ip6tables -A INPUT -m set --match-set firewall_v6 src -j DROP
ip6tables -A FORWARD -m set --match-set firewall_v6 src -j DROP

Ce qui apparaît sous la forme DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set firewall_v4 src dans iptables -L -n -v

« Et voilà », je bloque les IPs sur tout mon réseau grâce à ça, et je ne perds pas toutes les règles en cas de flap bgp.

Remonter le constructeur et le modèle d’un serveur en SNMP

2021-08-10T16:12:06+02:00

Par défaut, la configuration de net-snmpd ne remonte pas le constructeur et le modèle d’un serveur, ce qui fait que LibreNMS (ou Observium) vont afficher « Generic x86 64-bit » là où on pourrait avoir « Dell Inc. [PowerEdge R510] » ou « HP [ProLiant DL320e Gen8] », ce qui rend plus facile l’inventorisation d’un parc. Pourtant, ces information sont disponibles pour Linux, et les OID existent. Il suffit de deux lignes dans snmpd.conf pour que ça soit pris en compte :

extend		.1.3.6.1.4.1.2021.7890.2	hardware '/bin/cat /sys/devices/virtual/dmi/id/product_name'
extend		.1.3.6.1.4.1.2021.7890.3	manufacturer '/bin/cat /sys/devices/virtual/dmi/id/sys_vendor'

Si vous configurez une VM, ces fichiers vont contenir des informations sur l’hyperviseur.

Découvert grâce à un tweet de _Nidouille_

Installer son instance mastodon sous Gentoo

2021-01-31T11:42:32+01:00

Suite à l’annonce de Valère d’arrêter les services hostux, et donc l’instance mastodon, j’ai décidé de monter la mienne. La principale raison est que je n’ai pas trouvé d’autre instance en Europe avec un TLSA. Je ne vais pas ici expliquer toute l’installation, mais seulement ce que j’ai dû adapter de la doc officielle pour Gentoo. À l’heure actuelle, la dernière version stable est la v3.3.0, il y aura donc sûrement de nouvelles modifications à apporter dans le futur pour les versions suivantes.

Ruby

Mastodon est principalement codé en ruby, la doc demande de créer un rbenv en version 2.7.2. J’ai rapidement testé en gardant la version ruby des dépôts (actuellement 2.6.6-r2) et ça semble quand même fonctionner, mais après réflexion j’ai tout de même préféré garder le rbenv, au cas où il y ait un besoin strict d’une version pas encore stable chez gentoo ou que l’upgrade quotidienne demande de recompiler tous les assets de mastodon.

PostgreSQL

La doc parle de version 9.6, bien qu’elle soit présente dans les dépôts, les upgrades de PostgreSQL ne sont pas complètement automatiques (il faut jouer avec pg_upgrade à la main). J’ai donc décidé de prendre la version stable la plus récente (donc la 13) afin de remettre à plusieurs années le moment où il faudra changer de version majeure de PostgreSQL.

Conversion des scripts systemd en open-rc

Comme j’utilise Gentoo avant tout pour éviter d’avoir à subir systemd, et que les auteurs de la doc de mastodon partent du postulat que tout le monde utilise systemd, j’ai dû adapter les scripts d’init de mastodon.
Si vous utilisez le ruby des dépôts, il faut changer le chemin absolu pour bundle afin de laisser openrc-rc se baser sur votre $PATH.
Les logs seront dans /var/log/user.log. Si cela ne vous convient pas, adaptez les options de logger.

bulbizarre ~ # cat /etc/init.d/mastodon-sidekiq
#!/sbin/openrc-run
# Copyright 2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

name="mastodon-sidekiq daemon"
description="mastodon-sidekiq"

command_user="mastodon"
HOME="/opt/mastodon"
directory="$HOME/live"

output_logger="logger -t ${description}"
error_logger="logger -t ${description}"

source "$HOME/.bashrc"
export RAILS_ENV=production
export DB_POOL=25
export MALLOC_ARENA_MAX=2
command="$HOME/.rbenv/shims/bundle exec sidekiq"
command_args="-c 25"

pidfile="/run/${description}.pid"
command_background=true

depend() {
	use net
}


bulbizarre ~ # cat /etc/init.d/mastodon-streaming
#!/sbin/openrc-run
# Copyright 2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

name="mastodon-streaming daemon"
description="mastodon-streaming"

command_user="mastodon"
HOME="/opt/mastodon"
directory="$HOME/live"

output_logger="logger -t ${description}"
error_logger="logger -t ${description}"

source "$HOME/.bashrc"
export NODE_ENV=production
export PORT=4000
export STREAMING_CLUSTER_NUM=1
command="/usr/bin/node ./streaming"

pidfile="/run/${description}.pid"
command_background=true

depend() {
	use net
}


bulbizarre ~ # cat /etc/init.d/mastodon-web
#!/sbin/openrc-run
# Copyright 2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

name="mastodon-web daemon"
description="mastodon-web"

command_user="mastodon"
HOME="/opt/mastodon"
directory="$HOME/live"

output_logger="logger -t ${description}"
error_logger="logger -t ${description}"

source "$HOME/.bashrc"
export RAILS_ENV=production
export PORT=3000
command="$HOME/.rbenv/shims/bundle exec puma"
command_args="-C ${directory}/config/puma.rb"

pidfile="/run/${description}.pid"
command_background=true

depend() {
	use net
}

NodeJS

La version stable actuelle est la 14 et la doc demande la 12. Il se trouve que si vous tentez de lancer le streaming avec un node 14 vous aurez des erreurs 503 dans les logs de nginx et rien dans les logs de node. Il faut le lancer avec un node 12. J’ai donc masqué les versions supérieures à 13.

nginx

Il manque quelques modules par défault pour faire fonctionner mastodon. Il faut ajouter dav dav_ext xslt à NGINX_MODULES_HTTP.

imagemagick et ffmpeg

Les options de compilation des libs « multimédia » sont très limitées sur un profile serveur (car il n’y a pas tous les USE poussés par les profiles desktop). Comme je ne peux pas deviner quels types d’images et vidéos seront utilisés, j’ai vu assez large sur les options. On peut sûrement en retirer, mais dans le doute…
Donc j’ai ajouté hdri heif jbig jpeg jpeg2k lcms pango png raw svg tiff truetype webp xml à media-gfx/imagemagick et mp3 sdl svg theora truetype vorbis vpx x264 x265 xvid à media-video/ffmpeg.

Désactivation de la souris pour urxvt et terminator (et autres terminaux basés sur VTE)

2020-02-09T11:37:38+01:00

Depuis quelques temps, le support de la souris est activé par défaut sur certaines applications CLI, notamment vim. Ceci empêche d’utiliser le presse-papier « clic milieu » et ne sert en outre à rien, c’est donc fort ennuyeux.

J’ai un peu cherché comment désactiver le support de la souris sur le net pour les émulateurs de terminal que j’utilise, mais je n’ai jamais trouvé d’option qui allait bien. J’ai donc opté pour une solution de gentooïste allant à la source du problème : supprimer complètement le support de la souris dans le code. Voici donc comment je m’y suis pris :

Grepper des mots-clés tels que mice, mouse ou autres trucs s’en approchant
Supprimer les lignes
Échouer à compiler
Supprimer un peu moins de lignes
Et ainsi de suite

Ensuite, j’ai généré un patch par programme, que j’ai intégré avec un ebuild dans mon overlay personnel pour chaque terminal que j’utilise : urxvt et terminator (basé sur VTE). Le patch de x11-libs/vte n’a été testé qu’avec terminator, mais en théorie ça devrait aussi fonctionner avec gnome-terminal, xfce4-terminal ou autres.

Vérification RPKI avec routinator, bird et IOS-XE

2020-01-13T18:47:55+01:00

Quand on fait partie de la DFZ, on peut en gros annoncer n’importe quel préfixe tant que ça passe les filtres de nos pairs, et on est censé leur faire plus ou moins confiance. Sauf que croire encore à ce système de la confiance en 2020, c’est aussi croire aux bisounours. Il est bien plus sûr de faire des filtres qui taillent dans le vif et de vérifier que les préfixes que l’on reçoit viennent du bon AS. Pour ça, il est possible de signer ses annonces avec RPKI (ou de faire signer par son LIR si l’on n’en est pas un) et aussi de vérifier les signatures RPKI sur les préfixes que l’on reçoit. Les deux étant complètement décorrélés, un peu à la manière de DNSSEC : on peut très bien vérifier les signatures DNSSEC mais ne pas signer son domaine et inversement.

Comme les signatures RPKI sont cryptographiques et que les CPUs des routeurs ne sont pas des foudres de guerre (l’intérêt des routeurs c’est de profiter des ASIC/FPGA, pas de router via le CPU), il existe RPKI-RTR. C’est un protocole qui permet de faire les vérifications sur un serveur (avec un CPU puissant, donc) puis d’envoyer les données pré-machées au routeur pour qu’il puisse les traiter avec très peu de CPU.

J’ai testé deux implémentations : rpki-client d’OpenBSD et routinator de NLnetLabs. Comme je suis feignant, j’ai d’abord regardé si l’une des deux étaient déjà packagée pour gentoo. Ce fut un échec total. À vue de nez, rpki-client me semblait plus simple, j’ai donc commencé par cela, mais j’ai rencontré plusieurs soucis :

La numérotation des versions est un peu étrange, 0_3_0 au lieu de 0.3.0, que je règle en créant une variable $VERSION tirée de $PV : VERSION="VERSION_${PV//./_}", que je ré-utilise donc en lieu et place de $PV dans le reste de l’ebuild
La liste des préfixes pour bird était vide : bug #12
Encore plus gênant, je n’ai jamais réussi à importer la liste générée dans bird, pour cause d’erreur de syntaxe dans le fichier : /var/db/rpki-client/bird:1:1 syntax error, unexpected CF_SYM_UNDEFINED. La première ligne étant roa table roa {. D’après la documentation, le symbole roa est censé se trouver dans un protocole RPKI, sauf que ce protocole demande un serveur RPKI-RTR.

Il était donc assez clair que cette implémentation n’était pas la bonne approche pour mon besoin. De plus, elle n’est pas compatible avec IOS-XE, et j’ai également envie de vérifier RPKI dessus et pas seulement sur les bird.

Je me suis donc lancé dans le packaging de routinator. Comme il est écrit en rust, j’ai utilisé cargo-ebuild afin qu’il me génère un ebuild avec tous les dépendances rust qui ne sont pas dans l’arbre de portage. Et là premier souci : la façon d’installer les binaires a changée.

J’ai donc attendu un peu que la fonction soit mise à jour, puis j’ai pu l’installer. Là je me suis rendu compte que je n’avais pas fait de fichier de configuration ni de script d’init, je les ai donc écris et intégrés dans mon ebuild. À ce stade j’ai maintenant un routinator qui démarre, récupère les TALs et écoute sur le port standard. Il est maintenant temps de passer à l’intégration avec les routeurs.

Pour le cas de bird, la configuration se présente comme suit avec un serveur sur mon infrastructure propre et un autre sur celle de grifon :

roa4 table r4;
roa6 table r6;

protocol rpki rpki_msi {
        roa4 { table r4; };
        roa6 { table r6; };

        remote "msi.no.swordarmor.fr";
}

protocol rpki rpki_conan {
        roa4 { table r4; };
        roa6 { table r6; };

        remote "conan.grifon.fr";
}

Ici, je crée deux tables (r4 et r6) et je demande à mes protocoles de mettre les préfixes RPKI dedans.

Et là, en rechargeant la configuration, je tombe sur une erreur de syntaxe du même type que pour rpki-client. C’est pas très gentil… La vraie raison est que bird a besoin de la libssh pour activer le protocole RPKI. Et ce, même si on utilise le transport TCP classique. C’est un bug connu qui sera corrigé. Il se trouvait donc que l’ebuild de bird n’avait pas cette option. J’ai donc ajouté le USE flag libssh, recompilé et redémarré bird.

Maintenant, les nouveaux protocoles apparaissent puis… rien. Je me suis donc fendu d’un sur la ML de bird et Ondrej Zajicek m’a dirigé vers un commit de leur git qui corrige ce bug. J’ai donc généré le .patch entre ce commit et celui du tag de la version 2.0.7, je l’ai ajouté à mon ebuild, puis j’ai de nouveau recompilé et relancé mon bird. (quand on aime on ne compte pas) Et là, alléluia, j’ai bien les préfixes signés dans mon bird \o/

Il est maintenant temps de passer aux choses sérieuses : le filtrage des préfixes invalides. Pour ce faire, j’ai repris la configuration du LG du NLnog ring que j’ai adaptée à mon besoin :

function check_import_ipv4_rs()
[…]
        # scrub Origin Validation State Extended Community
        bgp_ext_community.delete((unknown 0x4300, 0, 0));
        bgp_ext_community.delete((unknown 0x4300, 0, 1));
        bgp_ext_community.delete((unknown 0x4300, 0, 2));

        # set RPKI Origin Validation State Extended Community
        case roa_check(r4, net, bgp_path.last_nonaggregated) {
                ROA_VALID:
                        /* add rfc8097 marker to routes for which a valid matching ROA exists */
                        bgp_ext_community.add((unknown 0x4300, 0, 0));
                        igp_metric = 10;
                ROA_INVALID:
                        bgp_ext_community.add((unknown 0x4300, 0, 2));
                        return false;
                else:
                        /* add rfc8097 marker to routes for which no covering ROA exists */
                        bgp_ext_community.add((unknown 0x4300, 0, 1));
                        igp_metric = 20;
        }

        return generic_check_import();
}
function check_import_ipv6_rs()
[…]
        # scrub Origin Validation State Extended Community
        bgp_ext_community.delete((unknown 0x4300, 0, 0));
        bgp_ext_community.delete((unknown 0x4300, 0, 1));
        bgp_ext_community.delete((unknown 0x4300, 0, 2));

        # set RPKI Origin Validation State Extended Community
        case roa_check(r6, net, bgp_path.last_nonaggregated) {
                ROA_VALID:
                        /* add rfc8097 marker to routes for which a valid matching ROA exists */
                        bgp_ext_community.add((unknown 0x4300, 0, 0));
                        igp_metric = 10;
                ROA_INVALID:
                        bgp_ext_community.add((unknown 0x4300, 0, 2));
                        return false;
                else:
                        /* add rfc8097 marker to routes for which no covering ROA exists */
                        bgp_ext_community.add((unknown 0x4300, 0, 1));
                        igp_metric = 20;
        }

        return generic_check_import();
}

La fonction roa_check est déjà intégrée dans bird, il n’y a pas besoin de la déclarer. De cette façon, je rejette les annonces invalides, je marque chaque préfixe en fonction de son type de validité et, en modifiant la métrique IGP, je préfère une annonce valide à une annonce non déclarée si le chemin BGP et la MED sont égales entre les deux annonces. Ce cas devrait arriver très rarement, uniquement quand un préfixe vient d’être signé et qu’une route n’a pas encore été mise à jour.

Si jamais vous avez une route par défaut, vous avez certainement envie de marquer la route comme injoignable (dest = RTD_UNREACHABLE) pour éviter d’utiliser la route par défaut si cette route plus spécifique n’est pas dans la FIB.

Pour le cas d’IOS XE, c’est beaucoup plus simple, il suffit de quelques lignes de configuration :

conf t
 router bgp 204092
  bgp rpki server tcp 2A00:5884::8 port 323 refresh 600
  bgp rpki server tcp 2A0E:F42::1 port 323 refresh 600
  address-family ipv4
   neighbor GRIF-iBGP-IPv4 send-community both
   neighbor GRIF-iBGP-IPv4 announce rpki state
  address-family ipv6
   neighbor GRIF-iBGP-IPv6 send-community both
   neighbor GRIF-iBGP-IPv6 announce rpki state

Nous sommes obligés de mettre l’IP directement, c’est spécifié dans la documentation. Les options sur les neighbors permettent de garder la communauté correspondant à la validité RPKI lors de l’export vers les autres routeurs du réseau.

Remplir la table SNMP ifAlias sous Linux

2019-10-20T16:57:13+02:00

Il m’arrive encore de jouer avec des routeurs soft, et comme à chaque fois il faut bricoler pour avoir ce que l’on veut, ici avoir une table ifAlias correcte. À une époque je le faisais avec FreeBSD, et j’avais trouvé la parade en utilisant un proxy vers bsnmpd. Sauf que sous Gentoo, on a pas bsnmpd.

Il existe un script sur le repo git d’observium qui permet de récupérer une valeur depuis /etc/network/interfaces. Mais je veux un truc standard, pas un nième script spécifique à Debian…

L’idée est donc de configurer les aliases de ses interfaces avec ip-link(8) :

ip link set eno1 alias "Transit: Grifon"

Pour retrouver la config au reboot, j’utilise la fonction postup() de /etc/conf.d/net ou directement tinc-up :

regis ~ # tail -n 6 /etc/conf.d/net
postup() {
        ip link set eno1 alias "Transit: Grifon"
        ip link set eno2 alias "Core: Admin Breizh-IX"
        ip link set enp1s0f0 alias "Peering: Breizh-IX"
        ip link set enp1s0f1 alias "Core: Quarantaine Breizh-IX"
}
regis ~ # cat /etc/tinc/backbone/tinc-up
#!/bin/sh

ip link set tinc0 up
ip addr add 45.91.126.235/29 dev tinc0
ip addr add 2a0e:f42:fffe::3/64 dev tinc0

ip link set tinc0 alias "Core: Backbone"

Mais évidemment, snmpd ne va pas réussir à trouver cette valeur tout seul…

metro ~ # snmpwalk -v2c -c public regis.swordarmor.fr ifAlias
IF-MIB::ifAlias.1 = STRING: 
IF-MIB::ifAlias.2 = STRING: 
IF-MIB::ifAlias.3 = STRING: 
IF-MIB::ifAlias.4 = STRING: 
IF-MIB::ifAlias.5 = STRING: 
IF-MIB::ifAlias.6 = STRING: 
IF-MIB::ifAlias.7 = STRING: 
IF-MIB::ifAlias.8 = STRING: 
IF-MIB::ifAlias.9 = STRING: 
IF-MIB::ifAlias.10 = STRING: 
IF-MIB::ifAlias.11 = STRING: 
IF-MIB::ifAlias.14 = STRING: 
IF-MIB::ifAlias.18 = STRING: 
IF-MIB::ifAlias.23 = STRING: 
IF-MIB::ifAlias.40 = STRING: 
IF-MIB::ifAlias.41 = STRING: 
IF-MIB::ifAlias.46 = STRING: 
IF-MIB::ifAlias.47 = STRING: 
IF-MIB::ifAlias.72 = STRING: 
IF-MIB::ifAlias.73 = STRING: 
IF-MIB::ifAlias.74 = STRING: 
IF-MIB::ifAlias.75 = STRING: 
IF-MIB::ifAlias.76 = STRING: 
IF-MIB::ifAlias.77 = STRING: 
IF-MIB::ifAlias.79 = STRING: 
IF-MIB::ifAlias.80 = STRING: 
IF-MIB::ifAlias.82 = STRING:

L’idée est donc d’utiliser un script qui va aller chercher les infos et les mettre dans la table. Le paquet


     dev-perl/SNMP-Extension-PassPersist

se trouve dans mon mon repo Gentoo personnel.

emerge -va dev-perl/SNMP-Extension-PassPersist
wget -O /usr/local/bin/ifAlias_persist https://git.grifon.fr/alarig/snmp-ifalias/raw/branch/master/ifAlias_persist
chmod +x /usr/local/bin/ifAlias_persist
echo "pass_persist .1.3.6.1.2.1.31.1.1.1.18 /usr/local/bin/ifAlias_persist" >> /etc/snmp/snmpd.conf
rc-service snmpd restart

Et maintenant, nous avons bien les valeurs que nous voulons :

metro ~ # snmpwalk -v2c -c public regis.swordarmor.fr ifAlias
IF-MIB::ifAlias.2 = STRING: Transit: Grifon
IF-MIB::ifAlias.3 = STRING: Core: Admin Breizh-IX
IF-MIB::ifAlias.4 = STRING: Peering: Breizh-IX
IF-MIB::ifAlias.5 = STRING: Core: Quarantaine Breizh-IX
IF-MIB::ifAlias.82 = STRING: Core: Backbone

Le script est disponible sur son repo git : snmp-ifalias.

Afficher correctement les AS 32 bits avec mtr

2018-09-25T11:57:25+02:00

mtr est un outil très pratique qui permet de faire un traceroute, mais en mieux. La sortie est beaucoup plus lisible, et ça utilise de l’ICMP par défaut (au lieu de l’UDP sous Linux/*BSD). Seulement, dans les anciennes versions, les AS 32 bits sont mal gérés : ils sont trop longs et sont collés au nom de la machine, du coup c’est fort peu pratique.


alarig@gourmaleon:~$ mtr -zbwe grifon01.ring.nlnog.net
Start: Mon Sep 24 13:31:22 2018
HOST: gourmaleon                                                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS34019 ve375-rt-std.bb.hivane.net (2001:67c:1740:9032::c1c8:2afd)                    0.0%    10    0.4   0.5   0.4   0.7   0.0
  2. AS???   equinix-th2.quantic-telecom.net (2001:7f8:43::19:8507:1)                      0.0%    10    0.7   1.0   0.7   2.4   0.3
  3. AS198507rennes-rns01-gw1.routers.quantic-telecom.net (2a06:e040:0:7501:1350:aa:0:2)   0.0%    10    9.7  10.0   9.4  13.3   1.2
  4. AS204092budic-vlan41-ibgp.cogent-rns.grifon.fr (2a00:5884:0:4::2)                     0.0%    10    9.8  10.0   9.7  10.4   0.0
  5. AS204092regis.swordarmor.fr (2a00:5884:102::1)                                        0.0%    10   10.0   9.9   9.7  10.3   0.0
  6. AS204092nlnogring-grifon.swordarmor.fr (2a00:5884:102:1::2)                           0.0%    10   10.5  10.2  10.0  10.5   0.0

Avec un petit awk, on peut ajouter de l’espace à chaque ligne contenant un ASN, et plus précisément entre la colonne 13 et 14 :


alarig@gourmaleon:~$ mtr -zbwe grifon01.ring.nlnog.net | awk '{ if(index($2,"AS")) { print substr($0,0,13), substr($0,14) } else print }'
Start: Mon Sep 24 13:31:55 2018
HOST: gourmaleon                                                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS34019  ve375-rt-std.bb.hivane.net (2001:67c:1740:9032::c1c8:2afd)                    0.0%    10    0.4   0.6   0.4   1.0   0.0
  2. AS???    equinix-th2.quantic-telecom.net (2001:7f8:43::19:8507:1)                      0.0%    10    0.7   0.8   0.6   1.0   0.0
  3. AS198507 rennes-rns01-gw1.routers.quantic-telecom.net (2a06:e040:0:7501:1350:aa:0:2)   0.0%    10    9.7   9.6   9.4  10.4   0.0
  4. AS204092 budic-vlan41-ibgp.cogent-rns.grifon.fr (2a00:5884:0:4::2)                     0.0%    10    9.7   9.9   9.7  10.3   0.0
  5. AS204092 regis.swordarmor.fr (2a00:5884:102::1)                                        0.0%    10   10.0  10.1   9.9  10.3   0.0
  6. AS204092 nlnogring-grifon.swordarmor.fr (2a00:5884:102:1::2)                           0.0%    10   10.4  10.1   9.9  10.4   0.0

Ensuite, on peut très bien se faire une fonction dans son ~/.bashrc ou ~/.zshrc pour éviter de devoir se rappeler du awk à chaque fois.
Notons que ça ne marche qu’en mode rapport (-w) mais que les versions récentes de mtr (au moins depuis la 0.87) gèrent correctement les AS 32 bits.

Merci à solene pour ce bout de awk.

Sauvegarder la configuration de ses switches et routeurs avec expect

2018-08-18T20:50:55+02:00

Si vous ne connaissez pas expect, c’est un outil qui permet d’écrire des scripts en TCL qui iront interagir avec telnet/ssh et d’autres trucs du genre, sans que vous ayez à le faire vous même. C’est donc très pratique pour écrire des scripts qui seront exécutés vers des équipements qui n’ont pas de cron (ce qui est typiquement le cas des switches et des routeurs).

Ici, le script est utilisé pour sauvegarder la configuration des switchs de Breizh-IX

On commence par écrire le script TCL pour aller chercher la version de l’OS qui tourne ainsi que la configuration qui tourne. Bien sûr, il faut changer user et password par les valeurs qui vont bien pour vous.
Je teste les noms d’hôte des switch afin d’adapter les commandes qui différent entre Cisco et Brocade. Dans l’idéal il faudrait tester ça par rapport au sh ver du début, et non par rapport à l’argument que l’on passe au script, mais dans l’immédiat ça suffit vu que je n’ai que deux switches.

#!/usr/bin/expect -f

set host [lindex $argv 0]
set prompt "(>|#|\\\$) $"

spawn telnet $host

expect Connected
set current_line $expect_out(buffer)
if { [string first "Connected" "$current_line"] == -1 } {
	exit 1
}

expect -nocase "user "
send "user\r"

expect -nocase "pass"
send "password\r"

send "enable\r"
send "password\r"

send \r
expect -re $prompt

send "show version\r"
expect -re $prompt
expect *;

# disable pagination on brocade
if { [string first "asterix" $host]!=-1 } {
	send "skip-page-display\r"
}

# disable pagination on cisco
if { [string first "amonbeaufils" $host]!=-1 } {
	send "terminal length 0\r"
}

expect -re $prompt
send "show run\r"
expect "end"
send \r
expect -re $prompt
send "exit\r"

exit

Ensuite, on écrit un petit script shell qui va renvoyer la sortie dans le bon dossier, et compresser les fichiers histoire de ne pas perdre trop de place, puis on retire les backups qui ont plus d’un mois.

#!/bin/sh

./expect-sh-run.tcl $1 > /var/backups/switches/${1}-$(date +%F).txt

if [ $? = 0 ]; then
	gzip /var/backups/switches/${1}-$(date +%F).txt
	find "/var/backups/switches/${1}-*" -mtime +30
else
	echo "Backup error!"
	cat /var/backups/switches/${1}-$(date +%F).txt
fi

Utiliser socat pour contourner les limiations SSL d’un navigateur moderne

2018-07-30T22:41:19+02:00

Depuis quelque temps, les navigateurs bloquent les requêtes SSL/TLS utilisant des versions de protocoles et suites cryptographiques jugées trop faibles.

Cependant, on peut avoir besoin de se connecter à de vieux équipements qui eux ne supportent que ces vielles versions ; en l’occurrence, un PDU. En théorie, ils supportent aussi les connexions en clair, sauf que des fois non…

C’est là que socat vient à la rescousse. En effet, il est parfaitement capable de négocier une version SSL arbitraire d’un côté et de ressortir ça en clair de l’autre.

while :; do socat TCP-LISTEN:8080,fork OPENSSL:172.20.44.171:443,method=SSL23,cipher=RC4-MD5,verify=0; sleep 1; done

Avec cette ligne, toutes les requêtes reçues en clair sur le port 8080 seront renvoyées en SSLv3 sur 172.20.44.171:443.

TCP-LISTEN:8080 écoute sur le port 8080 sans chiffrement
fork crée un processus enfant pour chaque connexion, ce qui évite de devoir relancer socat à chaque fois qu’une connexion est fermée
OPENSSL:172.20.44.171:443 se connecte en SSL sur l’IP 172.20.44.171 et le port 443
method=SSL23 négocie les protocoles SSLv2 et SSLv3
cipher=RC4-MD5 utilise le cipher RC4-MD5
verify=0 évite de vérifier la CA
sleep 1 sert à pour facilement interrompre la boucle avec ^C
while :; do […]; done permet de ne pas relancer la commande sans cesse

Maintenant pourquoi SSLv3 et RC4-MD5 ? Simplement parce que c’est ma référence d’algorithme pourri, j’étais donc à peu près sûr que ça allait marcher sur cet équipement.

Proxy SNMP pour une table précise (ifAlias)

2018-04-27T21:54:57+02:00

État des lieux

Sous FreeBSD nous avons le choix entre deux implémentations SNMP : bsnmp et le classique net-snmp. Le premier a des soucis sur les modèles de CPU et ne remonte pas les IPv6 des interfaces, alors que le second ne remonte pas la description des interfaces.
En clair, on a le choix entre la peste et le choléra.

Façon propre de résoudre le souci

Une bonne chose aurait été de patcher le code de net-snmp pour remonter les descriptions comme il faut. Mais, je ne sais pas programmer, surtout pas en C, et je n’ai pas le temps (ni vraiment l’envie) d’apprendre.

Façon pragmatique de résoudre le souci

Donc, j’ai choisi de faire autrement : laisser net-snmp sur le port standard, et proxéiser la table ifAlias vers bsnmp.

Configuration de bsnmp

Commençons par configurer correctement notre bsnmp, cela se passe dans /etc/snmpd.config.

read := "public"				# communauté publique en lecture
begemotSnmpdPortStatus.127.0.0.1.1161 = 1	# écoute sur localhost:1161

Maintenant, nous pouvons bien récupérer notre description depuis bsnmp :

root@budic:~ # snmpwalk -v2c -c public localhost:1161 ifAlias.6
IF-MIB::ifAlias.6 = STRING: Transit: Quantic

Configuration de net-snmp

Maintenant, il faut dire à net-snmp d’aller interroger bsnmp pour la table ifAlias. Pour cela, nous utilisons la directive proxy :

proxy -v 2c -c public localhost:1161 .1.3.6.1.2.1.31.1.1.1.18

Et maintenant, .1.3.6.1.2.1.31.1.1.1.18 (soit ifAlias) est redirigé vers bsnmp, et nous pouvons le vérifier :

alarig@conan ~ $ snmpwalk -v2c -c public budic.grif ifAlias.6
IF-MIB::ifAlias.6 = STRING: Transit: Quantic
alarig@conan ~ $ snmpwalk -On -v2c -c public budic.grif ifAlias.6
.1.3.6.1.2.1.31.1.1.1.18.6 = STRING: Transit: Quantic

Ebuild pour la suite de tests blaeu pour les sondes RIPE Atlas

2018-04-17T16:37:01+02:00

Blaeu

Blaeu permet de créer des tests en utilisant l’API d’Atlas puis d’afficher le résultat de manière lisible pour un humain ou une machine.
Une description complète est disponible dans le README du répertoire git .

L’installation sous gentoo

L’ebuild est dans mon overlay personnel, il faut donc commencer par l’ajouter :


morvan ~ # cat /etc/portage/repos.conf/SwordArMor.conf
[SwordArMor]
location = /usr/local/overlay/SwordArMor
sync-type = git
sync-uri = https://git.grifon.fr/alarig/SwordArMor-gentoo-overlay.git
auto-sync = yes

Ensuite après avoir synchronisé les dépôts, on peut l’installer avec emerge -va net-analyzer/blaeu, et ensuite c’est censé marcher :


alarig@morvan ~ % blaeu-traceroute --format --requested 1 --asn 204092 --protocol ICMP 2a00:5884:102:1::4
Measurement #12198809 Traceroute 2a00:5884:102:1::4 from AS #204092 uses 1 probes
1 probes reported
Test #12198809 done at 2018-04-17T14:35:41Z
From:  2a00:5884::44    204092    GRIFON, FR
Source address:  2a00:5884::44
Probe ID:  15467
1    2a00:5884::1    204092    GRIFON, FR    [0.511, 0.447, 0.343]
2    2a00:5884:102::1    204092    GRIFON, FR    [0.557, 0.553, 0.632]
3    2a00:5884:102:1::4    204092    GRIFON, FR    [0.795, 0.911, 0.766]

Ebuild

Si vous avez envie de savoir à quoi il ressemble, vous pouvez regarder le fichier blaeu-9999.ebuild sur l’interface web du git.
J’ai également dû écrire cymruwhois-1.6.ebuild car cette bibliothèque n’était pas disponible sous gentoo.

Notes

Attention cependant, je suis tout seul à maintenir mon dépôt. Donc il est possible qu’un jour l’ebuild ne fonctionne plus, et je ne pourrai pas garantir que je vais le réparer. Ce dépôt me sert avant tout à éviter de devoir ré-écrire chaque ebuild sur chacune de mes machines.

Le nœud AS112 chez grifon et Breizh-IX

2017-12-10T15:29:47+01:00

Le rôle de l’AS112

Cet AS est assez spécial, il sert de trou noir du DNS. C’est aussi l’une des premières utilisations de l’anycast.

En regardant la charge des serveurs racines du DNS, les administrateurs se sont rendu compte qu’une quantité non négligeable de requêtes étaient des demandes de PTR sur les adresses 1918. La parade est donc de créer une délégation pour ces zones et d’avoir des serveurs qui répondent que le domaine n’existe pas avec un très grand TTL. Ainsi, les serveurs racines seront soulagés de ces requêtes le temps que le TTL expire.
Le serveur doit répondre sur cinq IPs différentes :

prisoner.iana.org car c’est le serveur maître renseigné dans le SOA,
blackhole-1.iana.org et blackhole-2.iana.org car les zones sont déléguées dessus,
blackhole.as112.arpa afin de supporter les redirections DNAME,
et bien sûr les IPs anycast du nœud.

Bien évidemment, un administrateur consciencieux ne devrait pas faire sortir ce genre de requêtes de son réseau ; mais nous savons tous que nous ne sommes pas entourés que de gens compétents.

Le projet est défini dans le RFC 6304 et le support d’IPv6 et du DNAME sont ajoutés dans le RFC 7534.
Un brouillon est en cours de rédaction afin d’ajouter le support de la zone home.arpa.

Mise en place du nœud

Pour ce nœud j’ai choisi d’utiliser FreeBSD (en 11.1 à l’heure où j’écris ces lignes) avec les implémentations NSD pour le DNS et OpenBGPd pour le BGP.

DNS

Je me suis très fortement inspiré du fichier de configuration donné par Stéphane Bortzmeyer. Je l’ai adapté pour respecter le nouveau nommage de zones et supporter l’IPv6 d’une part, puis pour supporter les statistiques ainsi que quelques autres fioritures d’autre part.

Par défaut, NSD n’est pas compilé avec le support des statistiques dans FreeBSD, j’ai donc utilisé la version des ports en ajoutant les options BIND8_STATS et MUNIN_PLUGIN. Cette dernière servira à grapher les requêtes.

Voici les fichiers de configuration actuellement utilisés :

nsd.conf


# NSD configuration file for an AS112 name server. See RFC 6304 and
# 

# Inspired from http://www.bortzmeyer.org/6304.html

server:
	zonesdir: "/var/db/nsd"
	# Replace both with the real name
	# CH TXT queries
	identity: "hostname.as112.net - grifon node"
	# NSID (RFC 5011) queries. *Must* be in hex :-( Use for instance:
	# echo -n "ns.example.net" | hexdump -v -e '/1 "%02X"'
	nsid: "61733131322e677269666f6e2e6672"
	# The default value is too small
	tcp-count: 100
	tcp-query-count: 10
	tcp-timeout: 60

	# localhost
	ip-address: ::1
	ip-address: 127.0.0.1
	# Breizh-IX
	ip-address: 2001:7f8:b1::12
	ip-address: 185.1.89.16
	# grifon
	ip-address: 2a00:5884:0:100::1:10
	ip-address: 89.234.186.134
	# AS112
	ip-address: 2620:4f:8000::1
	ip-address: 2620:4f:8000::6
	ip-address: 2620:4f:8000::42
	ip-address: 2001:4:112::1
	ip-address: 192.175.48.1
	ip-address: 192.175.48.6
	ip-address: 192.175.48.42
	ip-address: 192.31.196.1

	logfile: "/var/log/nsd.log"
	statistics: 3600
	username: nsd

remote-control:
        control-enable: yes

# RFC 1918
zone:
       name: "10.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "16.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "17.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "18.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "19.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "20.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "21.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
	name: "22.172.in-addr.arpa"
	zonefile: "db.dd-empty"
	provide-xfr: 0.0.0.0/0 BLOCKED
	notify-retry: 0

zone:
       name: "23.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "24.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "25.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "26.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "27.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "28.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "29.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "30.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "31.172.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

zone:
       name: "168.192.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0

# RFC 5735
zone:
       name: "254.169.in-addr.arpa"
       zonefile: "db.dd-empty"
       provide-xfr: 0.0.0.0/0 BLOCKED
       notify-retry: 0


# DNAME redirection AS112 Service
zone:
	name: "empty.as112.arpa"
	zonefile: "db.dr-empty"
	provide-xfr: 0.0.0.0/0 BLOCKED
	notify-retry: 0

# Also answer authoritatively for the HOSTNAME.AS112.NET and
# HOSTNAME.AS112.ARPA zones, which contain data of operational
# relevance.
zone:
       name: "hostname.as112.net"
       zonefile: "db.hostname.as112.net"

zone:
	name: "hostname.as112.arpa"
	zonefile: "db.hostname.as112.arpa"

# https://tools.ietf.org/html/draft-ietf-homenet-dot-14
zone:
	name: "home.arpa"
	zonefile: "db.dd-empty"

# Unlike the sample BIND configuration in RFC 6304, we do not log
# requests: NSD cannot do it and, anyway, it is better done outside of
# the name server, for instance with dnscap
# .

db.dd-empty


; db.empty
;
; Empty zone for AS112 server.
;
$TTL	1W
@	IN	SOA	prisoner.iana.org. hostmaster.root-servers.org. (
                		1       ; serial number
		             	1W      ; refresh
        	             	1M      ; retry
                	     	1W      ; expire
                     		1W )    ; negative caching TTL
;
		NS	blackhole-1.iana.org.
		NS	blackhole-2.iana.org.
;
; There should be no other resource records included in this zone.
;
; Records that relate to RFC 1918-numbered resources within the
; site hosting this AS112 node should not be hosted on this
; nameserver.

db.dr-empty


; db.dr-empty
;
; Empty zone for DNAME redirection AS112 service.
;
$TTL    1W
@  IN	SOA  blackhole.as112.arpa. noc.dns.icann.org. (
                                  1       ; serial number
                                  1W      ; refresh
                                  1M      ; retry
                                  1W      ; expire
                                  1W )    ; negative caching TTL
;
	NS     blackhole.as112.arpa.
;
; There should be no other resource records included in this zone.
;
; Records that relate to RFC 1918-numbered resources within the
; site hosting this AS112 node should not be hosted on this
; nameserver.

db.hostname.as112.arpa


; db.hostname.as112.net
;
$TTL    1W
@       SOA	as112.grifon.fr. adminsys.grifon.fr. (
                	1               ; serial number
                        1W              ; refresh
                        1M              ; retry
                        1W              ; expire
                        1W )            ; negative caching TTL
;
	NS 	blackhole-2.iana.org.
        NS      blackhole-1.iana.org.
;
	TXT     "grifon" "Rennes, FR"
        TXT     "See http://www.as112.net/ for more information."
;
	LOC     48 51 29.520 N 2 20 19.320 E 0.00m 1m 10000m 10m

db.hostname.as112.net


; db.hostname.as112.net
;
$TTL    1W
@       SOA	as112.grifon.fr. adminsys.grifon.fr. (
                	2017120900      ; serial number
                        1W              ; refresh
                        1M              ; retry
                        1W              ; expire
                        1W )            ; negative caching TTL
;
	NS 	blackhole-2.iana.org.
        NS      blackhole-1.iana.org.
;
	TXT     "grifon" "Rennes, FR"
        TXT     "See http://www.as112.net/ for more information."
	TXT	"See https://monitoring.grifon.fr/munin/grifon.fr/as112.grifon.fr/index.html#dns for statistics."
	TXT	"Unicast IP: 89.234.186.134"
;
	LOC     48 51 29.520 N 2 20 19.320 E 0.00m 1m 10000m 10m

BGP

Le nœud est connecté aux deux routeurs de bordure de grifon afin d’obtenir une vue complète d’Internet. Ces routeurs ne relaient pas encore l’annonce, ça viendra sûrement un jour, quand je me serai fait relire ;).
Le nœud est également connecté au serveur de routes de Breizh-IX afin d’annoncer l’AS sur cet IX.

Les filtres d’AS sont commentés car ils contiennent des routes légitimes, comme 199.71.168.0/21 et 199.71.172.0/22.


root@as112:~ # bgpctl show rib transit-as 64500
flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete

flags destination          gateway          lpref   med aspath origin
*>    199.71.168.0/21      89.234.186.130     100     0 3.7484 174 19752 21992 64499 64500 3411 i
*     199.71.168.0/21      89.234.186.129     100     0 3.7484 174 19752 21992 64499 64500 3411 i
*>    199.71.168.0/23      89.234.186.130     100     0 3.7484 174 19752 21992 64499 64500 3411 i
*     199.71.168.0/23      89.234.186.129     100     0 3.7484 174 19752 21992 64499 64500 3411 i
*>    199.71.172.0/22      89.234.186.130     100     0 3.7484 174 19752 21992 64499 64500 3411 i
*     199.71.172.0/22      89.234.186.129     100     0 3.7484 174 19752 21992 64499 64500 3411 i

bgpd.conf


router-id 89.234.186.134
AS 112
fib-update yes

network 192.175.48.0/24
network 192.31.196.0/24
network 2620:4f:8000::/48
network 2001:4:112::/48

group "peering" {
	softreconfig in	yes
	softreconfig out yes
	announce	all

	neighbor 89.234.186.129 {
		remote-as	204092
		descr		"Grifon nominoe IPv4"
	}

	neighbor 2a00:5884:0:100::1:1 {
		remote-as	204092
		descr		"Grifon nominoe IPv6"
	}

	neighbor 89.234.186.130 {
		remote-as	204092
		descr		"Grifon budic IPv4"
	}

	neighbor 2a00:5884:0:100::1:2 {
		remote-as	204092
		descr		"Grifon budic IPv6"
	}

	neighbor 185.1.89.1 {
		remote-as	206165
		descr		"Breizh-IX RS1"
		enforce neighbor-as no
		set localpref	150
	}

	neighbor 2001:7f8:b1::1 {
		remote-as	206165
		descr		"Breizh-IX RS1"
		enforce neighbor-as no
		set localpref	150
	}
}

# do not send or use routes from neighbors without further explicit
# configuration
deny from any
deny to any

# filter out prefixes longer than 24 or shorter than 8 bits for IPv4
# and longer than 48 or shorter than 16 bits for IPv6.
allow from any inet prefixlen 8 - 24
allow from any inet6 prefixlen 16 - 48

# filter bogus networks according to RFC5735
deny from any prefix 0.0.0.0/8 prefixlen >= 8		# 'this' network [RFC1122]
deny from any prefix 10.0.0.0/8 prefixlen >= 8		# private space [RFC1918]
deny from any prefix 100.64.0.0/10 prefixlen >= 10	# CGN Shared [RFC6598]
deny from any prefix 127.0.0.0/8 prefixlen >= 8 	# localhost [RFC1122]
deny from any prefix 169.254.0.0/16 prefixlen >= 16	# link local [RFC3927]
deny from any prefix 172.16.0.0/12 prefixlen >= 12	# private space [RFC1918]
deny from any prefix 192.0.2.0/24 prefixlen >= 24	# TEST-NET-1 [RFC5737]
deny from any prefix 192.168.0.0/16 prefixlen >= 16	# private space [RFC1918]
deny from any prefix 198.18.0.0/15 prefixlen >= 15	# benchmarking [RFC2544]
deny from any prefix 198.51.100.0/24 prefixlen >= 24	# TEST-NET-2 [RFC5737]
deny from any prefix 203.0.113.0/24 prefixlen >= 24	# TEST-NET-3 [RFC5737]
deny from any prefix 224.0.0.0/4 prefixlen >= 4 	# multicast
deny from any prefix 240.0.0.0/4 prefixlen >= 4		# reserved

# filter bogus IPv6 networks according to IANA
deny from any prefix ::/8 prefixlen >= 8
deny from any prefix 0100::/64 prefixlen >= 64          # Discard-Only [RFC6666]
deny from any prefix 2001:2::/48 prefixlen >= 48        # BMWG [RFC5180]
deny from any prefix 2001:10::/28 prefixlen >= 28       # ORCHID [RFC4843]
deny from any prefix 2001:db8::/32 prefixlen >= 32      # docu range [RFC3849]
deny from any prefix 3ffe::/16 prefixlen >= 16          # old 6bone
deny from any prefix fc00::/7 prefixlen >= 7            # unique local unicast
deny from any prefix fe80::/10 prefixlen >= 10          # link local unicast
deny from any prefix fec0::/10 prefixlen >= 10          # old site local unicast
deny from any prefix ff00::/8 prefixlen >= 8            # multicast

## filter bogon AS numbers
## http://www.iana.org/assignments/as-numbers/as-numbers.xhtml
#deny from any AS 23456				# AS_TRANS
#deny from any AS 64496 - 64511			# Reserved for use in docs and code RFC5398
#deny from any AS 64512 - 65534		# Reserved for Private Use RFC6996
#deny from any AS 65535				# Reserved RFC7300
#deny from any AS 65536 - 65551			# Reserved for use in docs and code RFC5398
#deny from any AS 65552 - 131071		# Reserved
#deny from any AS 4200000000 - 4294967294	# Reserved for Private Use RFC6996
#deny from any AS 4294967295			# Reserved RFC7300

allow to any prefix 2620:4f:8000::/48
allow to any prefix 2001:4:112::/48
allow to any prefix 192.175.48.0/24
allow to any prefix 192.31.196.0/24

Post-installation

Statistiques

Si on a compilé NSD avec le support des statistiques bind8 et que l’on a configuré le support des dites statistiques et de nsd-control, on peut utiliser un plugin munin qui nous fera de (presque) jolis graphes.
Pour cela, on l’active : for i in hits memory by_type by_class by_opcode by_rcode zones; do ln -s /usr/local/share/munin/plugins/nsd_munin_ /usr/local/etc/munin/plugins/nsd_munin_${i}; done et on ajoute les lignes demandées dans le code à /usr/local/etc/munin/plugin-conf.d/plugins.conf.
Les graphes de ce nœud sont visibles sur le munin de grifon.

J’ai également installé net-snmp afin de collecter les métriques SNMP depuis le LibreNMS et ainsi intégrer le nœud à la weathermap.

Monitoring

Je monitore ce nœud de deux façons : la résolution du SOA de hostname.as112.arpa sur l’IP unicast de façon distante et la résolution du SOA de toutes les zones en utilisant NRPE. Je ne peux pas monitorer les IPs anycast de façon distante car l’icinga tourne chez hivane, je monitorerais alors le nœud d’hivane et non celui que je mets en place.
Cela nous fait beaucoup trop de tests pour les écrire à la main, j’ai généré le fichier de conf d’icinga qui va aller taper sur le NRPE avec un onliner en parsant le fichier de conf de NSD : [root@as112 ~]# for address in prisoner.iana.org blackhole-1.iana.org blackhole-2.iana.org blackhole.as112.arpa; do awk -F '"' '/name:/ { print $2 }' /usr/local/etc/nsd/nsd.conf | grep -v '^$' | while read zone; do printf "object Service \"nrpe-as112-${zone}-${address}\" {\n\timport \"generic-service\"\n\n\thost_name = \"as112.grifon.fr\"\n\tcheck_command = \"nrpe\"\n\tvars.nrpe_command = \"check_as112"\!"${zone}"\!"${address}\"\n\tvars.sla = \"24x7\"\n}\n\n"; done; done > nrpe.conf. (et non, je n’ai même pas honte, j’ai pas l’intention de réutiliser cette ligne un jour). Et j’ai écrit une bête ligne dans le fichier de configuration du serveur NRPE : command[check_as112]=/usr/local/libexec/nagios/check_dig -l '$ARG1$' -H '$ARG2$' -T SOA.

Annonces

Une fois que j’aurai reçu des retours sur cet article m’indiquant que je n’ai rien raté, ce nœud sera d’abord mis en production uniquement chez grifon afin de le tester. J’ai la main sur à peu près tout, ce sera donc assez facile de débugguer. À ce moment je ferai une annonce sur as112-ops en disant qu’il n’est pas visible d’Internet et sur la ML d’annonces de grifon.
Ensuite, il sera mis en production sur Breizh-IX, une annonce sera alors faite sur la ML de l’IX.
Enfin, si tout se passe bien, il sera peut-être annoncé publiquement, je répondrai alors à mon premier mail sur as112-ops afin de prévenir du changement de statut.

Remerciements

Merci à Pierre Emeriaud et à Stéphane Bortzmeyer pour leurs relectures.

Sources

De l’IPv6 dans du PPP

2017-09-28T23:09:33+02:00

Que j’aurais aussi pu titrer « Pourquoi aucun opérateur ne fait de collecte IPv6 en PPP ».

Tout d’abord, un rappel du fonctionnement d’une collecte PPP s’impose

L’abonné entre ses identifiants PPP dans son modem,
De l’autre côté, le BAS regarde le realm, et l’envoie à qui de droit en fonction. Par exemple un realm en @neufpnp ira chez SFR alors qu’un @grifon.ptel.ipadsl ira chez grifon,
Le LNS de l’opérateur vérifie les identifiants depuis une base RADIUS,
Et s’ils sont corrects, envoie la configuration au client en allant également la chercher dans une base RADIUS.

J’ai volontairement omis certains détails, mais le plus gros y est.

Fonctionnement en IPv4

C’est tout simple, le LNS prend une IP (soit fixe soit dynamique en fonction de votre FAI), un résolveur DNS, et envoie tout ça en IPCP dans le PPP.
Le routeur a l’autre bout, il a son IP pour faire son NAT et tout, il peut partager une IP entre tous les membres de la maison, il est content (nous non, parce que le NAT, mais c’est une autre histoire).

Et en IPv6

Et bien ce n’est pas du tout la même chose !
Il existe bien sûr IPv6CP (RFC5072, section 4), sauf que ça ne permet que de transmettre les 64 derniers bits de l’adresse que doit prendre l’abonné. Mais quid du range utilisé pour cette adresse, des ranges éventuellement délégués et des résolveurs DNS à utiliser ?

C’est là que ça devient intéressant, parce que tout ça doit être géré par des programmes extérieurs à PPP, qui injecteront tout cela dans le tunnel PPP. D’un côté c’est intéressant car on peut continuer à utiliser les implémentations dont on a l’habitude, mais d’un autre côté c’est embêtant, parce que l’on doit extraire les informations du RADIUS, pour configurer des RA et du DHCPv6 à la volée, et les implémentations ne sont pas forcément prévues pour.
Mais surtout, c’est plein de bugs partout, vous allez voir.

Père Castor, raconte nous une histoire

Voici donc mon histoire. Nous sommes un FAI, Grifon, et j’y ai mis en place un routeur de collecte ADSL. On trouve donc un opérateur de collecte, on se branche, on récupère le L2TP, tout va bien… jusqu’au moment où j’attaque IPv6.

Les attributs RADIUS

Je regarde les RFCs et mets donc les attributs qui vont bien pour ma connexion.


Framed-IPv6-Prefix = 2a00:5884:1100:1::/64,
Framed-IPv6-Address = 2a00:5884:1100:1::2,
Framed-Interface-Id = 0:0:0:2,
Delegated-IPv6-Prefix = 2a00:5884:1101::/48

Et là, rien ne se passe. Parce que dans le dictionnaire d’attributs utilisé par pppd, ils ne sont pas présents. Je les ajoute.


#IPv6
ATTRIBUTE       Framed-IPv6-Prefix      97      ipv6prefix
ATTRIBUTE       Framed-IPv6-Address     168     ipv6addr
ATTRIBUTE       Framed-Interface-Id     96      string
ATTRIBUTE       Delegated-IPv6-Prefix   123     ipv6prefix

Je recommence. Et :


Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 65 of length 4: 0x00000001
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 67 of length 13: 0x38392E3233342E3138362E3131
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 64 of length 4: 0x00000003
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 97 of length 18: 0x00402A005884110000010000000000000000
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 168 of length 16: 0x2A005884110000010000000000000001
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 96 of length 8: 0x0000000000000002

Là, ça commence déjà à devenir plus sérieux. Mais qu’à cela ne tienne, dans notre jeunesse nous avions déjà eu ce souci sur notre première solution VPN (à base d’IPsec pour chiffrer et de L2TP et PPP pour se rapprocher d’une collecte ADSL) et nous avions publié un patch, c’est juste dommage qu’en un an et demi il n’ait pas été intégré.
Je le reprends donc, je remercie gentoo de permettre de patcher facilement le code et je recommence une nouvelle fois, et je ne reçois rien.

Extraire les informations du RADIUS

Et oui, parce que PPP n’envoie aucune information utile pour que je puisse configurer ma pile IPv6 de mon côté. Se pose alors la question de comment récupérer les attributs utiles. Je peux bien sûr parser le fichier de la base de données RADIUS, car c’est un fichier plat, mais rien ne prouve qu’il sera toujours sur cette machine et je ne sais pas dire a priori quel identifiant est sur quelle interface.
Heureusement, en cherchant un peu, il existe le module radattr.so qui permet d’écrire les attributs RADIUS dans un fichier.

Service-Type Framed-User
Framed-Protocol PPP
Framed-Routing None
Framed-IP-Address 89.234.186.21
Framed-IP-Netmask 255.255.255.255
Framed-MTU 1492
Framed-IPv6-Prefix 2a00:5884:1100:1::/64
Framed-IPv6-Address 2a00:5884:1100:1::1
Framed-Interface-Id
Delegated-IPv6-Prefix 2a00:5884:1101::/48

Voilà qui est facilement parsable, c’est parfait. Mais, comment je mets ça dans radvd ? Je peux echo >> /etc/radvd.conf mais ça va être compliqué de retirer une configuration quand quelqu’un se déconnecte.
La solution retenue a donc été d’écrire un fichier de configuration basique, d’écrire un fichier par utilisateur, et de faire cat /etc/radvd.conf.base > /etc/radvd.conf; cat /run/vpn/radvd-user.*.conf >> /etc/radvd.conf puis de recharger la conf à chaque nouvelle connexion.
Je retente donc une nouvelle fois, et cette fois-ci j’ai une IP et une route par défaut ! Je commençais à désespérer… Mais seulement, je n’ai qu’une IP dans le range d’interco (le /64). Évidemment, je n’ai rien fait de mon range routé dans la configuration de radvd. Il faut donc que je configure cette partie à la main si je veux redistribuer des IPv6 à mes machines. Ce n’est pas très grave pour moi, mais c’est plus grave si je veux que ça marche automatiquement chez tout le monde.

Histoire de vérifier un peu ma configuration quand même, je demande à un copain qui a un modem linksys censé supporter IPv6 de tester. Et évidemment, l’IPv4 monte directement et l’IPv6 reste bloquée.

Rajouter une couche de DHCPv6

En regardant les trames de plus près, je me rends compte que son modem demande du DHCPv6. Je me dis que ce n’est pas si grave, je prends une implémentation connue, type celle de l’ISC, j’utilise la même méthode de configuration qu’avec radvd, et ça va le faire.
Sauf que non, parce qu’il échoue en disans « Unsupported device type 512 for "ppp0" ».

Il me faut alors chercher une autre implémentation, par exemple kea, qui elle supporte le PPP. Par contre, la configuration est en JSON et fait environ 70 lignes là où celle de radvd en fait 10. Je ne peux donc pas toutes les concaténer dans le même fichier, ça deviendrait rapidement inexploitable si pour une raison ou une autre je dois aller regarder dedans.
J’écris donc un template, que je sed avec les vraies valeurs et que j’écris dans un autre fichier, que j’utilise comme configuration pour kea.

Documentation technique

Si jamais vous souhaitez savoir ce que donne la configuration complète et comment les différentes briques se mettent place, vous pouvez lire la page de wiki que j’ai écrite à ce sujet.

Conclusion

Pour faire marcher IPv6 sur PPP, il m’a donc fallu :

Ajouter les attributs RADIUS dans le dictionnaire,
patcher ppp,
extraire la configuration IPv6 qui passe dans le PPP,
bricoler la configuration de radvd,
faire de même avec kea, en me prenant un bug sur isc-dhcp au passage.

Maintenant je comprends donc pourquoi personne ne fait d’IPv6 dans PPP. Ça demande beaucoup trop de bidouille pour que ça soit exploitable. Je comprends également pourquoi Orange attend de passer en collecte ethernet pour proposer de l’IPv6 et pourquoi Free utilise 6rd.
Je suis sacrément attaché à IPv6, donc j’ai bien creusé pour le faire marcher, mais à plusieurs moments je me suis dit que faire de l’IPv4-only ce ne serait peut-être pas si mal.

Après, il est vrai que j’aurais pu utiliser l2tpns, mais il a aussi dû être patché pour faire fonctionner IPv6, sans que le code ne soit intégré en upstream, et il fait tout en un seul programme (L2TP et PPP).
De plus, il comporte un bug qui fait que le RA n’est envoyé qu’une fois en début de session et que si le routeur ne l’a pas reçu (mauvais câble, implémentation qui ne s’attendait pas à le recevoir à ce moment, etc.), la route par défaut n’est jamais connue. De plus, il commençait à partir en buffer-overflow quand je l’ai testé chez moi.

Configuration dhcpcd pour le DHCPv6 de online

2017-05-22T09:22:07+02:00

En voulant faire un peu de ménage sur mon disque dur, je suis tombé sur une vielle sauvegarde d’une gentoo que j’avais chez online. Cela m’a permis de tomber sur une configuration DHCPv6 pour dhcpcd (le daemon DHCP « par défaut » de gentoo) fonctionnelle chez online. La configuration se met dans /etc/dhcpcd.conf et le DUID dans /etc/dhcpcd.duid.
Je la mets ici car je me rappelle avoir un peu galèré pour l’obtenir, alors ça peut peut-être servir à quelqu’un :)

# Persist interface configuration when dhcpcd exits.
persistent

# do not release, it override persistant!
#release

# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
duid

# no autoconfig
noipv4ll
noipv6rs

# We want routing, don't use kernel ra
ipv6ra_own

ipv6rs
ipv6ra_accept_nopublic

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname
nohook resolv.conf

waitip 4

interface eth0
# We want a prefix delegation

#ia_ta 33
#ia_na 0
ia_pd 0 eth0/0

Monitoring des sessions BGP de bird via NRPE

2017-05-10T13:15:22+02:00

Présentation

Toujours pour l’association grifon, j’ai eu besoin d’écrire un script afin de pouvoir remonter l’état de nos session BGP dans notre monitoring, c’est à dire un icinga2. Comme icinga est un fork de nagios, ça devrait marcher avec tous les outils de monitoring compatibles avec nagios.

Installation

La procédure d’installation a été réalisée sous FreeBSD, mais le script fonctionne aussi sous Linux, il suffit d’adapter les chemins

Récupération du script

Pour commencer, copiez le script si dessous dans le dossier contenant tous les plugins nagios sous le nom check_bgp. Vous devez donc obtenir un truc du genre /usr/local/libexec/nagios/check_bgp ou /usr/lib/nagios/plugins/check_bgp en fonction de votre OS.

Ensuite, rendez-le exécutable avec un petit chmod +x.

Configuration de sudo

Les plugins nagios tournent avec les droits de l’utilisateur nagios mais les droits sur le socket de bird sont très souvent limités à root. Il faut donc soit modifier les droits, soit utiliser sudo sans mot de passe. Voici une ligne de configuration sudo pour permettre à nagios d’exécuter birdc et birdc6 : nagios ALL=(ALL) NOPASSWD: /usr/local/sbin/birdc, /usr/local/sbin/birdc6.

Configuration de nrpe

Si nrpe n’est pas installé, installez-le avec pkg install nrpe-ssl. La configuration se fait dans /usr/local/etc/nrpe.cfg.
Il faut ajouter l’IP de la machine de monitoring dans allowed_hosts. Il est possible d’en mettre plusieurs séparée par des virgules. Par exemple : allowed_hosts=127.0.0.1, 2001:67c:1740:9032::229, 193.200.42.229.
Il faut ensuite ajouter les sessions que nous allons monitorées. Il faut obligatoirement utiliser -4 ou -6 pour préciser si on monitore une session IPv4 ou IPv6 ainsi que -p $protocol. L’option -s permet d’utiliser sudo pour avoir accès au socket de bird, elle n’est pas obligatoire. Par exemple, pour les sessions entre mon serveur et les routeurs de grifon s’appelle « bgp_alarig » aussi bien en IPv4 qu’en IPv6, je vais donc utiliser ces arguments :

command[check_bgp_ipv4_alarig]=/usr/local/libexec/nagios/check_bgp -4 -s -p bgp_alarig
command[check_bgp_ipv6_alarig]=/usr/local/libexec/nagios/check_bgp -6 -s -p bgp_alarig

Configuration de icinga2

Enfin, on va dire à icinga d’aller utiliser les commandes que l’on vient de créer :

object Service "nrpe-bgp-ipv4-alarig" {
  import "generic-service"

  host_name = "budic.grifon.fr"
  check_command = "nrpe"
  vars.nrpe_command = "check_bgp_ipv4_alarig"
  vars.sla = "24x7"
}

object Service "nrpe-bgp-ipv6-alarig" {
  import "generic-service"

  host_name = "budic.grifon.fr"
  check_command = "nrpe"
  vars.nrpe_command = "check_bgp_ipv6_alarig"
  vars.sla = "24x7"
}

On recharge les confs, et normalement on a un beau check qui vient de s’ajouter.

Code

Et voici le script à utiliser :

#!/bin/sh

# Copyright 2017 alarig <alarig@grifon.fr>
#
# BSD-3-Clause licence
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# 3. Neither the name of the copyright holder nor the names of its contributors
# may be used to endorse or promote products derived from this software without
# specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.

# For debuggin purpose, uncomment the next line and `tail -F` the file.
#exec 2> /tmp/check_bgp.log

usage() {
        printf "Usage:\n"
        printf "check_bgp [-4|-6] -p session\n"
        printf "Must be run with user account able to use birdc/birdc6 or use"
        printf "-s to use birdc with sudo.\n"
}

args=$(getopt 46hsp: $*)

if [ $? -ne 0 ]; then
        usage
        exit 3
fi
set -- $args

while :; do
        case "$1" in
                -h)
                        usage
                        exit 0
                        shift
                        ;;
                -4)
                        VERSION="IPv4"
                        shift
                        ;;
                -6)
                        VERSION="IPv6"
                        shift
                        ;;
                -s)
                        SUDO='sudo'
                        shift
                        ;;
                -p)
                        SESSION="$2"
                        shift; shift
                        ;;
                --)
                        shift; break
                        ;;
        esac
done

# path expansion for birdc and sudo of FreeBSD
PATH="$PATH:/usr/local/sbin/:/usr/local/bin/"

if [ "${VERSION}" = "IPv4" ]; then
        birdc="${SUDO} birdc -r"
elif [ "${VERSION}" = "IPv6" ]; then
        birdc="${SUDO} birdc6 -r"
else
        printf "CRITICAL: Invalid IP version, use -4 for IPv4 and -6 for IPv6\n"
        exit 2
fi

if [ -z ${SESSION} ]; then
        printf "CRITICAL: No session name supplied, use -p \$session.\n"
        exit 2
fi

STATE="$($birdc show protocol ${SESSION} | awk -v session=${SESSION} '$0 ~ session { print $6 }')"

# Session states: https://gitlab.labs.nic.cz/labs/bird/blob/master/proto/bgp/bgp.c#L1465
# Plugin return codes: https://nagios-plugins.org/doc/guidelines.html#AEN78

case ${STATE} in
        Established)
                printf "OK: ${SESSION} is ${STATE}\n"
                exit 0
                ;;
        OpenSent | OpenConfirm)
                printf "WARNING: ${SESSION} is in ${STATE} state\n"
                exit 1
                ;;
        Idle | Connect | Active)
                printf "CRITICAL: ${SESSION} is in ${STATE} state\n"
                exit 2
                ;;
        *)
                printf "Unknown state: ${STATE}\n"
                exit 3
                ;;
esac

CARP IPv6 avec FreeBSD

2017-05-01T17:25:16+02:00

Introduction

CARP est un protocole permettant à plusieurs machines de partager une même adresse IP sur un segment IP. Chez grifon nous l’utilisons entre nos deux routeurs afin d’être tolérant à leurs pannes.
Nous mettons une IP en gateway sur les machines de nos adhérents (89.234.186.1 en IPv4, fe80::240:092:100::1 en IPv6) et elles se baladent toutes seules entre les routeurs en cas de panne de l’un d’eux.
C’est un protocole master/slave, c’est à dire que les deux routeurs ne peuvent pas être master en même temps. Seul l’un des deux sert de passerelle à tout le monde à un moment donné.

Nous utilisons toujours FreeBSD pour nos routeurs, je vais donc ici parler de l’utilisation de CARP avec FreeBSD. Nous avions déjà une configuration CARP en IPv4, en voulant mettre de l’IPv6 en plus en suivant la même méthode ça a juste tout cassé. Il y a deux/trois subtilités que je vais expliquer.

Configuration basique

Afin de pouvoir reprendre la main sur les routeurs, il nous faut un IP sur chaque en plus de celle que nous allons avoir en CARP :

hostname="nominoe.grifon.fr"
# LAN
ifconfig_em1="inet 89.234.186.7 netmask 255.255.255.128"
ifconfig_em1_ipv6="inet6 2a00:5884::1/64"

hostname="budic.cogent-rns.grifon.fr"
# LAN
ifconfig_re1="inet 89.234.186.6 netmask 255.255.255.128"
ifconfig_re1_ipv6="inet6 2a00:5884::6/64"

Ce qui nous donne cette configuration sur chaque routeur :

alarig@nominoe:~ % ifconfig em1
em1: flags=8943 metric 0 mtu 1500
	options=4019b
	ether 00:15:17:39:f0:1b
	inet 89.234.186.7 netmask 0xffffff80 broadcast 89.234.186.127 
	inet6 fe80::215:17ff:fe39:f01b%em1 prefixlen 64 scopeid 0x2 
	inet6 2a00:5884::1 prefixlen 64 
	nd6 options=21
	media: Ethernet autoselect (100baseTX )
	status: active

alarig@budic:~ % ifconfig re1
re1: flags=8943 metric 0 mtu 1500
	options=8209b
	ether 00:0d:b9:3a:24:b9
	inet 89.234.186.6 netmask 0xffffff80 broadcast 89.234.186.127
	inet6 fe80::20d:b9ff:fe3a:24b9%re1 prefixlen 64 scopeid 0x2
	inet6 2a00:5884::6 prefixlen 64
	nd6 options=21
	media: Ethernet autoselect (100baseTX )
	status: active

CARP IPv6

Nous allons maintenant ajouter une adresse IPv6 en mode CARP. vhid 2 correspond au numéro de groupe vituel ; advskew 10 correspond à la priorité, plus le chiffre est élevé, plus elle est faible ; pass passwdv6 correspond au mot de passe pour authentifier le paquet CARP.

hostname="nominoe.grifon.fr"
# LAN
ifconfig_em1="inet 89.234.186.7 netmask 255.255.255.128"
ifconfig_em1_ipv6="inet6 2a00:5884::1/64"

# CARP
ifconfig_em1_alias0="inet6 fe80::204:092:100:1/64 vhid 2 advskew 1 pass passv6"

hostname="budic.cogent-rns.grifon.fr"
# LAN
ifconfig_re1="inet 89.234.186.6 netmask 255.255.255.128"
ifconfig_re1_ipv6="inet6 2a00:5884::6/64"

# CARP
ifconfig_re1_alias0="inet6 fe80::204:092:100:1/64 vhid 2 advskew 10 pass passv6"

Nous redémarrons ensuite les interfaces :

root@nominoe:~ % service netif restart em1

root@budic:~ % service netif restart re1

Ce qui nous donne ceci :

alarig@nominoe:~ % ifconfig em1
em1: flags=8943 metric 0 mtu 1500
	options=4019b
	ether 00:15:17:39:f0:1b
	inet 89.234.186.7 netmask 0xffffff80 broadcast 89.234.186.127
	inet6 fe80::215:17ff:fe39:f01b%em1 prefixlen 64 scopeid 0x2
	inet6 2a00:5884::1 prefixlen 64
	inet6 fe80::204:92:100:1%em1 prefixlen 64 scopeid 0x2 vhid 2
	nd6 options=21
	media: Ethernet autoselect (100baseTX )
	status: active
	carp: MASTER vhid 2 advbase 1 advskew 1

alarig@budic:~ % ifconfig re1
re1: flags=8943 metric 0 mtu 1500
	options=8209b
	ether 00:0d:b9:3a:24:b9
	inet 89.234.186.6 netmask 0xffffff80 broadcast 89.234.186.127 
	inet6 fe80::20d:b9ff:fe3a:24b9%re1 prefixlen 64 scopeid 0x2 
	inet6 2a00:5884::6 prefixlen 64 
	inet6 fe80::204:92:100:1%re1 prefixlen 64 scopeid 0x2 vhid 2 
	nd6 options=21
	media: Ethernet autoselect (100baseTX )
	status: active
	carp: BACKUP vhid 2 advbase 1 advskew 10

CARP IPv4

Et c’est là où c’est subtil, c’est qu’en IPv4 il faut ajouter alias et avoir un numéro d’alias d’interface différent. Aussi, on avait le même mot de passe en IPv4 et en IPv6 avant, je ne sais pas si le fait d’en avoir un différent a changé les choses ou pas, dans le doute je le garde. On a aussi inversé l’ordre IPv4/IPv6 dans la conf (avant l’IPv4 était configuré en premier).

hostname="nominoe.grifon.fr"
# LAN
ifconfig_em1="inet 89.234.186.7 netmask 255.255.255.128"
ifconfig_em1_ipv6="inet6 2a00:5884::1/64"

# CARP
ifconfig_em1_alias0="inet6 fe80::204:092:100:1/64 vhid 2 advskew 1 pass passv6"
ifconfig_em1_alias1="inet vhid 1 advskew 1 pass passv4 alias 89.234.186.1/32"

hostname="budic.cogent-rns.grifon.fr"
# LAN
ifconfig_re1="inet 89.234.186.6 netmask 255.255.255.128"
ifconfig_re1_ipv6="inet6 2a00:5884::6/64"

# CARP
ifconfig_re1_alias0="inet6 fe80::204:092:100:1/64 vhid 2 advskew 10 pass passv6"
ifconfig_re1_alias1="inet vhid 1 advskew 10 pass passv4 alias 89.234.186.1/32"

Nous redémarrons ensuite les interfaces :

root@nominoe:~ % service netif restart em1

root@budic:~ % service netif restart re1

Ce qui nous donne ceci :

alarig@nominoe:~ % ifconfig em1
em1: flags=8943 metric 0 mtu 1500
	options=4019b
	ether 00:15:17:39:f0:1b
	inet 89.234.186.7 netmask 0xffffff80 broadcast 89.234.186.127
	inet6 fe80::215:17ff:fe39:f01b%em1 prefixlen 64 scopeid 0x2
	inet6 2a00:5884::1 prefixlen 64
	inet 89.234.186.1 netmask 0xffffffff broadcast 89.234.186.1 vhid 1
	inet6 fe80::204:92:100:1%em1 prefixlen 64 scopeid 0x2 vhid 2
	nd6 options=21
	media: Ethernet autoselect (100baseTX )
	status: active
	carp: MASTER vhid 1 advbase 1 advskew 1
	carp: MASTER vhid 2 advbase 1 advskew 1

alarig@budic:~ % ifconfig re1
re1: flags=8943 metric 0 mtu 1500
	options=8209b
	ether 00:0d:b9:3a:24:b9
	inet 89.234.186.6 netmask 0xffffff80 broadcast 89.234.186.127
	inet 89.234.186.1 netmask 0xffffffff broadcast 89.234.186.1 vhid 1
	inet6 fe80::20d:b9ff:fe3a:24b9%re1 prefixlen 64 scopeid 0x2
	inet6 2a00:5884::6 prefixlen 64
	inet6 fe80::204:92:100:1%re1 prefixlen 64 scopeid 0x2 vhid 2
	nd6 options=21
	media: Ethernet autoselect (100baseTX )
	status: active
	carp: BACKUP vhid 1 advbase 1 advskew 10
	carp: BACKUP vhid 2 advbase 1 advskew 10

Conclusion

Alors, pourquoi il faut des subtilités en IPv4 quand on met de l’IPv6 en plus, ça je ne sais pas… Mais une fois qu’on l’accepte, ça marche bien. Ceci dit, si quelqu’un a une explication je suis preneur.

Voici les docs que j’ai utilisé pour faire marcher tout ça. La doc OpenBSD est plus pour comprendre le protocole, l’implémentation est différente sous FreeBSD.

Plugin munin pour grapher les routes de bird

2017-03-30T09:51:47+02:00

Présentation

Voici un script que j’ai écrit dans le cade de l’association grifon afin de savoir quel est le nombre de routes que nous avons pour chaque transitaire (chacun représenté par une session BGP), et de voir l’évolution dans le temps. Nous avons déjà un munin, j’ai donc écrit un scrit qu’il peut comprendre afin de ne pas avoir à gérer la partie rrd.

Si vous voulez des exemples, voici le graph IPv4 et le graph IPv6.

Si vous voyez des améliorations, n’hésitez pas à m’envoyer un mail :) (l’adresse est dans la licence)

Pour l’installation, il faut faire comme pour tout plugin munin. Il faut juste que le plugin tourne en root car le socket de bird n’est accessible que par root.

panoramix ~ # mkdir -p /usr/libexec/munin/plugins/
panoramix ~ # wget -O /usr/libexec/munin/plugins/bird_ https://git.grifon.fr/alarig/munin-bird/raw/branch/master/bird_
panoramix ~ # chmod +x /usr/local/libexec/munin/plugins/bird_
panoramix ~ # ln -s /usr/local/libexec/munin/plugins/bird_ /etc/munin/plugins/bird_v4
panoramix ~ # ln -s /usr/local/libexec/munin/plugins/bird_ /etc/munin/plugins/bird_v6
panoramix ~ # vim /etc/munin/plugin-conf.d/bird.conf
[bird*]
user root

Code

Il est disponible sur le git de grifon.

Comment monter un point d’échange, partie technique : un serveur de routes avec bird

2017-03-20T11:47:56+01:00

Présentation d’un point d’échange

Sur Internet, il y a globalement deux façons de parler aux autres opérateurs : soit en passant par du peering, soit en passant par un transitaire.
Un transitaire est un opérateur branché à beaucoup de monde qui se charge d’acheminer nos paquets vers le reste d’Internet et de relayer nos annonces BGP. Le contrat que l’on passe avec ce type d’opérateur est très généralement payant.
Un peering est un contrat entre deux opérateurs permettant de s’échanger du trafic entre eux (et éventuellement leurs clients), mais seulement. Bien que l’on atteint beaucoup moins de monde avec cette session BGP, l’intérêt est que ce type de contrat est très généralement gratuit pour les deux parties (si on oublie les frais annexes, comme la cross-connection). Pour que cela soit possible, ils faut que les deux opérateurs aient un câble entre eux. Comme il est très compliqué de se brancher avec tout le monde, il est très courant de voir des structure se chargeant de brancher beaucoup de monde entre eux, c’est que l’on appelle un point d’échange internet, souvent abrégé en IX ou IXP pour Internet eXchange Point.

Mais là, nous rencontrons un autre problème, le nombre de sessions BGP pour que tout le monde s’échange des routes. Soit on a un serveur de routes central, qui reçoit les annonces de tout le monde et les redistribue, ce qui permet à chaque participant à l’IX de ne monter une session BGP qu’avec le serveur de routes. Soit, il faudra que chaque participant monte une session avec chaque autre ; dans ce cas le nombre de sessions augmente au carré du nombre de participants, ce n’est pas envisageable sur le long terme.

Notez bien que je ne parle ici que du serveur de routes, quand on en arrive là, c’est que l’on a déjà reçu ses ressources RIPE afin d’adresser votre LAN d’interconnexion et surtout que l’on a du monde à brancher.

Notre serveur de route avec bird

Ici, bird ne va servir qu’à recevoir des routes et à les redistribuer, il est complètement inutile de les installer dans la table de routage du kernel. Un serveur de route n’est pas un routeur.
Toute la configuration de bird se fait dans /etc/bird.conf en IPv4 et dans /etc/bird6.conf. Cette configuration est tirée de ce que j’ai fait pour BreizhIX, l’ASN est 206165, le range IPv4 est 185.1.89.0/24 et le range IPv6 est 2001:7f8:b1::/64.

Configuration globale

Ici, c’est ce que nous retrouvons dans quasi toutes les configurations bird.

# Configure logging
log syslog { warning, error, fatal, bug };

# Turn on global debugging of all protocols
# debug protocols all;


# Override router ID and store ASN
router id 185.1.89.1;
define myasn = 206165;


#####################
# GENERAL PROTOCOLS #
#####################
# This pseudo-protocol watches all interface up/down events.
protocol device {
	# Scan interfaces every 5 seconds
        scan time 5;
}

Fonctions pour les filtres

Ces fonctions seront utilisées plus tard afin de filtrer les préfixes reçus par chaque pair BGP.

function check_import(int peeras; ip nexthop)
  prefix set martians;
  int set reserved_asn;
  prefix set our_prefixes;
{
    martians = [ 10.0.0.0/8+, 100.64.0.0/10+,
        127.0.0.0/8+, 169.254.0.0/16+, 172.16.0.0/12+,
        192.0.0.0/24+, 192.0.2.0/24+, 192.168.0.0/16+,
        198.18.0.0/15+, 198.51.100.0/24+, 203.0.113.0/24+,
        224.0.0.0/4+, 240.0.0.0/4+, 255.255.255.255/32 ];

    reserved_asn = [ 0, 64297..131071, 4200000000..4294967294, 4294967295 ];

    # Avoid too short and too long prefixes
    if (net.len < 8) || (net.len > 24) then return false;

    # Avoid 0.0.0.0/X (default route + 0.0.0.0/8)
    if net.ip = 0.0.0.0 then return false;

    # Avoid reserved networks
    if net ~ martians then return false;

    # Remove our prefixes. Only us can announce them
    # Remove also our interconnection prefixes. We are directly connected.
    if net ~ 185.1.89.0/24 then return false;

    # Check that the next AS is our neighbour's.
    # Same for next-hop
    if bgp_path.first != peeras then return false;
    if bgp_next_hop != nexthop then return false;

    # AS_PATH too long (2 because a member could re-annonce its clients on the
    # IXP)
    if bgp_path.len > 2 then return false;

    # Don't accept if path contains a reserved AS
    # Disabled because it removes legit prefixes
    # if bgp_path ~ reserved_asn then return false;

    return true;
}

# In;  each prefix annonced by peer
# Out: prefixes specified (drop all the rest)
function bgp_filter_customer_in (prefix set customer_prefix) {
	return (net ~ customer_prefix);
}

Gabarit de configuration

Ce bout de configuration nous évitera de le répéter pour chaque pair alors qu’il ne changera jamais.
Ce qui change par rapport à un pair BGP classique est le rs client qui indique à bird de ne pas insérer l’ASN du pair dans l’AS path lors de l’export de la route à un autre pair.

template bgp PEERS {
	local as myasn;
	import keep filtered;
	import all;
	export all;
	import limit 100 action restart;
	rs client;
	source address 185.1.89.1;
}

Définition des pairs

Je ne prends qu’un routeur de grifon en exemple, mais nous retrouvons une configuration de ce type pour chaque pair. L’ASN est 204092, l’IP d’interconnexion est 185.1.89.10 et le réseau annoncé est 89.234.186.0/24.

filter bgp_filter_grifon_nominoe_in {
	if (check_import(204092, 185.1.89.10) &&
	    bgp_filter_customer_in([ 89.234.186.0/24 ])) then {
	    	accept;
	} else {
		reject "Prefix filtered for Grifon";
	}
}

protocol bgp bgp_grifon_nominoe from PEERS {
	description "Grifon nominoe";
	neighbor 185.1.89.10 as 204092;
	import filter bgp_filter_grifon_nominoe_in;
}

Résultat final

De cette façon, nous avons bien un échange de route entre les pairs, sans les installer dans notre noyau.

panoramix ~ # birdc sh pr all
BIRD 1.6.3 ready.
name     proto    table    state  since       info
device1  Device   master   up     2017-03-19  
  Preference:     240
  Input filter:   ACCEPT
  Output filter:  REJECT
  Routes:         0 imported, 0 exported, 0 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              0          0          0          0          0
    Import withdraws:            0          0        ---          0          0
    Export updates:              0          0          0        ---          0
    Export withdraws:            0        ---        ---        ---          0

bgp_awedia BGP      master   up     19:32:18    Established   
  Description:    awedia
  Preference:     100
  Input filter:   ACCEPT
  Output filter:  ACCEPT
  Import limit:   100
    Action:       restart
  Routes:         2 imported, 0 filtered, 1 exported, 2 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              4          0          0          2          2
    Import withdraws:            0          0        ---          0          0
    Export updates:              3          2          0        ---          1
    Export withdraws:            0        ---        ---        ---          0
  BGP state:          Established
    Neighbor address: 185.1.89.11
    Neighbor AS:      61198
    Neighbor ID:      89.234.151.5
    Neighbor caps:    refresh AS4
    Session:          external route-server AS4
    Source address:   185.1.89.1
    Route limit:      2/100
    Hold timer:       153/180
    Keepalive timer:  50/60

bgp_grifon_nominoe BGP      master   up     2017-03-19  Established   
  Description:    Grifon nominoe
  Preference:     100
  Input filter:   bgp_filter_grifon_nominoe_in
  Output filter:  ACCEPT
  Import limit:   100
    Action:       restart
  Routes:         1 imported, 0 filtered, 3 exported, 0 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              3          0          1          0          2
    Import withdraws:      1262772          0        ---    1262772          1
    Export updates:             15          1          0        ---         14
    Export withdraws:            9        ---        ---        ---          9
  BGP state:          Established
    Neighbor address: 185.1.89.10
    Neighbor AS:      204092
    Neighbor ID:      89.234.186.7
    Neighbor caps:    refresh enhanced-refresh restart-aware AS4
    Session:          external route-server AS4
    Source address:   185.1.89.1
    Route limit:      1/100
    Hold timer:       205/240
    Keepalive timer:  44/80

bgp_grifon_budic BGP      master   up     2017-03-19  Established   
  Description:    Grifon budic
  Preference:     100
  Input filter:   bgp_filter_grifon_budic_in
  Output filter:  ACCEPT
  Import limit:   100
    Action:       restart
  Routes:         1 imported, 0 filtered, 2 exported, 1 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              3          0          0          0          3
    Import withdraws:      1262752          0        ---    1262752          0
    Export updates:              9          3          0        ---          6
    Export withdraws:            4        ---        ---        ---          4
  BGP state:          Established
    Neighbor address: 185.1.89.13
    Neighbor AS:      204092
    Neighbor ID:      89.234.186.6
    Neighbor caps:    refresh enhanced-refresh restart-aware AS4
    Session:          external route-server AS4
    Source address:   185.1.89.1
    Route limit:      1/100
    Hold timer:       164/240
    Keepalive timer:  30/80

panoramix ~ # birdc sh route all
BIRD 1.6.3 ready.
154.43.33.0/24     via 185.1.89.11 on eth2 [bgp_awedia 19:32:18] * (100) [AS61198i]
	Type: BGP unicast univ
	BGP.origin: IGP
	BGP.as_path: 61198
	BGP.next_hop: 185.1.89.11
	BGP.local_pref: 100
89.234.186.0/24    via 185.1.89.13 on eth2 [bgp_grifon_budic 19:06:23] * (100) [AS204092i]
	Type: BGP unicast univ
	BGP.origin: IGP
	BGP.as_path: 204092
	BGP.next_hop: 185.1.89.13
	BGP.local_pref: 100
                   via 185.1.89.10 on eth2 [bgp_grifon_nominoe 19:04:29] (100) [AS204092i]
	Type: BGP unicast univ
	BGP.origin: IGP
	BGP.as_path: 204092
	BGP.next_hop: 185.1.89.10
	BGP.local_pref: 100
89.234.151.0/24    via 185.1.89.11 on eth2 [bgp_awedia 19:32:18] * (100) [AS61198i]
	Type: BGP unicast univ
	BGP.origin: IGP
	BGP.as_path: 61198
	BGP.next_hop: 185.1.89.11
	BGP.local_pref: 100
panoramix ~ # ip route list 
default via 89.234.186.209 dev eth0  metric 2 
89.234.186.208/28 dev eth0  proto kernel  scope link  src 89.234.186.213 
172.16.0.0/24 dev eth3  proto kernel  scope link  src 172.16.0.2 
185.1.89.0/24 dev eth2  proto kernel  scope link  src 185.1.89.1

Et vu du côté d’un participant à l’IX, nous allons bien voir l’autre participant directement, sans avoir l’ASN de l’IX dans notre chemin :

alarig@nominoe:~ % birdc show route all protocol bgp_breizhix
BIRD 1.5.0 ready.
154.43.33.0/24     via 185.1.89.11 on em0.22 [bgp_breizhix 19:33:49 from 185.1.89.1] * (100) [AS61198i]
	Type: BGP unicast univ
	BGP.origin: IGP
	BGP.as_path: 61198
	BGP.next_hop: 185.1.89.11
	BGP.local_pref: 100
89.234.151.0/24    via 185.1.89.11 on em0.22 [bgp_breizhix 19:33:49 from 185.1.89.1] * (100) [AS61198i]
	Type: BGP unicast univ
	BGP.origin: IGP
	BGP.as_path: 61198
	BGP.next_hop: 185.1.89.11
	BGP.local_pref: 100

Du DNSSEC sur ses reverses

2017-03-16T19:31:28+01:00

Parce que bon, soyons franc, c’est inutile donc indispensable (presque autant que le module puzzle de VLC).

Je ne vous rappelle pas comment jouer avec DNSSEC, je l’ai déjà fait pour knot et nsd. Dites vous juste qu’une zone reverse est exactement la même chose que tout autre domaine, on met juste des PTR à la place des A/AAAA.

Je vais donc simplement me contenter d’expliquer comment publier votre enregistrement chez votre RIR. Je vais prendre l’exemple du RIPE, car les IPs que je gère dépendent du RIPE.
Pour commencer, il faut se rendre sur https://apps.db.ripe.net/search/query.html et vous connecter. Une fois ceci fait, recherchez le nom de domaine qui correspond à votre range IP, comme par exemple 1.b.0.0.8.f.7.0.1.0.0.2.ip6.arpa (créez le s’il n’existe pas, mais j’ose espérer que vous savez déjà gérer des reverses si vous lisez cet article) et cliquez sur le bouton « update ». Ensuite, ajoutez un champs « ds-rdata » en cliquant sur l’un des plus à droite des champs déjà existant. Dans ce champs vous devez rentrer votre DS sous la forme ${Keytag} ${Algorithm} ${Digest type} ${Digest}, exactement dans le même ordre qu’un DS dans une zone DNS. Par exemple, si j’obtiens cette sortie :

ns ~ # ods-ksmutil key export --zone 1.b.0.0.8.f.7.0.1.0.0.2.ip6.arpa --ds

;active KSK DS record (SHA1):
1.b.0.0.8.f.7.0.1.0.0.2.ip6.arpa.	3600	IN	DS	14966 8 1 f700670f65c039315fff4a18d72f69a89755f4b4

;active KSK DS record (SHA256):
1.b.0.0.8.f.7.0.1.0.0.2.ip6.arpa.	3600	IN	DS	14966 8 2 adacef8b735f8399e3bf03950baec04e87ed5a5753d28cabc4525b6212cc2e2e

je vais mettre

14966 8 2
     adacef8b735f8399e3bf03950baec04e87ed5a5753d28cabc4525b6212cc2e2e

dans ce champs. SHA1 étant déprécié, ce n’est pas la peine de publier ce DS.
Vous devez alors avoir quelque chose qui ressemble à ça :

Une fois le formulaire validé, vous devriez avoir le drapeau ad pour authenticate data, ce qui indique que la validation DNSSEC est bonne sur une requête de reverse DNS, comme sur les deux requêtes suivante (voir la ligne flags:) :

alarig@pikachu ~ % dig -x 185.1.89.10

; <<>> DiG 9.11.0-P3 <<>> -x 185.1.89.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25966
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;10.89.1.185.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
10.89.1.185.in-addr.arpa. 3600	IN	PTR	grifon-nominoe.breizh-ix.net.

;; AUTHORITY SECTION:
89.1.185.in-addr.arpa.	3600	IN	NS	ns.breizh-ix.net.
89.1.185.in-addr.arpa.	3600	IN	NS	pokedex.swordarmor.fr.

;; Query time: 851 msec
;; SERVER: 89.234.186.4#53(89.234.186.4)
;; WHEN: Thu Mar 16 20:37:50 CET 2017
;; MSG SIZE  rcvd: 147

alarig@pikachu ~ % dig -x 2001:7f8:b1::a

; <<>> DiG 9.11.0-P3 <<>> -x 2001:7f8:b1::a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63930
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.b.0.0.8.f.7.0.1.0.0.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.b.0.0.8.f.7.0.1.0.0.2.ip6.arpa. 3600 IN PTR grifon-nominoe.breizh-ix.net.

;; AUTHORITY SECTION:
1.b.0.0.8.f.7.0.1.0.0.2.ip6.arpa. 3600 IN NS	ns.breizh-ix.net.
1.b.0.0.8.f.7.0.1.0.0.2.ip6.arpa. 3600 IN NS	pokedex.swordarmor.fr.

;; Query time: 270 msec
;; SERVER: 2a00:5884::7#53(2a00:5884::7)
;; WHEN: Thu Mar 16 20:38:00 CET 2017
;; MSG SIZE  rcvd: 195

BGP avec bird : favorisation d’un fournisseur par rapport à un autre en cas d’égalité sur l’AS path

2017-03-09T15:25:38+01:00

Introduction à BGP

C’est la première fois que je parle de BGP, ça me semble donc être une bonne idée de dire ce que c’est. Il s’agit d’un protocole de niveau 7 se basant sur TCP et permettant un échange dynamique de routes entre des entités sur Internet possédant un ASN (Autonomous System Number). Son nom complet est Border Gateway Protocol.
À la différence d’autres protocoles de routage dynamique, BGP n’a pas de métrique simple mais tout un tas de critères que l’on évalue séquentiellement et on s’arrête dès qu’il n’y a plus égalité. Voici ce que donne la doc de bird :

Préférer les routes avec la plus grande préférence locale
Préférer les routes avec le chemin d’AS le plus court
Préférer l’origine IGP par rapport à EGP et incomplète
Préférer la plus faible valeur du discriminant des sorties multiples
Préférer les routes reçues en eBGP à celles reçues en iBGP
Préférer les routes avec la plus petite distance interne
Préférer les routes du routeur avec le plus petit identifiant

Notre cas

Chez grifon on a deux fournisseurs de transit : cogent et quantic télécom. On a donc une session BGP entre chacun de nos routeurs vers leurs routeurs.
Cogent étant un opérateur bien plus gros que quantic, ils gagnaient très souvent en raison de leur capacité à se brancher directement avec beaucoup de monde, ce qui leur permet donc d’avoir un AS path plus court. Nous nous retrouvions alors avec 20651 routes pour quantic contre 608776 pour cogent.

Quantic a un très gros avantage, on peut facilement boire des bières avec eux. De plus, ils sont normands alors que cogent est américain. Ça m’a donc semblé logique de les favoriser, en plus de pouvoir apprendre comment faire.

Par contre, je ne voulais pas favoriser quantic dans tous les cas afin de ne pas amputer sur la qualité du réseau.

La solution

Nos différents pairs BGP sont définis par rapport à des templates :

template bgp UPSTREAM
{
    local as myasn;

    # Be able to see filtered routes with "sh route filtered" command
    import keep filtered;

    # Protect ourselves from massive routes leaks
    receive limit 640000 action block;

    # Announce only our IP allocations
    export where proto = "static_grifon_allocations";
    export limit 1 action disable;
}

Et ensuite, nous les déclarons depuis ce template, avec un filtre pour chaqun :

filter bgp_filter_quantic_in
{
    if (check_import(198507, 169.254.1.1)) then
    {
        # Here we can set localpref or remove a prefix, for example

        accept;
    }
    else
    {
        reject "Prefix filtered IN quantic";
    }
}
protocol bgp bgp_quantic from UPSTREAM
{
    description "quantic";

    neighbor 169.254.1.1 as 198507;

    # Local address we use to establish the BGP session
    source address 169.254.1.3;

    # We cannot use TCP-MD5 auth because we use a poorly designed OS ;)
    # password=''

    # Accept all routes from Cogent except bogons and other bad stuff
    import filter bgp_filter_quantic_in;
}

Avec cette configuration, tous les critères de choix de BGP était égaux en cas de longueur d’AS égale sauf le dernier (router-id) qui faisait gagner cogent.
Nous sommes ici dans un cas où on peut faire gagner quantic sans perdre en latence. Mais comme dit plus haut, je ne veux faire gagner quantic que dans ce cas, il n’est donc pas possible d’utiliser la localpref. Il faut donc chercher dans les critère suivants :

Les deux routes sont d’origine IGP, on ne peut rien y faire,
les deux routes ont la même MED, ça on peut le changer.

Jouer sur la MED

Pour faire varier ce paramètre, il faut commencer par le définir dans le filtre BGP correspondant à quantic :

filter bgp_filter_quantic_in
{
    if (check_import(198507, 169.254.1.1)) then
    {
        # Here we can set localpref or remove a prefix, for example
        bgp_med = 50;
        accept;
    }
    else
    {
        reject "Prefix filtered IN quantic";
    }
}

Et si nous rechargeons la configuration de bird, rien ne se passe… Pourquoi ? Parce que par défaut bird ne prend pas ce paramètre en compte dans le cas de routes reçues d’ASes différents, c’est écrit dans la documentation :

med metric switch
Enable comparison of MED attributes (during best route selection) even between routes received from different ASes. This may be useful if all MED attributes contain some consistent metric, perhaps enforced in import filters of AS boundary routers. If this option is disabled, MED attributes are compared only if routes are received from the same AS (which is the standard behavior).
Default: off.

Il faut alors, en plus de cela, ajouter la gestion de la MED dans notre template de configuration :

template bgp UPSTREAM
{
    local as myasn;

    # Be able to see filtered routes with "sh route filtered" command
    import keep filtered;

    # Protect ourselves from massive routes leaks
    receive limit 640000 action block;

    # Announce only our IP allocations
    export where proto = "static_grifon_allocations";
    export limit 1 action disable;

        med metric on;
}

Et là, une fois la configuration rechargée, nous passons bien par quantic lorsque l’AS path est égal, tout en gardant le mécanisme de sélection normal autrement :

root@budic:~ # birdc show route all for 37.187.103.228
BIRD 1.6.0 ready.
37.187.0.0/16      via 169.254.1.1 on re0.21 [bgp_quantic 14:53:28] * (100) [AS16276i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 198507 16276
        BGP.next_hop: 169.254.1.1
        BGP.med: 50
        BGP.local_pref: 100
                   via 149.6.72.97 on re0.20 [bgp_cogent 14:51:07] (100) [AS16276i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 174 16276
        BGP.next_hop: 149.6.72.97
        BGP.med: 15051
        BGP.local_pref: 100
        BGP.community: (174,21101) (174,22008)
                   unreachable [ibgp_nominoe 2017-02-09 from 89.234.186.7] (100/-) [AS16276i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 174 16276
        BGP.next_hop: 89.234.186.1
        BGP.med: 15051
        BGP.local_pref: 100
        BGP.community: (174,21101) (174,22008)
root@budic:~ # birdc show route all for 89.234.141.1
BIRD 1.6.0 ready.
89.234.141.0/24    via 149.6.72.97 on re0.20 [bgp_cogent 14:50:16] * (100) [AS60630i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 174 60630
        BGP.next_hop: 149.6.72.97
        BGP.med: 21051
        BGP.local_pref: 100
        BGP.community: (174,21101) (174,22008)
                   via 169.254.1.1 on re0.21 [bgp_quantic 14:49:45] (100) [AS60630i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 198507 174 60630
        BGP.next_hop: 169.254.1.1
        BGP.med: 50
        BGP.local_pref: 100
        BGP.community: (174,21101) (174,22008)
                   unreachable [ibgp_nominoe 2017-02-09 from 89.234.186.7] (100/-) [AS60630i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 174 60630
        BGP.next_hop: 89.234.186.1
        BGP.med: 21051
        BGP.local_pref: 100
        BGP.community: (174,21101) (174,22008)
root@budic:~ # birdc show route all for 216.66.84.42
BIRD 1.6.0 ready.
216.66.80.0/20     via 169.254.1.1 on re0.21 [bgp_quantic 14:50:27] * (100) [AS6939i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 198507 6939
        BGP.next_hop: 169.254.1.1
        BGP.med: 50
        BGP.local_pref: 100
        BGP.community: (24115,6939)
                   via 149.6.72.97 on re0.20 [bgp_cogent 14:50:56] (100) [AS6939i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 174 1299 6939 6939
        BGP.next_hop: 149.6.72.97
        BGP.med: 14040
        BGP.local_pref: 100
        BGP.community: (174,21100) (174,22008)
                   unreachable [ibgp_nominoe 2017-03-08 from 89.234.186.7] (100/-) [AS6939i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 198507 6939
        BGP.next_hop: 89.234.186.1
        BGP.local_pref: 100
        BGP.community: (24115,6939)

Conclusion

Nous nous retrouvons maintenant avec 49576 routes pour quantic (contre 20651 précédemment) et 579833 pour cogent (contre 608776 précédemment). Et cela se voit très bien sur le graph :

knot : reverse automatique et DNSSEC

2016-12-10T12:38:50+01:00

Reverse simple

Il peut arriver, pour une raison X ou Y, que vous ayez envie de servir des reverses DNS sur une grande plage d’adresses IP. Par exemple, admettons que votre FAI vous route tout un bloc, vous n’allez pas entrer chaque reverse pour chaque machine qui reçoit une IP.

knot a un module nommé mod-synth-record qui permet cela. Son utilisation est relativement simple. On commence par définir deux zones basiques. Une pour servir les PTR, et l’autre pour servir les A/AAAA associés. En effet, un reverse doit marcher dans les deux sens.
Zone de résolution directe :

@	864000	IN	SOA	tregon-grifon.swordarmor.fr. hostmaster.swordarmor.fr. (
		2 3600 900 1209600 43200 )

	864000	IN	NS	tregon-grifon.swordarmor.fr.

		IN	AAAA	2a00:5884:8316::1
			A	89.234.186.16

Zone de résolution inverse :

@	864000	IN	SOA	tregon-grifon.swordarmor.fr. hostmaster.swordarmor.fr. (
		2 3600 900 1209600 43200 )
	864000	IN	NS	tregon-grifon.swordarmor.fr.

Ensuite, nous expliquons à knot comment remplir ces deux zones automatiquement :

mod-synth-record:
  - id: tregon-grifon
    type: forward
    prefix: ip6-
    ttl: 400
    network: 2a00:5884:8316::/48

mod-synth-record:
  - id: tregon-grifon-reverse
    type: reverse
    prefix: ip6-
    origin: tregon-grifon.swordarmor.fr
    ttl: 400
    network: 2a00:5884:8316::/48

Puis nous précisons à knot qu’il faut utiliser ces modules pour les deux zones :

  - domain: tregon-grifon.swordarmor.fr
    file: tregon-grifon.swordarmor.fr.zone # Must exist
    module: mod-synth-record/tregon-grifon

  - domain: 6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa
    file: 6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa.zone # Must exist
    module: mod-synth-record/tregon-grifon-reverse

Notre serveur DNS est maintenant en capacité de répondre au A et au PTR :

alarig@pikachu ~ % dig +short -x 2a00:5884:8316::1234 @tregon-grifon.swordarmor.fr
ip6-2a00-5884-8316-0000-0000-0000-0000-1234.tregon-grifon.swordarmor.fr.
alarig@pikachu ~ % dig +short -t AAAA ip6-2a00-5884-8316-0000-0000-0000-0000-1234.tregon-grifon.swordarmor.fr. @tregon-grifon.swordarmor.fr
2a00:5884:8316::1234

Et nous pouvons même définir des reverses personnalisés en les mettant dans le fichier de zone.

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR tregon-grifon.swordarmor.fr.
6.2.4.c.f.6.5.5.d.7.4.d.0.4.d.f.3.5.6.2 IN PTR pika-tregon.swordarmor.fr.

alarig@pikachu ~ % dig +short -x 2a00:5884:8316::1 @tregon-grifon.swordarmor.fr
tregon-grifon.swordarmor.fr.
alarig@pikachu ~ % dig +short -x 2a00:5884:8316:2653:fd40:d47d:556f:c426 @tregon-grifon.swordarmor.fr
pika-tregon.swordarmor.fr.

Mettons maintenant un peu de DNSSEC

(parce que c’est très important d’avoir du DNSSEC sur un reverse)

Arrivé ici, nous pouvons nous dire que knot va, comme à son habitude, gérer le DNSSEC comme un grand sans rien avoir besoin de toucher.
Alors oui et non. Il va générer les RRSIG pour les RRs que nous avons entré dans notre zone (c’est à dire ici un A, un NS, un SOA, un AAAA, plus le NSEC et le DNSKEY générés par knot), mais pas pour tout ce qui est généré à la volée, nous avons un SERVFAIL au lieu d’une réponse.

alarig@pikachu ~ % dig -t RRSIG tregon-grifon.swordarmor.fr.

; <<>> DiG 9.10.4-P3 <<>> -t RRSIG tregon-grifon.swordarmor.fr.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53081
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tregon-grifon.swordarmor.fr.	IN	RRSIG

;; ANSWER SECTION:
tregon-grifon.swordarmor.fr. 3600 IN	RRSIG	A 13 3 3600 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. YlT/vCMLDyGHwKLoMOdQqENwWTyhphrbBatKhhtvCteTubwBp9FCrf9b /jc0cRM07a321de7kw3cYPD3lfbPYA==
tregon-grifon.swordarmor.fr. 864000 IN	RRSIG	NS 13 3 864000 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. l6HiWFaqz3Hys7aknEHEG6woKJ9xdYqopxNUTOYmMk94733jMnDiH5bx fDKGPjgyVCkbQWfFsJCr/udwnelSaQ==
tregon-grifon.swordarmor.fr. 864000 IN	RRSIG	SOA 13 3 864000 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. OUWibAYe8oyRBWgGyPAxG0etUcGQe1ZEZ+1ywZIi1xQvhWMQy/0B+HNH RyQYYdJ9eXqXPP3uQRyXPTtsa+9KKQ==
tregon-grifon.swordarmor.fr. 3600 IN	RRSIG	AAAA 13 3 3600 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. NIEEeURn0/RH9IqWxGM9W74Gf8UqDh4Bqap0NlZ4XQ+95FpfylAQKxo0 KZUNCDCXCFQ4Rpg/dJH4EhpWw8Pxtw==
tregon-grifon.swordarmor.fr. 43200 IN	RRSIG	NSEC 13 3 43200 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. 6T2+GjrRU8qU/zGNmY8R9bmkNUFGPJuJQP2qkhakV0GeiyseEWA5yPDE /YIELH04KKAE3yrudo8S6xcaQ6DveQ==
tregon-grifon.swordarmor.fr. 864000 IN	RRSIG	DNSKEY 13 3 864000 20161208210625 20161124210625 57104 tregon-grifon.swordarmor.fr. F/jepDBqQriHFUSN8mnkiNZ6l3vP5K8ob44yuHkHBupimIo4S6hvuZXD F7AnbF5GtVsZPDdjA4qumkv1HaiTFQ==

;; Query time: 160 msec
;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1)
;; WHEN: Mon Nov 28 11:02:27 CET 2016
;; MSG SIZE  rcvd: 794

alarig@pikachu ~ % dig -t RRSIG ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr.

; <<>> DiG 9.10.4-P3 <<>> -t RRSIG ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27161
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. IN RRSIG

;; Query time: 457 msec
;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1)
;; WHEN: Mon Nov 28 11:02:33 CET 2016
;; MSG SIZE  rcvd: 100

Mais l’équipe de nic.cz a déjà pensé à tout en développant un autre module qui permet de signer toute une zone à la volée. Il s’agît de mod-online-sign.
Par contre, ce module n’a pas encore été mis à jour pour supporter la nouvelle mouture de gestion DNSSEC, il faut toujours utiliser keymgr en mode de compatibilité (option -l). Il est important de noter que le fichier de zone référencé dans la configuration ne doit pas comporter de signatures DNSSEC et que le système de signature classique doit être désactivé.
Nous avons donc une configuration comme ceci :

template:
  - id: default
    storage: "/var/lib/knot"
    kasp-db: kasp

mod-online-sign:
   - id: default
  - domain: tregon-grifon.swordarmor.fr
    file: tregon-grifon.swordarmor.fr.zone.nodnssec # Must exist
    module: [mod-synth-record/tregon-grifon, mod-online-sign/default]
    dnssec-signing: false

Et nous générons les clés comme à la bonne époque :

eddy ~ # mkdir /var/lib/knot/kasp
eddy ~ # chown knot: /var/lib/knot/kasp/
eddy ~ # su - knot -s /bin/sh 
No directory, logging in with HOME=/
$ cd /var/lib/knot/kasp/
$ keymgr -l init
$ keymgr -l zone add tregon-grifon.swordarmor.fr
$ keymgr -l zone key generate tregon-grifon.swordarmor.fr algorithm ecdsap256sha256 size 256
# je n’ai pas généré de clé pour 6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa. car
# 4.8.8.5.0.0.a.2.ip6.arpa. n’est pas encore signé

Pour finir, nous devons publier le DS dans la zone parente, ainsi que le NS pour la délégation et le glue record, comme toujours en DNS.

tregon-grifon.swordarmor.fr.	10800	A	89.234.186.16
tregon-grifon.swordarmor.fr.	10800	AAAA	2a00:5884:8316::1
tregon-grifon.swordarmor.fr.	10800	NS	tregon-grifon.swordarmor.fr.
tregon-grifon.swordarmor.fr.	10800	DS	(22942 13 2 E4E1B6EFF9D473905D0DA9C5C6CF43D9BC38E73D44E9579723748D8CD8AE3C1C)

Et maintenant, si nous demandons un AAAA autogénéré pour cette zone, nous avons bien le flag ad pour Autentic Data, c’est à dire que la vérification DNSSEC a fonctionné.

alarig@pikachu ~ % dig -t AAAA ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35285
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. 400 IN	AAAA 2a00:5884:8316:2653:fd40:d47d:556f:c427

Redondance

Si vous gérez les reverses d’un range IP un temps soit peu conséquent (on va dire, un /24 d’un FAI par exemple), il est plus que probable que vous vouliez un peu de redondance.

Sachez alors qu’il faudra soit utiliser un autre knot, soit utiliser un autre système de reverse automatique si vous ne voulez pas avoir deux knot pour cette zone. En effet, les enregistrements étant générés à la volée, il n’est pas possible de faire un transfert de la zone complète comme nous en avons l’habitude.

Cependant, il faudra tout de même commencer par avoir une réplication des zones originales.
Sur le master :


remote:
  - id: freebsd
    address: 2a01:cb08:898c:fc00:5054:ff:fe0e:b8e

acl:
  - id: acl_freebsd
    address: 2a01:cb08:898c:fc00:5054:ff:fe0e:b8e
    action: transfer

  - domain: tregon-grifon.swordarmor.fr
    file: tregon-grifon.swordarmor.fr.zone.nodnssec # Must exist
    module: [mod-synth-record/tregon-grifon, mod-online-sign/default]
    dnssec-signing: false
    notify: freebsd
    acl: acl_freebsd

  - domain: 6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa
    file: 6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa.zone.nodnssec # Must exist
    module: [mod-synth-record/tregon-grifon-reverse, mod-online-sign/default]
    dnssec-signing: false
    notify: freebsd
    acl: acl_freebsd

Par rapport à la configuration précédente, nous n’avons fait que ajouter une machine, donner le droit la notifier de la mise à jour de la zone, puis de l’assigner à nos deux zones. Sur cette machine (le slave), nous allons donc configurer le knot :


remote:
  - id: tregon
    address: 2a00:5884:8316::1

acl:
  - id: acl_tregon
    address: 2a00:5884:8316::1
    action: notify

template:
  - id: default
    storage: "/var/db/knot"
    kasp-db: kasp

mod-synth-record:
  - id: tregon-grifon
    type: forward
    prefix: ip6-
    ttl: 400
    network: 2a00:5884:8316::/48

mod-synth-record:
  - id: tregon-grifon-reverse
    type: reverse
    prefix: ip6-
    origin: tregon-grifon.swordarmor.fr
    ttl: 400
    network: 2a00:5884:8316::/48

mod-online-sign:
   - id: default

  - domain: tregon-grifon.swordarmor.fr
    file: tregon-grifon.swordarmor.fr.zone
    master: tregon
    acl: acl_tregon
    module: [mod-synth-record/tregon-grifon, mod-online-sign/default]

  - domain: 6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa
    file: 6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa.zone
    master: tregon
    acl: acl_tregon
    module: [mod-synth-record/tregon-grifon-reverse, mod-online-sign/default]

Nous voyons ici qu’il faut également répéter la configuration de mod-synth-record et de mod-online-sign. En effet, tous les enregistrements issus de ces modules sont générés à la volée, ils ne sont donc pas à proprement parler dans la zone. Le daemon knot va les recalculer à chaque requête, alors que pour une zone classique, il se contente d’aller lire le fichier.

Aussi, pour que le DNSSEC soit disponible sur les deux serveurs, il faut avoir une copie de la KSK sur chaque serveur : scp -r /var/lib/knot/kasp/ root@freebsd.swordarmor.fr:/var/db/knot/.
Ici j’ai copié tout le dossier car je n’ai pas d’autre clé, mais il est plus sage de ne copier que les fichiers nécessaires.

Si nous testons, nous voyons que notre nouveau serveur répond bien les résultats attendus, accompagnés de leur RRSIG :

alarig@pikachu ~ % dig +dnssec -x 2a00:5884:8316:2653:fd40:d47d:556f:c426 @freebsd.swordarmor.fr                  

; <<>> DiG 9.10.4-P4 <<>> +dnssec -x 2a00:5884:8316:2653:fd40:d47d:556f:c426 @freebsd.swordarmor.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59166
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;6.2.4.c.f.6.5.5.d.7.4.d.0.4.d.f.3.5.6.2.6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
6.2.4.c.f.6.5.5.d.7.4.d.0.4.d.f.3.5.6.2.6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa. 3600 IN PTR pika-tregon.swordarmor.fr.
6.2.4.c.f.6.5.5.d.7.4.d.0.4.d.f.3.5.6.2.6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa. 3600 IN RRSIG	PTR 13 34 3600 20170114212255 20170113202255 3655 6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa. 0YE68evOCjovGMoY8X/32mvWjAdEkEod/SjXPMTS5YGUvmH+gvo3R/hP H6yxOtMYygb+ZtXKakIVrIH65kV0GA==

;; Query time: 52 msec
;; SERVER: 2a01:cb08:898c:fc00:5054:ff:fe0e:b8e#53(2a01:cb08:898c:fc00:5054:ff:fe0e:b8e)
;; WHEN: Fri Jan 13 21:22:56 CET 2017
;; MSG SIZE  rcvd: 268

alarig@pikachu ~ % dig +dnssec -x 2a00:5884:8316::1234 @freebsd.swordarmor.fr      

; <<>> DiG 9.10.4-P4 <<>> +dnssec -x 2a00:5884:8316::1234 @freebsd.swordarmor.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13829
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa. 400 IN PTR ip6-2a00-5884-8316-0000-0000-0000-0000-1234.tregon-grifon.swordarmor.fr.
4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa. 400 IN RRSIG PTR 13 34 400 20170114210829 20170113200829 3655 6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa. QxPtzxT62oilXha9Ns4EyfOtj8fCBqhCCxI0SfKb4Yol61c2Pjum/DcZ fBIiMWdN+7VT6/Q2vs6S8uKjd1THOA==

;; Query time: 55 msec
;; SERVER: 2a01:cb08:898c:fc00:5054:ff:fe0e:b8e#53(2a01:cb08:898c:fc00:5054:ff:fe0e:b8e)
;; WHEN: Fri Jan 13 21:08:29 CET 2017
;; MSG SIZE  rcvd: 314

alarig@pikachu ~ % dig +dnssec -t AAAA ip6-2a00-5884-8316-0000-0000-0000-0000-1234.tregon-grifon.swordarmor.fr. @freebsd.swordarmor.fr

; <<>> DiG 9.10.4-P4 <<>> +dnssec -t AAAA ip6-2a00-5884-8316-0000-0000-0000-0000-1234.tregon-grifon.swordarmor.fr. @freebsd.swordarmor.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58686
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ip6-2a00-5884-8316-0000-0000-0000-0000-1234.tregon-grifon.swordarmor.fr. IN AAAA

;; ANSWER SECTION:
ip6-2a00-5884-8316-0000-0000-0000-0000-1234.tregon-grifon.swordarmor.fr. 400 IN	AAAA 2a00:5884:8316::1234
ip6-2a00-5884-8316-0000-0000-0000-0000-1234.tregon-grifon.swordarmor.fr. 400 IN	RRSIG AAAA 13 4 400 20170114212107 20170113202107 22942 tregon-grifon.swordarmor.fr. NpU/Q+vC3BzR1iLeqIWEWNlo0MMe+aUxDeVIkCd3Z5wUnwgmAsz9oXaS DjkGEfFvR3Wpbgp/RbjDlPNu7qhxqA==

;; Query time: 43 msec
;; SERVER: 2a01:cb08:898c:fc00:5054:ff:fe0e:b8e#53(2a01:cb08:898c:fc00:5054:ff:fe0e:b8e)
;; WHEN: Fri Jan 13 21:21:08 CET 2017
;; MSG SIZE  rcvd: 251

Documentation officielle de knot

Automatic reverse records
online-sign

Comprendre les grands principes du SSL/TLS

2016-09-11T21:54:12+02:00

Histoire et terminologie

SSL est un acronyme anglais voulant dire Secure Sockets Layer. Il a été initialement développé par Netscape Communications (qui a développé Netscape Navigator qui a servi de base à Mozilla pour firefox). Il existe en trois versions : SSLv1, SSLv2 et SSLv3. Aucune de ces versions n’est plus utilisée de nos jours (ou alors par des gens inconscients) car il est possible d’utiliser des failles inhérentes au protocole afin de déchiffrer le trafic.
Il a ensuite été remplacé par TLS (pour Transport Layer Security). Ce dernier existe également en trois versions : TLSv1.0, TLSv1.1 et TLSv1.2. Une version 1.3 est actuellement en cours de développement mais encore au stade de brouillon à l’IETF.
Par abus de langage, et comme je vais le faire tout au long de cet article, on utiliser souvent le terme SSL pour parler de TLS.

Cas d’usage

Le SSL est un standard de chiffrement très utilisé sur Internet. Par exemple, vous l’utilisez en visitant ce blog ainsi que tous les sites dont l’URL commence par https://.
Il est également utilisé dans le mail, avec jabber, sur IRC, etc.

Grands principes

Chiffrement

Comme beaucoup de protocoles de chiffrement de nos jours, SSL se base sur de la cryptographie asymétrique, c’est à dire avec une clé publique et une clé privée. La clé publique est le certificat, généré par une autorité de certification comme nous le verrons plus tard et la clé privée est générée (ainsi que le CSR) par l’administrateur du serveur et y reste ; c’est le propre d’une clé privée, sinon elle n’est plus tellement privée et il y a un souci. Comme toujours, la clé publique est dérivée de la clé privée et l’une ne peut pas fonctionner sans l’autre.
Cependant, comme le chiffrement asymétrique coûte cher en ressources, une fois la session établie entre le client et le serveur, une clé symétrique est négociée pour une durée limitée et c’est cette clé qui servira à chiffrer les données qui transitent.
Nous n’utilisons pas une clé symétrique dès le début car dans ce cas, tout le monde devrait connaître cette clé pour déchiffrer du contenu, et donc tout le monde pourrait ré-utiliser cette clé pour se faire passer pour le serveur (et donc intercepter le trafic chiffré et en connaître le contenu).

Authentification

Dans un contexte de chiffrement se pose toujours la question de l’authenticité du pair avec lequel on discute. En effet, ce n’est pas le tout de chiffrer pour empêcher les grandes oreilles de mettre leur nez où elle ne devrait pas, mais encore faut il le faire avec la bonne personne.
Admettons que vous chiffriez une conversation mais en se connectant au mauvais serveur. Ce serveur peut très bien déchiffrer ce qui passe, le lire et le re-chiffrer pour l’envoyer à qui de droit. Tout l’intérêt du chiffrement est donc perdu et personne ne se rendrait compte de la supercherie.
Généralement, on se contente de vérifier l’identité du serveur, mais on peut aussi vérifier celle du client. Dans le cas du serveur, on se base généralement sur le nom de domaine (www.swordarmor.fr pour ce qui nous concerne) et dans le cas du client on se base généralement sur l’adresse mail (alarig@swordarmor.fr en ce qui me concerne).

Afin de répondre à ce problème, nous faisons intervenir un tiers de confiance (sic), ce sont les fameuses CA – pour Certification Autorities en anglais, soit autorités de certification en français. Il s’agit de grands organismes en charge de distribuer – souvent contre finances – des certificats x509 (du nom de la norme qui les défini) aux personnes physiques ou morales qui en font la demande. On dit aussi « signer un certificat ».
Ces organismes ont leur propre certificat déjà enregistré dans les navigateurs (dans le cas du web, mais c’est le cas pour tout client supportant le SSL). Votre certificat ayant été signé par une de ces entités, le navigateur peut vérifier sa validité en établissant une chaîne de confiance. Théoriquement, ça semble sympathique, sauf qu’en fait non. Toute CA enregistrée dans le navigateur peut émettre n’importe quel certificat, y compris des certificats pour des noms de domaines qui ont déjà été singés. Ainsi, une autorité peu scrupuleuse peut parfaitement fournir des certificats valides sans se préoccuper de savoir si la personne qui en fait la demande le fait légitimement ou non. On peut par exemple citer Symantec qui signe des certificats pour les proxy de Blue Coat Systems, ces derniers pouvant donc intercepter le trafic SSL qui y passe ; et on sait que cette entreprise est pour le moins controversée.

Intégrité

SSL est aussi en charge de s’assurer que les données n’ont pas été altérées entre ce que le serveur a envoyé et ce que le client a reçu. En effet, il est nécessaire de s’assurer que les données reçues par le client sont bien celles envoyées par le serveur et qu’elle n’ont pas été modifiées sur le chemin.
C’est là qu’intervient la HMAC. Il s’agît d’un calcul mathématique relativement compliqué se basant sur une fonction de hachage cryptographique combiné avec une clé secrète.

En pratique

Afin de proposer votre site en HTTPS, vous devez disposer d’un HTTPd compatible avec le SSL. C’est le cas de la plupart d’entre eux. Pour ne pas m’éterniser sur des exemples de configuration, je me contenterai de nginx et apache2.

Génération d’un CSR et d’une clé privée

Le CSR est un fichier que devrez envoyer à l’autorité de certification afin qu’elle vous signe un certificat. L’acronyme CSR a pour signification Certificate Signing Request, soit requête de signature de certificat. Ce CSR doit à minima contenir le nom qui doit être certifié (soit le nom DNS du site dans notre cas) mais il est possible d’y ajouter d’autres champs comme la localisation ou l’identité de l’organisation qui demande le certificat. Le FQDN doit être donné à la question « Common Name (e.g. server FQDN or YOUR name) ». Nous devons aussi générer la clé privée associée au futur certificat.
La génération se fait avec openssl (ou libressl ;).

openssl req -nodes -newkey RSA:4096 -keyout
      exemple.org.key -out exemple.org.csr

Une fois que le CSR est généré, transmettez le à l’autorité de certification et elle vous donnera un certificat. Placez le tout dans /etc/ssl/httpd/.
Ensuite, assurez vous que la clé ne soit pas ouverte à tous vents. Un petit chmod 600 /etc/ssl/httpd/exemple.org.key ne fera pas de mal.

Je ne copie ici que la partie spécifique au SSL, le reste du fichier de configuration est le même.

nginx

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;

	ssl_certificate		/etc/ssl/httpd/exemple.org-chained.crt;
	ssl_certificate_key	/etc/ssl/nginx/exemple.org.key;

Nous remarquons que j’ai donné le fichier /etc/ssl/httpd/exemple.org-chained.crt et non /etc/ssl/httpd/exemple.org.crt comme certificat. En effet, afin de reconstituer la chaîne de certificats, le client HTTP a besoin que l’on lui envoie le certificat racine de la CA qui a signé le certificat. On chaîne donc les deux certificats dans un seul. Pour cela il faut télécharger le certificat racine depuis le site de la CA puis concaténer les deux :

cat /etc/ssl/httpd/exemple.org.crt $root_ca_cert.crt > /etc/ssl/httpd/exemple.org-chained.crt

Les plus avisés d’entre vous auront peut-être remarqué le http2 sur les lignes listen. Ce mot clé indique à nginx de supporter le protocole HTTP/2 en plus de HTTP/1.0 et HTTP/1.1 ; il est optionnel.

apache2

<VirtualHost *:443>
	SSLEngine		on
	SSLCertificateFile	/etc/ssl/httpd/exemple.org.crt
	SSLCertificateKeyFile	/etc/ssl/nginx/exemple.org.key
	SSLCACertificateFile	/etc/ssl/certs/$root_ca_cert.crt
	SSLVerifyClient		None

Contrairement à nginx, apache demande la certificat racine et le certificat du serveur dans un fichier séparé.

Complément

J’avais écrit une doc similaire à destination des administrateurs de grifon dans ma jeunesse. Elle vous permettra peut-être d’éclaircir des points qui ne le sont pas ici.

Supplément

Comme nous avons pu le constater, il existe quelques bémols au HTTPS dûs à la conception de x509. Il existe des moyens de s’en prévenir, mais ils sont encore peu développés. J’ai appelé le DANE et le TLSA : The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA.
Ce standard permet de publier un condensat de tout ou partie de sa chaîne de certificats (juste le sien, juste celui de la CA, juste la clé publique, etc.) dans le DNS à condition que la zone soit signée avec DNSSEC. Cela permet de se dispenser de CA car la vérification est directement faite par le client. Le wiki de grifon me semble être un bon point d’entrée pour le moment. J’écrirai un article plus détaillé ici-même plus tard.
Côté client, firefox ne supporte pas nativement la vérification du TLSA, mais les auteur de knot ont écrit un plugin prévu à cet effet, il s’appelle DNSSEC/TLSA Validator.
Avec firefox vous pouvez également vérifier que le certificat du site que vous visitez n’a pas été remplacé inopinément avec Certificate Patrol.

Les confs apache et nginx que je propose plus haut sont prévues pour « juste marcher », mais vous pouvez les durcir en empêchant les ciphers faibles ou en forçant la connexion en HTTPS sur votre site. Attention, ici j’active l’HSTS, entrez à vos risques et périls.
Pour nginx :

server {
	listen		80;
	listen		[::]:80;
	rewrite		^/(.*)$ https://exemple.org/$1 permanent;
	server_name	exemple.org
}

ssl_ciphers "AES128+EECDH:AES128+EDH";
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7

ssl_dhparam /etc/nginx/ssl/dhparams2048.pem;

Et pour apache :

<VirtualHost *:80>
	RewriteEngine	on
	RewriteCond 	%{HTTPS} !=on
	RewriteRule	.* https://%{SERVER_NAME}%{REQUEST_URI} [NE,R,L]

	ServerName	exemple.org
</VirtualHost>

<IfDefine SSL>
SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
</IfDefine>

Script de regénération d’un certificat let’s encrypt à la création d’un site sur wordpress

2016-08-29T16:28:12+02:00

Dans le cadre de gozmail, nous proposons également l’hébergement de blogs pour nos adhérents. Nous utilisons wordpress car il dispose d’une fonctionnalité qui permet de créer un réseau de sites. Ainsi, chaque adhérent dispose de sonsite.log.bzh et ne peut pas aller fouiner chez son voisin.

Au bout d’un moment, nous nous sommes dit que ça serait pas mal d’avoir du SSL. Premièrement parce que ça évite d’envoyer son mot de passe en clair, deuxièmement parce que le chiffrement devient de plus en plus nécessaire dans notre monde actuel. Comme l’asso n’a pas spécialement envie de payer un certificat global *.log.bzh, nous avons décidé d’utiliser let’s encrypt et de mettre chaque nom de domaine dans le certificat. Jusqu’à présent il s’agissait d’un cron qui tournait tous les jours et redemandait un certificat si un nouveau site a été créé. En soit ça ne marche pas si mal, mais tout nouveau site se retrouve avec un mauvais certificat le premier jour, on peut faire mieux.
Il faut donc régénérer le certificat au moment de la création du compte. Pour ça nous pouvions soit utiliser les hooks de wordpress (et donc se taper du code en PHP, et personne n’a envie de faire du PHP), soit écrire un petit wrapper shell qui crée un compte wordpress en se basant sur wp-cli puis lance la tambouille let’s encrypt avec acme-tiny.
Le script que je vous propose ici part donc du principe que ces deux projets sont utilisables sur la machine depuis laquelle vous le lancez. Les chemins sont spécifiques à log.bzh, vous devrez donc les modifier en fonction de vos besoins. Il faudra également modifier les variables $DBUSER, $DBPASS et $DBNAME.

#!/bin/sh

usage() {
cat <<EOF
Usage of $0:
	-h, --help	Print this help
	-u, --user	User name
			Create a site \$user.log.bzh
	-e, --email	User’s mail
EOF
}

die() {
	echo "$@" >&2
	exit 1
}

nargs=$(($#/2))

OPTS=$(getopt -o u:,e:,h -l user:,email:,help -- "$@") || die

if [ $# -eq 0 ]; then
        >&2 usage
        exit 1
fi

eval set -- "$OPTS"

while :; do
	case "$1" in
		-h | --help)	usage;
				exit 0;;
		-u | --user)	USER="$2";
				shift 2;;
		-e | --email)	EMAIL="$2";
				shift 2;;
		--) shift; break;;
	esac
done

PASSWORD="$(head -c 12 /dev/urandom | base64)"

if [ $nargs -ne 2 ]; then
	>&2 printf "Error, username or email not specified\n"
	>&2 usage
	exit 1
fi

cd /var/www/html/log.bzh

su www-data -s /bin/sh -c "wp site create --slug=$USER --email=$EMAIL" || die "Error while creating site"
su www-data -s /bin/sh -c "wp user update $USER --user_pass=$PASSWORD" || die "Error while setting password"

cd $OLDPWD

DBUSER="coucou"
DBPASS="je"
DBNAME="teste"

# Very ugly code here.
# Just for memory, because insane ;)
#openssl req -nodes -sha256 -newkey rsa:4096 \
# -keyout /etc/ssl/nginx/blogs.log.bzh.key \
# -out /etc/ssl/nginx/blogs.log.bzh.csr -subj "/" -reqexts SAN \
# -config <(cat /etc/ssl/blogs.cnf \
#  <(printf '[SAN]\nsubjectAltName=DNS:log.bzh,DNS:www.log.bzh,'; \
#  while read fqdn; do printf "DNS:${fqdn},"; done < \
#   <(echo 'SELECT domain FROM wp_blogs;' | mysql -u $DBUSER -p$DBPASS $DBNAME \
#    | sed -e '1d' | grep -v "^log\.bzh$") | sed 's/,$//'; printf '\n'))

# A bit less ugly
(	printf '[SAN]\nsubjectAltName=DNS:log.bzh,DNS:www.log.bzh,'; \
	echo 'SELECT domain FROM wp_blogs;' | \
	mysql -u $DBUSER -p$DBPASS $DBNAME | \
	sed -e '1d' | \
	grep -v '^log\.bzh$' | \
	while read fqdn; do \
		printf "DNS:${fqdn},"; \
	done | \
	sed 's/,$//'; printf '\n') | \
cat /etc/ssl/blogs.cnf - | \
openssl req \
	-nodes \
	-sha256 \
	-newkey rsa:4096 \
	-keyout /etc/ssl/nginx/blogs.log.bzh.key \
	-out /etc/ssl/nginx/blogs.log.bzh.csr \
	-subj "/" \
	-reqexts SAN \
	-config /dev/stdin \
|| die "Error while getting site list"

acme_tiny.py --account-key /usr/local/var/lib/sslle/account.key \
 --csr /etc/ssl/nginx/blogs.log.bzh.csr --acme-dir /var/www/le-challenges/ > \
 /etc/ssl/nginx/blogs.log.bzh.crt || die "Error while signing certificate"

cat /etc/ssl/nginx/blogs.log.bzh.crt \
 /etc/ssl/certs/lets-encrypt-x3-cross-signed.pem > \
 /etc/ssl/nginx/blogs.log.bzh-chained.crt || die "Error while chaining certificate"

service nginx reload || die "Error while reloading nginx"

SUBJECT=$(perl -wse "use utf8; use Encode qw(encode); print encode(\"MIME-Q\",\
 \"Votre site https://${USER}.log.bzh vient d’être créé\");")

echo "From: Admins log.bzh <log@gozmail.bzh>
To: $EMAIL
Cc: Admins log.bzh <log@gozmail.bzh>
Content-Type: text/plain; charset=UTF-8
Subject: $SUBJECT

Bonjour,
Votre site vient d’être créé. Son adresse est https://${USER}.log.bzh
Pour vous connecter, rendez-vous sur https://${USER}.log.bzh/wp-admin/

Votre identifiant est $USER
Votre mot de passe est $PASSWORD

Cordialement,
--
Les admins de log.bzh" | /usr/sbin/sendmail -f log@gozmail.bzh -t


exit 0

# À la base je voulais la faire simple, j’ai glissé chef.

Mettre en œuvre BCP38 avec un routeur FreeBSD en utilisant pf

2016-08-22T18:18:00+02:00

BCP38 (pour Best Current Practice numéro 38) est un document de l’IETF qui présente les bonnes pratiques en matière de filtrage de trafic, notamment vis à vis de l’IP source. En effet, par défaut un routeur ne regarde que les IPs de destinations afin de savoir vers où envoyer le paquet, sans se soucier de savoir si l’IP source fait partie des blocs d’IP qu’il route ou pas.
Ceci a pour effet de pouvoir usurper l’IP source et de pouvoir mener des attaques sans révéler sa propre IP. Cela participe également aux attaques par amplification.
Exemple :

 # scapy
>>> p=IP(dst="86.229.168.245", src="89.234.141.6")/ICMP()
>>> send(p)
WARNING: No broadcast address found for iface eth0

.
Sent 1 packets.

root@drscott:~# tcpdump -i eth0.832 host 89.234.141.6 and '(icmp or icmp6)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.832, link-type EN10MB (Ethernet), capture size 262144 bytes
22:45:17.556468 IP 89.234.141.6 > LFbn-1-3662-245.w86-229.abo.wanadoo.fr: ICMP echo request, id 0, seq 0, length 8
22:45:17.556632 IP LFbn-1-3662-245.w86-229.abo.wanadoo.fr > 89.234.141.6: ICMP echo reply, id 0, seq 0, length 8
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

Je viens donc de faire sortir par l’AS204092 une IP de l’AS60630. Ce qui n’aurait jamais dû arriver en temps normal, étant donné que nous ne routons pas les mêmes blocs d’IP. Notons que ça fonctionne aussi bien en IPv6.

Packet Filter (ou pf) possède un module qui vérifie que le paquet envoyé aurait bien dû prendre cette route s’il avait été reçu. Si ce n’est pas le cas, le paquet est bloqué. Attention, cela veut dire que ça ne marche que dans le cas de routage symétrique ; dès que le routage est asymétrique, les paquets seront bloqués même s’ils sont légitimes. Ce module se nomme urpf-failed pour Unicast Reverse Path Forwarding.

Prenons un exemple, j’ai un routeur avec d’un côté internet (sur em0), de l’autre mon réseau (sur em1).
Sur em0, le routage n’est pas forcément symétrique en raison de BGP. Mon AS n’a pas forcément les même préférences que celui de celui à qui je cause. Par exemple chez grifon, nous allons voir orange par cogent mais ils nous répondent par interoute.
Par contre, em1 ne contient qu’une seule route, celle de mon réseau local. C’est donc sur cette interface qu’il faut activer la vérification uRPF. Je vous conseille de toutes façons de préférer appliquer les règles de filtrage sur vos interfaces internes plutôt que vos interfaces externes. Si vous vous trompez, vous pourrez au moins reprendre la main sur vos équipement via les IPs d’interco (pour peu qu’elles soient annoncées en BGP).
Si l’on suit la doc de pf, il faut donc ajouter

block in quick on em1 from urpf-failed label uRPF

dans /etc/pf.conf et recharger la configuration de pf avec service pf reload.
Si nous reprenons notre exemple plus haut, ça donne ça :

morvan ~ # scapy 
INFO: Can't import python gnuplot wrapper . Won't be able to plot.
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
Welcome to Scapy (2.2.0)
>>> p=IP(dst="86.229.168.245", src="20.23.31.25")/ICMP()
>>> send(p)
WARNING: No broadcast address found for iface eth0

.
Sent 1 packets.
>>> 


root@nominoe:~ # tcpdump -i em1 host rennes.swordarmor.fr and '(icmp or icmp6)' 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
18:14:11.730868 IP 20.23.31.25 > LFbn-1-3662-245.w86-229.abo.wanadoo.fr: ICMP echo request, id 0, seq 0, length 8
^C
root@nominoe:~ # tcpdump -i em0 host rennes.swordarmor.fr and '(icmp or icmp6)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0.20, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
8393 packets received by filter
0 packets dropped by kernel

Nous voyons donc bien que le paquet arrive sur l’interface interne, mais n’est pas transférée sur l’interface externe, et n’est donc pas envoyé sur Internet.

De cette façon, tout paquet ayant une IP source qui n’est pas accessible par votre interface interne — et qui ne fait donc pas partie de votre réseau — ne sera pas envoyé sur Internet. Et c’est bien le but de BCP38, n’autoriser que ses IPs à sortir depuis son réseau.
L’équivalent de cette fonctionnalité avec Netfilter s’appelle rpfilter. Vous pouvez trouver un exemple à ce propos sur la la doc d’ARN.

Gestion automatique de DNSSEC avec OpenDNSSEC et nsd

2016-07-21T12:59:00+02:00

Introduction

J’avais déjà parlé du DNSSEC avec knot. Ici l’article sera similaire mais utilisera deux daemons différents, nsd pour le serveur faisant autorité et OpenDNSSEC pour la gestion du DNSSEC.
Alors là, il va y avoir des petits malins qui vont me dire « oui mais tu sais déjà faire avec knot, alors pourquoi s’embêter avec autre chose, niania ». Et bien justement, c’est parce que je ne connais pas que j’essaye ; simplement parce que l’on pas toujours le choix des logiciels que l’on utilise, donc en connaître le plus possible est une bonne chose.

Je vais d’abord faire un déroulé censé marcher du premier coup, puis ensuite vider mon sac sur les problèmes que j’ai rencontrés avec OpenDNSSEC.

Installation

Cette configuration a été faite sous gentoo. Je n’ai pas forcément choisi les versions les plus récentes dans les dépôts car elle a vocation a être mise en production sur du debian. La base de données utilisée pour stocker les clés avec dev-libs/softhsm sera du sqlite.

printf '=net-dns/opendnssec-1.4.7 ~amd64\n=dev-libs/softhsm-1.3.7
~amd64\n=net-dns/nsd ~amd64' >> /etc/portage/package.accept_keywords
echo 'net-dns/opendnssec	-mysql	sqlite' >> /etc/portage/package.use
emerge -va net-dns/opendnssec dev-libs/softhsm

Configuration quand tout va bien

OpenDNSSEC

Il faut commencer par préparer le stockage des clés.

echo "0:/var/lib/opendnssec/softhsm_slot0.db" > /etc/softhsm.conf
touch /var/lib/opendnssec/softhsm_slot0.db
chown opendnssec:opendnssec /var/lib/opendnssec/softhsm_slot0.db
chmod o-r /var/lib/opendnssec/softhsm_slot0.db
softhsm --init-token --slot 0 --label OpenDNSSEC

Le mot de passe (le USERPIN, le SOPIN sert à révoquer des USERPIN) qui vous est demandé sera à renseigner dans la configuration d’OpenDNSSEC par la suite.

Maintenant, on va dire à OpenDNSSEC comment aller utiliser softhsm. Il faut éditer /etc/opendnssec/conf.xml
Ici je ne copie que le bout de configuration qui nous intéresse, il faut bien évidemment garder le reste :)

<Repository name="SoftHSM">
	<Module>/usr/lib64/softhsm/libsofthsm.so</Module>
	<TokenLabel>OpenDNSSEC</TokenLabel>
	<PIN>monmotdepasse</PIN>
	<SkipPublicKey/>
</Repository>

Ensuite, il faut que opendnssec puisse dire à nsd de recharger la zone lors des rotations de clés.
Depuis nsd4, il existe nsd-control. C’est une commande qui permet d’envoyer des ordres à nsd, tel que la relecture de zone. Pour pouvoir l’utiliser, il faut avoir accès à la clé publique du serveur et à la clé privée et publique du client.
Une fois que tout cela sera lisible par opendnssec, il faudra lui dire quelle commande utiliser.

chown root:opendnssec /etc/nsd/nsd_control.*
chown root:opendnssec /etc/nsd/nsd_server.pem

Puis toujours dans /etc/opendnssec/conf.xml :

<NotifyCommand>/usr/sbin/nsd-control reload %zone</NotifyCommand>

Nous allons maintenant dire à OpenDNSSEC où aller chercher la zone brute, et où la publier. Ça se passe dans /etc/opendnssec/zonelist.xml :

<Zone name="grifon.fr">
	<Policy>default</Policy>
	<!-- https://wiki.opendnssec.org/display/DOCS/zonelist.xml#zonelist.xml-Zones
	     (Note that this file is a temporary file that passed between OpenDNSSEC components and is not intended to be edited by users.)
	-->
	<SignerConfiguration>/var/lib/opendnssec/signconf/grifon.fr.xml</SignerConfiguration>
	<Adapters>
		<Input>
			<Adapter type="File">/var/lib/opendnssec/unsigned/grifon.fr</Adapter>
		</Input>
		<Output>
			<Adapter type="File">/var/lib/opendnssec/signed/grifon.fr</Adapter>
		</Output>
	</Adapters>
</Zone>

/var/lib/opendnssec/unsigned/grifon.fr correspond à une copie de la zone qui était servie jusqu’à présent (/etc/nsd/grifon.fr.zone dans mon cas). C’est aussi ce fichier qu’il faudra éditer si on veut mettre à jour la zone.

Pour finir, on démarre le service et on demande une signature de la zone.

service opendnssec start
ods-ksmutil update all
ods-signer sign grifon.fr

Et là, en théorie vous avez une zone signée dans /var/lib/opendnssec/signed/grifon.fr.

nsd

La configuration de nsd est très basique, il faut juste lui dire d’aller chercher la zone dans la fichier généré par opendnssec au lieu de l’ancien.

zone:
	name:		"grifon.fr"
	zonefile:	"/var/lib/opendnssec/signed/grifon.fr"
	# vos serveur secondaires

Publication de la KSK

Pour avoir la KSK, il faut utiliser ods-ksmutil key export --zone grifon.fr une fois que le délai de mise à jour complete de tous les caches soit passé (24h par défaut). Ce délai est visible avec ods-ksmutil key list --zone grifon.fr --verbose --all.

Mes mésaventures avec OpenDNSSEC

Pour commencer, la doc est vraiment mal foutue, elle est mal organisée et il en manque même des bouts (404 sur certaines pages). De plus, quelques commentaires dans les fichiers de conf ne feraient pas de mal histoire de dire à quoi sert quel fichier ; je pense notamment au fichier temporaire dans zonelist.xml.

Parfois, les erreurs n’ont rien à voir avec le problème. Si je reprends l’exemple du fichier temporaire, je l’avais oublié au début et j’avais comme erreur « /etc/opendnssec/zonelist.xml:7: element Adapters: Relax-NG validity error : Did not expect element Adapters there » alors que le souci était que j’avais oublié une ligne, pas que ce bloc n’a rien à faire là. Et puis, c’est pas comme si le message était à l’opposé de ce qu’il faut faire…

Toujours sur cette histoire de fichier temporaire, il n’y a pas de commentaire à son propos dans l’exemple de conf (c’est moi qui l’ai rajouté à la main dans celle que j’ai copiée). N’ayant rien vu dans le dossier d’exemple, je me suis dit qu’il ne servait pas à grand chose. Et ben c’est raté.

Le MTU et le MSS

2016-05-24T20:01:50+02:00

En théorie

Le MTU est la taille maximale qu’un paquet peut avoir lors de son transport sur le réseau. Elle est généralement de 1500 octets. À partir de ce MTU, nous calculons le MSS, c’est à dire la quantité maximale de données que nous pouvons atteindre dans un seul paquet sans qu’il ne soit fragmenté lorsque nous utilisons le protocole de transport TCP.
Le but de ce mécanisme est d’éviter la fragmentation de paquets. En effet, la performance d’un routeur est déterminée en fonction du nombre de paquets par seconde qu’il peut gérer, indépendamment de leur taille. Pour avoir les meilleurs performances possibles, il faut donc avoir les plus gros paquets possibles. Le MSS est déterminé par TCP lors de la poignée de main initiale.

Seulement, il arrive que cet échange de MSS ne suffise pas à déterminer la taille de paquet optimale. Par exemple, si le paquet passe par un tunnel sur le chemin, vous aurez un MTU inférieur à un moment alors que les deux machines qui se parlent sont capables de recevoir des paquets de 1500 octets.
Dans ce cas, il existe le Path MTU discovery. Si jamais le paquet est trop gros mais qu’il est marqué comme ne pouvant pas être fragmenté (drapeau d’en-tête IP DF, pour Don’t Fragment), la machine va envoyer un paquet ICMP de type 3 code 4 (Fragmentation Needed and Don’t Fragment was Set).

En pratique

Mais… nous avons parfois affaire à des admins bourrins qui bloquent totalement ICMP. Du coup, le paquet ne passe juste pas et la session TCP finit par se fermer.
C’est par exemple le cas avec laposte.net. Nous avons remarqué ceci chez grifon car nous avons un tunnel GRE vers ARN pour la redondance BGP. Il arrive donc que des paquets arrivent par chez eux. Or, ce tunnel a un MTU de 1476 octets, ce qui ne cadre pas avec le MTU de toutes les machines du réseau.

En voyant ça, nous avons d’abord pensé à un simple problème de MTU. Mais en mettant le GRE à 1200, ça n’a rien changé. Effectivement, le problème n’était pas le GRE en lui-même, puisque nous pouvions parfaitement faire passer des paquets de 1500 octets dessus, mais de faire comprendre au serveur que l’on veut joindre qu’il faut réduire le MTU s’il passe par là.

Ainsi, ça ne peut être qu’un problème de PMTUd. Une solution à ce problème est de ne pas avoir besoin d’y faire appel. Nous avons alors essayé de mettre le MTU du port interne de grifon à 1460 pour voir si ça avait une influence dans le calcul du MSS, nada.

Nous aurions pu également changer le MTU de toutes les machines du réseau grifon, mais ce n’est pas possible puisque nous n’avons pas la main dessus.

Il ne nous restait alors plus que la solution de ré-écrire le MSS pour les paquets qui passent par ce routeur. Ce n’est clairement pas la meilleure des solutions, car ça veut dire mettre ses mains dans la couche 4, mais c’est la seule qui marche.
Le routeur de grifon est sous FreeBSD, nous avons donc ajouté la règle pf scrub out all max-mss 1436. Ainsi, tous les paquets ont une MSS maximale de 1436 octets, soit 1476 (MTU GRE) – 40 (en-tête IP et TCP).

Pour aller plus loin

Si vous voulez en savoir plus sur ces histoires de MSS et MTU, vous pouvez lire https://www.bortzmeyer.org/mtu-et-mss-sont-dans-un-reseau.html, https://www.grenode.net/Documentation_technique/Divers/Multiples_encapsulations/ ou http://shaarli.guiguishow.info/?JjNf1g.

Un autre article (mais plus récent que le mien) nous explique pourquoi la fragmentation ne marche pour ainsi dire pas.

Gestion automatique de DNSSEC avec knot

2016-03-02T12:55:10+01:00

Depuis quelques temps, je me suis mis au DNSSEC. Comme je suis feignant, je n’ai pas envie de re-signer ma zone à la main tous les jours :) Comme j’ai vu que knot savait gérer la signature DNSSEC comme un grand, je me suis dit que ça serait une bonne occasion de l’essayer.

Installation

Je suis sous FreeBSD et j’ai choisi d’utiliser les ports.


root@kaiminus:~ # cd /usr/ports/dns/knot2/
root@kaiminus:/usr/ports/dns/knot2 # make install clean
root@kaiminus:~ # echo 'knot_enable="YES"' >> /etc/rc.conf
root@kaiminus:~ # echo 'knot_config="/usr/local/etc/knot/knot.conf"' >> \
	/etc/rc.conf

Configuration de base

La configuration de knot se base sur du YAML. Il faut commencer par définir les options du serveur en lui-même, puis les serveurs avec qui le votre va parler (pour la réplication de zone), mettre en place des acl et enfin définir les zone.


# configuration de base
server:
    # Listen on all configured IPv4 interfaces.
    listen: 0.0.0.0@53
    # Listen on all configured IPv6 interfaces.
    listen: ::@53
    # User for running the server.
    user: knot:knot

log:
    # Log info and more serious events to syslog.
  - target: /var/log/knot.log
    any: info

# Si on veut utiliser une clé pour s’authentifier auprès d’autres serveurs
key:
  - id: blah
    algorithm: hmac-sha256
    secret: "blah2="

# On précise les autres serveurs
remote:
  - id: ttn
    address: 2a01:6600:8081:c600::1

  - id: bulbizarre
    address: 2a01:240:fe00:82af:764f:b47e:d131:85e4
    key: blah

# Les ACL (tout le monde n’a pas le droit de faire le même chose)
  - id: acl_allow_nokey
    address: [2a01:6600:8081:c600::1]
    action: [transfer, notify]

  - id: acl_key
    address: 2a01:240:fe00:82af:764f:b47e:d131:85e4
    action: transfer
    key: blah

# Slave zones
# reverse jaguar (florizarre)
  - domain: 4.0.8.0.0.4.1.8.8.5.0.0.a.2.ip6.arpa
    master: bulbizarre
    acl: acl_key

# Master zones
zone:
  - domain: swordarmor.fr
    file: "/usr/local/etc/knot/swordarmor.fr.zone"
    acl: [acl_allow_nokey, acl_key]
    notify: [ttn, bulbizarre]

Signature automatique DNSSEC

Pour ma part, j’ai choisi la gestion automatique des clés. La façon de faire varie légèrement en fonction de la version (post ou pre 2.3). Je ne sais pas exactement si c’est à cette version que ça a changé, mais en tout cas c’est là que je m’en suis rendu compte.

Avant la version 2.3

Il nous faut d’abord dire à knot où seront stockées les clés.


template:
  - id: default
    storage: "/usr/local/etc/knot/var"
    kasp-db: kasp

Si votre knot ne tourne pas en root (ce qui est une bonne idée), ce répertoire doit appartenir à knot (ou à l’utilisateur qui le fait tourner si ce n’est pas knot).


# mkdir -p /usr/local/etc/knot/var/kasp
# chown -R knot /usr/local/etc/knot/var
# cd /usr/local/etc/knot/var/kasp
# keymgr init
# keymgr policy add rsa algorithm RSASHA256 zsk-size 1024 ksk-size 2048
# keymgr zone add swordarmor.fr policy rsa

Ensuite, on rajoute dnssec-signing: on au domaine swordarmor.fr et knot se débrouille tout seul :)

À partir de la 2.3

À partir de cette version nous n’avons même plus besoin de nous soucier de la gestion de la base de clés ; knot gère tout. Il suffit juste d’ajouter dnssec-signing: on et dnssec-policy: default à notre configuration de zone et le tour est joué.
Ça doit donner un truc qui ressemble à ça au final :


zone:
  - domain: log.bzh
    file: "log.bzh.zone"
    acl: acl_slaves
    notify: [togepi, bihen]
    dnssec-signing: on
    dnssec-policy: default

Publication de la clé DNSSEC dans la zone parente

Il existe deux types de bureaux d’enregistrement : ceux qui veulent un DS et ceux qui veulent une clé DNSKEY complète.

Publication de la clé DNSKEY

Ancienne méthode

Si l’on a précisé une kasp dans la conf, les clés se trouveront dedans. Si ce n’et pas le cas, ce sera dans storage. Comme à l’époque où je me suis mis à knot il fallait un kasp, mes clés sont dans /usr/local/etc/knot/var/kasp/. Dedans nous trouvons un fichier avec un nom qui ressemble à zone_swordarmor.fr.json. Nous l’ouvrons (par exemple avec cat) et dans ce JSON, nous avons une section "ksk": true. On y trouve aussi l’entrée algorithm et public_key. Il faut prendre ces deux valeurs et les reporter dans l’interface de son bureau d’enregistrement.
Vous devez donc avoir un formulaire qui ressemble à la capture si dessous. Il faut bien faire attention à préciser le bon algorithme et à publier la KSK.

Nouvelle méthode

Depuis knot 2.4, les clés ne sont plus stockées dans un JSON, il n’est donc plus possible d’utiliser un bête cat. Par contre, il est maintenant possible d’interroger knot en local pour avoir la clé actuellement servie :

root@argall:~# knotc zone-read swordarmor.fr @ DNSKEY
[swordarmor.fr.] swordarmor.fr. 10800 DNSKEY 256 3 13 iy2V9pyqoImi7WmhTbkjntLt8FyK4/XxPrN9kDsweXjnKtl8DvFStjKwgMnJNKpkr3U2xsWx70o2xbLHLdgUbg==
[swordarmor.fr.] swordarmor.fr. 10800 DNSKEY 257 3 13 Uk3Vek1FDqzgQlI39NZcPKfpVex8unrHPmBLURrZCSjyje2o2UQel2FBGl2xHMl7qtcijj0x/g1n6tEmpio/jQ==

Pour lire cet enregistrement, il faut se référer aux RFC 4034, section 2 et 6605. L’enregistrement qui nous intéresse est le second, avec le tag 257, il correspond à notre KSK.
Ici nous avons donc affaire à une clé condensée avec ECDSAP256SHA256 (algorithme 13) et dont le résultat est « Uk3Vek1FDqzgQlI39NZcPKfpVex8unrHPmBLURrZCSjyje2o2UQel2FBGl2xHMl7qtcijj0x/g1n6tEmpio/jQ== ».

Exemple avec gandi

Ensuite, nous nous rendons sur la page « Gérer le DNSSEC » de son domaine et nous remplissons les champs en fonction du résultat des champs précédents.
J’ai délibérément fait le choix de ne pas publier la ZSK, car ce n’est pas nécessaire pour que le DNSSEC fonctionne correctement et qu’elle change régulièrement.

(cette capture étant plus vielle que la mise a jour de l’article, elle contient une clé différente de l’extraction avec la nouvelle méthode)

Publication d’un DS

Knot ne gère pas nativement l’export du DS, mais nous pouvons utiliser la commande drill du paquet ldnsutils à la place.

argall ~ # apt-get install ldnsutils 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  ldnsutils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 142 kB of archives.
After this operation, 561 kB of additional disk space will be used.
Get:1 http://mirrors.online.net/debian/ jessie/main ldnsutils amd64 1.6.17-5+b1 [142 kB]
Fetched 142 kB in 0s (2,857 kB/s) 
Selecting previously unselected package ldnsutils.
(Reading database ... 37564 files and directories currently installed.)
Preparing to unpack .../ldnsutils_1.6.17-5+b1_amd64.deb ...
Unpacking ldnsutils (1.6.17-5+b1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up ldnsutils (1.6.17-5+b1) ...

argall ~ # drill @argall.gozmail.bzh -s gozmail.net DNSKEY
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 15512
;; flags: qr aa rd ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; gozmail.net.	IN	DNSKEY

;; ANSWER SECTION:
gozmail.net.	10800	IN	DNSKEY	256 3 13 mIXljDQFdQIqixY5pmsgzCewpK+KbQPS1lqFV5iGzxXez8mTBT30uquL7Y/K2ZWGk3vMkGc/MN5Kp0hLVFS5Pg== ;{id = 34200 (zsk), size = 256b}
gozmail.net.	10800	IN	DNSKEY	257 3 13 xi9r6PYVykH5Xxk7iJKL9LfS6B/ka04+aJW5E8O2At+sdfwhH2wTvX+pPUYBjTNI54iRFofJFOajrIPrdzcV2g== ;{id = 28666 (ksk), size = 256b}

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Nov 17 15:28:58 2016
;; MSG SIZE  rcvd: 189
;
; equivalent DS records for key 34200:
; sha1: gozmail.net.	10800	IN	DS	34200 13 1 01349b4563e4f7ab36b2b4b54f98c300d6a8da88
; sha256: gozmail.net.	10800	IN	DS	34200 13 2 a8a6af6404675d34bd933fbdb8539118d021bcd56876dcccaebeb777c21eb28b
;
; equivalent DS records for key 28666:
; sha1: gozmail.net.	10800	IN	DS	28666 13 1 888e055ab8523ac1c847fd12d8d03ec88586c3b7
; sha256: gozmail.net.	10800	IN	DS	28666 13 2 a211a1a59a553710f127cf77b1a09af8eaf0249b505337bd8e3dc615f649014d

Ici la clé qui nous intéresse est la 28666 puisque c’est elle la KSK (cf. les commentaires des enregistrements DNSKEY).
Dans mon exemple, argall.gozmail.bzh est le master et gozmail.net est le domaine dont on veut avoir le DS.

Je vous déconseille très fortement d’utiliser le DS sha1. Cet algorithme de condensat est en effet considéré comme ayant des risques de collision. Par contre le sha256 n’a pas (encore) ce souci.

Mise à jour d’une zone

La méthode normale pour mettre à jour une zone avec knot est l’utilisation de la commande knotc avec les actions zone-begin, zone-set, zone-commit, etc. C’est très pratique dans un script, ça évite du sed, grep, awk, mais je trouve ça lourd de manière interactive.
Il n’est pas possible non plus d’éditer directement le fichier de zone renseigné dans la conf car knot réorganise le fichier à sa façon et on ne retrouve plus ses petits.

Je filoute donc un peu en ayant un fichier de zone non signé (en .zone.nodnssec) dont je fais ce que je veux et un fichier de zone qui est dans la conf de knot (en .zone) et qui est donc signé régulièrement.
Ce que je fais, c’est que j’édite la zone non-signée, je mets ce que je veux dedans, je la copie par dessus la zone signée, puis je demande à knot de recharger la zone. Il va alors la modifier comme il veut pour ajouter les signatures DNSSEC et l’avoir à sa convenance, mais j’aurais toujours ma zone non-signée à côté, avec mon organisation à moi. Par contre, il ne faut pas oublie d’incrémenter le serial, de préférence sous le format YYYYMMDDNN car les renouvellements de clé DNSSEC font incrémenter le sérial même si on ne modifie pas la zone à la main.
Par exemple, si je veux modifier la zone log.bzh stockée dans /var/lib/knot/log.bzh.zone ça done un truc comme ça :

master # vim /var/lib/knot/log.bzh.zone.nodnssec
Là je fais les modifs que je veux.
master # cp /var/lib/knot/log.bzh.zone.nodnssec /var/lib/knot/log.bzh.zone
master # knotc zone-reload log.bzh
OK

Et hop, j’ai ma zone modifiée, re-signée, et distribuée sur tous les masters.

Premières impressions sur knot

C’est la première fois que j’utilise knot, et je dois dire que je ne suis pas déçu. Le seul souci que j’ai eu était sur le choix de l’adresse IP source lors des réponses, et ce bug a été corrigé à peu près une semaine après l’avoir reporté.
De plus, leur doc est vraiment très bien faite, et ça c’est pas négligeable.

Complétion de dig avec zsh

2015-12-31T12:53:08+01:00

J’utilise zsh comme shell par défaut sur mon laptop. J’en suis satisfait, sauf que je n’avais pas de complétion pour la commande dig(1).
En demandant comment utiliser la complétion de bash pour cette commande, un gentil monsieur a tout simplement écrit un script de complétion pour dig :).
Pour avoir la complétion de dig dans votre zsh, il faut donc télécharger ce script, puis le mettre dans le dossier de complétion de zsh (/usr/share/zsh/5.0.5/functions/Completion/Unix/ chez moi).
Soit :

curl -k https://www.swordarmor.fr/documents/dig-zsh.patch > /tmp/dig-zsh.patch
su -l
cd /usr/share/zsh/5.0.5/functions/Completion/Unix/
patch -p4 < /tmp/dig-zsh.patch

Problèmes avec systemd et pourquoi j’aime l’init de BSD

2015-12-22T18:40:46+01:00

Préambule

Ceci n’est pas un article que j’ai écrit, mais une traduction de “Problems with Systemd and Why I like BSD Init” écrit par Randy Westlund. Tout « moi » est donc en fait lui.

La traduction

Dans le le premier article de mon blog, je disais que systemd était l’une des choses qui m’ont poussées à jeter un œil aux BSDs et éventuellement à migrer vers FreeBSD. Des gens me demandaient quel était mon problème avec systemd, mais je n’avais jamais rien écrit à ce propos. Finalement, voici ce que j’en pense.

J’ai été réticent à parler de systemd ici car j’étais fatigué de voir tout le monde se battre à son sujet. La liste de diffusion de Gentoo (et toutes les autres sur internet) est devenu une énorme arène de guerre où chacun pense que systemd est soit une menace tout en attaquant personnellement Lennart Poettering, soit chacun pense que systemd va tous nous sauver de nous même et tout le monde devrait l’utiliser. J’étais juste malade de voir tout le monde tomber dans l’excès.

Pour ma part, je ne suis pas fan de systemd mais je ne pense pas que ça soit la fin du monde non plus. J’ai regardé un très bon interview avec Lennart dans le Linux Action Show où il expliquait comment il l’a implémenté, et il a certaines bonnes raisons. Pour écrire un daemon pour Linux, vous êtes obligé de maintenir différents scripts pour chaque distribution car elles placent les choses à des endroits différents. Et sysVinit n’est pas le meilleur avec la gestion des dépendances. Développer des choses pour Linux en tant qu’ordinateur de bureau n’est pas aussi facile que ça devrait l’être, en grande partie à cause du manque d’homogénéité.

J’ai évité ceci quand j’utilisais Linux à la maison, mais ces jours-ci je dois utiliser Linux au travail et je ne plus plus y couper. Après avoir utilisé systemd pendant un moment, il y a définitivement des choses que j’aime dedans. Il rend les choses plus faciles. Comme prendre un daemon que j’ai écrit et en faire un service. Les fichiers de services sont sympas, et leur dire de redémarrer mon service s’il crash est très pratique. J’aime le fait que les fichiers de service vont fonctionner sur toutes les distributions Linux qui utilisent systemd. Je peux simplement écrire un fichier de service de mémoire [NDT : service files], alors que je dois partir d’un exemple pour un script de rc.

D’un autre côté, il rend les choses difficiles encore plus difficiles. Si je veux faire quelque chose de complexe pour lequel systemd n’a pas été prévu, je suis foutu. Avec l’init de BSD, je peux simplement éditer le script /etc/rc et le remplacer par du code shell arbitraire. Par défaut, il regarde dans /etc/rc.d/ et exécute les scripts activés ici, mais je peux changer ça en moins de cinq minutes.

Voici le /etc/rc de FreeBSD. /sbin/init appelle ce script, et /etc/rc appelle les scripts activés dans /etc/rc.d/.

https://github.com/freebsd/freebsd/blob/master/etc/rc

Regardez à quel point il est léger. Je peux changer tout ce que je veux. Je peux enlever la partie où il démarre les services et en démarrer manuellement juste un ou deux. Je peux changer la destination de la sortie console, comme la rediriger vers un fichier. Je peux dire à ce script d’appeler tout ce que je veux, comme je le veux. Flexibilité illimitée.

Je ne suis pas un expert des systèmes d’init, mais j’ai utilisé OpenRC depuis un long moment et je suis maintenant assez familier avec l’init de BSD. Pour ce que je comprends, l’init de BSD est supérieur au vieux sysVinit que Linux avait pour habitude d’utiliser. Et l’OpenRC de Gentoo est similaire à l’init de BSD. Je n’ai pas d’expérience particulière avec le classique sysVinit. Voilà d’où je viens.

Systemd est très opaque. Ce que je veux dire par là est qu’il est très compliqué à débugguer. Je ne peux pas regarder à l’intérieur et voir ce qu’il fait, parce que c’est un binaire compliqué. Je ne peux pas facilement voir la façon dont il se comporte. L’init de BSD est juste un script, donc je peux l’inspecter, ajouter des déclarations d’état, et le changer de toutes les façons que je veux. Il est facile de regarder à l’intérieur et de comprendre exactement ce qu’il va faire et comment.

La façon avec laquelle systemd fait le démarrage en parallèle me dérange. Si un service A dépend d’un service B, ils vont traditionnellement démarrer l’un après l’autre ; A va seulement démarrer si B est lancé. Systemd va les démarrer en même temps, mais temporiser tous les messages que A va tenter d’envoyer à B tant que B n’est pas prêt. Donc A va juste penser que B met du temps à répondre, et le système va démarrer plus vite. Vous pouvez désactiver ceci en utilisant la directive 'After', mais ceci ne va pas s’appliquer à tout le système et de toutes façons, désactiver une fonctionnalité n’est pas une réponse à ce qui devrait exister à la place.

Mon problème avec ceci est que, selon moi, l’ordre dans lequel les services démarrent devrait être exactement le même et prédictible pour l’administrateur système. Avec systemd, l’ordre n’est pas déterminé, donc vous ne savez pas ce qui va arriver au prochain démarrage. Je travaille avec des serveurs et des systèmes embarqués ; le temps de démarrage n’est pas ma préoccupation. Un serveur passe plusieurs minutes dans le BIOS pendant le POST de toutes façon, avant même que l’amorceur de démarrage soit chargé ; faire en sorte que le système d’exploitation démarre plus vite ne va pas changer grand chose. Les systèmes embarqués démarrent déjà rapidement car vous faites en sorte d’y mettre le strict minimum. Ce qui m’intéresse, c’est qu’à chaque fois que je démarre, les choses se déroulent exactement dans le même ordre — dans l’ordre que je veux.

Il semblerait que personne ne s’accorde à dire si systemd est modulaire ou non. Je pense que le problème vient des différentes définition de la modularité. Systemd ne met pas tout dans le PID 1 comme certains le suggèrent ; il utilise des modules qui communiquent entre eux. Dans ce sens, il est modulaire. Mais ces modules sont très étroitement imbriqués. Vous ne pouvez pas en enlever certains, ou les remplacer avec d’autres choses. Dans ce sens il est monolithique. Ce n’est pas comme avoir une interface simple et passer les données via l’entrée et la sortie standard, ce qui est la modularité qui a rendu les pipes UNIX possibles. C’est le sens qui importe pour moi.

Je n’aime pas la façon avec laquelle systemd absorbe tout. Ce n’est pas un simple système d’init, il devient un micmac de gestion du système. Ça ne me semble pas modulaire. Pourquoi systemd devrait implémenter NTP alors que ntpd existe déjà ? Je pense que systemd-timesyncd et toutes ces choses comme ça ne sont qu’une réinvention de la roue.

Dans le cas de ntpd, vous pouvez dire que c’est une monstruosité qui doit être remplacée par quelque chose de plus petit, et vous avez raison. Il existe d’autres implémentations. OpenBSD a créé OpenNTPD, qui est très léger, seulement un client, et peut même aller vérifier sur des sites en HTTPS que le temps obtenu par NTP est raisonnable. Nettoyer ou ré-implémenter ntpd est une bonne chose, mais OpenBSD n’a pas jugé nécessaire de l’inclure dans un init.

Édition du 31 octobre 2015 : Merci @myfreeweb de me corriger, OpenNTPD n’est pas seulement un client. Il est, cependant, orienté client, mais c’est perdre en précision pour gagner en simplification. Si vous faites tourner un serveur de temps, vous utilisez sûrement quelque chose d’autre.

Linux est très fragmenté et systemd recolle un peu les bouts ensembles. Ça pourrait être une bonne chose. Mais de la façon dont c’est mené, il va y avoir un point à partir duquel on ne pourra plus dire « GNU/Linux ». Ce sera « GNU/systemd-linuxd ».

Mais une partie de ce qui fait que Linux est si spécial est la capacité à littéralement échanger un composant pour autre chose — même la libc ! Tout ce dont un programme Linux a besoin est un noyau et quelque chose que ressemble à libstdc.so. Il est répandu de construire des systèmes embarqués sous Linux avec ulibc, ou quelque chose de minimaliste. BSD ne peut pas remplacer sa libc, elle est trop incorporée.

Il a eu un très bon interview de quelques développeurs GNOME sur BSD Now il y a peu de temps. Ils disaient qu’ils vont porter leur attention sur la compatibilité avec BSD, mais ils parlaient aussi des raisons de leur dépendance à systemd : il n’y a pas d’API ou de façon standard de faire des choses telles que régler le fuseau horaire, changer de réseau Wi-Fi, ou mener à bien beaucoup de tâches banales avec Linux. Le code de GNOME est plein de #ifdefs donc ils peuvent utiliser du code différent en fonction des distributions ou du système d’exploitation, et ce n’est pas maintenable. Systemd apporte ces API de manière propre et portable, ce qui n’est pas négligeable pour les environnements de bureau.

OpenBSD travaille sur systemBSD, un substrat de systemd. Il fournit les APIs dont GNOME a besoin, mais n’implémente pas le reste. Je pense qu’avoir ce genre d’API est une très bonne chose, et j’aimerais nous voir comme une industrie de la standardisation là-dessus (ou quelque chose du genre).

Sytemd semble toujours instable. Je ne sais pas si c’est parce qu’il a plus de problèmes que les autres logiciels ou si c’est juste que les gens aiment à divulguer ses défectuosités, mais il a quelques problèmes qui pourraient être très drôles s’ils n’étaient pas si critiques. J’ai inclus des liens vers les rapports de bug actuels :

Incapacité à éteindre le sytème.
Systemd-journald utilisant 100 % du CPU.
Des corruptions fréquentes dont Lennart dit que ce n’est pas un problème. Il semble évident que des logs binaires non transactionnels est une idée terrible.
Systemd n’utilise pas les espaces de noms pour ses paramètres sur la ligne de commande du noyau et bloque le système. Les développeurs de systemd n’ont pas bien abordé la situation, et le fil de discussion est devenu désagréable.
De nombreux rapports vis à vis de systemd bloquant au démarrage à cause de quelque chose dans le fstab qui ne respecte pas POLA.

Pour une pièce critique de l’infrastructure, avoir des bugs réguliers de ce genre est un gros problème. Ça peut rendre une machine inutilisable et ruiner la journée de quelqu’un. Comparez ceci avec un projet réellement bien dirigé comme OpenZFS. De ce que j’en sais, personne n’a jamais perdu de données à cause d’un bug dans ZFS. Des projets d’infrastructure comme celui-ci doivent être maintenu à un standard encore plus élevé que le reste des logiciels à cause des conséquences si sévères qu’un bug peut avoir.

Je pense que les développeurs de systemd souffrent du syndrome du Not invented here. Je ne peux rien trouver qui suggère qu’ils ont considéré OpenRC ; ils ont l’air d’avoir des soucis personnels avec Gentoo. Une bonne part des problèmes dans les systèmes d’init qu’ils décrivent ont déjà été résolu par à la fois OpenRC et l’init de BSD. Maintenant ils sont autour de la ré-implémentation de tous les daemons Linux possibles en tant que module de systemd, juste parce qu’ils le peuvent.

Je parlais récemment avec un lecteur qui disait, « À chaque fois que je regarde le développement de systemd, j’ai l’impression que tout est une épreuve. ». Je pense que c’est particulièrement vrai. Systemd a été imposé à la communauté, et tout s’est enchaîné très vite. Il y a eu beaucoup de manœuvres politiques et de bras de fer avec les mainteneurs de distributions pour en faire le choix par défaut partout avant qu’il soit mature.

Debian n’aurait pas dû l’adopter avant au moins quelques années ; ils ont pour habitude d’être une distribution lente, régulière et stable. Leur adoption rapide de systemd a heurté les mœurs et entraîné le départ de la moitié de leur équipe pour Devuan. Ceci ne devrait pas arriver. Si votre équipe est farouchement divisée sur un point, la bonne réponse est de garder le statut quo et d’y revenir à tête reposée. Debian a perdu une grande part de sa réputation de stabilité à cause de ça.

Honnêtement, je pense que si systemd avait été graduellement adopté, au lieu d’être imposé, il aurait été plus populaire. Les gens auraient pu voir Fedora et Arch l’utiliser depuis plusieurs années et peut-être qu’à ce moment tout le monde aurait vu les avantages et aurait voulu l’adopter alors qu’il serait devenu stable. Mais de la façon dont ça s’est passé, la communauté n’a pas eu son mot à dire, et ce n’est pas une bonne chose.

J’aurais accueilli un remplaçant de sysVinit qui soit plus dans la mouvance UNIX. Quelque chose comme systemd aurait pu être bien, mais systemd a trop de défauts à la fois dans sa conception et son implémentation pour être ce dont nous avons besoin.

Je pense que le bon côté des choses est que ça a montré les problèmes causés par le modèle de la dictature du bénévolat que Linux utilise. Je pense que les gens ont fuit vers BSD pour sa communauté tout autant que pour sa supériorité technique.

Je trouve dérangeant que systemd manque de foi en UNIX. Alors venez rejoindre la communauté BSD. On a des cookies ;)

Mise en place d’un tunnel L2TP chiffré avec IPsec autentifié avec radius

2015-12-02T16:57:25+01:00

Cette infrastructure a été mise en œuvre au sein de grifon afin de fournir un VPN le plus proche possible de la collecte ADSL.

Côté serveur

Le radius

Le radius sert à authentifier les utilisateurs et à donner les autorisations qui leur sont relatives (comme par exemple, quelle adresse IP untel a le droit d’utiliser).

Pour que le serveur radius fonctionne, il faut commencer par changer le mot de passe dans /etc/freeradius/clients.conf (directive secret). Ensuite, les utilisateurs s’ajoutent dans /etc/freeradius/users selon le canevas

monuser Cleartext-Password := "monmotdepasse"
	Service-Type = Framed-User,
	Framed-Protocol = PPP,
	Framed-IP-Address = $ipv4,
	Framed-IP-Netmask = 255.255.255.255,
	Framed-IPv6-Prefix = $ipv6_interco,
	Framed-IPv6-Address = $ipv6_interco::1,
	Framed-Interface-Id = 0:0:0:$3,
	Delegated-IPv6-Prefix = $ipv6_deleg

Je vous conseille de vider ce fichier avant, il y a pas mal d’exemples qui ne sont pas commentés et qui peuvent perturber les utilisateurs que vous créerez.
Ensuite, il faut aussi mettre le mot de passe dans /etc/radiusclient/servers précédé de localhost car le client et le serveur tournent sur la même machine.

Le L2TP

Nous avons choisi l’implémentation openl2tp car tout le travail est fait au niveau du kernel. Ça évite les allers/retours entre l’espace utilisateur et le noyau.
Il n’est pas dans les dépôts de debian, il faut donc télécharger le .deb (version 64-bit, version 32-bit) directement sur leur site, puis l’installer avec dpkg.


root@judicael:~# wget ftp://ftp.openl2tp.org/releases/openl2tp-1.8/debian-squeeze/openl2tp_1.8-1_amd64.deb
root@judicael:~# dpkg -i openl2tp_1.8-1_amd64.deb
root@judicael:~# apt-get -f install # pour installer les dépendances

Il faut maintenant configurer openl2tpd.
Il faut savoir que les tunnels L2TP se montent dans des sessions L2TP. Il peut y avoir plusieurs tunnels par session, même si ce n’est pas le cas le plus répendu.
C’est dans ce fichier que nous disons quel est le port UDP depuis lequel nous allons répondre, où aller authentifier les clients, ainsi que notre endpoint IPv4. L’IPv6 se configure directement dans ppp.
Celà nous donne donc un fichier de conf du genre de


# system

# peer profiles

# tunnel profiles
tunnel profile modify profile_name=default \
       our_udp_port=1701 \

# session profiles

# ppp profiles
ppp profile modify profile_name=default \
       use_radius=yes \
       radius_hint=/etc/radiusclient/radiusclient.conf \
       auth_pap=no \
       auth_mschapv1=no \
       auth_mschapv2=no \
       auth_eap=no \
       auth_none=no \
       local_ipaddr=89.234.186.4 \

# locally created tunnels and sessions

Le PPP

Nous voulons de l’IPv6, il faut donc ajouter l’option +ipv6 à la fin de /etc/ppp/options. Ceci va activer le support d’IPv6 dans PPP (vous aurez une fe80 sur vos interfaces ppp) mais ce n’est pas pour autant que tout va fonctionner. Il faut ajouter des scripts dans /etc/ppp/ipv6-up.d/ et dans /etc/ppp/ipv6-down.d/, et ne pas oublier de les rendre exécutables.
L’IPv6 fonctionne avec du SLAAC, nous installons radvd afin d’envoyer des RA sur les interfaces ppp.
Le PPP remonte les informations qu’il obtient du radius et les place dans /run/radattr.$PPP_IFACE, nous allons parser ce fichier afin de configurer le radvd en conséquence.
Les scripts que nous utilisons sont les suivants :


root@judicael:~# cat /etc/ppp/ipv6-up.d/vpn 
#!/bin/sh

prefix_interco=$(awk '$1 == "Framed-IPv6-Prefix" { print $2 }' /run/radattr.$PPP_IFACE)
prefix_deleg=$(awk '$1 == "Delegated-IPv6-Prefix" { print $2 }' /run/radattr.$PPP_IFACE)

ip -6 route add $prefix_interco dev $PPP_IFACE

echo "
interface $PPP_IFACE
{
	AdvSendAdvert on;
	IgnoreIfMissing on;

	prefix $prefix_interco {};
};
# $PPP_LOCAL $PPP_REMOTE
" > /run/vpn/radvd-user.${PPP_IFACE}.conf
echo "interface lo {};" > /run/vpn/radvd-vpn.conf
cat /run/vpn/radvd-user.*.conf >> /run/vpn/radvd-vpn.conf

kill -HUP $(cat /run/radvd/radvd.pid)

ip -6 route add $prefix_deleg via $PPP_REMOTE dev $PPP_IFACE
root@judicael:~# cat /etc/ppp/ipv6-down.d/vpn 
#!/bin/sh

rm -f /run/vpn/radvd-user.${PPP_IFACE}.conf
echo "interface lo {};" > /run/vpn/radvd-vpn.conf
cat /run/vpn/radvd-user.*.conf >> /run/vpn/radvd-vpn.conf
kill -HUP $(/run/radvd/radvd.pid)

ip -6 route del $prefix dev $PPP_IFACE

Il faut aussi vérifier que les attributs sont des mêmes types dans /etc/radiusclient/dictionary et /usr/share/freeradius/dictionary*, le second faisant foi.

L’IPsec

Si vous trouviez ça difficile jusqu’ici, ça va devenir encore pire :p
Avant de continuer, assurez vous que le openl2tp et ppp fonctionnent, l’IPsec ne va pas les faire marcher miraculeusement, il ne sert qu’à chiffrer ce qui passe dans le tunnel L2TP.

Pour l’IPsec, nous avons choisi strongswan. La version dans les dépôts de wheezy est très vielle, je vous conseille d’utiliser la version des backports. Il se base sur le modèle X509 pour chiffrer et authentifier.

Nous devons commencer par corriger les certificats. On a besoin d’un certificat d’une AC quelconque. On place le certificat de l’autorité dans un fichier .pem dans le dossier /etc/ipsec.d/cacerts. On place notre certificat obtenu dans /etc/ipsec.d/aacerts et dans /etc/ipsec.d/certs. On place la clef privée dans /etc/ipsec.d/private.
Il faut dire quelle est la clé privée utilisé pour chiffrer les connexion. On spécifie cette option dans /etc/ipsec.secrets avec : RSA "vpn.grifon.fr.key" (les deux-points sont inclus). Les mots de passe seront à mettre à la suite dans ce fichier.
Une fois ceci fait, il faut préparer notre strongswan à recevoir des connexions depuis les clients VPN, on met donc ceci dans /etc/ipsec.conf :


conn %default
	ikelifetime=60m
	keylife=20m
	rekeymargin=3m
	keyingtries=1
	keyexchange=ikev2

conn client
	left=%any
	leftid=*@vpn.grifon.fr
	leftauth=eap-ttls
	leftfirewall=yes
	right=vpn.grifon.fr
	rightid="C=FR, ST=Bretagne, L=Cesson Sevigne, O=GRIFON, OU=VPN, CN=vpn.grifon.fr"
	rightauth=eap
	rightsendcert=never
	type=transport
	auto=add
	mobike=yes

include /var/lib/strongswan/ipsec.conf.inc

Côté client

L’IPsec

Nous commençons par mettre en place l’IPsec afin d’éviter que les identifiants se baladent en clair sur Internet.

Il faut également installer strongswan, de la même manière que pour le serveur. Par contre la configuration est différente :


config setup
       plutostart=no

conn %default
       ikelifetime=60m
       keylife=20m
       rekeymargin=3m
       keyingtries=1
       keyexchange=ikev2

conn grifon
       leftid=$utilisateur@vpn.grifon.fr
       leftfirewall=yes
       leftauth=eap-ttls
       right=vpn.grifon.fr #ici l'IPv4 de la machine de grifon
       rightid="C=FR, ST=Bretagne, L=Cesson Sevigne, O=GRIFON, OU=VPN, CN=vpn.grifon.fr"
       rightsendcert=never
       rightauth=eap
       type=transport
       auto=start
       closeaction=restart

Le mot de passe doit également être mis dans /etc/ipsec.secrets sous la forme $utilisateur@vpn.grifon.fr : EAP "motdepasseutilisateur".

Le L2TP

Tout comme pour l’IPsec, le programme est le même, seule la configuration diffère.

Dans /etc/openl2tp.conf :

# system

# peer profiles

# tunnel profiles

# session profiles

# ppp profiles
ppp profile create profile_name=grifon
ppp profile modify profile_name=grifon \
       auth_chap=yes \


# locally created tunnels and sessions
tunnel create tunnel_name=l2tp17507 dest_ipaddr=89.234.186.3 \

session create tunnel_name=l2tp17507 \
       ppp_profile_name=grifon \
       user_name=monuser \
       user_password=monmotdepasse

Il faut également utiliser des scripts ppp afin d’avoir de l’IPv6 et de faire passer tout les flux (v4 et v6) au travers du VPN.

alarig@debian-backports:~$ cat /etc/ppp/ip-up.d/grifon 
#!/bin/sh

defaultroute="$(ip route list | grep default | cut -d ' ' -f 3)"

ip route add 89.234.186.3/32 via $defaultroute

ip route add 0.0.0.0/1 dev ppp0
ip route add 128.0.0.0/1 dev ppp0

ip route add 10.0.0.0/8 via $defaultroute
ip route add 172.16.0.0/12 via $defaultroute
ip route add 192.168.0.0/16 via $defaultroute
alarig@debian-backports:~$ cat /etc/ppp/ip-down.d/grifon 
#!/bin/sh

ip route del 0.0.0.0/1 dev ppp0
ip route del 128.0.0.0/1 dev ppp0
alarig@debian-backports:~$ cat /etc/ppp/ipv6-up.d/grifon 
#!/bin/sh

prefix="$(ip -6 addr show ppp0 | grep global | cut -d ' ' -f 6 | cut -d ':' -f 1,2,3,4)"

ip -6 route add 2000::/3 dev ppp0
ip -6 addr add $prefix::1/64 dev ppp0
alarig@debian-backports:~$ cat /etc/ppp/ipv6-down.d/grifon 
#!/bin/sh

ip -6 route del 2000::/3 dev ppp0

Notons qu’il est également possible d’utiliser une autre table de routage pour que le VPN ne soit utilisé que si l’on veut joindre l’IP du VPN et que tout le reste du trafic passe par la route par défaut. Il faut alors utiliser les commandes suivantes :


echo "200 grifon" >> /etc/iproute2/rt_tables
ip route add default via 89.234.186.4 table grifon
ip route add 89.234.186.0 dev ppp0 src $votreipgrifon table grifon
ip rule add from $votreipgrifon table grifon

Pour finir, on charge le fichier de conf de openl2tp et ça devrait marcher.

root@ # service ipsec restart
root@ # service openl2tp restart
root@ # l2tpconfig
l2tp>config restore file=/etc/openl2tp.conf
l2tp>exit

Réplication master/master entre deux serveurs mail avec dovecot-dsync

2015-08-28T15:59:24+02:00

En gros, ça sert à éviter de faire exploser votre queue de mails

Peut-être avez-vous déjà un serveur mail secondaire pour votre domaine, qui discutent entre eux avec du SMTP tout simple. Cela fonctionne très bien tant que le serveur principal n’est pas trop longtemps dans le noir, sinon vous verrez votre queue grandir de façon démentielle (enfin, celle de postfix).
Il existe alors une parade à ce problème si vous avez installé dovecot, le dsync. Ce n’est plus postfix, mais dovecot qui se chargera de synchroniser les mails entre les deux serveurs, allégeant ainsi le premier.

Il y a quelques vérifications à faire avant d’entamer la configuration

Dans mon cas, je veux synchroniser un serveur sous gentoo avec un autre sous debian oldstable (wheezy à ce jour). Or dans le wiki de dovecot, il est précisé « NOTE: v2.2 is highly recommended for this. Earlier versions can't do incremental metadata syncing. This means that the more mails a mailbox has, the slower it is to sync it. ». Et comme debian aime bien les paquets pas à jour, il faut commencer par prendre la version des backports.
Une fois ceci fait, il faut s’assurer que doveadm user '*' ressorte bien la liste des utilisateurs. Et ce, sur les deux serveurs. J’utilise un backend MySQL, il faut donc que dans le fichier /etc/dovecot/dovecot-sql.conf.ext j’ai un truc du genre iterate_query = SELECT username AS user FROM mailbox;.
Sous gentoo, je n’ai pas eu à modifier les useflags pour utiliser dsync.

Et maintenant on peut configurer

Dans /etc/dovecot/conf.d/10-mail.conf il faut ajouter replication à la variable mail_plugins : mail_plugins = $mail_plugins [vos autres plugins] replication.
Puis, dans /etc/dovecot/conf.d/10-master.conf, on ajoute

service doveadm {
	inet_listener {
		port = $port
		ssl = yes
	}
}
doveadm_port = $port
doveadm_password = $passwd
service replicator {
	process_min_avail = 1
	unix_listener replicator-doveadm {
		mode = 0600
	}
}
service aggregator {
	fifo_listener replication-notify-fifo {
		user = dovecot
	}
	unix_listener replication-notify {
		user = dovecot
	}
}

Les valeurs commençant par un dollar sont à remplacer selon votre envie, il faut juste être cohérent :).
Pour l’utilisateur du service aggregator, j’utilise dovecot sous debian et mail sous gentoo.
Ensuite, il faut éditer /etc/dovecot/conf.d/90-plugin.conf pour préciser le serveur avec lequel on veut synchroniser les mails :

plugin {
[autres variables]
mail_replica = tcps:$fqdn_du_serveur_en_face
}

Enfin, comme je suis un gros psychomaniaque du chiffrement, il faut préciser les paramètres SSL dans /etc/dovecot/conf.d/10-ssl.conf :


ssl = yes
ssl_cert = </etc/ssl/certs/swordarmor.fr.crt
ssl_key = </etc/ssl/private/swordarmor.fr.key
ssl_client_ca_dir = /etc/ssl/certs/

Tests et conclusion

Pour tester votre configuration, vous pouvez utiliser doveadm sync -A -d et vérifier que vous avez bien tous les mails de l’autre côté. Attention cependant, la synchronisation peut prendre pas mal de temps la première fois.
Si ça fonctionne, réglez le postfix du secondaire pour lui dire qu’il n’est plus serveur secondaire mais serveur principal sur votre domaine (oui, vous aurez deux serveurs principaux). Avec tout ceci, vous devriez pouvoir éteindre l’un des deux serveurs deux semaines si vous voulez et quand même avoir accès à tous vos mails en IMAP.

Router son bloc IPv6 /48 pour ses VMs chez online.net

2015-04-29T21:07:06+02:00

Jusqu’à aujourd’hui je n’utilisais qu’une IPv6 chez online, tout tournait sur la même machine. Puis, je me suis dit que ça serait pas mal de séparer un peu les choses, simplement parce que je ne savais pas le faire.
Je suis parti sur des containers LXC. Alors oui, je sais, ce n’est pas le plus sécurisé et tout, mais là le but pour moi est juste de connaître les bases (surtout au niveau réseau), pas de faire un truc qui résistera à des attaques que je ne subis pas. Au passage, le fait de faire des containers m’évite la surcouche matérielle pour chaque machine, mon serveur n’aurait pas résisté.

Histoire de ne pas faire trop compliqué je ne vais utiliser que deux machines pour cet exemple : la machine physique est ginette et le container LXC est rodolphe.
Configuration IP de ginette avant toute modification :


root@ginette:~# ip addr show 
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether c8:0a:a9:03:3c:8f brd ff:ff:ff:ff:ff:ff
   inet 195.154.116.3/24 brd 195.154.116.255 scope global eth0
       valid_lft forever preferred_lft forever
   inet6 2001:bc8:3c56:100::1/56 scope global 
       valid_lft forever preferred_lft forever
   inet6 fe80::ca0a:a9ff:fe03:3c8f/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether c8:0a:a9:03:3c:90 brd ff:ff:ff:ff:ff:ff
root@ginette:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

iface eth0 inet6 static
	address 	2001:bc8:3c56:100::1
	netmask		56
	accept_ra	1
	pre-up /sbin/dhclient -1 -v -pf /run/dhclient6.eth0.pid -lf /var/lib/dhcp/dhclient6.eth0.leases -cf /etc/dhcp/dhclient6.conf -6 -P eth0
	pre-down /sbin/ip -6 addr del 2001:bc8:3c56:100::1/56 dev eth0

La ligne pre-up dans /etc/network/interfaces vient du wiki online. Je ne m’attarderai pas dessus, je vous conseille de le lire pour savoir comment générer vos DIUD et comment configurer votre machine.
Comme vous pouvez le voir, j’ai délégué tout un /56 (et non un /64) à ma machine, afin de pouvoir le découper en différents /64 plus proprement par la suite.

Comme je compte faire du LXC, ça peut être bien de l’installer : apt-get install lxc, on vérifie ensuite qu’il y a tout ce qu’il faut sur la machine avec lxc-checkconfig et pour finir on crée un container avec MIRROR=http://mirrors.online.net/debian lxc-create -n rodolphe -t debian -- -r wheezy
À ce moment, il peut être intéressant de savoir ce que LXC fait au niveau réseau.


root@ginette:~# ip addr show 
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether c8:0a:a9:03:3c:8f brd ff:ff:ff:ff:ff:ff
    inet 195.154.116.3/24 brd 195.154.116.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:bc8:3c56:100::1/56 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ca0a:a9ff:fe03:3c8f/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether c8:0a:a9:03:3c:90 brd ff:ff:ff:ff:ff:ff
4: lxcbr0:  mtu 1500 qdisc noqueue state UP group default 
    link/ether fe:38:cd:72:d6:e5 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::fc38:33ff:fee1:275f/64 scope link 
       valid_lft forever preferred_lft forever
8: vethBCTHMQ:  mtu 1500 qdisc pfifo_fast master lxcbr0 state UP group default qlen 1000
    link/ether fe:38:cd:72:d6:e5 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc38:cdff:fe72:d6e5/64 scope link 
       valid_lft forever preferred_lft forever

En voyant cela je me dis que lxcbr0 sert d’interface entre le réseau physique et le réseau LXC, je décide donc d’y ajouter la première IPv6 d’un /64 découlant de mon /56 : ip -6 addr add 2001:bc8:3c56:101::1/64 dev lxcbr0.
Ensuite, je me mets dans mon container et je lui attribue l’IP suivante et je configure la route par défaut :


root@rodolphe:~# ip -6 addr add 2001:bc8:3c56:101::2/64 dev eth0
root@rodolphe:~# ip -6 route add default via 2001:bc8:3c56:101::1 dev eth0
root@rodolphe:~# root@rodolphe:~# ping6 2001:bc8:3c56:101::1
PING 2001:bc8:3c56:101::1(2001:bc8:3c56:101::1) 56 data bytes
64 bytes from 2001:bc8:3c56:101::1: icmp_seq=1 ttl=64 time=0.090 ms
64 bytes from 2001:bc8:3c56:101::1: icmp_seq=2 ttl=64 time=0.116 ms
64 bytes from 2001:bc8:3c56:101::1: icmp_seq=3 ttl=64 time=0.116 ms
^C
--- 2001:bc8:3c56:101::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.090/0.107/0.116/0.014 ms

Le ping6 est là uniquement pour m’assurer que j’ai ajouté l’IPv6 sur la bonne interface de la machine physique, il semblerait que oui.
À ce moment, tout le monde est près à communiquer en IPv6, il ne reste plus qu’à activer le routage sur la machine physique : sysctl net.ipv6.conf.all.forwarding=1
Sauf qu’en activant le routage on ignore les RA des routeur d’online et on ne peut plus joindre notre machine en IPv6. Il faut alors forcer la prise en compte des RA malgré l’activation du routage : sysctl net.ipv6.conf.eth0.accept_ra=2
Et là normalement vous devriez pouvoir joindre votre container en IPv6 et également sortir en IPv6 depuis ce container :


alarig@pikachu ~ $ traceroute6 rodolphe.swordarmor.fr 
traceroute to rodolphe.swordarmor.fr (2001:bc8:3c56:101::2), 30 hops max, 80 byte packets
 1  drscott.swordarmor.fr (2001:470:1f13:138::1)  0.183 ms  0.166 ms  0.151 ms
 2  alarig-1.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:138::1)  67.437 ms  70.337 ms  72.927 ms
 3  ge2-3.core1.par1.he.net (2001:470:0:7b::1)  73.396 ms  73.390 ms  73.457 ms
 4  10ge9-1.core1.par2.he.net (2001:470:0:1b0::2)  74.513 ms  74.502 ms  74.496 ms
 5  online.equinix-ix.fr (2001:7f8:43::1:2876:1)  113.226 ms  113.185 ms  113.190 ms
 6  2001:bc8:0:1::45 (2001:bc8:0:1::45)  75.511 ms  75.132 ms  73.964 ms
 7  2001:bc8:0:1::76 (2001:bc8:0:1::76)  73.343 ms  27.323 ms  21.447 ms
 8  ginette.swordarmor.fr (2001:bc8:3c56:100::1)  21.341 ms  21.320 ms  21.294 ms
 9  rodolphe.swordarmor.fr (2001:bc8:3c56:101::2)  21.269 ms  21.390 ms  21.272 ms

root@rodolphe:~# traceroute6 pokedex.swordarmor.fr
traceroute to pokedex.swordarmor.fr (2001:470:1f13:138:715d:2fa0:b591:532f), 30 hops max, 80 byte packets
 1  2001:bc8:3c56:101::1 (2001:bc8:3c56:101::1)  0.124 ms  0.074 ms  0.066 ms
 2  2001:bc8:2::2:125:1 (2001:bc8:2::2:125:1)  0.986 ms  0.970 ms  0.940 ms
 3  2001:bc8:0:1::79 (2001:bc8:0:1::79)  0.974 ms  1.244 ms  1.251 ms
 4  2001:bc8:0:1::1 (2001:bc8:0:1::1)  1.092 ms  0.996 ms  0.927 ms
 5  he.franceix.net (2001:7f8:54::10)  0.700 ms  0.660 ms  0.881 ms
 6  10ge3-1.core1.par1.he.net (2001:470:0:1b0::1)  0.896 ms  0.968 ms  0.912 ms
 7  tserv1.par1.he.net (2001:470:0:7b::2)  3.772 ms  6.530 ms  9.269 ms
 8  alarig-1-pt.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:138::2)  24.777 ms  24.680 ms  18.963 ms
 9  bulbizarre.swordarmor.fr (2001:470:1f13:138:715d:2fa0:b591:532f)  18.843 ms  18.742 ms  18.344 ms

Maintenant, il faut mettre cette configuration dans les fichiers pour que ça résiste au reboot.
Dans le container c’est très simple :


root@rodolphe:~# cat /etc/network/interfaces 
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
iface eth0 inet6 static
	address	2001:bc8:3c56:101::2
	netmask	64
	up	ip -6 route add default via 2001:bc8:3c56:101::1 dev eth0
	down	ip -6 route del default via 2001:bc8:3c56:101::1 dev eth0

Ça se corse un peu pour la machine physique. Il faut d’abord ajouter net.ipv6.conf.all.forwarding=1 à /etc/sysctl.conf.
Ensuite, il faut modifier un peu le fichier /etc/network/interfaces afin d’ajouter l’IP à l’interface LXC et de quand même recevoir les RA :


root@ginette:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

iface eth0 inet6 static
	address 	2001:bc8:3c56:100::1
	netmask		56
	accept_ra	2
	pre-up		/sbin/dhclient -1 -v -pf /run/dhclient6.eth0.pid -lf /var/lib/dhcp/dhclient6.eth0.leases -cf /etc/dhcp/dhclient6.conf -6 -P eth0
	up		ip -6 addr add 2001:bc8:3c56:101::1/64 dev lxcbr0
	pre-down	/sbin/ip -6 addr del 2001:bc8:3c56:100::1/56 dev eth0

Je n’ai volontairement pas fait de RA sur mon réseau interne parce que je sais déjà comment on fait, mais ça aurait parfaitement pu être possible.

Installer son propre résolveur DNS pour contourner la censure du gouvernement

2015-03-17T17:07:06+01:00

Contexte

Vous le savez peut-être déjà mais le gouvernement a fait voter une loi qui lui permet de censurer n’importe quel site s’il ne correspond pas à ses attentes. Feu islamic-news.info vient d’en faire les frais. La question ici n’est pas de déterminer si ce site est effectivement peu fréquentable ou pas, mais de savoir se prémunir de ce genre de pratiques vu qu’elles se font sans l’intervention du juge.

Savoir comment ça marche pour savoir comment se protéger

Afin de mettre en œuvre cette censure, le gouvernement utilise la méthode dite du « DNS menteur ». Le DNS pour Domain Name System est un protocole utilisé sur Internet pour traduire le nom de domaine d’un site en adresse IP compréhensible par tous les PCs, serveurs et routeur. Si nous prenons l’exemple de ce site, nous voyons qu’il correspond aux IPs 89.234.140.133, 2001:470:1f13:138:715d:2fa0:b591:532f et 2a00:5881:4008:400::1 :

$ dig +short A www.swordarmor.fr
pokedex.swordarmor.fr.
89.234.140.133

$ dig +short AAAA www.swordarmor.fr
pokedex.swordarmor.fr.
2001:470:1f13:138:715d:2fa0:b591:532f
2a00:5881:4008:400::1

Si nous allons un peu plus loin dans la technique, nous remarquons que ces réponses ne tombent pas du ciel, elle viennent d’un serveur. Quand ce serveur sert à résoudre des noms de domaine en adresse IP, on dit que l’on a affaire à un résolveur DNS. Généralement vous utilisez celui de votre FAI, mais nous verrons que nous ne sommes pas du tout obligés.
En effet, si nous n’utilisons pas un résolveur DNS sur lequel nous avons un minimum de contrôle nous nous exposons à des réponses erronées, d’où l’appellation de « DNS menteur ». Nous le voyons très bien dans le cas de islamic-news.info :

$ dig +short islamic-news.info @192.168.0.254 # derrière une freebox
90.85.16.52

$ dig +short islamic-news.info @192.168.1.1 # derrière une livebox
90.85.16.52

$ dig +short islamic-news.info @192.168.0.2 # chez moi
37.59.14.72

Les DNS de free et orange mentent alors que le mien donne bien la bonne IP.

Savoir comment faire pour savoir comment se protéger

Il va maintenant être temps de passer à l’action. La solution que je propose consiste à s’intaller son propre résolveur dans un coin et à l’utiliser au lieu d’utiliser celui du FAI.
Comme tout service qui devra être disponible en permanance, il faut l’installer sur une machine qui tourne sans arrêt. Cependant, un résolveur DNS ne prend vraiment pas beaucoup de ressources, vous devriez pouvoir le faire tourner sur à peu près tout : beaglebone, rasberry pi, vielle tour qui ne sert plus (c’est mon cas, et ça marche parfaitement bien du haut de ses 256 Mo de RAM, son PIII 600 MHz et ses 8 Go de disque).
Ensuite, installez la distribution linux de votre choix, puis le résolveur à proprement parlé avec apt-get install unbound sur debian (et debian-based) ou emerge unbound sur gentoo, ou tout autre commande en fonction de votre gestionnaire de paquets.
Pour finir, mettez un configuration du genre dans /etc/unbound/unbound.conf en faisant attention aux commentaires.

server:
	auto-trust-anchor-file: "/var/lib/unbound/root.key"

access-control: 192.168.0.0/16 allow_snoop
access-control: 10.0.0.0/8 allow_snoop
access-control: 172.16.0.0/12 allow_snoop
access-control: 127.0.0.0/8 allow_snoop

interface: 127.0.0.1	# obligatoire
interface: 0.0.0.0	# Pour écouter sur toutes les interfaces, à la fois en
interface: ::0		# IPv4 et en IPv6

Pour tester votre résolveur, faites dig swordarmor.fr @$IPduResolveur et normalement vous devriez avoir une réponse en 95.130.9.160.
Si cela fonctionne, vous pouvez maintenant dire au serveur DHCP de votre box de l’annoncer dans ses réponses (ou offres) DHCP. Vous devriez trouver comment faire si vous tappez « dns dhcp monFAIbox » ou un truc du genre dans votre moteur de recherche préféré.

Le source-specific routing sous linux 3.12 et supérieur

2015-02-21T14:46:17+01:00

D’abord définissons ce qu’est le source-specific routing

Le source-specific routing se traduit en français par « routage en fonction de la source ». En termes moins barbares, cela veut dire que l’on enverra nos paquets via une route différente en fonction de leur provenance. Cela sert par exemple quand on a plusieurs accès internet sur une machine, et que l’on veut répartir la charge entre les deux. Nous pouvons aussi en avoir l’utilité si l’on veut redonder un serveur.

Et voici comment ça fonctionne

Je suis pour ma part dans le cas où je veux redonder mon serveur chez moi. Qui dit serveur à la maison, dit serveur sur mon réseau local, donc sans forcément d’IPv4 publique dessus.
Comme je n’avais pas envie de m’embêter avec les redirections NAT et que je voulais être sûr d’avoir une IP fixe, j’ai choisi de prendre un VPN chez Illyse qui tombe directement sur mon serveur. Ainsi, je peux changer de FAI comme je veux, l’IP publique de mon serveur ne changera pas et je résiste aussi à toutes les règles de filtrage qui peuvent m’être imposées. Ce VPN m’offre une IPv4 fixe et un bloc IPv6 /56.
Et aussi, comme j’aime bien jouer, j’ai un tunnel 6in4 qui arrive chez moi depuis he.net et qui me permet d’avoir de l’IPv6 sur tout mon réseau local alors que numéricâble ne sait pas faire ça. Je me suis donc retrouvé avec deux IPv6 publiques sur mon serveur : 2001:470:1f13:138:715d:2fa0:b591:532f/64 par he et 2a00:5881:4008:400::1/56 par Illyse.
S’est alors posée la question « comment puis-je être joignable via ces deux IPs sachant que je n’ai qu’une seule route par défaut ? ».

2001:470:1f13:138::/64 dev eth0  proto kernel  metric 4 
2a00:5881:4008:400::/64 dev tun0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via fe80::250:fcff:fe4d:c3a4 dev eth0  metric 1024

En effet, avec une seule route par défaut, tous les paquets IP ressortiront via la même interface, pour ma part eth0. Auparavant il fallait jouer avec ip rules, créer plusieurs tables de routage et composer avec tout ça. Si cela vous intéresse, vous pouvez regarder sur lartc.org comment procéder. Pour ma part je trouve que ça fait un peu mal aux cheveux.
Et bien depuis la version 3.12 du kernel Linux et la clause from, il suffit de deux commandes :

ip -6 route add
    default dev tun0 from 2a00:5881:4008:400::/56

ip -6 route
    add default via fe80::250:fcff:fe4d:c3a4 dev eth0 from
    2001:470:1f13:138::/64

si je veux répondre sur une IP dans chacun de ces réseaux, sur leur interface respective. Nous obtenons alors une table de routage du genre de :

default from 2001:470:1f13:138::/64 via fe80::250:fcff:fe4d:c3a4 dev eth0  metric 1024 
default from 2a00:5881:4008:400::/56 dev tun0  metric 1024 
2001:470:1f13:138::/64 dev eth0  proto kernel  metric 4 
2a00:5881:4008:400::/64 dev tun0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via fe80::250:fcff:fe4d:c3a4 dev eth0  metric 1024

Ainsi, mon serveur saura quelle interface utiliser en fonction de l’adresse source.

Pas de ssl en localhost avec spampd et postfix

2014-07-24T18:16:22+02:00

J’utilise postfix comme serveur mail et spampd pour filtrer les spams. Il y a peu j’ai eu envie de me mettre au TLS/SSL. J’ai alors rencontré un problème de timeout sur localhost:10025, les logs disaient « Cannot start TLS: handshake failure » et « SSL_connect error to 127.0.0.1[127.0.0.1]:10025: Connection timed out » à chaque fois qu’un mail devait passer par l’anti-spam.
Le problème est dû à postfix qui veut absolument faire du SSL/TLS et spampd qui ne sait pas le faire. Ma conf avant était :

# TLS parameters
smtpd_tls_cert_file =	/etc/ssl/certs/smtp.swordarmor.fr.crt
smtpd_tls_key_file =	/etc/ssl/private/smtp.swordarmor.fr.key
smtpd_tls_CAfile =	/etc/ssl/certs/cacert.org.pem
smtpd_tls_CApath =	/etc/ssl/certs

smtpd_tls_security_level =	may
smtpd_tls_auth_only =		no

smtpd_tls_session_cache_database =	btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout =	3600s
tls_random_source =			dev:/dev/urandom

smtpd_tls_received_header =	yes
smtpd_tls_loglevel =		1

smtp_tls_session_cache_database =	btree:${data_directory}/smtp_scache
smtp_tls_security_level =		may
smtp_tls_loglevel =			1

# Content filtering
content_filter = smtp:127.0.0.1:10025

La solution vient avec le paramètre smtp_tls_policy_maps. Il faut ajouter

smtp_tls_policy_maps =			hash:/etc/postfix/tls_policy

Dans /etc/postfix/tls_policy je mets

localhost:10025	none
127.0.0.1:10025	none
::1:10025	none

Attention, il faut penser à mettre le port sur lequel tourne l’anti-spam. Au début je m’étais fait avoir en ne mettant que localhost. Aussi, il ne faut pas oublier de hasher le fichier avec postmap.

Avoir du mail propre

2014-07-11T18:11:12+02:00

Par propre, j’entends ne pas se faire voler ses correspondances en toute impunité par des services d’espionnage.

Les enjeux

Dans un monde où la surveillance généralisée (PRISM, Echelon, loi de programmation militaire, etc.) devient monnaie courante et où presque toutes nos communications se font via des moyens de communication électronique, se protéger devient essentiel.
Je vais ici parler d’un système très utilisé, le mail.

Les façons d’agir

Utiliser un serveur « NSA proof »

C’est une étape très importante. En effet, si les services de renseignement veulent connaître les correspondances d’une personne avec une adresse en @gmail.com ou @hotmail.com, il leur suffit d’aller sur les serveurs de google ou microsoft et de prendre ce qui les intéresse.
C’est très simple pour eux puisqu’ils ont déjà les accès, ça a été prouvé avec les révélations d’Edward Snowden. De plus, en une opération ils ont accès à des millions de comptes.
Si vos mails sont gérés par de plus petites structures, cela leur demandera plus de travail pour un résultat similaire voire moindre puisqu’il leur faudra demander les mails à plus de monde. D’ailleurs personne n’est tenu d’accepter.
Pour se faire, vous pouvez soit utiliser votre propre serveur ou si vous n’avez pas l’envie ou les compétences de le faire, utiliser un serveur dans lequel vous avez confiance. Dans ce cas je vous conseille gozmail.

Et encore mieux, chiffrer

Le contenu du mail

Nous avons ici deux options, PGP ou S/MIME. Le premier se base sur des clés GPG et le deuxième sur des certificats x509. J’utilise PGP pour ma part donc je vais vous présenter cette méthode.
Comme pour tout chiffrement digne de ce nom, il faut qu’il soit fait chez vous, depuis votre client mail et non sur un serveur à Katmandou depuis un webmail, d’ailleurs on ne devrait jamais utiliser de webmail. Ensuite, il faut faire en sorte que votre client sache faire du PGP. C’est inclus de base dans mutt, pour thunderbird il faut utiliser le plugin enigmail. Il vous faut alors générer votre clé PGP associée à votre adresse (avec enigmail vous aurez un assistant qui vous expliquera comment faire, vous pouvez aussi suivre le tutoriel de ubuntu-fr).
Pour finir, échangez votre clé publique (et non privée qui doit le rester) avec vos autres contacts et vous êtes prêt à envoyer des mails chiffrés en PGP. La mienne peut-être trouvée sur les serveurs de clés ou bien chez moi.
Attention, si vous signez publiquement des clés PGP, n’oubliez pas que vous créez un réseau de confiance. Votre signature ne vaut plus rien si vous signez à volo.

Lors du transport du mail

Ça s’adresse ici à ceux qui ont leur propre serveur mail.
Grâce au protocole DANE, nous pouvons mettre le fingerprint de notre certificat SSL dans le DNS et ainsi dire aux autres serveurs de communiquer de manière chiffrée en utilisant ce certificat.
Bortz a fait un article simple et efficace pour savoir comment configurer postfix avec TLS / SSL.

XMPP et OTR avec irssi

2014-07-02T00:01:00+02:00

Introduction à XMPP

Je vais reprendre la présentation que j’ai faite pour gozmail.net.
XMPP (ou Jabber) est un protocole de discussion instantanée, un peu comme IRC ou MSN à son époque. Par rapport à MSN, il a le gros avantage d’être libre et par rapport à IRC, il offre la possibilité de faire des appels audio et vidéo ainsi que les messages hors-ligne. Comme tout protocole, il nécessite un client. Jusqu’à présent j’utilisais pidgin en graphique mais il me fallait quelque chose que je puisse mettre à côté de mon client IRC dans mon tmux. Si vous voulez de plus amples informations sur le protocole, vous pouvez consulter le wiki de jabberfr.

Maintenant, la partie pratique

Pour utiliser irssi, il vous faut bien sûr l’installer : apt-get install irssi irssi-plugin-otr irssi-plugin-xmpp.
Ensuite, il faut que irssi charge les modules pour OTR et XMPP au démarrage : echo "load xmpp" >> ~/.irssi/startup && echo "load otr" >> ~/.irssi/startup. Si vous ne voulez pas redémarrer irssi, faites en plus /LOAD xmpp et /LOAD otr.
irssi doit savoir à quel serveur il doit se connecter. Il nous faut donc éditer ~/.irssi/config :

Dans la section servers, ajoutez

  {
    address = "gozmail.net";
    chatnet = "gozmail.net";
    port = "5222";
    password = "$votremotdepasse";
    use_ssl = "no";
    ssl_verify = "yes";	// mettre à no si irssi sort des erreur de vérification
			// du certificat SSL (et que vous êtes sûr que ce n’est
			// pas une attaque MITM)
    autoconnect = "yes";
  }

et dans la section chatnets, ajoutez

  "gozmail.net" = { type = "XMPP"; nick = "alarig@gozmail.net/irssi"; };

J’ai ici pris l’exemple du serveur gozmail.net, c’est bien évidement à ajuster chez vous. Pour connaître le serveur à mettre dans address, faites dig +short _xmpp-client._tcp.$votredomaine. Le troisième chiffre est le port à utiliser et ensuite vient le FQDN du serveur jabber. Si cela ne donne rien, mettez simplement votre domaine et le port 5222.
L’option chatnet de la section servers doit être en accord avec ce que vous mettez entre guillemets dans la section chatnets.

Lorsque vous démarrez irssi, vous devriez voir un truc du genre :

23:10 -!- Irssi: Loaded module xmpp/core
23:10 -!- Irssi: Loaded module xmpp/text
23:10 -!- Irssi: Loaded module xmpp/fe
23:10 -!- Irssi: Loaded module otr/core
23:10 [gozmail.net] -!- Irssi: Looking up gozmail.net
23:10 [gozmail.net] -!- Irssi: Connecting to gozmail.net [192.168.0.5] port 5222
23:10 [gozmail.net] -!- Irssi: Using STARTTLS encryption. 
23:10 [gozmail.net] -!- Irssi: Authenticated successfully. 
23:10 [gozmail.net] -!- Irssi: Requesting the roster. 
23:10 [gozmail.net] -!- Irssi: Connection to gozmail.net established

Les commandes de base

Se connecter à un serveur XMPP « en live » : /xmppconnect
Voir les contacts : /roster
Gérer les contacts : /presence
Parler à quelqu’un : /msg $debutdesonnom<tab> (de l’autocompletion en somme)

Je vous invite à lire une une doc plus complète.

Et la cerise sur le gâteau, OTR

OTR, pour Off-the-Record, permet de faire du chiffrement asymétrique pour de la messagerie instantanée. Au tout début, je vous ai fait installer irssi-plugin-otr et fait charger le plugin au démarrage d’irssi, il est donc d’ores et déjà utilisable. Si vous n’avez pas de clé OTR, générant vous une avec /otr genkey ${jig}@serveur. C’est un peu compliqué parce que le plugin croit que nous faisons de l’IRC, donc notre JID est pour lui notre nick et le paramètre address que nous avons spécifié au début, notre serveur. Pour moi ça donne donc /otr genkey alarig@gozmail.net@gozmail.net. Si vous avez déjà une clé, vous pouvez la mettre dans ~/.irssi/otr/otr.key en prenant garde de mettre le même format que pour la génération dans name et IRC pour le protocole. Ensuite pour l’échange de clé vous pouvez les faire avec /otr auth $secret ou alors avec /otr trust dans la fenêtre de discussion si vous voulez vérifier le fingerprint à la main. Je vous recommande également d’ajouter l’item otr à votre barre irssi : /statusbar window add otr, ça vous permettra de savoir si votre conversation est chiffrée ou pas.

Si vous avez des soucis, n’hésitez à passer me poser des questions sur IRC (vu que XMPP n’est pas encore sensé fonctionner), je suis alarig sur le chan #SwordArMor, serveur irc.swordarmor.fr

L’auto-hébergement ou comment avoir son serveur à la maison

2014-05-27T00:01:00+02:00

Qu’est-ce que l’auto-hébergement ?

Si l’on se réfère à la page wikipedia, c’est le fait d’héberger les services que nous utilisons le plus (ou que nous voulons offrir) sur sa propre machine, au lieu de le faire gérer par une boîte. Dans cet article, je vais me concentrer sur le cas où le serveur est à la maison et non chez un hébergeur.
Un serveur, ce n’est rien de plus qu’un PC (comme le votre) qui répond à des requêtes.

Les prérequis techniques

Ce qui est essentiel :

avoir un PC qui tourne h24 (forcément, pour répondre il faut que ça tourne),
avoir au moins une IP publique routable sur Internet (ça devrait être le cas tant que vous n’êtes pas en 3G),
pouvoir faire de la redirection de port si vous êtes en NAT, (pour ceux qui ne savent pas ce que c’est, je l’explique plus loin)
avoir un nom de domaine (au sens large, tails.boum.org est tout aussi valable que swordarmor.fr).

Ce qui est optionnel :

avoir un gros PC comme serveur,
avoir une IP fixe

Pour le coup, avoir un gros PC est même a éviter, ça va bouffer beaucoup de courant pour pas grand chose. Le mien est un iMac de récup' qui va facilement entrer dans sa dixième année et il fonctionne parfaitement bien. C’est dingue le peu de puissance que demande un OS un peu propre comme freeBSD ou GNU/Linux, et en plus il n’y a pas d’affichage à gérer.

Donc, le NAT. Pour faire simple, c’est dégueulasse. Pour faire plus impartial, ça veut dire Network Address Translation en anglais, pour traduction d’adresse réseau en français.
Il y a ici deux concepts à comprendre :

Pour discuter sur Internet, les ordinateurs utilisent des adresses IP (aussi appellées simplement IP).
En IPv4 (IPv6 n’étant que relativement déployé à l’heure où j’écris ces lignes) nous avons un nombre limité d’adresses, nous ne pouvons pas en attribuer une par PC. Ce que nous faisons donc est d’attribuer une IP publique à la box, puis des IPs privées aux ordinateurs.

Le NAT sert à faire ce partage d’IPs entre la box et les PCs.

Pour la redirection de port, cela conciste à dire que tel port de l’IP publique correspond à tel port de tel PC (donc de telle IP) de votre réseau local (aussi appellé LAN). Ceci est dû au NAT, car l’Internet s’arrête en réalité à votre box (comme c’est elle qui a l’IP publique). En effet, on ne peut pas joindre directement les PCs à l’intérieur du réseau local, ce qui complique les choses (et n’augmente pas la sécurité comme le disent certains, ça c’est le rôle du firewall).

Les détails techniques

Pour le PC que l’on mettra en serveur, le plus vieux au fond de le cave fera amplement l’affaire tant que c’est PIII. Si vous ne comptez pas faire tourner de java ou de ruby, vous serez à l’aise avec 512 Mo de RAM. Pour ce qui est du disque dur, 20 Go devraient être pas mal.

La méthode pour faire les redirections de port étant spécifique à chaque équipement, je ne vais pas pouvoir vous dire comme il faut faire. Par contre je suis preneur de screenshots pour illustrer l’article. Hébergez vos images sur pix.toile-libre.org et envoyez moi les liens par mail
J’ai reçu une capture d’écran qui montre comment faire avec SFR :

Ici, les ports 22 et 80 (respectivement SSH et HTTP) de l’IPv4 publique sont redirigés vers les ports 22 et 80 (ça aurait pu être des ports différents mais ce serait se compliquer la vie) de l’IP privée 192.168.1.86. Elle correspond à celle que vous obtenez avec un

ip addr show dev
			eth0

sur votre serveur. Les ports externes sont relatifs à l’IP publique et ceux de destination à l’IP privée.

Deux options s’offrent à vous si vous n’avez pas d’IP fix :

soit vous changez rarement donc c’est possible de changer l’entrée DNS à la main à chaque fois,
soit vous changez souvent d’IP (comme sur les lignes Orange) et là il vaut mieux utiliser un VPN qui lui a une IP fixe, celui de FDN est fait pour ça.

Si vous n’avez pas de domaine, je peux vous en faire à prix libre en .pennvad.eu, par contre il vous faudra une IP fixe, je n’ai pas envie de maintenir trouzemille entrées à la main.

Si on mettait les mains dans le cambouis

Installation physique de la machine

Vous avez maintenant une brique vaguement remplie d’électronique qui démarre. Branchez là par câble à votre réseau, surtout pas en Wi-Fi. Le Wi-Fi est lent, peu fiable et pas sécurisé, ce sera bien vite un nid à emmerde.
Prévoyez quand même un écran et un clavier pour l’installation du système d’exploitation. Nous ne devrions plus en avoir besoin par la suite.

Installation logicielle

Je vous recommande une distribution GNU/Linux standard, telle que debian.
Une fois que votre support d’installation est prêt, démarrez dessus et laissez les options par défaut jusqu’à ce que l’on vous demande quels types de logiciels vous voulez installez. Décochez tout sauf le serveur SSH et les utilitaires usuels du système.
Si vous avez des soucis pour installer Debian, vous pouvez lire le manuel simplifié écrit par debian-facile.org ou le manuel complet écrit par l’équipe de debian. Ce dernier est plus complet mais moins facile d’accès.

Redémarrez normalement puis éditez le fichier /etc/network/interfaces afin de mettre à la main l’IP locale de votre serveur au lieu d’en demandez une au DHCP. Ça vous évitera les mauvaises surprises si jamais ce dernier décide de changer son adressage et vous met vos règles NAT en carafe au passage.
Depuis votre PC habituel, connectez vous en SSH sur l’IP locale, installez vos services. Pour les tester, commencez par le faire en local. Ce n’est pas la peine de brûler cette étape, si ça ne marche pas en local, ça ne marchera pas non plus une fois les règles NAT mise en place.
Une fois que tout fonctionne correctement, configurez votre NAT pour qu’il redirige les bons ports vers la bonne machine en local et le tour est joué

Rien ne marche !

Vous pouvez bien sûr passer sur IRC pour me poser des questions, mais faites des recherches sur le net avant. Ça pullule de documentation et tutoriels sur comme se faire son serveur à la maison.

Login impossible des utilisateurs virtuels avec vsftpd

2013-05-10T00:01:00+02:00

Si comme moi vous venez de mettre à jour Debian 6 (squeeze) vers Debian 7 (wheezy) et que vous ne pouvez plus vous connecter à votre daemon vsftpd en utilisant des utilisateurs virtuels, ceci vient certainement du fait que /lib/security/pam_userdb.so a été déplacé en /lib/x86_64-linux-gnu/security/pam_userdb.so. Ce fichier sert à vsftpd pour gérer les authentifications.

Pour régler ce problème, il vous suffit d’éditer /etc/pam.d/vsftpd et de remplacer /lib/security/pam_userdb.so par /lib/x86_64-linux-gnu/security/pam_userdb.so et de redémarrer le service.
Le fichier de PAM pour vsftpd doit donc contenir :

auth       required     /lib/x86_64-linux-gnu/security/pam_userdb.so db=/etc/vsftpd/login
account    required     /lib/x86_64-linux-gnu/security/pam_userdb.so db=/etc/vsftpd/login

Belyscendre, un groupe qui vous fera aimer la musique trad'

2012-12-26T00:01:00+01:00

En 2007 je découvrais Belyscendre via la première partie d'un concert du Naheulband à la loco. Déjà à l'époque j'étais attiré par la musique folklorique, seulement rebuté par la mélancolie de certains chants irlandais. Le Naheulband apportait alors la joie qu'il y manquait.
J'ai ensuite voulu revenir à des textes plus en osmose avec ce genre musical sans pour autant renoncer au dynamisme que je connaissait auparavant. C'est là que Belyscendre prend toute son importance, les morceaux retracent la vie à l'époque médiévale avec joie et vivacité.

Les arrangements à tendance rock apportés à chaque morceau combinés à la qualité des musiciens en font de vrais bijoux pour nos oreilles. Autant sur le premier que sur le deuxième disque.
La seule chose que nous pouvons reprocher au deuxième opus est l’absence d'intermède qui limite le côté historique de l'ensemble. D'un autre côté, ceci rend l'écoute plus fluide. Nous ne passons pas du chant à la narration à la fin de chaque chanson.

Bien évidement l'amour est présent dans ce genre d'œuvre, à sa manière. Ce sont tout de même deux femmes qui chantent. Cependant nous n'avons pas affaire à des chants à l'eau de rose comme ce serait le cas dans bon nombre de disques. Il s'agit ici d'amour plus concret et plus amusant tout en restant dans le romantisme, ce qui n'est pas évident à obtenir.

Vous pouvez en savoir plus en cliquant sur les liens donnés précédemment, notamment sur le site de ZoC Radio où vous retrouvez gratuitement ledit concert.

Mise en place d’un flux RSS et d’un réseau IRC

2012-10-17T00:01:00+02:00

Bonjour tout le monde,
La news d’aujourd’hui sera très courte puisqu’elle juste là pour vous dire de vous abonner au flux RSS que je viens de mettre en place.

Pour ceux qui ne savent pas, les flux RSS sont des document XML contenant une liste de parution qui se met automatiquement à jour. Ils sont lisibles directement dans les navigateurs modernes mais cela manque un peu d'ergonomie. Vous pouvez utiliser un agrégateur pour avoir une meilleure lisibilité. Nous pouvons citer la webapp netvibes pour les desktops ou l'application pulse pour les smartphones. Ceci est bien sûr loin d'être une liste exhaustive, c'est à vous de trouver le client qui vous convient.

Si vous voulez en savoir plus à propos du RSS, je vous propose de lire la documentation du MDN

Édition du 2 novembre :

Le réseau IRC est disponible à l’adresse irc.swordarmor.fr (thanks captain obvious) sur le port 6667 pour les connexions classiques et 6697 pour le SSL. Vous pouvez vous connecter en IPv4 comme en IPv6. J’ai également configuré un qwebirc pour les gros sales qui veulent discuter directement depuis leur navigateur. Vous pouvez y accéder à travers pennvad.eu (c’est le petit nom du réseau IRC).
Ce fût une expérience fort sympathique et pleine de surprises de mettre tout ça en place. Ce n’était pas si facile que ça à configurer, surtout que je n’ai que rarement administré un réseau de ce genre.
Pour l’instant il existe seulement un chan à mon nom (oh la belle symétrie) mais vous pouvez très bien en faire un pour vous, c’est là pour ça. ;)
Pour cela, rien de plus simple. Tapez /join #votrenomdechan puis /msg ChanServ register #votrenomdechan et voilà. Vous devez au préalable être authentifié à NickServ. Je vais faire un guide de la débrouille sur IRC dans les semaines qui suivent.
N’hésitez pas à passer sur #SwordArMor si vous avez besoin d'aide.

Si vous ne savez pas ce qu’est l'IRC, allez donc lire la page spéciale que j'ai faite dessus. Car oui, je n’ai pas envie de faire quelques copiés/collés.
Brièvement, c’est un moyen de discussion instantané en groupe.

Qu’est-ce que la neutralité du net ? Et pourquoi est-ce important de la préserver ?

2012-10-04T00:01:00+02:00

Vous avez certainement dû en entendre parler un jour ou l’autre. Beaucoup d'acteurs des Internets en parlent. Même certains politiques s’y mettent pour savoir s’il faut créer, ou non, une loi à ce propos.

Mais qu'est-ce que c'est que ce truc ? Et pourquoi en parle-t-on autant ?

Résumons le contexte : au début tout le monde (ou presque) avais accès au réseau des réseaux, quelque soit leurs intentions. Ensuite il fût techniquement possible de filtrer tous ces flux, en fonction de l'émetteur, du destinataire et/ou du contenu.
C'est alors que certains ce sont montrés favorable à la mise en place de ce genre d'infrastructure. Les avis allant dans ce sens venaient – et viennent toujours – majoritairement des acteurs « hardware » (FAI, opérateurs, etc) historiquement orientés vers des technologies propriétaires.
Les arguments avancés sont le manque de partage des richesses entre ces derniers et les diffuseurs de contenu (Google, Dailymotion, Twitter ou autres). D'un côté des entreprises doivent maintenir le réseau, et donc investir, alors que d'autres génèrent au contraire d'importantes recettes avec très peu d'investissements de base.

Ceci ne peut pas être totalement justifié.
En effet, bien que les investissements soient lourds, les fournisseurs de services ne sont pas les plus à plaindre, et de beaux jours les attendent encore avec la globalisation de la connexion permanente.
Ensuite, c'est le principe même de fonctionnement des Internets que de pouvoir publier à moindre cout. Vous pouvez aussi retrouver cette idée sous le nom d'innovation sans permission. C'est d'ailleurs une des raisons de son développement si rapide. Notons que c'est grâce à cela que les adversaires de la neutralité existent.
Mais encore, il est écrit dans la Déclaration des droits de l'homme et du citoyen de 1789 que « La libre communication des pensées et des opinions est un des droits les plus précieux de l’homme : tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l’abus de cette liberté dans les cas déterminés par la loi ». Et l'HADOPI (qui a pourtant un penchant pour les majors) de rajouter « qu'en l'état actuel des moyens de communication et eu égard au développement généralisé des services de communication au public en ligne ainsi qu'à l'importance prise par ces services pour la participation à la vie démocratique et l'expression des idées et des opinions, ce droit implique la liberté d'accéder à ces services. ». Soit en clair que tout le monde a le droit de s'exprimer sur la toile, et que pour ce faire il faut pouvoir avoir accès aux informations déjà présentes.
Pour finir, le libre concurrence ne serait plus respectée puisque certaines applications seraient bridées au profit d'autres.

Et maintenant, où en est-on ?
Et bien nous pouvons citer de nombreux exemples, en France et à l'étranger.

Discriminations à l'égard de la destination

Free bride l'accès à YouTube en raison de la forte demande en bande passante qu'il génère.
Neuf a bloqué l'accès à Dailymotion suite a des négociations commerciales.
Des sites de syndicats ont été inaccessible depuis le réseau de Telus suite à un mouvement social interne. C'était en 2005 au Canada.

Discriminations à l'égard du contenu

Les services de VoIP – comme Skype – sont souvent interdit sur le réseau 3G/3G+ en France ou en Allemagne.
UPC (Hollande) a réduit la bande passante de ces abonnés les plus gourmands entre midi et minuit.

Discriminations à l'égard du source

Certains services comme Deezer peuvent être inclus dans son forfait Orange. Ils ne sont alors plus soumis aux quotas de données, alors que les autres le sont.
Vodafone a une offre depuis novembre 2009 permettant à ceux qui ont payé de naviguer plus vite.
Bouygues Telecom offre la possibilité d'être prioritaires par rapport aux autres en cas d'engorgement du réseau.
La Chine et l'Iran filtrent les flux venant des États-Unis et plus particulièrement ceux de Google.

Les limites du concept
Il est bien sûr impensable d'appliquer ce principe de neutralité à 100%. Effectivement, la diffusion d'un virus n'est bénéfique pour personne, s'il on omet son créateur. Tout comme le ralentissement des échanges entre deux gouvernement, mise à part leurs ennemis. Il y a donc des informations qui sont réellement plus importantes que d'autre. Mais ceci doit rester très ciblé.

C'est là qu'une loi sur la neutralité du Net essentielle. Elle peut fixer – entre autres – les pratiques raisonnables du réseau.
À ce jour, seulement trois pays ont pris en compte ce concept dans leur constitution, le Chili, le Pérou et les Pays-Bas. Des lois similaires existent également dans d'autres pays comme en Europe, en Belgique, en France, en Italie, en Norvège ou aux États-Unis. Mais ce sont bien souvent des projets ou des embryons.

En conclusion, nous pouvons dire que le Web est basé sur un modèle ouvert. Il se développe donc de lui-même grâce aux échanges entre ses différents utilisateurs. Ces échanges ne sont possibles que si les informations déjà présentent sont lisible de tous.
C'est là le cœur de la neutralité du Net. La remettre en cause reviendrait à créer un Internet à plusieurs vitesses où la diffusion et la réception de données seraient limitées à une oligarchie. De plus, les inter-acteurs seraient triés sur le volet.
Nous perdrions alors la diversité de contenu et d'utilisation que nous connaissons aujourd'hui.

Sources :

Et pour finir voici deux infographies qui résument partiellement la situation.

Si vous voulez découvrir une nouvelle série médiévale, regardez Game of Thrones

2012-04-14T00:01:00+02:00

Aujourd'hui, nous allons parler de télévision. Bien que beaucoup d’émissions manquent d’intérêt, certaines (très rares) sont à ne pas manquer.
La série dont je vais parler est Game of Thrones, plus connue en France sous le nom du Trône de fer. L’histoire est tirée des livres de la saga Le trône de fer écrite par George R. R. Martin.

L'intrigue se déroule dans un univers médiéval composé de sept contrées chacune dirigées par un seigneur. Le pouvoir suprême appartient au roi des sept couronnes, assit sur le trône de fer. Il est épaulé par la main du roi, son premier ministre. Dans ce monde, les saisons n'ont pas de durée fixe comme chez nous, elles peuvent se prolonger durant plusieurs années.

Les problèmes commencent avec la mort de Jon Arryn, main du roi Robert Baratheon. Le roi décide alors de nommer Eddard Stark à ce poste. Étant donné qu'il est l'une des rares personnes loyales autour du roi, il va se heurter à de nombreux obstacles.
Parallèlement à cela, une garnison, la Garde de Nuit, composée d'anciens criminels ou de volontaires voués corps et âme à la défense du Mur retrouve la trace des Marcheurs blancs au nord de celui-ci. Ce sont des créatures transformant en mort-vivant tout être vivant qu'ils tuent, ça n'arrange donc pas du tout la population du sud.
À cela, il faut encore ajouter les querelles qui animent les différentes maisons et le désintéressement de la garde de la frontière nord pourtant vitale.

L'histoire évolue ensuite autour des supercheries manigancées par les familles puissantes pour accéder au trône où se côtoient trahisons, mensonges et autres coup bas mais aussi bravoure, loyauté et honneur ; le tout agrémenté d'un peu de romance.

L'univers dans lequel évolue les personnages est très développé, que ce soit géographiquement ou généalogiquement. Il est une pièce maîtresse dans la compréhension de l'histoire et il participe au réalisme général de cette série, ce qui en fait un point fort.
Un autre avantage de cette série est la présence la plus limitée possible de toute forme de manichéisme. On peut très bien prendre parti pour telle ou telle famille alors qu'elle agit contre le pouvoir en place. Dans le même sens, les différents rois qui se succèdent sont loin d'être parfaits.
Un autre facteur de cette sensation de réalité est la beauté des décors. Ils sont très soignés, presque authentiques. Le tournage a, en très grande partie, été fait en Irlande, un pays naturellement médiéval avec ses collines et ses châteaux, ce qui participe à l'immersion du spectateur.

Pour conclure, nous avons dans cette saga un fabuleux mélange de politique, fantasy, action et romance, associé à un récit complexe comme il le faut, des personnages originaux et des décors très réussis. Tout ceci confère un effet naturel, donc attirant, et de surcroît donne du charme à cette série que vous vous devez de regarder si ce n'est déjà fait.

Comme d'habitude, vous avez le droit à la bande annonce,

Trine, un jeu vidéo trop méconnu

2012-04-05T00:01:00+02:00

Une fois n’est pas coutume, je vais parler de jeux vidéo. N’étant pas très joueur, vous me verrez rarement en parler. Cependant, il y en a un qui mérite bien une news.
Il s’agit d'une suite de jeux de plateforme, d’énigme et d’action très bien réalisé, le tout en indépendant. Je parle bien sûr de Trine 1 et 2.

On va commencer par le premier. Vous incarnez 3 personnages à la fois, Amadeus le Magnifique (un magicien), Zoya la Silencieuse (une voleuse) et Pontius le Brave (un chevalier) liés par le Trine, l’artefact des âmes, pour libérer le royaume du joug du sorcier maléfique. Le scénario peut paraitre un peu basique au premier abord mais le jeu devient très prenant quand on est dedans. Les plus grandes qualités de ce jeu se situent dans le game-play et dans la finition. En effet, tant du côté du graphisme, des énigmes à résoudre ou de la musique, les développeurs ont passé du temps pour obtenir un résultat très appréciable.

Ce jeu est aussi original dans la manière de concevoir l’aventure. Vous ne dirigez pas un seul personnage avec ses qualités et ses défauts, vous en dirigez trois, ce qui vous permet de vous adapter à de nombreuses situations. Par exemple, le magicien sera très utile pour créer de nouvelles voies, la voleuse possède une très grande agilité ainsi qu'un arc pour attaquer à distance, tandis que le guerrier a une très forte puissante à l’épée pour le corps à corps ou au marteau pour le tir mais est plus lent.

Dans le deuxième volet, l’histoire se déroule dans le même monde. Cette fois, le royaume est sous l’emprise d'une princesse félonne et la nature en est déséquilibrée. Il apporte de nouvelles énigmes et un environnement de jeu encore supérieur.

Si vous voulez vous-même vous faire une idée de ce jeu, vous pouvez regarder les trailers qui suivent. Ils correspondent respectivement au 1^er et 2^ème chapitre de l’aventure. Je vous conseille de regarder ces vidéos en 720p (au moins) pour pleinement apprécier la beauté des niveaux. Vous pouvez aussi télécharger une démo gratuite directement depuis leur site pour Trine 1. Pour le 2, ça se passe sur steam. La troisième vidéo est la bande originale du 2^èmejeu. Appréciez la qualité par vous-même.

What about me? Intel vous dit comment on vous voit depuis les réseaux sociaux.

2012-03-19T00:01:00+01:00

Intel a développé une application web nommée What About Me?. Elle permet d’analyser comment vous êtes vu sur les réseaux sociaux twitter, YouTube ou Facebook (ou les 3 en même temps si vous voulez) et de vous l’afficher sous forme d’une infographie sympa.

Pour ma part, j’obtiens l’image à gauche, ce qui correspond bien à mes centres d’intérêt. Ce n’est qu’une petite partie de ce que vous pouvez obtenir. Il est aussi dit dans quels posts les informations ont été prises, le ton général de vos publications, si vous êtes plutôt de la journée ou de la nuit et d’autres choses encore. Vous pouvez voir tout ça en cliquant sur l’image.

Si vous aussi vous voulez essayer, c’est très simple : allez sur http://whataboutme.intel.com et identifiez-vous via les réseaux sociaux que vous avez choisis. (C’était très simple, Intel a fermé ce site entre temps.) De l’autre côté ça turbule et vous avez votre propre image que vous pourrez ensuite partager avec vos amis.

Ceci montre bien à quel point il est facile d’avoir des informations sur les gens depuis les réseaux sociaux. Il est donc impératif de filtrer ce que vous dites sur ce genre de sites. Sur Facebook par exemple, vous pouvez choisir qui peut voir tel ou tel parution ou photo, vous pouvez aussi régler le type de personnes ayant accès à votre profil (amis, amis des amis, tout le monde…) tout ça se passe dans les paramêtres de confidentialité ou à côté du bouton « publier ».
Le mieux étant bien évidemment d’éviter ce genre de sites.