Depuis longtemps, j’ai l’habitude de ripper mes CD audio avec Exact Audio Copy, éditer les tags et la pochette plus ou moins manuellement (Exact Audio Copy puis Mp3tag), ensuite les déplacer sur mon NAS à l’endroit qui va bien pour qu’ils soient enfin ajoutés à mon audiothèque.
Je vous propose ici une méthode beaucoup moins chronophage et entièrement automatisée sous FreeNAS basée sur abcde.
Vous insérez le CD dans le NAS (s’il dispose d’un lecteur) : il sera automatiquement encodé en FLAC et les fichiers résultants tagués (avec la pochette), nommés, puis déplacés dans le bon répertoire, et enfin le CD éjecté.
La première étape consiste à créer une jail dont le paramètre « devfs_rulset » est positionné à « 3 » dans les « Jail Properties ».
Ensuite, ajouter un « mount point » dans le répertoire de stockage de votre musique. Si vous utilisez le plugin Plex, cela devient très pratique.
Une fois la jail créée, connectez vous à celle-ci, pour installer les prérequis :
# pkg install abcde flac eject cdparanoia cd-discid sqlite3 cmake glib pkgconf
La transformation du CD audio en fichiers FLAC correctement nommés et tagués va donc être confiée à abcde. Pour cela :
# rm /usr/local/etc/abcde.conf
# vi /usr/local/etc/abcde.conf
CDDBMETHOD=musicbrainz
CDDBPROTO=6
HELLOINFO="`whoami`@`hostname`"
NOSUBMIT=y
FLACENCODERSYNTAX=default
CDROMREADERSYNTAX=cdparanoia
PADTRACKS=y
INTERACTIVE=n
LAME=lame
FLAC=flac
ID3=id3
ID3V2=id3v2
CDPARANOIA=cdparanoia
EJECT=eject
METAFLAC=metaflac
CDSPEED=eject
LAMEOPTS='--preset extreme'
FLACOPTS="-f --best"
ACTIONS=cddb,read,encode,tag,move,clean
CDROM=/dev/cd0
OUTPUTDIR=/media
WAVOUTPUTDIR=/tmp
OUTPUTTYPE=flac
OUTPUTFORMAT='${ARTISTFILE}/${ALBUMFILE}/${TRACKNUM}.${TRACKFILE}'
VAOUTPUTFORMAT='Various/${ALBUMFILE}/${TRACKNUM}.${ARTISTFILE}-${TRACKFILE}'
ONETRACKOUTPUTFORMAT=$OUTPUTFORMAT
VAONETRACKOUTPUTFORMAT=$VAOUTPUTFORMAT
LOWDISK=n
PLAYLISTFORMAT='${ARTISTFILE}/${ALBUMFILE}.${OUTPUT}.m3u'
VAPLAYLISTFORMAT='${ARTISTFILE}/${ALBUMFILE}.${OUTPUT}.m3u'
EJECTCD=y
Les paramètres à adapter à votre installation sont : CDROM
et OUTPUTDIR
permettant respectivement de désigner votre périphérique CDROM et le répertoire de sortie pour vos fichiers FLAC.
Si vous souhaitez ajouter automatiquement dans le tag de chaque fichier FLAC la pochette de l’album, il vous faudra utiliser glyr, qui n’est pas dans les ports FreeBSD.
Pour compiler et installer glyr :
# cd
# wget --no-check-certificate http://github.com/sahib/glyr/tarball/master -O glyr.tar
# tar xfv glyr.tar
# cd glyr
# sh
# cmake -DCMAKE_INSTALL_PREFIX=/usr .
# export LIBRARY_PATH=/usr/local/lib
# make && make install
Une fois glyr installé, remplacez dans le fichier abcde.conf
le paramètre ACTIONS
par :
ACTIONS=cddb,embedalbumart,read,encode,tag,move,clean
Une fois ceci fait, nous pouvons mettre en place l’automatisation du lancement de abcde à l’insertion d’un CD. Pour cela, mettez en place le cronjob qui teste toutes les minutes si un CD est présent, puis lance abcde :
# crontab -e
SHELL=/bin/sh
@every_minute ( /usr/sbin/cdcontrol info > /dev/null 2>&1 ) && ( ! pgrep bash ) && /usr/local/bin/abcde
Maintenant, dès que vous allez insérer un CD audio dans votre NAS, il va être automatiquement encodé, tagué et déplacé dans le bon répertoire. A la fin de l’encodage, le CD sera éjecté, et vous pourrez passer au suivant :-).
Voici un lien utile qui m’a permis de mettre cela en place : reddit: CD Passthrough to VM
]]>Ceci, afin d’obtenir une délégation de préfixe IPv6 : un /56 entièrement routé jusqu’à l’équipement du client et utilisable comme bon lui semble.
Jusqu’à maintenant, seul dibbler fonctionnait (un peu par hasard), mais il est maintenant possible d’utiliser dhcpcd proprement, grâce à Roy Marples, son développeur, qui a implémenté toutes les fonctionnalités manquantes.
En effet, même si cela fonctionnait avec dibbler, plusieurs problèmes subsistent :
Je me suis donc penché sur dhcpcd, qui est l’un des rare client DHCPv6 activement maintenu. Après quelques recherches, j’ai constaté que l’option 15 (USER_CLASS) n’était pas supportée. J’ai donc contacté Roy Marples, le développeur de dhcpcd. Celui-ci a très gentiment accepté d’ajouter le support de cette option. Après pas mal d’échanges, nous avons également constaté quelques soucis sur les autres options qu’Orange nécessite : l’option 16 (VENDOR_CLASS) et l’option 11 (AUTH). Roy a très patiemment corrigé les différents problèmes.
Ainsi, la branche de développement de dhcpcd (qui devrait devenir la version 7.0.4 prochainement) a maintenant tout le nécessaire pour obtenir un bail DHCPv6 et récupérer une délégation de préfixe IPv6. Cette configuration minimale fonctionne (remplacez xxxxxxx par votre identifiant Orange) :
ipv6only
duid
authprotocol token 0x123/0x456
authtoken 0x123 "" forever fti/xxxxxxx
authtoken 0x456 "" forever dhcpliveboxfr250
userclass FSVDSL_livebox.Internet.softathome.livebox3
vendclass 1038 sagem
persistent
noipv6rs
allowinterfaces vlan832
interface vlan832
ia_pd 1
Cette configuration permet non seulement de supporter toutes les options nécessaires, mais aussi de gérer correctement l’authentification :
Attention, il semble qu’en plus des différentes options requises, Orange filtre sur la valeur du DUID de l’option 1 (CLIENTID) dans les requêtes DHCPv6. Mon impression est que la première valeur du DUID émise par l’équipement client connecté est mise sur liste blanche, et qu’il n’est ensuite plus possible d’utiliser une autre valeur. Ceci permettant à Orange de limiter les équipements connectés, éviter les échanges sauvages de Livebox, etc.
Il y a donc un travail nécessaire pour récupérer cette fameuse valeur du DUID :
/var/lib/dibbler/client-duid
en la concaténant avec les valeurs de type de lien et date/heure de ce même fichier,Ensuite, il faut éditer le fichier /var/db/dhcpcd/duid
pour positionner la bonne valeur.
Voilà donc qui devrait faire le bonheur de beaucoup de monde, car beaucoup de projets pourront en profiter : pfSense, OpenWRT, etc.
Enfin, pour finir, je remercie encore Roy Marples pour ce support et sa sympathie.
Note 04/05/2018 : dhcpcd 7.0.4 est maintenant officiel et le port OpenBSD a été mis à jour.
]]>Je ne vais pas réécrire les nombreux guides déjà présents sur Internet, l’objectif est de donner quelques astuces pour profiter de toutes les fonctionnalités.
1. Les priorités 802.1Q/802.1p
Sur la Livebox, les différents types de flux passent par plusieurs VLAN 802.1Q pour séparer Internet, la VoD, la télévision et la téléphonie.
Selon l’endroit où vous habitez, il se peut que les infrastructures Orange nécessitent de positionner des priorités 802.1p pour les différents paquets au sein de ces VLAN. Je pense que ce paramétrage est nécessaire sur les anciennes infrastructures compatibles PPPoE. Sur les nouvelles, uniquement en DHCP, cela ne devrait plus être nécessaire.
Je suis pour ma part dans le mauvais cas… sans les bonnes priorités rien ne fonctionne. Voici ce qu’il faut respecter et la manière de faire :
Sous OpenBSD, les requêtes DHCP notamment, passent par des raw sockets. Il n’est donc pas possible de mettre la bonne priorité avec PF. La solution consiste donc à positionner la priorité des interfaces comme suit avec l’option ‘llprio’ de ifconfig(8) disponible depuis OpenBSD 6.0 :
# ifconfig vlan832 llprio 6
# ifconfig vlan838 llprio 4
#pas de DHCP sur l'interface vlan840
Ensuite, vous pouvez utiliser PF pour forcer dans le trafic sortant, toutes les autres priorités. Quelque chose comme ceci fonctionne :
match out on vlan832 set prio 1
match out on vlan838 set prio 4
match out on vlan840 set prio 5
A vous d’adapter la configuration selon votre besoin. Selon les règles que vous avez, il sera également nécessaire de forcer la priorité au niveau des règles de filtrage elle-mêmes (notamment pour DHCPv6, voir plus bas).
2. IPv4
Pour IPv4, rien de particulier à signaler : dhclient(8) fourni de base avec OpenBSD peut être configuré sans problème pour passer les bonnes options à Orange. Les liens fournis en fin d’article permettent de mettre les bonnes valeurs selon votre cas.
3. IPv6
Pour IPv6, la configuration est un peu plus particulière. Il est nécessaire d’utiliser deux mécanismes.
D’abord, attribuer une adresse IPv6 de type linklocal sur l’interface vlan832 et récupérer la route par défaut d’Orange avec quelque chose comme :
# ifconfig vlan832 inet6 eui64 autoconf
Ensuite, il faut récupérer votre préfixe IPv6 public chez Orange par DHCPv6. OpenBSD n’a pas de client de base pour faire cela. D’après mes recherches, dhcpcd dans les ports permettrait (peut-être) de le faire dans ses dernières versions mais :
Le plus facile est d’utiliser dibbler. Ce client IPv6, dont vous pourrez trouver la version 1.0.1 ici fonctionne bien. Il n’est pas disponible dans les ports, mais sa compilation est simple et la configuration se trouve également dans les liens plus bas. Attention, dibbler n’utilise pas les raw sockets, il vous faudra donc avoir des règles PF spécifiques pour positionner la priorité 802.1p à 6 sur les paquets UDP pour DHCPv6.
Pour ma part, contrairement aux autres articles que l’on peut trouver sur Internet, je me sers de dibbler uniquement pour maintenir le bail DHCPv6 (et donc garder le préfixe qu’Orange m’a attribué). Je n’exécute aucun script pour configurer mes interfaces. En effet, Orange distribue via DHCPv6 un préfixe /56 et l’intégralité est routé chez vous. La Livebox ne vous donne accès qu’au premier /64, mais avec votre propre routeur, libre à vous d’utiliser le reste… c’est ce que je fais.
Au niveau de mon réseau local privé, j’utilise rtadvd(8) pour distribuer automatiquement un subnet /64 de ce /56 et sa route par défaut. Dans l’environnement DMZ, j’ai paramétré en statique un autre /64.
Ceci n’est pas à 100% robuste, car si Orange décide un jour de changer le préfixe IPv6 qu’ils m’attribuent, plus rien ne fonctionnera. En pratique, Orange maintient en IPv4 et IPv6 des baux de 7 jours. Donc si votre client DHCPv[46] les renouvelle à temps, il n’y a pas de raison qu’ils changent. De plus, hébergeant ce serveur sur l’un des /64, ça deviendrait une usine à gaz si je souhaitais tout paramétrer en automatique, jusqu’aux changements DNS…
4. VoD / Télévision
Pour La VoD, donc le VLAN 838, les guides cités en lien sont assez complets. Ce qui est important :
Pour la Télévision, VLAN 840, il va falloir utiliser igmpproxy disponible dans les ports. Sa configuration est très simple. Vous la trouverez également dans les liens indiqués en dernière partie.
L’important pour que cela fonctionne est :
Enfin, un point important, le décodeur TV Orange doit être configuré pour utiliser les serveurs DNS d’Orange. Je vous recommande donc de paramétrer dhcpd(8) de manière à lui réserver une IP avec les bons DNS :
host player {
hardware ethernet 18:1e:78:xx:xx:xx;
fixed-address 192.168.xx.xx;
option domain-name-servers 80.10.246.136, 81.253.149.6;
Remarque : différents exemples de configuration sur Internet montent un bridge(4) entre les interfaces vlan838 et vlan840. Ça n’est absolument pas nécessaire.
5. Le pr0n nécessaire
6. Liens utiles
Dans cet article, je vais présenter une check-list des bonnes pratiques lorsque l’on administre un serveur web sécurisé.
Je ne détaillerai pas toutes les différentes techniques mises en oeuvre : d’innombrables sites ou blogs le font très bien. Je vais en revanche lister les point importants pour rendre le protocole TLS particulièrement robuste. Ceci avec des exemples de configuration pour le serveur HTTP NGINX.
1. Maintenir à jour la librairie TLS
On ne le répétera jamais assez : la librairie TLS (par exemple OpenSSL ou mieux, LibreSSL) doit absolument être maintenue à jour, en particulier après chaque correctif de sécurité.
Bien évidemment, cela s’applique également au serveur HTTP et tout le système d’exploitation en général.
2. Désactiver SSL
Aujourd’hui il est plus que recommandé de désactiver totalement SSL (jusqu’à la v3). En particulier pour bénéficier de la confidentialité persistante (PFS). Ainsi, votre serveur web ne devrait répondre qu’aux protocoles TLS (1.0 et supérieur).
Ceci aura pour effet de casser la compatibilité avec les navigateurs anciens. Notamment Internet Explorer 6 sous Windows XP qui ne supporte pas TLS par défaut (il peut être paramétré pour supporter TLS 1.0, avec quelques algorithmes de faible robustesse, qui doivent absolument être bannis de nos jours). Est-ce réellement un problème ?
NGINX : ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
3. Suites de chiffrement fortes
Votre serveur web doit être paramétré pour fonctionner avec des suites de chiffrement robustes. Il faut donc, dans la configuration du serveur web prohiber : RC4, MD5, DES, EXPORT (suites de chiffrement anciennes, autorisées à être exportées des USA).
De la même façon que la désactivation de SSL, ce point cassera la compatibilité avec les navigateurs anciens.
NGINX :
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
4. Générer ses propres paramètres DH
Avec l’utilisation de PFS et des certificats de 2048 bits, ceci permet de rendre plus robuste les échanges de clés Diffie Hellman, qui utiliseraient sinon les clés par défaut d’OpenSSL d’une taille de 1024 bits.
NGINX : ssl_dhparam /etc/ssl/certs/dhparam.pem;
5. OCSP Stapling
OCSP souffre de deux problèmes :
L’OCSP Stapling permet de rendre plus efficient la validation des certificats, puisqu’il délègue cette tâche au serveur lui-même, qui renvoie au client le certificat accompagné de sa validation signée par l’AC. Cette extension de TLS inclut un mécanisme de cache pour améliorer les performances et ne pas trop solliciter l’AC.
NGINX :
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/startssl_ca.pem;
resolver 127.0.0.1 valid=300s;
resolver_timeout 5s;
6. HTTP Strict Transport Security
Le mécanisme HSTS permet au serveur web d’inclure une en-tête HTTP signalant au navigateur que durant une période donnée (6 mois minimum recommandé), il ne doit communiquer avec le serveur que de façon sécurisée.
NGINX : add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
7. HTTP Public Key Pinning
L’extension HPKP permet au serveur web d’inclure une entête HTTP contenant un condensat du ou des certificats autorisés à établir la session TLS.
Le serveur web fournit donc une liste blanche de certificats autorisés à chiffrer une communication avec un site web.
Ceci permet d’être certain que le certificat que l’on utilise pour chiffrer la communication est bien celui autorisé par le propriétaire du site : et donc bloquer les attaques MiTM sur lesquelles reposent notamment les solutions de déchiffrement SSL du marché, très utilisées en entreprise ou par les Etats.
NGINX : add_header Public-Key-Pins 'pin-sha256="XXX_le_condensat_apparait_ici_XXX"; max-age=2592000; includeSubDomains';
Attention, ce mécanisme nécessite des précautions lors du renouvellement des certificats. Je vous conseille de bien étudier HPKP avant de le mettre en place.
8. Conclusion
Ces mécanismes de sécurité autour de TLS sont applicables sur d’autres serveurs web (Apache ou Lighttpd).
Pour mes configuration, je me suis fortement inspiré de cet article, plus complet et renvoyant vers beaucoup de liens très intéressants. Je vous en conseille la lecture.
Enfin, l’éditeur Qualys fournit un outil très pratique permettant de tester la robustesse d’un service HTTPS. Je vous conseille de l’utiliser pour valider votre configuration.
Voici mon résultat :
]]>
Comme je m’y attendais, celui-ci ne compile plus, l’infrastructure des ports d’OpenBSD a comme toujours beaucoup évolué. Après quelques tentatives rapides, je me dis qu’il serait préférable de repartir from scratch, avec les dernières sources d’ioquake3. Et là, merveilleux… en une poignée de commandes j’ai ioquake3 qui démarre sur mon OpenBSD -current.
$ git clone git://github.com/ioquake/ioq3.git
$ cd ioq3
$ gmake
$ sudo gmake copyfiles
$ /usr/local/games/quake3/ioquake3.x86_64
Tellement simple que je vais faire quelques frags avant de penser à un port… qui devient presque superflu.
Comme depuis de nombreuses années, merci aux développeurs d’OpenBSD pour tout le travail accompli. Ces derniers mois, le boulot pour le support de KMS sur les drivers intel(4) et radeon(4) est impressionnant. Sans ce travail, jouer dans de bonnes conditions à ce genre de jeux ne serait pas possible.
]]>Ce que je vous propose n’est pas un test complet de l’appareil (il en existe des dizaines sur le net), mais mon ressenti après presque 3 semaines d’utilisation.
1. Design et finition
J’avais de gros doutes concernant LG, mais je dois dire que le téléphone est très réussi. On ne retrouve pas l’impression de robustesse du Nexus One, mais la finition du téléphone est clairement au dessus des deux Nexus développés par Samsung. La face arrière en verre est très jolie : je trouve les motifs ainsi que la mention « nexus » du plus bel effet. J’apprécie également beaucoup le tour du téléphone dans un matériau plus souple et moins glissant, permettant de bien le tenir en main. L’effet arrondi du verre au dessus de l’écran est non seulement joli, mais confortable à l’utilisation.
Au niveau du placement des boutons, c’est le même principe que le Galaxy Nexus. Pour ceux qui ont l’habitude vous ne serez pas dépaysés. Par contre, l’entrée casque revient au dessus du téléphone, ce que je trouve plus pratique… mais ça n’est qu’une question de goûts…
2. Matériel/Puissance
Au niveau matériel, les caractéristiques ainsi que de nombreux benchs existent sur Internet. Clairement, c’est un téléphone haut de gamme. Pour la première fois avec un Nexus, je ne ressens plus aucun ralentissement ou saccade dans l’interface. Tout est extrêmement fluide, plus qu’un iPhone 5 à mon avis (après avoir pu le comparer).
J’ai pu tester plusieurs jeux, dont NOVA 3 qui est très gourmand en ressources. Et bien là encore, pas de ralentissement, tout est très fluide et parfaitement jouable. Les ralentissements que je constatais dans les jeux gourmands sur le Galaxy Nexus ne se font plus du tout ressentir.
Concernant le matériel, un petit point à nuancer. Le vibreur est très léger. Il m’arrive souvent de ne pas sentir la vibration alors que le téléphone est posé sur mon bureau.
3. Réception GSM
Concernant la réception GSM/Data, mon ressenti est encore une fois très bon. Je bascule régulièrement entre wifi et 3G à différents endroits. Avec le Galaxy Nexus, j’avais constamment des pertes de signal et pire, des pertes de data, sans qu’il soit possible au téléphone de la récupérer. Il fallait alors changer les APN au niveau d’Android puis les remettre en place, pour forcer le téléphone à réinitialiser l’accrochage de la data. C’était très pénible car ça m’arrivait presque tous les jours. Avec le Nexus 4, aucun problème, après 3 semaines d’utilisation, je n’ai pas constaté le problème. J’ajouterais que la réception téléphonique est très bonne, avec une qualité audio excellente.
4. Ecran
Contrairement au Galaxy Nexus qui possède une dalle AMOLED, le Nexus 4 possède lui une dalle IPS. Lorsque l’on est habitué depuis quelques années comme moi aux écrans AMOLED, les modèles IPS paraissent ternes. Mais ça n’est qu’une question d’habitude des premiers jours car au final, les couleurs sont plus naturelles, moins saturées.
J’avais été très déçu de la dalle AMOLED du Galaxy Nexus. Sur un fond blanc par exemple, l’écran laissait apparaître des « lignes ». L’affichage n’était pas uniforme et pour un téléphone de ce prix c’était clairement honteux. Surtout qu’après quelques mois d’utilisation, des pixels « morts » sont apparus. Visiblement je ne suis pas le seul car ce phénomène est arrivé à beaucoup de possesseurs de Galaxy Nexus.
La dalle du Nexus 4 est d’excellente facture : l’affichage est parfaitement uniforme, les couleurs sont nettes, sans être saturées et l’écran reste visible même dans des zones fortement éclairées (comme en extérieur au soleil).
5. Appareil photo
Ici, pas de surprise, l’appareil photo est excellent. Il était déjà très bon sur le Galaxy Nexus, mais la version 4 de la gamme Nexus est très bien équipée. Un mode HDR fait son apparition (comme sur iPhone) et la fonction photosphère est assez bien faite. Préférez cependant les photosphère à l’extérieur. A l’intérieur, le rendu est moins joli du fait du peu de recul.
Je précise que l’application appareil photo a été mise à jour, pour ne laisser apparaître que le bouton de prise de photo, les options et le mode (photo, vidéo, etc.). Ces boutons étant en transparence au dessus de la vue visée par l’objectif.
6. Stabilité
Encore une fois, par comparaison avec le Galaxy Nexus, je trouve que la stabilité du téléphone s’est grandement améliorée. Avec le Galaxy Nexus j’avais de gros problèmes de stabilité : freeze, perte de réseau, perte de data, reboot intempestif, etc. Il m’était d’ailleurs compliqué d’avoir plus de 2 jours d’uptime.
Ce Nexus 4 semble avoir une stabilité à toute épreuve : aucun plantage, aucun freeze, plus de perte de réseau. En 3 semaines d’utilisation, je n’ai dû le redémarrer qu’une seule fois, lors de la mise à jour vers Android 4.2.1… après près de 13 jours d’uptime.
7. Jelly Bean 4.2
Ici pas de surprise, depuis Ice Cream Sandwich, Android évolue doucement mais sûrement. Les évolutions de 4.1 étaient appréciables, 4.2 ne déroge pas à la règle avec plusieurs fonctionnalités sympas comme les widgets sur l’écran de verrouillage. On peut également constater un peu plus de fluidité (par rapport à 4.1) dans l’interface ainsi que des effets sympas.
A noter que la synchronisation avec Facebook des contacts fait son grand retour, dans une forme plus basique qu’à l’époque d’Android Eclair (2.1) mais c’est tout de même appréciable !
8. Conclusion
Avec ce 4ème Nexus, Google nous offre ce qu’il y a de mieux à l’heure actuelle dans le monde Android, mais également dans les smartphones haut de gamme.
Après avoir été extrêmement déçu de Samsung pour le précédent Nexus, je dois dire que ce Nexus 4 signé par LG fait un sans faute. D’autant plus qu’il est proposé à un prix défiant toute concurrence : à 349.90€ le modèle 16Go, vous ne pouvez pas vous tromper !
]]>Je propose dans cet article une manière efficace et rapide de corriger cela sur une passerelle OpenBSD à l’aide de quelques règles PF en utilisant une première approche avec le moteur de priorisation ALTQ et la nouvelle souplesse des règles match depuis la version 4.6, puis en utilisant le nouveau moteur de priorisation intégré disponible à partir de la version 5.1.
1. Détail du problème
Lorsque l’on télécharge un fichier en utilisant le protocole TCP, les données que nous recevons sont contenues dans des paquets TCP ayant des données « utiles ». Selon le fonctionnement du protocole TCP, nous devons acquitter au fur et à mesure les données reçues, en envoyant au serveur des paquets TCP vides, mais acquittant de la réception des données (ces paquets contiennent le drapeau ACK). Lorsque nous envoyons un fichier sur internet, c’est le mécanisme inverse qui se produit : la machine recevant notre fichier nous envoie des paquets d’acquittement. Pour plus de détails, lire la RFC 793.
Si à un moment donné, les paquets d’acquittement sont ralentis ou perdus, alors le trafic est ralenti puisque la machine envoyant les données, doit attendre voir ré-émettre les données : car les paquets auront été acquittés tardivement ou pas du tout. Avec les connexions ADSL, fortement asymétriques, que nous avons aujourd’hui, on voit aisément le problème qui peut survenir : si nous lançons sur notre connexion internet, plusieurs envois/réceptions de fichiers simultanés, il est facile de saturer notre débit d’émission. Ce qui a pour effet de ralentir l’émission des paquets d’acquittement pour les fichiers que l’on télécharge, et donc de ralentir la vitesse de téléchargement de nos fichiers.
2. Solution A
Le filtre de paquets PF d’OpenBSD possède depuis longtemps un moteur très souple, ALTQ, permettant de prioriser les flux suivant différents algorithmes et paramètres. Sa configuration est détaillée dans la page de manuel pf.conf(5). Nous ne détaillerons pas sa syntaxe, juste les quelques règles qui nous intéressent. Voyons tout d’abord comment créer une queue permettant de prioriser les paquets. Ajoutons cette section au fichier /etc/pf.conf :
ext_if = vr3
altq on $ext_if priq bandwidth 920Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)
Ici nous avons créé une macro ext_if, nommant notre interface externe vr3 sur laquelle nous allons prioriser nos paquets. Puis, nous créons une queue mère sur l’interface $ext_if en utilisant l’algorithme priq (simple algorithme de priorité). Cette queue mère se voit affecter 820Kb et deux queues filles : q_pri ayant une priorité élevée de 7 et q_def la queue par défaut ayant une priorité plus basse de 1.
L’algorithme priq est le plus simple présent dans ALTQ : on affecte une priorité différente aux sous-queues (de 0 à 15), les paquets de la queue ayant la priorité la plus élevée sont traités en premier.
Dans la déclaration de la queue mère, j’ai réservé 920Kb de bande passante. Ma connexion internet synchronise à environ 6Mb en réception et 1Mb en émission. Avec l’encapsulation IPoA chez Free, j’ai un débit effectif d’environ 920Kb. Je vous conseille de faire quelques essais : si vous ne réservez pas assez de bande passante, la priorisation sera inefficace, et si vous réservez trop de débit, vous allez brider inutilement votre connexion.
Une fois les queues déclarées, passons maintenant à leur affectation dans nos règles de filtrage. J’écrivais précédemment que depuis OpenBSD 4.6, une nouvelle façon de filtrer est apparue avec le mot clé match. En effet, depuis cette version, de profonds changements structurels ont été apportés à PF, résultant en une bien meilleure souplesse d’écriture. Le mot clé ‘match’ permet ainsi de « matcher » certains flux pour modifier leur filtrage à la volée, sans arrêter leur évaluation dans le fichier de règles : c’est à dire sans modifier l’action finale block ou pass.
Alors que précédemment, l’affectation des queues ALTQ aux flux se faisait à chaque règle de filtrage, il est maintenant possible d’affecter nos queues par une simple règle match au début des règles de filtrage :
match on $ext_if inet proto tcp queue (q_def, q_pri)
Ainsi, toutes les connexions TCP sur l’interface externe $ext_if se verront affecter nos deux queues : q_def et q_pri. L’évaluation des règles continuera ensuite normalement.
Notons que l’ordre dans lequel nous avons mis les deux queues est indispensable. La première queue précisée dans la règle match est la queue par défaut : q_def. Si nous précisons une deuxième queue (c’est ce que nous avons fait), q_pri, alors PF lui affecte automatiquement les paquets ayant l’option IP ToS positionnée à « nodelay » ainsi que les paquets TCP sans charge utile ayant le drapeau ACK. C’est exactement le comportement que nous recherchons : nos acquittements TCP seront ainsi priorisés par rapport aux autres paquets et nous diminuerons les risques de ralentissement.
3. Solution B
La solution précédente relativement simple, peut être encore beaucoup plus simplifiée, depuis OpenBSD 5.1. En effet, de gros travaux sont en cours pour intégrer totalement à PF les fonctionnalités de ALTQ. Aujourd’hui, ALTQ peut être très pénalisant en terme de performance et sa complexité rend difficile son évolution.
Ainsi, le mot-clé prio est apparu, permettant à chaque règle d’affecter une priorité au trafic visé. Ce nouveau système de priorisation peut être combiné avec les règles match. Ainsi, les quelques lignes précédentes avec ALTQ peuvent être simplifiées en :
match on $ext_if inet proto tcp prio (2, 5)
Ici, plus besoin de déclaration de queues et d’algorithme. Nous affectons une priorité 2 au trafic normal et une priorité 5 aux paquets ayant un champ IP TOS nodelay, ou les paquets TCP ACK sans donnée utile.
A noter qu’en utilisant ce nouveau mécanisme de priorisation, nous avons à notre disponibilité 8 queues (priorité de 0 à 7. De plus, certains trafics sont automatiquement priorisés :
Attention : la syntaxe est sujette à évolution, puisque l’intégration des autres parties de ALTQ est en cours.
4. Illustration
Voici maintenant en pratique le résultat. Le premier graphe correspond à notre politique de filtrage sans ALTQ, le second avec ALTQ.
Dans ce premier graphe, les trois premières minutes consistent à télécharger quelques fichiers. Ensuite, je lance une émission de fichier simultanée aux téléchargements durant les quatre minutes suivantes. On peut voir que non seulement la réception de mes fichiers (en vert) est perturbée par rapport à la première partie du graphe, mais également l’émission de mon fichier qui n’utilise pas les 1Mb de bande passante disponible.
Dans ce second graphe, les deux premières minutes correspondent à plusieurs téléchargements de fichiers. Puis, je lance une émission de fichier durant quatre minutes. On peut voir que ALTQ fait correctement son travail : la réception de mes fichiers n’est absolument pas perturbée par l’émission de mon autre fichier qui se fait en utilisant au maximum les 1Mb de capacité d’émission de mon lien internet.
]]>Le protocole L2TP (Layer 2 Tunneling Protocol) est un protocole de tunneling à la popularité grandissante, car supporté nativement par de nombreux OS : Windows, MacOS X, Linux, etc. mais également par les plate-formes mobiles populaires que sont Android et iOS. De plus, L2TP permet aisément de réaliser des VPN au dessus d’infrastructures existantes puisqu’il est transporté dans des paquets IP/UDP sur le port 1701. Dans la suite du document, nous allons utiliser le nouveau daemon npppd(8), inclus dans le système de base d’OpenBSD.
Afin de rendre le VPN plus sûr, la méthode est de chiffrer le trafic L2TP dans un tunnel IPsec. Ici rien de bien nouveau, nous nous reposerons sur l’extrême simplicité de configuration offerte par OpenBSD.
Un petit HOWTO est disponible avec les sources du ‘daemon’ npppd(8) que nous allons utiliser à cette adresse. Seulement, cet exemple de configuration ne s’intéresse qu’au cas générique et ne peut pas être repris tel quel dans certains scénarios.
1. Eléments d’architecture
Mon opérateur internet est Free. J’utilise une Freebox Revolution (v6) en mode routeur afin d’utiliser toutes les fonctionnalités multimedia qu’elle offre. Il faut donc noter que ma passerelle VPN possède une adresse IPv4 privée (192.168.0.1) sur le réseau interne de ma Freebox. Il ne faut donc pas oublier de configurer la Freebox pour rediriger le trafic IPsec et L2TP (chiffré avec IPsec) sur la passerelle VPN, en utilisant une IP « DMZ » dans l’interface de configuration de la Freebox.
Note : Les simples redirections de ports ne fonctionnent pas, car il faut non seulement rediriger le trafic UDP sur les ports 500 et 4500 (pour respectivement les protocoles ISAKMP et NAT-Traversal concernant la gestion de clés) mais également le trafic ESP (Encap Security Payload), qui a le numéro de protocole IP n°50 ; et qui concerne nos données utiles chiffrées.
Ensuite, mon opérateur mobile est également Free. Free ne pouvant techniquement pas assigner une adresse IP publique à chaque équipement mobile sur son réseau, lorsque vous utilisez des connexions pour de la donnée, vous vous retrouvez avec une IP en adressage privé (10.X.X.X).
Ces points sont à prendre en compte, surtout concernant la configuration IPsec qui devient légèrement plus complexe sur notre passerelle.
2. Configuration de la passerelle VPN
L’étape d’installation de l’OS OpenBSD ne sera pas détaillée puisque c’est une installation tout ce qu’il y a de plus standard. Deux points sont cependant à noter.
D’une part, vous aurez besoin d’utiliser au minimum OpenBSD 5.1 dont la date de sortie est comme d’habitude (cycles de développement de 6 mois) fixée au 1er mai 2012. A l’heure où je rédige cet article, OpenBSD 5.1 est seulement taggé dans le CVS, vous pouvez donc utiliser un snapshot de -current.
D’autre part, vous aurez besoin d’installer les sources de l’OS (src, pas xenocara ni les ports). J’utilise pour ma part une machine à base de Soekris net5501 avec le système installé sur une carte flash. Ne pouvant pas vraiment installer les sources et compiler les outils nécessaires, du fait de l’utilisation d’une carte flash, je monte les répertoires (/usr/obj et /usr/src) via un partage NFS exporté par une autre machine.
Je vous invite à lire la FAQ d’OpenBSD qui est un modèle du genre pour de plus amples informations sur l’installation de l’OS.
Une fois l’OS OpenBSD 5.1 installé, ainsi que ses sources, il faut modifier le fichier /etc/sysctl.conf pour autoriser certaines fonctionnalités au niveau du noyau d’OpenBSD. Pour cela, il faut s’assurer que ces lignes soient dé-commentées :
net.inet.ip.forwarding=1 # transfert IP entre interfaces
net.inet.gre.allow=1 # autorise le protocole de tunneling GRE
net.pipex.enable=1 # accélérateur de transfert IP pour PPP
4. Installation et configuration de npppd(8)
Ensuite, il faut compiler le daemon npppd(8). Celui-ci est déjà stable ; il n’est cependant pas compilé par défaut, suite à un manque de documentation mais également à une configuration qui doit être ré-écrite, afin de coller à la syntaxe des autres daemons d’OpenBSD. Pour compiler npppd(8) :
$ cd /usr/src/usr.sbin/npppd
$ make
$ sudo make install
Pour compiler npppdctl(8), son outil de contrôle :
$ cd /usr/src/usr.sbin/npppctl
$ make
$ sudo make install
Créer le fichier npppd.conf (issu du HOWTO évoqué précédemment) :
interface_list: tun0
interface.tun0.ip4addr: 10.0.0.1
pool.dyna_pool: 10.0.0.0/25
pool.pool: 10.0.0.128/25
auth.local.realm_list: local
auth.local.realm.acctlist: /etc/npppd/npppd-users.csv
realm.local.concentrate: tun0
lcp.mru: 1400
auth.method: mschapv2 chap
pptpd.enabled: true
pptpd.ip4_allow: 0.0.0.0/0
l2tpd.enabled: true
l2tpd.ip4_allow: 0.0.0.0/0
l2tpd.require_ipsec: false
Adapter ce fichier à votre convenance, en particulier les paramètres :
interface_list
: l’interface tun(4) à utiliser, « tun0 » si aucun autre tunnel n’existe.interface.tunX.ip4addr
: l’adresse de l’interface tun(4).pool.dyna_pool
: la plage dynamique des IP attribuées à vos utilisateurs.pool.pool
: la plage utilisée pour les utilisateurs disposant d’adresses statiques (précisé plus bas).realm.local.concentrate
: doit correspondre à l’interface tun(4) configurée précédemment.Créer le fichier npppd-users.csv (issu du HOWTO évoqué précédemment) :
Username,Passwd,IP-Address,IP-Netmask,Descr,Calling-Id
user1,user1's secret,10.0.0.129,,memo for user1
Ce fichier contiendra les noms d’utilisateurs, leur mot de passe, l’adresse IP statique qui leur est affectée, ainsi que des informations optionnelles.
Une fois ces fichiers créés et ajustés à vos besoins, placez-les à l’endroit approprié :
$ sudo mkdir -m 0755 /etc/npppd
$ sudo cp npppd.conf /etc/npppd/
$ sudo cp npppd-users.csv /etc/npppd/
Ensuite, nous pouvons démarrer npppd(8) :
$ sudo npppd -D
5. Confiruration IPsec
Sous OpenBSD, la configuration IPsec est extrêmement simple et se trouve centralisée dans le fichier /etc/ipsec.conf. Éditer ce fichier, pour y ajouter la configuration IPsec :
ike dynamic esp transport \
proto udp from AA.AA.AA.AA (192.168.0.1) to any port 1701 \
aggressive auth "hmac-sha" enc "3des" group modp1024 \
quick auth "hmac-sha" enc "aes" \
srcid "server@my.domain" dstid "client@my.domain" \
psk "myandroidpsk"
Quelques précisions :
dynamic
: aide les configurations dans lequel le client a une IP qui change constemment.AA.AA.AA.AA
: adresse IP publique de la connexion internet de notre passerelle VPN.192.168.0.1
: adresse IP privée de notre passerelle VPN.aggressive
: ce mode est nécessaire lors de l’utilisation d’ID spécifiques pour la connexion.srcid "server@my.domain"
: ID IPsec du serveur, utilisé comme identité de la passerelle.dstid "client@my.domain"
: ID IPsec du client, à configurer dans le client VPN du smartphone.Note : ici, nous utilisons des ID spécifiques (srcid et dstid) car par défaut, les ID utilisés sont les IP des machines : c’est-à-dire les IP privées du smartphone et de la passerelle sur leur réseau respectif. Or, nos deux connexions à internet (celle du smartphone et celle de la passerelle VPN) sont derrière du NAT. Donc les ID utilisés par défaut ne sont pas reconnus par la machine distante, puisque la machine locale ne voit que l’IP publique de la machine distante.
Une fois la configuration IPsec effectuée, il faut :
Cela se traduit par les commandes :
$ sudo ifconfig enc0 up
$ sudo isakmpd -Kv
$ sudo ipsecctl -f /etc/ipsec.conf
6. Le filtrage avec PF
Je ne vais pas détailler l’utilisation de Packet Filter (PF), le filtre de paquets d’OpenBSD ; pour celà vous pouvez vous référer à l’excellente FAQ de PF.
Je vais par contre détailler les points importants concernant notre utilisation dans le cadre de cette passerelle VPN L2TP/IPsec.
PF est maintenant activé par défaut dans OpenBSD, il est seulement nécessaire d’éditer sa configuration qui se fait dans le fichier /etc/pf.conf.
Tout d’abord, commençons par établir quelques variables utiles :
# Interface réseau physique
$ext_if = vr3
# Interface réseau virtuelle tun(4)
$tun_if = tun0
# Plage des clients VPN
$vpn_net = "10.0.0.0/24"
# Ports pour IPsec en UDP
$serv_udp = "{ isakmp, ipsec-nat-t }"
# Ports pour IPsec en TCP ainsi que SSH pour le management
$serv_tcp = "{ ssh, ipsec-nat-t }"
Notre règle par défaut bloque tout en entrée, mais pas en sortie ; par défaut avec PF, ce qui n’est pas bloqué est autorisé :
block in all
Ensuite, définissons une règle de NAT pour que les clients VPN qui arrivent sur l’interface virtuelle, puissent sortir sur l’interface physique, et donc les réseaux locaux de notre passerelle (et internet).
match out on $ext_if inet from $vpn_net nat-to $ext_if
Passons maintenant au filtrage à proprement dit. Commençons par autoriser le trafic IPsec sur notre interface physique :
Cela se traduit par les règles :
pass in on $ext_if proto esp to $ext_if
pass in on $ext_if proto udp to $ext_if port $serv_udp
pass in on $ext_if proto tcp to $ext_if port $serv_tcp
Puis, autorisons le trafic déchiffré, c’est à dire le trafic L2TP venant du smartphone vers notre passerelle, à passer sur l’interface enc(4) :
pass in on enc0 proto udp to $ext_if port l2tp keep state (if-bound)
Note : le mot clé ‘keep state (if-bound)’ est nécessaire sur une interface enc(4). Il permet de lier l’état créé dans PF à l’interface enc0 (par défaut, les états sont flottants), évitant ainsi d’avoir des flux non chiffrés sur d’autres interfaces.
Pour finir, autorisons le trafic utile de notre VPN : le trafic encapsulé dans le VPN, à destination de notre réseau local, d’internet, etc. à entrer sur l’interface virtuelle tun0. Celui-ci sera ensuite automatiquement routé vers la bonne interface :
pass in on $tun_if inet proto { icmp, tcp, udp } from $vpn_net
7. Rendre permanente la configuration
Pour configurer l’interface enc0 à chaque démarrage :
$ sudo sh -c "echo up > /etc/hostname.enc0"
$ sudo chmod 640 /etc/hostname.enc0
Pour démarrer isakmpd(8) au démarrage, ajouter ces lignes au fichier /etc/rc.conf.local :
ipsec=YES
isakmpd_flags="-K"
Pour démarrer npppd(8) automatiquement, ajouter ces lignes au fichier /etc/rc.local :
echo -n 'starting site daemons:'
if [ -x /usr/sbin/npppd ] ; then
/usr/sbin/npppd -D
echo -n ' npppd'
fi
echo '.'
8. Configuration du client
La configuration d’un VPN sur un téléphone Android est très simple. Pour cela, allons dans les paramètres, puis les paramètres sans fil, puis dans la section VPN :
Ajoutons maintenant un nouveau VPN en sélectionnant le type « L2TP/IPsec PSK », puis remplissons les données que nous avons indiquées précédemment :
Une fois les paramètres renseignés, démarrons la connexion, en fournissant le nom d’utilisateur et le mot de passe indiqués dans le fichier npppd-users.conf :
La connexion VPN est démarrée une fois que la petite clé est présente dans la barre de notification en haut à gauche :
9. Gestion de la passerelle
Pour avoir une vision de ce qu’il se passe en temps réel sur notre passerelle VPN, deux commandes sont très utiles.
Tout d’abord, pour consulter les sessions IPsec en cours et en particulier la Security Association Database (SAD) :
$ sudo ipsecctl -sa
FLOWS:
flow esp in proto udp from BB.BB.BB.BB to 192.168.0.1 peer BB.BB.BB.BB srcid server@my.domain dstid client@my.domain type use
flow esp out proto udp from 192.168.0.1 to BB.BB.BB.BB peer BB.BB.BB.BB srcid server@my.domain dstid client@my.domain type require
SAD:
esp transport from 192.168.0.1 to BB.BB.BB.BB spi 0x026f944d auth hmac-sha1 enc aes-256
esp transport from BB.BB.BB.BB to 192.168.0.1 spi 0x20510079 auth hmac-sha1 enc aes-256
Et ensuite pour consulter les sessions L2TP démarrées dans npppd(8) ainsi que des statistiques utiles :
$ sudo npppctl session all
Ppp Id = 14
Ppp Id : 14
Username : user1
Realm Name : local
Concentrated Interface : tun0
Assigned IPv4 Address : 10.0.0.129
Tunnel Protocol : L2TP
Tunnel From : BB-BB-BB-BB.romanichel.net:43682
Start Time : 2012/02/15 16:48:57
Elapsed Time : 114 sec (1 minute)
Input Bytes : 3214 (3.1 KB)
Input Packets : 45
Input Errors : 0 (0.0%)
Output Bytes : 6861 (6.7 KB)
Output Packets : 25
Output Errors : 0 (0.0%)
Note : Depuis OpenBSD 5.2, un certain nombre de corrections ont été apportées. Voici une configuration /etc/ipsec.conf qui devrait mieux fonctionner (testé avec Android 4.1 Jelly Bean) :
ike passive esp transport \
proto udp from AA.AA.AA.AA (192.168.0.1) to any port 1701 \
aggressive auth "hmac-sha" enc "aes" group modp1024 \
quick auth "hmac-sha" enc "aes" \
srcid "server@my.domain" dstid "client@my.domain" \
psk "myandroidpsk"
Même Free qui propose de l’IPv6 à ses clients ne propose qu’un semblant d’accès natif, avec du 6rd mais il se limite à donner un /64.
Dans ce billet, je vais donc m’attacher à présenter les grandes lignes pour mettre en place à la maison (et même ailleurs) un accès IPv6 avec différents sous-réseaux, en utilisant un tunnel broker. Pour y arriver je présenterai des exemples de configuration pour une passerelle OpenBSD, ainsi que des astuces.
Tout d’abord, revenons sur quelques bases. Avec IPv4 il se pratique depuis de nombreuse années un routage ne se basant plus sur les classes avec CIDR (Classless Inter Domain Routing). Ceci est rendu possible par l’utilisation de masques réseau à taille variable (VLSM, Variable Length Subnet Masking). Avec IPv6, les masques disparaissent au profit de préfixes. Un préfixe IPv6 est l’équivalent d’un masque, qui permet de router un sous-réseau à travers internet. D’un point de vue routage, un préfixe a une taille maximale de 64 bits (une adresse IPv6 ayant une taille de 128 bits). Les opérateurs peuvent localement découper plus finement cet espace d’adressage, mais sur internet, les règles de routage seront communes au /64.
Ainsi, Free qui propose un /64 à ses clients, ne donne la possibilité d’adresser qu’un seul sous-réseau. Si vous souhaitez vous amuser avec les joies de l’IPv6 qui vous permet de posséder pour chaque machine une adresse publique routable, alors la solution de Free montre vite ses limites. Il vous sera en effet impossible (comme c’est également le cas de tous les autres FAIs grand public français) de segmenter votre réseau pour séparer vos clients de vos serveurs en mettant par exemple en place un LAN local, une DMZ, un accès Wifi, etc. le tout sur un espace d’adressage IPv6 public.
Mais comme sur internet on trouve de tout, il existe des « tunnel brokers » qui fournissent des points d’accès IPv6 un peu partout dans le monde. La technique est simple : depuis votre accès IPv4 natif, on va encapsuler jusqu’au point de présence du tunnel broker l’intégralité du trafic IPv6 sur de l’IPv4. Il y a quelques années, les points de présence étaient bien souvent situés aux États Unis ou assez loin géographiquement de l’Europe. Mais désormais, de nombreux tunnel brokers ont fait leur apparition proposant des services très intéressants comme :
Même si toutes ces fonctionnalités sont loin d’être indispensables pour un accès personnel… (c’est le moins que l’on puisse dire ), les deux premières sont très alléchantes. Chez moi, j’ai choisi d’utiliser Hurricane Electric (HE). Il propose l’ensemble des services ci-dessus, pour la très modique somme de 0 euros…
La première étape est bien évidemment de s’inscrire sur le site, puis de créer un tunnel (en choisissant le point d’accès le plus proche de chez sois). Ce tunnel, comme je le disais précédemment consiste à encapsuler sur votre passerelle, tout le trafic IPv6 dans de l’IPv4. Pour cela, il faudra donc établir une lisaison point à point IPv4 entre votre passerelle et l’autre bout du tunnel chez HE. Une fois celui-ci créé depuis l’interface web du site, HE vous indique alors les différents paramètres d’accès.
Ces paramètres, vous l’aurez compris, vont vous permettre de monter le tunnel vers le point d’accès HE. Sous OpenBSD, ce tunnel se concrétisera par une interface virtuelle gif(4). Elle se configure très simplement en ligne de commande (remplacez évidemment les adresses par celles fournies par HE) :
$ sudo ifconfig gif0 tunnel <client_ipv4> <server_ipv4>
$ sudo ifconfig gif0 inet6 alias <client_ipv6> <server_ipv6> prefixlen 128
$ sudo route -n add -inet6 default <server_ipv6>
Et pour automatiquement monter le tunnel au démarrage, par un fichier « /etc/hostname.gif0 » :
tunnel <client_ipv4> <server_ipv4>
inet6 <client_ipv6> 128 <server_ipv6>
! /sbin/route add -inet6 default <server_ipv6>
Lorsque le tunnel est monté sur votre passerelle, cela signifie qu’il est fonctionnel et que la passerelle dispose maintenant d’un accès public IPv6. A noter que si vous souhaitez filtrer finement les flux du tunnel avec PF (ce qui est plus que recommandé), des lignes similaires (à adapter en fonction de votre config) permettront d’autoriser le tunnel sur votre interface physique en IPv4 (l’interface gif0 verra le trafic IPv6 non encapsulé, comme s’il venait d’une connexion native) :
pass in on $ext_if proto ipv6 from $server_ipv4 to $ext_if
pass out on $ext_if proto ipv6 from $ext_if to $server_ipv4
Pour le moment, nous disposons simplement d’un accès IPv6 sur la passerelle. Pour votre réseau interne, par défaut, HE vous propose un sous-réseau /64 routé. Mais comme je l’expliquais en début de l’article, c’est insuffisant dans notre cas car nous souhaitons un /48 pour pouvoir le fractionner et le router sur internet. Il sera donc nécessaire de demander l’assignation d’un /48 routé. Cette opération ne prend que quelques secondes et s’effectue en un clique sur l’interface de gestion de votre compte HE.
Ce /48 se présente sous la forme xxxx:yyyy:zzzz::/48. C’est ce sous-réseau que nous allons fractionner. Ainsi on peut imaginer :
Une adresse de ces sous-réseaux est à assigner à chaque interface de la passerelle, dans un fichier « /etc/hostname.if » approprié. Si vous souhaitez bénéficier de l’autoconfiguration « stateless », rtadvd(8) est fait pour vous. Par exemple, si vous souhaitez configurer vos machines du LAN local, ajoutez cette ligne au fichier « /etc/rtadvd.conf » (remplacer « if » par l’interface sur laquelle vous souhaitez activer l’autoconfiguration) :
if:\
:addr="xxxx:yyyy:zzzz:1::":prefixlen#64:
Ensuite vous pouvez activer définitivement rtadvd en ajoutant cette ligne dans le fichier « /etc/rc.conf.local » (remplacer « if » par l’interface sur laquelle vous souhaitez activer l’autoconfiguration) :
rtadvd_flags="if"
Selon le trafic que vous souhaitez autoriser sur votre passerelle avec PF, il faut noter qu’IPv6 n’utilise pas le protocole ARP d’IPv4 pour faire la résolution entre adresse MAC et adresse IP sur un segment réseau. Il utilise au contraire une nouvelle fonctionnalité apportée par ICMPv6 (version d’ICMP pour IPv6) qui est la découverte du voisinage (ND, Neighbor Discovery). Ce mécanisme repose sur deux types de paquets :
Il faudra donc absolument autoriser ces paquets pour que les machines puissent communiquer. Des règles PF peuvent ainsi être :
pass in on gif0 inet6 proto icmp6 icmp6-type neighbrsol
Ici on autorise juste le paquet neighbrsol : le paquet neighbradv retourné par l’autre machine sera autorisé par l’état créé par le premier paquet.
De même que si vous utilisez rtadvd et que vous souhaitez effectuer un filtrage fin, il faudra autoriser les paquets du mécanisme de découverte de routeur. Le principe :
Les règles peuvent ainsi être :
pass in on $int_if inet6 proto icmp6 icmp6-type routersol
De la même façon que pour le mécanisme de ND présenté précédemment, la réponse routeradv est automatiquement acceptée par PF, un état étant créé par le premier paquet.
Il faut également noter qu’avec IPv6, filtrer l’ICMP est très délicat. La bonne pratique avec IPv4 est de ne pas le bloquer. Mais pour IPv6, plus qu’une bonne pratique c’est également une règle pour éviter d’aller vers de gros problèmes. Le meilleur exemple est le « Path MTU Discovery » (PMTU) qui se base sur les paquets ICMP « Packet too big ».
Enfin, le dernier point à aborder, le FTP. C’est souvent le protocole qui pose problème. OpenBSD offre un outil très utile pour automatiquement gérer les connexions de donnée avec PF : ftp-proxy(8). En IPv4 le fonctionnement est assez naturel, mais avec IPv6 il y a quelques particularités à prendre en compte. Prenons comme exemple un server FTP hébergé dans notre DMZ, que nous souhaitons rendre accessible en IPv6 depuis l’extérieur.
La page de manuel indique que lorsque ftp-proxy fonctionne en IPv6, l’adresse par défaut sur laquelle il écoute est ::1 (équivalent de 127.0.0.1 pour IPv6). Or, un bug rend impossible les redirections IPv6 vers ::1. Il faudra donc rediriger avec PF le trafic sur une adresse globale, et non sur le localhost. Par exemple :
anchor "ftp-proxy/*"
pass in quick inet6 proto tcp to port ftp rdr-to $client_ipv6 port 8021
Ensuite, lorsque l’on démarre ftp-proxy, il faut lui passer les bons arguments pour qu’il écoute sur l’adresse en question et redirige le trafic sur notre serveur FTP :
$ sudo /usr/sbin/ftp-proxy -6 -b <client_ipv6> -R <ftp_server>
Pour conclure cet article, il faut bien garder à l’esprit que les extraits de configuration dont je parle sont uniquement là pour améliorer la compréhension. Ils doivent être finement adaptés selon votre configuration, vos buts et la topologie de votre réseau.
]]>Ma configuration marche tellement bien que plusieurs personnes de mon entourage m’ont demandé des accès. Mais j’ai rapidement eu envie de surveiller la consommation relative à OpenVPN ainsi que les utilisateurs connectés à un instant T.
OpenVPN ne facilite pas vraiment la tâche pour récupérer des informations. Elles sont de plus très minimales. Deux moyens sont possibles : envoyer un signal SIGUSR2 au processus OpenVPN ou consulter le fichier défini par l’option status dans la configuration du serveur.
La solution la plus simple que j’ai trouvé est de réaliser un petit script qui parcourt le ou les fichiers de configuration d’OpenVPN (pour ma part deux instances fonctionnent donc j’ai deux fichiers à analyser). Ce script est écrit en Perl et génère une page HTML classique contenant un tableau avec des informations comme le nom de l’utilisateur, son adresse IP source, son adresse IP virtuelle, les quantités de données envoyées et reçues et enfin le temps de connexion.
Je l’utilise dans un cronjob qui réécrit la page en question toutes les minutes.
Pour l’utiliser :
openvpnstatus.pl fichier_log1 [fichier_log2...] > webpage.html
Il permet d’utiliser des en-têtes et pieds de page personnalisés. Il faut positionner les variables header
et footer
.
Voici le script openvpnstatus.pl.
]]>