Home :

• Home
• Contact
• Lisez-moi
• Remerciements
• Traductions
• Historique
• Références
• Statistiques
• A propos

Tutorials :

• Analyse
• 
• Wireshark
• Ettercap
• Snort & BASE
• Snort_Inline & BASE
• Kismet
• 
• Surveillance
• 
• Cacti
• PHP Weathermap
• 
• Journalisation
• 
• Php-syslog-ng
• Rancid
• IPplan
• 
• Routage
• 
• Vyatta
• Quagga
• 
• VPN
• 
• OpenVPN
• 
• Telephony
• 
• Trixbox
• 
• Emulation de lien
• 
• WANem

Autre :

• Open Source
• MySQL

Réseau :

• Réseau
• Ping
• TCPdump
• Netstat
• Iperf
• CDP

OS :

• Linux ;
• Windows ;
• 
• Debian ;
• Ubuntu ;
• 
• Outils APT
• CheckInstall
• Minicom

Php Scripts :

• Temps du monde
• Menu

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

---

⚠️⚠️⚠️
Please check our website about
attractions in Western Switzerland !! (Please use english translation).

⚠️⚠️⚠️
Merci de consulter notre site sur les
activités à faire en Suisse romande !!

---

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.

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:



Haut de la page

---

3. CONFIGURATION OPENVPN

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

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.



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.

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