Utili­ser un Turris Omnia comme client VPN

J’ai récem­ment acheté un routeur Turris Omnia. En effet, ayant démé­nagé dans un appar­te­ment dispo­sant de la fibre, je ne pouvais plus avoir de liai­son ADSL chez LDN. Qu’à celà ne tienne me disais-je, je prends un VPN chez eux et hop, j’ai un accès tout propre à Inter­net. Mais mon fidèle Buffalo était trop peu puis­sant pour faire office de client VPN pour une bande passante aussi élevée. D’où le Turris, plus puis­sant (et on peut faire plein de trucs avec, c’est un très beau jouet (certes, pas donné)).

Voici comment je m’y suis pris. Tout d’abord, envoyer sur le Turris les fichiers néces­saires à la connexion VPN four­nis par LDN : ca_server.crt, client.crt, et client.key. Je mets tout ça dans /etc/openvpn.

Puis je rajoute la confi­gu­ra­tion VPN au fichier /etc/config/openvpn :

config openvpn 'vpn'
    option enabled '1'
    option client '1'
    option dev 'tun'
    option keepalive '10 1200'
    option nobind '1'
    option ca '/etc/openvpn/ca_server.crt'
    option cert '/etc/openvpn/client.crt'
    option key '/etc/openvpn/client.key'
    option ns_cert_type 'server'
    option comp_lzo 'yes'
    option verb '3'
    option log '/tmp/log/openvpn.log'
    list remote 'vpn.ldn-fai.net 1194'
    option up '/etc/openvpn/up.sh'
    option down '/etc/openvpn/down.sh'
    option script_security '2'

Dans le script /etc/openvpn/up.sh, je remplace les routes par défaut du routeur pour faire passer tout le trafic par le VPN, et dans /etc/openvpn/down.sh, je les remets en place. Je crois (j’ai fait toutes ces mani­pu­la­tions il y a quelques mois, je ne me souviens plus très bien) que j’ai créé ces scripts parce que les routes ne se mettaient pas en place toutes seules.

NB : le réseau de la box opéra­teur est 192.168.2.0/24, je l’ai modi­fié pour ne pas le confondre avec mon réseau local 192.168.1.0/24 fourni par le Turris. 192.168.2.1 est l’adresse IP de la box.

/etc/openvpn/up.sh :

#!/bin/ash
ip route del default via 192.168.2.1 dev eth1
ip route add default via mon_IP_publique_fournie_par_LDN dev tun0
exit 0

/etc/openvpn/down.sh :

#!/bin/ash
ip route del default via mon_IP_publique_fournie_par_LDN dev tun0
ip route add default via 192.168.2.1 dev eth1
exit 0

Pour que le routeur arrive quand même à joindre le serveur VPN de LDN une fois les routes par défaut modi­fiées, j’ai modi­fié le fichier /etc/config/network :

config route
    option interface 'wan'
    option target '80.67.188.131' # IP du serveur vpn.ldn-fai.net
    option metric '10'
    option gateway '192.168.2.1'

config route
    option interface 'vpn'
    option target '0.0.0.0'
    option netmask '0.0.0.0'
    option gateway 'mon_IP_publique_fournie_par_LDN'

Au niveau du fire­wall, il faut créer une zone tun et ajou­ter quelque petits trucs (dans /etc/config/firewall) :

config zone
    option input 'ACCEPT'
    option output 'ACCEPT'
    option name 'tun'
    option masq '1'
    option network 'vpn'
    option forward 'REJECT'

config forwarding
    option dest 'wan'
    option src 'lan'

config forwarding
    option dest 'wan'
    option src 'tun'

config forwarding
    option dest 'tun'
    option src 'lan'

Norma­le­ment, il y a tout ce qu’il faut pour faire du Turris (et par exten­sion, d’un routeur sous OpenWRT) un client VPN qui va four­nir un réseau exploi­tant ce VPN.

Et l’IPv6 ? C’est vrai, je n’ai pas parlé d’IPv6 ici. Tout d’abord parce qu’il m’a moins embêté qu’IPv4 (pas besoin de redé­fi­nir les routes par défaut dans des scripts par exemple), ensuite parce que j’ai des bouts de confi­gu­ra­tion IPv6 dont je ne pas convaincu qu’ils soient néces­saires. Je vous les donne quand même :

Dans /etc/config/network :

config route6
    option interface 'wan'
    option target '2001:913:0:2000::131'  # IP du serveur vpn.ldn-fai.net
    option gateway 'fe80::a3e:5dff:fe74:b40a' # adresse link-local de la route IPv6 par défaut de mon Turris

config route6
    option interface 'vpn'
    option target '::/0'
    option gateway 'fe80::a3e:5dff:fe74:b40a'
    # Oui, c'est la même qu'au dessus. On pourrait croire que ça ne fonctionne pas, mais si.
    # Et je ne vois pas trace d'une IP orange lors d'un traceroute6.
    # Donc vraiment, je ne sais pas si c'est nécessaire

Pour propo­ser de l’IPv6 en DHCP à votre réseau local, mettez ceci dans /etc/config/network :

config interface 'lan'
    option ifname 'eth0 eth2'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6prefix '2001:DB8:42::/48' # Range IPv6 fourni par LDN
    option ip6assign '64' # Je réduis à un /64 pour mon réseau local
    option ip6hint 'beef' # Je choisis 2001:DB8:42:beef::/64 pour mon réseau local

Pourquoi créer un bridge entre eth0 et eth2 ? Bon sang, je ne sais plus… mais ça fonc­tionne donc bon.

Bonus : si les hôtes de votre réseau local ne peuvent pas se connec­ter les uns aux autres, j’avais déjà écrit un article avec la solu­tion 🙂

Pour le Turris, j’ai fait ainsi, dans /etc/config/network, d’après ce post :

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0 1 2 3 5'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '4 6'

Merci à mes tipeurs :-)

Le 14 juillet 2016, j’ai lancé mes pages Tipeee et Libe­ra­pay.

La récom­pense de base est l’ap­pa­ri­tion sur une page mensuelle de remer­cie­ments… voici celle de juin !

Le code, c’est comme une drogue pour moi : quand j’y retouche, je replonge sévère 🙂

Merci à :

Profi­tons un peu de cet article pour faire un petit résumé de mon acti­vité libriste du mois de juin.

  • Lutim est sorti en version 0.8 ! Pas mal de chan­ge­ments dont un construc­teur de gale­rie depuis la liste des images déjà envoyées, une page de statis­tiques de l’ins­tance amélio­rée et surtout le support de Post­greSQL, ce qui permet d’amé­lio­rer gran­de­ment les perfor­mances sur les instances très solli­ci­tées (dont l’ins­tance offi­cielle, ainsi que celle de Frama­soft). À noter que cette version fut vite suivie de versions de correc­tion de bugs. Nous en sommes aujourd’­hui à la version 0.8.4
  • Un peu de boulot sur Lstu : amélio­ra­tion des tests unitaires et auto­ri­sa­tion du raccour­cis­se­ment d’URL en .onion. À noter que l’ins­tance offi­cielle est main­te­nant acces­sible via le réseau Tor à l’adresse http://lstu­piioqgxmq66f.onion/. (Vous pouvez retrou­ver cette adresse en allant sur https://lstu.fr/onion)
  • J’ai déve­loppé un plugin Mojo­li­cious pour m’ai­der à déve­lop­per mes logi­ciels utili­sant ce frame­work et qui utilisent Post­greSQL : Mojo­li­cious::Plugin::PgURLHel­per
  • Un autre plugin Mojo­li­cious, pour amélio­rer les perfor­mances de mes logi­ciels en cachant faci­le­ment les ressources statiques (javas­cript, feuilles de style, etc) : Mojo­li­cious::Plugin::StaticCache
  • Connais­sez-vous Masto­don ? Non, pas le groupe de musique, le réseau social, semblable à Twit­ter. J’y suis présent sur l’instance de Frama­soft et je parti­cipe à un petit jeu fort sympa­thique qui s’y déroule : le #Mercre­diFic­tion. Chaque mercredi, les parti­ci­pants écrivent une petite fiction en 500 carac­tères (ou plus, ou moins, on s’en fiche un peu, mais ce n’est pas non plus un roman qu’il faut écrire, même pas une nouvelle). Mais comment garder trace de ses micro-fictions ? En utili­sant Last pardi ! Un nouveau logi­ciel que j’ai créé pour l’oc­ca­sion. On lui donne une liste de pouets (sur Masto­don, on ne twitte pas, on pouéte) et, par la magie des Gitlab Pages, il publie un site repre­nant les pouets en ques­tion et génère aussi un flux RSS ainsi qu’un epub. Je compile mes #Mercre­diFic­tion sur https://luc.frama.io/mercre­di­fic­tion/, mais j’ai aussi compilé la fiction « Back-Up » de Stéphane Desienne sur https://luc.frama.io/backup/. Back-Up a été initia­le­ment publié en 117 pouets, publiés entre le 29 mai et le 23 juin 2017.
    Je n’ai pas encore eu le temps de faire un guide de Last à l’usage des non-tech­ni­ciens, mais cela vien­dra. Pour les tech­ni­ciens : forkez le dépôt sur une instance de Gitlab, modi­fiez le nom du dépôt selon votre envie, modi­fiez la confi­gu­ra­tion, commit­tez, pushez et lais­sez Gitlab Pages s’oc­cu­per du reste 🙂
  • J’ai terminé un projet commencé (et aban­donné) il y 8 mois, un programme de créa­tion de musique à partir de l’his­to­rique d’un dépôt git : Audource. Une fois n’est pas coutume, je l’ai programmé en Python (il n’y avait pas de module Perl correct pour trai­ter du son). Si vous voulez voir ce que ça peut donner, télé­char­gez et écou­tez https://frama­git.org/luc/audource/-/jobs/arti­facts/master/down­load?job=lutim (musique géné­rée à partir du dépôt git de Lutim).
  • Et enfin, j’ai repris le déve­lop­pe­ment de Dolo­mon (je n’ai pas encore poussé les modi­fi­ca­tions sur le dépôt, hein), à moitié pendant mon temps de travail chez Frama­soft, à moitié sur mon temps libre. J’y ai ajouté la possi­bi­lité d’y ouvrir un compte (avant, il n’y avait qu’une authen­ti­fi­ca­tion LDAP), de s’y connec­ter, de le modi­fier, de retrou­ver son mot de passe et — raffi­ne­ment qui manque assez souvent dans les logi­ciels libres — de suppri­mer son compte. Plus la possi­bi­lité de désac­ti­ver les dolos au bout d’un certain temps ou au bout d’un certain temps après la première visite (Olivier Saraja saura d’où vient cette fonc­tion­na­lité 😉)

Bref, je n’ai pas chômé 😁 (comme en atteste la frise chro­no­lo­gique de mes commits)