Partage ADSL OpenVPN avec bloc d'IP routé.¶
Le but est d'utiliser OpenVPN pour du partage de connexion ADSL. La collecte ADSL n'est pas maitrisée mais étant celle d'un opérateur tiers et quelconque. Les options et le fonctionnement sont très similaires à la configuration point-à-point. Sauf que tout démarre avec un script d'init et qu'il y a en plus la question du routage du bloc d'adresses. IP.
Le but est d'ammener des adresses IP publiques, via le VPN jusque chez les utilisateurs finaux (barbus du schémas). Là où par défaut, ils ne pourraient que se mettre derrière la *box et recevoir des adresses privées. Ce montage permet également de "neutraliser" un accès internet qui l'est peu…
Comme un schéma vaut mieux qu'un pavé…
- la manière dont le routeur term_distante effectue le routage du bloc vers internet.
- la manière dont le trafic est collecté sur le réseau local du côté eth1 de term_locale.
- la manière dont sont distribuée les adresses du bloc aux machines sur le réseau local (DHCP, statique…)
Préparation¶
On utilise ici le fonctionnement Debian d'OpenVPN : chaque /etc/openvpn/<nom_tunnel>.conf est une instance d'openvpn différente qui sera démarrée par le script d'init (voir /etc/default/openvpn). Ici notre instance s'appelle trifouillis.
On génère une clé symétrique et on la copie dans /etc/openvpn/trifouillis/vpn-trifouillis.key sur term_locale et term_distante.
openvpn --genkey --secret trifouillis.key
Interfaces réseau virtuelles¶
Il faut créer, via OpenVPN des interfaces virtuelles (tap). On peut faire ça proprement dans le fichier /etc/network/interfaces en ajoutant le contenu suivant (côté term_locale) :
auto tap0
iface tap0 inet static
pre-up /usr/sbin/openvpn --mktun --dev-type tap --dev tap0
post-down /usr/sbin/openvpn --rmtun --dev-type tap --dev tap0
address 9.9.9.9
netmask 255.255.255.254
C'est identique côté serveur (term_distante), on change juste 9.9.9.9 en 9.9.9.8
Puis de chaque côté, un petit
ifup tap0
Configuration d'OpenVPN¶
Configuration OpenVPN client (machine term_locale)¶
/etc/openvpn/trifouillis.conf :
dev tap0 dev-type tap comp-lzo yes cipher none proto udp verb 3 daemon log-append /var/log/openvpn-trifouillis.log remote 5.5.5.5 9999 secret /etc/openvpn/trifouillis/vpn-trifouillis.key up /etc/openvpn/trifouillis/vpn.up.sh down /etc/openvpn/trifouillis/vpn.down.sh keepalive 10 30 persist-tun # nobind permet de prendre un port aléatoire à chaque démarrage d'openVPN évitera # les bugs liés aux NAT lorsque certaines box changent d'IP publique... nobind
Configuration OpenVPN serveur (machine term_distante)¶
/etc/openvpn/trifouillis.conf :
dev tap0 dev-type tap comp-lzo yes cipher none proto udp verb 3 daemon log-append /var/log/openvpn-trifouillis.log port 9999 secret /etc/openvpn/trifouillis/vpn-trifouillis.key keepalive 10 30 persist-tun
Routage¶
Sur le serveur (machine term_distante)¶
Sort du cadre de cette documentation. Simplement le bloc (1.2.3.1/28 dans notre exemple) doit être routé vers term_distante.
Sur le client (machine term_locale)¶
L'idée ici est la suivante :- Les paquets provenant de l'interface tap OpenVPN et correspondant au bloc 1.2.3.1/28 doivent-être routés vers l'interface eth1.
- Les paquets provenant d'eth1 et avec une adresse source dans 1.2.3.1/28
Le 1. est trivial, le 2. correspond à du source-routing. Il faut tout d'abord vérifier que le source-routing est disponible dans le kernel. Cela correspond aux options du kernel Linux suivantes :
- IP_ADVANCED_ROUTER
- IP_MULTIPLE_TABLES
- IPV6_MULTIPLE_TABLES
- IPV6_SUBTREES
À vérifier dans /boot/config-$(uname -r) ou /proc/config.gz une Debian Wheezy récente est ok.
Les règles de routage sont ensuite mises en places/retirées au démarrage/arrêt d'OpenVPN (cf partie précédente, options up et down). Le contenu des scripts est le suivant :
/etc/openvpn/trifouillis/vpn.up.sh
#!/bin/sh ## On gère via une table perso (250) uniquement les IP du bloc /28 et l'IP du endpoint VPN local. ## Les autres passent par la table default du système # source-routing des IPs du bloc ip rule add prio 200 from 1.2.3.0/28 lookup 250 # endpoint local (tap0) ip rule add prio 200 from 9.9.9.9 lookup 250 ## Fonctionnement de la table 250 # Ce qui est à destination des IPs du bloc va sur eth0 # (internet -> bloc) ip route add 1.2.3.0/28 dev eth1 table 250 # Ce qui vient du bloc vers internet va dans le tunnel # (bloc -> internet) ip route add default via 9.9.9.8 dev tap0 table 250
/etc/openvpn/trifouillis/vpn.down.sh
#!/bin/sh # On supprime toutes les règles de routage du *.up.sh ip rule del prio 200 from 1.2.3.0/28 lookup 250 ip rule del prio 200 from 9.9.9.9 lookup 250 ip route del default via 9.9.9.8 dev taprhi table 250 ip route del 1.2.3.0/28 dev eth0 table 250
OpenVPN, lis-mes scripts !¶
Il convient d'ajuster une variable pour autoriser OpenVPN à utiliser nos scripts d'up/down.
/etc/default/openvpn
… OPTARGS="--script-security 2" …
On lance¶
De chaque côté pour que la magie opère :
/etc/init.d/openvpn restart
…et on débugue¶
Quelques commandes pour tester/debuguer (sur term_locale)
Interface tap existe ?
ifconfig tap
Tunnel monté et fonctionnel (depuis local_endpoint) ?
ping 9.9.9.8
Source-routing du blocpasse bien par le tunnel ?
ip route get 8.8.8.8 from # Réponse attendue : 8.8.8.8 from via dev tap0
Ping fonctionne depuis le réseau routé à travers le VPN ?
ping -I 1.2.3.1/28 www.ffdn.org
Visualiser les paquets passant dans le tunnel, dans /etc/openvpn/trifouillis.conf
… verb 5 …
Afficher les règles de routage de la table 250
ip route show table 250
Afficher les règles de consultation des tables :
ip rule show
Pour aller plus loin…¶
Et IPv6 dans tout ça ?¶
Le tunnel est de niveau 2, ce qui signifie qu'il peut faire passer aussi bien IPv4 qu'IPv6 dedans. Il faut simplement adapter le routage :
- Ajouter des règles ip route et ip rule similaires à celles pour les blocs IPv4 dans les scripts *.up.sh et *.down.sh
- Configurer l'interface tap0 en IPv6. Exemple d'etc/network/interfaces :
iface tap0 inet6 static address 2607:f0d0:2001:000a:0000:0000:0000:0010 netmask 64 gateway 2607:f0d0:2001:000a:0000:0000:0000:0001