TOTAL
Depuis Dec 2006
1'942'871 Visiteurs
4'218'042 Pages

Stats Nov 2010
82'909 Visiteurs
146'476 Pages
196 pays
Statistiques completes



Aidez-nous à traduire
nos tutoriaux!

REJOINGNEZ
l'équipe OpenManiak.
OPENVPN - Le Tutorial Facile - Routage

OpenVPN Routage
Dernière modif: Dec 20 2007


Outil
Installation
Ergonomie
Forum



Détails OpenVPN, c'est quoi?
Captures d'écran
Prérequis & Installation
Tutorial OpenVPN
-----MODE DE SECURITÉ -----------
Tunnel transparent
Clef statique
SSL & PKI (certificats)
-----ÉTUDE DE CAS-----------
VPN IP (TUN)
VPN Ethernet (TAP)
Configurations VPN avancées
----------------
Bridging
Routing




If you like our tutorials, don't hesitate to support us and visit our sponsors!
Si vous aimez nos tutoriaux, n'hésitez pas à nous supporter et visiter nos sponsors!



1. PRINCIPE
2. SCHEMA
3. CONFIGURATION OPENVPN
4. CONFIGURATION QUAGGA
5. VERIFICATIONS
6. TEST DE REDONDANCE
7. SCENARIO DU SITE CENTRAL



1. PRINCIPES

Dans ce scénario, nous allons associer OpenVPN avec un routeur open source appelé Quagga pour créer un triangle de redondance. Les systèmes d'exploitation utilisés sont des Linux Ubuntu. Notez que OpenVPN peut être installé indifféremment sur Linux ou Windows mais par contre Quagga seulement sur Linux.

Le principe de l'étude de cas est que chaque site a deux liens Internet avec deux différents fournisseurs d'accès et chaque lien Internet supporte un tunnel OpenVPN vers l'un des deux autres sites.

Si un tunnel tombe par exemple dans le cas d'un problème chez le fournisseur d'accès, tout le trafic sera derouté via l'autre tunnel OpenVPN avec l'aide du protocole de routage dynamique OSPF.

attention Veuillez être attentif au fait que dans ce scénario avancé, vous devez posséder les connaissances sur l'utilisation d'OpenVPN en clefs partagées et mode IP ainsi que de Quagga.
Utilisez les liens web dans les sections OpenVPN et Quagga pour trouver de l'aide.
Haut de la page



2. SCHEMA:

openvpn routing ospf quagga

Haut de la page



3. CONFIGURATION OPENVPN

attention Avant de procéder aux configurations OpenVPN, vous devez connaître les concepts suivants:
- Bases d'OpenVPN.
- Création d'une clef statique OpenVPN.
- Etablissement d'un tunnel OpenVPN en mode clefs partagées & mode IP.

L' étude de cas OpenVPN paramètres avancés peut aussi être consultée pour information.

***************************

Chaque routeur Linux a deux tunnels vers les autres sites. Le mode de sécurité et les clefs partagées, le mode du tunnel est le mode IP et une clef différente est utilisée pour chacun des trois tunnels

Les prérequis pour utiliser plusieurs tunnels OpenVPN sur le même système sont les suivants:
- chaque tunnel doit avoir un port différent.
- un fichier de configuration séparé doit être établi pour chaque tunnel.

Voici le résumé à propos des tunnels avec la désignation du serveur/client, le port UDP et le nom fichier contenant la clef:
- Tunnel Site A - Site B: A est le serveur, B le client, port 2003, keyAB.txt
- Tunnel Site A - Site C: A est le serveur, C le client, port 2001, keyAC.txt
- Tunnel Site B - Site C: B est le serveur, C le client, port 2002, keyBC.txt

Créons des fichiers de configurations OpenVPN. Soyez attentif à mettre les fichiers de configurations dans le dossier /etc/openvpn et avec une extension "*.conf" pour pouvoir utiliser le script de démarrage d'OpenVPN.

Linux du Site A

# /etc/openvpn/siteAB.conf
# Site A (serveur) - Site B (client)
dev tun0
ifconfig 10.7.0.9 10.7.0.10
secret /etc/openvpn/keyAB.txt
verb 2
port 2003
# /etc/openvpn/siteAC.conf
# Site A (serveur) - Site C (client)
dev tun1
ifconfig 10.7.0.1 10.7.0.2
secret /etc/openvpn/keyAC.txt
verb 2
port 2001
Linux du Site B

# /etc/openvpn/siteBA.conf
# Site B (client) - Site A (serveur)
dev tun0
remote 50.0.2.52
ifconfig 10.7.0.10 10.7.0.9
secret /etc/openvpn/keyAB.txt
verb 2
port 2001
# /etc/openvpn/siteBC.conf
# Site B (serveur) - Site C (client)
dev tun1
ifconfig 10.7.0.5 10.7.0.6
secret /etc/openvpn/keyBC.txt
verb 2
port 2002
Linux du Site C

# /etc/openvpn/siteCA.conf
# Site C (client) - Site A (serveur)
dev tun0
remote 50.0.1.51
ifconfig 10.7.0.2 10.7.0.1
secret /etc/openvpn/keyAC.txt
verb 2
port 2002
# /etc/openvpn/siteCB.conf
# Site C (client) - Site B (server)
dev tun1
remote 60.0.1.61
ifconfig 10.7.0.6 10.7.0.5
secret /etc/openvpn/keyAC.txt
verb 2
port 2002
Haut de la page


4. CONFIGURATION QUAGGA

attention Avant de procéder à la configuration de Quagga, il est obligatoire de savoir installer l'outil et en configurer les bases.
***************************

Trois choses doivent être paramétrées sous Quagga:
1. Les adresses IP des interfaces.
2. Les annonces OSPF.
3. Le routage des passerelles OpenVPN.

Ne configurez pas l'adresse IP des interfaces au niveau Linux mais seulement sur le routeur Quagga.

Site A

Quagga_SiteA#vtysh
configure terminal
  interface eth0
    description Liaison vers Site C
    ip address 50.0.1.51/24
    link-detect
  interface eth1
    description Liaison vers Site B
    ip address 50.0.2.52/24
    link-detect
  interface lo
    Réseau local virtuel
    ip address 10.1.1.1/32
    link-detect
!
  router ospf
    network 10.1.1.0/32 area 0.0.0.0
    network 10.7.0.0/30 area 0.0.0.0
    network 10.7.0.8/30 area 0.0.0.0
!
  ip route 60.0.2.62/32 50.0.2.1
  ip route 70.0.1.71/32 50.0.1.1
!
!
--
|
|
|
|
|
1. Adresses IP des interfaces
|
|
|
|
|
|
--
|
|
2. Annonces OSPF
|
--
|
3. Routages des passerelles OpenVPN
|
--
Site B

Quagga_SiteB#vtysh
configure terminal
  interface eth0
    description Liaison vers Site C
    ip address 60.0.1.61/24
    link-detect
  interface eth1
    description Liaison vers Site A
    ip address 60.0.2.62/24
    link-detect
  interface lo
    Réseau local virtuel
    ip address 10.2.2.2/32
    link-detect
!
  router ospf
    network 10.2.2.2/32 area 0.0.0.0
    network 10.7.0.4/30 area 0.0.0.0
    network 10.7.0.8/30 area 0.0.0.0
!
  ip route 50.0.2.52/32 60.0.2.1
  ip route 70.0.2.72/32 60.0.1.1
!
!
--
|
|
|
|
|
1. Adresses IP des interfaces
|
|
|
|
|
|
--
|
|
2. Annonces OSPF
|
--
|
3. Routages des passerelles OpenVPN
|
--
Site C

Quagga_SiteC#vtysh
configure terminal
  interface eth0
    description Liaison vers Site A
    ip address 70.0.1.71/24
    link-detect
  interface eth1
    description Liaison vers Site B
    ip address 70.0.2.72/24
    link-detect
  interface lo
    Réseau local virtuel
    ip address 10.3.3.3/32
    link-detect
!
  router ospf
    network 10.3.3.3/32 area 0.0.0.0
    network 10.7.0.0/30 area 0.0.0.0
    network 10.7.0.4/30 area 0.0.0.0
!
  ip route 60.0.1.61/32 70.0.2.1
  ip route 50.0.1.51/32 70.0.1.1
!
!
--
|
|
|
|
|
1. Adresses IP des interfaces
|
|
|
|
|
|
--
|
|
2. Annonces OSPF
|
--
|
3. Routages des passerelles OpenVPN
|
--

*****************************************************************

Activation de la redirection IP ("IP forwarding") sur les trois systèmes Linux:

L'IP forwarding (redirection IP) est requit pour transférer des paquets entre les interfaces réseaux d'un système Linux.
Voir un schéma du routage dans le noyau Linux.

#echo "1" > /proc/sys/net/ipv4/ip_forward
La commande ci-dessous va ajouter la valeur "1" à l'intérieur du fichier /proc/sys/net/ipv4/ip_forward et ainsi activer l'IP forwarding.
Si vous voulez garder l'IP forwarding après un redémarrage du système Linux:

#echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
Il est possible de vérifier le statut de l'ip_forwarding au niveau du routeur Quagga:

#show ip forwarding
IP forwarding is on

Dans ce cas, l'IP forwarding est activé.

Haut de la page



5. VERIFICATIONS

Vérifions l'état du routage depuis le système Linux situé sur le site A.

Regardons d'abord le processus "openvpn", vous devriez en voir deux, un pour chaque tunnel.

Linux_SiteA#ps -ef | grep openvpn
UID PID PPID C STIME TTY TIME CMD
root




 
4495




 
1




 
0




 
08:26




 
?




 
00:00:00




 
/usr/sbin/openvpn
--writepid /var/run/openvpn.siteAB.pid
--daemon ovpn-siteAB
--status /var/run/openvpn.siteAB.status 10
--cd /etc/openvpn
--config /etc/openvpn/siteAB.conf
root




 
4502




 
1




 
0




 
08:26




 
?




 
00:00:00




 
/usr/sbin/openvpn
--writepid /var/run/openvpn.keyAC.pid --daemon ovpn-keyAC
--status /var/run/openvpn.keyAC.status 10
--cd /etc/openvpn
--config /etc/openvpn/keyAC.conf
Vérifiez les routes depuis la plateforme Quagga.

Quagga_SiteA#show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
    I - ISIS, B - BGP, > - selected route, * - FIB route
     
C>* 10.1.1.1/32 is directly connected, lo
C>* 50.0.1.0/24 is directly connected, eth0
C>* 50.0.2.0/24 is directly connected, eth1
C>* 10.7.0.2/32 is directly connected, tun1
C>* 10.7.0.10/32 is directly connected, tun0
     
S>* 60.0.2.62/32 [1/0] via 50.0.2.1, eth1
S>* 70.0.1.71/32 [1/0] via 50.0.1.1, eth0
     
O 10.7.0.2/32 [110/10] is directly connected, tun1, 00:19:09
O 10.7.0.10/32 [110/10] is directly connected, tun0, 00:19:09
     
O>* 10.2.2.2/32 [110/20] via 10.7.0.10, tun0, 00:07:56
O>* 10.7.0.6/32 [110/20] via 10.7.0.10, tun0, 00:07:56
O>* 10.7.0.9/32 [110/20] via 10.7.0.10, tun0, 00:07:56
O>* 10.3.3.3/32 [110/20] via 10.7.0.2, tun1, 00:00:48
O>* 10.7.0.1/32 [110/20] via 10.7.0.2, tun1, 00:00:48
O>* 10.7.0.5/32 [110/20] via 10.7.0.2, tun1, 00:00:48
Vérifiez les voisins OSPF. (OSPF neighbors)

Quagga_SiteA#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
10.3.3.3 1 Full/DROther 36.522s 10.7.0.2 tun1:10.7.0.1 0 0 0
10.2.2.2 1 Full/DROther 33.610s 10.7.0.10 tun0:10.7.0.9 0 0 0
Vérifiez les routes OSPF.

Quagga_SiteA#show ip ospf route
============ OSPF network routing table ============
N 10.2.2.2/32 [20] area: 0.0.0.0
    via 10.7.0.10, tun0
N 10.3.3.3/32 [20] area: 0.0.0.0
    via 10.7.0.2, tun1
N 10.7.0.1/32 [20] area: 0.0.0.0
    via 10.7.0.2, tun1
N 10.7.0.2/32 [10] area: 0.0.0.0
    directly attached to tun1
N 10.7.0.5/32 [20] area: 0.0.0.0
    via 10.7.0.2, tun1
N 10.7.0.6/32 [20] area: 0.0.0.0
    via 10.7.0.10, tun0
N 10.7.0.9/32 [20] area: 0.0.0.0
    via 10.7.0.10, tun0
N 10.7.0.10/32 [10] area: 0.0.0.0
    directly attached to tun0
     
============ OSPF router routing table =============
     
============ OSPF external routing table ===========
Veuillez noter que Quagga montre seulement les meilleures routes OSPF. Sous les routeurs Cisco ou Vyatta par exemple, nous verrions dans la base de données OSPF (OSPF database, toutes les routes apprises pour un sous-réseau.

Vérifiez les routes au niveau Linux.

Quagga_SiteA#route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
50.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
70.0.1.71 50.0.1.1 255.255.255.255 UGH 0 0 0 eth0
               
50.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
60.0.2.62 50.0.2.1 255.255.255.255 UGH 0 0 0 eth1
               
10.2.2.2 10.7.0.10 255.255.255.255 UGH 20 0 0 tun0
10.7.0.6 10.7.0.10 255.255.255.255 UGH 20 0 0 tun0
10.7.0.9 0 10.7.0.10 255.255.255.255 UGH 20 0 0 tun0
10.7.0.10 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
               
10.3.3.3 10.7.0.2 255.255.255.255 UGH 20 0 0 tun1
10.7.0.1 10.7.0.2 255.255.255.255 UGH 20 0 0 tun1
10.7.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
10.7.0.5 10.7.0.2 255.255.255.255 UGH 20 0 0 tun1
Vérifiez les ports UDP ouverts.

Quagga_SiteA#netstat -uae
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode
Active Internet connections (servers and established)
udp 0 0 *:2001 *:*   root 15387
udp 0 0 *:2003 *:*   root 15352
Voir des informations détaillées sur netstat.

Haut de la page



6. SCENARIO DE REDONDANCE

Il est temps de tester si le triangle de redondance marche correctement.

Pour le tester, nous retirons le câble physique connecté à l'interface "eth0" de Quagga sur le site A. Ceci simulera une coupure de lien Internet.

Le tunnel OpenVPN Site A - Site B va tomber et Quagga sur le site A n'apprendra donc plus les réseaux OSPF de Quagga sur le Site C.
Ainsi, Quagga A va utiliser la route via Quagga sur le site B pour atteindre le site C.

openvpn routing ospf quagga

Vérifiez les routes depuis le routeur Quagga.

Quagga_SiteA#show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
    I - ISIS, B - BGP, > - selected route, * - FIB route
     
C>* 10.1.1.1/32 is directly connected, lo
C>* 50.0.1.0/24 is directly connected, eth0
C>* 50.0.2.0/24 is directly connected, eth1
C>* 10.7.0.2/32 is directly connected, tun1
C>* 10.7.0.10/32 is directly connected, tun0
     
S>* 60.0.2.62/32 [1/0] via 50.0.2.1, eth1
S>* 70.0.1.71/32 [1/0] via 50.0.1.1, eth0
     
O 10.7.0.2/32 [110/10] is directly connected, tun1, 00:19:09
O 10.7.0.10/32 [110/10] is directly connected, tun0, 00:19:09
     
O>* 10.2.2.2/32 [110/20] via 10.7.0.10, tun0, 00:11:53
O>* 10.3.3.3/32 [110/30] via 10.7.0.10, tun0, 00:02:18
O>* 10.7.0.1/32 [110/30] via 10.7.0.10, tun0, 00:02:18
O>* 10.7.0.5/32 [110/30] via 10.7.0.10, tun0, 00:02:18
O>* 10.7.0.6/32 [110/20] via 10.7.0.10, tun0, 00:11:53
O>* 10.7.0.9/32 [110/20] via 10.7.0.10, tun0, 00:11:53
Quand le tunnel Site A - Site B est fonctionnel, la route pour 10.3.3.3/32 est apprise de la manière suivante:
O>*   10.3.3.3/32 [110/20] via 10.7.0.2, tun1, 00:02:18

Vérifiez les voisins OSPF. (OSPF neighbors)

Quagga_SiteA#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
10.2.2.2 1 Full/DROther 33.610s 10.7.0.10 tun0:10.7.0.9 0 0 0
Traceroute de Quagga sur le Site C pour voir si les paquets sont bien deroutés via le Site B.

Le traceroute est lancé au niveau Linux parce nous avons besoin d'utiliser l'option "s" pour spécifier l'adresse IP source. Les options des utilitaires Traceroute ou Ping ne sont pas disponibles sous la plateforme Quagga.

Linux_SiteA#traceroute -s 10.1.1.1 10.3.3.3
traceroute to 10.3.3.3 (10.3.3.3) from 10.1.1.1, 30 hops max, 40 byte packets 1 10.7.0.10 (10.7.0.10) 0.588 ms 0.471 ms 0.347 ms 2 10.3.3.3 (10.3.3.3) 0.715 ms 1.734 ms 0.512 ms
Vérifiez la base de données OSPF. (OSPF database)

Quagga_SiteA#show ip ospf database
  OSPF Router with ID (10.1.1.1)
    Router Link States (Area 0.0.0.0)
               
Link ID   ADV Router Age Seq# CkSum Link count
10.1.1.1   10.1.1.1 240 0x8000000d 0x91df 4
10.2.2.2   10.2.2.2 816 0x80000006 0xa110 5
10.3.3.3   10.3.3.3 242 0x80000040 0xbc81 4
Vérifiez les routes OSPF.

Quagga_SiteA#show ip ospf route
============ OSPF network routing table ============
N 10.2.2.2/32 [20] area: 0.0.0.0
    via 10.7.0.10, tun0
N 10.3.3.3/32 [30] area: 0.0.0.0
    via 10.7.0.10, tun0
N 10.7.0.1/32 [30] area: 0.0.0.0
    via 10.7.0.10, tun0
N 10.7.0.2/32 [10] area: 0.0.0.0
    directly attached to tun1
N 10.7.0.5/32 [30] area: 0.0.0.0
    via 10.7.0.10, tun0
N 10.7.0.6/32 [20] area: 0.0.0.0
    via 10.7.0.10, tun0
N 10.7.0.9/32 [20] area: 0.0.0.0
    via 10.7.0.10, tun0
N 10.7.0.10/32 [10] area: 0.0.0.0
    directly attached to tun0
     
============ OSPF router routing table =============
     
============ OSPF external routing table ===========
Quand le tunnel Site A - Site B est fonctionnel, la route pour 10.3.3.3/32 est apprise de la manière suivante:

N
 
10.3.3.3/32
 
[20] area: 0.0.0.0
via 10.7.0.2, tun0
Retour à la situation normale.

Quand le lien Internet sur le Site A remonte, le tunnel OpenVPN Site A - Site C est reconstruit automatiquement et, dans le même temps, les annonces OSPF venant du routeur Quagga sur le site C sont de nouveau apprises.
Depuis le site A, 10.3.3.3 sera appris directement du site C avec une métrique de 20 et indirectement depuis le site B avec une métrique de 30.
Comme la route avec la métrique la plus basse est élue meilleure route, le chemin vers le site C va revenir sur le tunnel Site A - Site C au lieu du tunnel Site A - Site B au moment de la coupure du fournisseur Internet

Haut de la page



7. SCENARIO DU SITE CENTRAL

Dans ce scénario, le site B est considéré comme un site central (hub site). Les deux liens réseaux sur ce site sont de hauts débits. Le lien Site A - Site C est un lien téléphonique de très faible bande passante utilisé pour la redondance.
Si nous gardons les paramètres OSPF par défaut, nous serons dans le même scénario que celui décrit en haut de cette page où les trois liens sont actifs.
Si le Site A veut atteindre le Site C via le site B, nous devons augmenter le Cout OSPF sur le lien Site A - Site C à une valeur supérieur à celui du cout OSPF via le site B qui est de 30.

Pour les configurations OpenVPN et Quagga, nous pouvons garder exactement les mêmes paramètres que ceux présentés dans le scénario du haut de cette page, nous avons juste à ajouter les Couts OSPF.

openvpn routing hub

Quagga_SiteA#vtysh
configure terminal
  interface tun1
    ip ospf cost 100
Quagga_SiteC#vtysh
configure terminal
  interface tun0
    ip ospf cost 100
Quagga sur le site A va recevoir deux annonces pour 10.3.3.3/32 qui est le réseau local sur le site C.

Annonces OSPF apprises au niveau du routeur Quagga sur le Site C:

N
 
10.3.3.3/32
 
[30] area: 0.0.0.0
via 10.7.0.10, tun0
Annonces OSPF apprises au niveau du routeur Quagga sur le Site B:

N
 
10.3.3.3/32
 
[110] area: 0.0.0.0
via 10.7.0.2, tun1
Veuillez noter que Quagga montre seulement la meilleure route OSPF. Sous les routeurs Cisco ou Vyatta par exemple, nous verrions dans la base de données OSPF (OSPF database) toutes les routes apprises pour un sous-réseau.

Avec Quagga, nous ne voyons que la meilleure annonce avec un Cout égal à 30 (commande "show ip ospf route"). Si le tunnel Site A - Site B est en panne, la seconde annonce OSPF sera affiché à l'écran

Haut de la page





If you liked our tutorials, don't hesitate to support us and visit our sponsors!
Si vous aimez nos tutoriaux, n'hésitez pas à nous supporter et visiter nos sponsors!