Projet

Général

Profil

Historique

Wiki » Technique »

OpenVPN » Historique » Version 7

« Précédent - Version 7/48 (diff) - Suivant » - Version actuelle
Jocelyn Dealande, 02/05/2012 00:40

OpenVPN

point a point

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

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.

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…)

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

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 ce tutoriel. 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 :
  1. 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.
  2. 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

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

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

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