h1. 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é…

p=. !vpn_partage.png!

Ce quie ne couvre pas cette documentation.
* 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…)

h2. 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_.

<pre>
openvpn --genkey --secret trifouillis.key
</pre>

h2. 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_) :

<pre>
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
</pre>

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

<pre>
ifup tap0
</pre>

h2. Configuration d'OpenVPN

h3. Configuration OpenVPN client (machine term_locale)

_/etc/openvpn/trifouillis.conf_ : 
<pre>
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
</pre>

h3. Configuration OpenVPN serveur (machine term_distante)

_/etc/openvpn/trifouillis.conf_ : 
<pre>
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
</pre>

h2. Routage

h3. Sur le serveur (machine term_distante)

Sort du cadre de ce tutoriel. Simplement le bloc (_1.2.3.1/28_ dans notre exemple) doit être routé vers _term_distante_.

h3. 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_

<pre>
#!/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

</pre>

_/etc/openvpn/trifouillis/vpn.down.sh_

<pre>
#!/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
</pre>

h2. On lance

De chaque côté pour que la magie opère :

<pre>
/etc/init.d/openvpn restart
</pre>

h2. …et on débugue
Quelques commandes pour tester/debuguer (sur term_locale)

Interface tap existe ?
<pre>
ifconfig tap
</pre>

Tunnel monté et fonctionnel (depuis local_endpoint) ?
<pre>
ping 9.9.9.8
</pre>

Source-routing du blocpasse bien par le tunnel ?
<pre>
ip route get 8.8.8.8 from

# Réponse attendue :
8.8.8.8 from via dev tap0
</pre>

Ping fonctionne depuis le réseau routé à travers le VPN ?

<pre>
ping -I 1.2.3.1/28 www.ffdn.org
</pre>

Afficher les règles de routage de la table 250
<pre>
ip route show table 250
</pre>

Afficher les règles de consultation des tables :
<pre>
ip rule show
</pre>

h2.Pour aller plus loin…

h3. 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 :
<pre>
iface tap0 inet6 static
address 2607:f0d0:2001:000a:0000:0000:0000:0010
netmask 64
gateway 2607:f0d0:2001:000a:0000:0000:0000:0001
</pre>