{{>toc}}

h1. OpenVPN

h2. point a point

<pre>

openvpn --genkey --secret tst.key

#server

openvpn --mktun --dev-type tap --dev taptst

ip link set taptst up

openvpn --dev-type tap --dev tapstg --comp-lzo yes --cipher none --proto udp --daemon --keepalive 10 30 --secret tst.key --port 1234

#client

openvpn --mktun --dev-type tap --dev taptst

ip link set taptst up

openvpn --dev-type tap --dev tapstg --comp-lzo yes --cipher none --proto udp --daemon --keepalive 10 30 --secret tst.key --remote A.B.C.D 1234

</pre>

h2. server

Pour ignorer les push IP et route du serveur coté client openvpn il suffit de mettre "tls-client" a la place de "client"

l'option --client est un raccourci pour --tls-client  --pull et --pull est ce qui accepte les directives serveur.

h2. Point-à-point avec routage d'un bloc d'IP.

Le but est d'utiliser OpenVPN pour du *partage de connexion ADSL*. La collecte ADSL n'étant 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…

Ce qui ne concerne 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…)

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

h3. Configuration d'OpenVPN

h4. 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>

h4. 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>

h3. Routage

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

h4. 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>

h3. On lance

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

<pre>

/etc/init.d/openvpn restart

</pre>

h3. …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. Proxmox

http://www.nedproductions.biz/wiki/configuring-a-proxmox-ve-2.x-cluster-running-over-an-openvpn-intranet

http://blog.developpeur-neurasthenique.fr/auto-hebergement-configurer-un-cluster-proxmox-2-sans-multicast.html