OpenVPN – BranchOffice

Introduction

Dans cette section, nous verrons la configuration de openVPN pour arriver à une connexion BranchOffice entre deux sites distants.

 

Préliminaires

Comme d’habitude, un système Debian Etch 4.0 à jour…. Si l’installation est fraiche et n’a pas été déjà torturé… c’est mieux… ca évite les effets de bord parfois étrange !

Pour OpenVPN, il n’y a pas de prérequis particulier, il suffit de l’installer.

Il nous faudra surtout une paire clef/certificat pour chaque gateway. Pour cela, vous pouvez vous reporter aux documentations Création de l’autorité de certification et Création d’un certificat avec le CA pour générer des certificats signés par soi-même.

 

Description réseau

Dans notre cas, nous allons considérer que nous avons 2 machines reliées à Internet avec une IP publique et chacune de ces machines a son réseau privé derrière.

Ce qui nous donne quelque chose de la forme:

   ---------------- 192.168.0.0/24
         |
         | 192.168.0.254
      Gateway A
         | 1.2.3.4
         |
        ***
        *** Internet
        ***
         |
         | 5.6.7.8
      Gateway B
         | 192.168.1.254
         |
   ---------------- 192.168.1.0/24

 

Gateway A

Sur la Gateway A, nous allons devoir lui dire d’établir un tunnel vers la gateway B, puis nous lui dirons d’emprunter ce tunnel pour joindre le réseau 192.168.1.0/24.

Le fichier de configuration assez bien commenté est juste en dessous.

Fichier /etc/openvpn/openvpn.conf:

# La gateway distante
remote 5.6.7.8
 
# On utilise un device de type tun
dev tun

# Si aucun paquet n'est envoyé pendant 30 secondes
# on envoie un ping pour maintenir la connexion
ping 30

# L'IP local et remote des interfaces tun
# Ces IP servent pour le lien point à point créé par OpenVPN
# elles n'ont rien à voir avec les LANs derrière chaque gateway
ifconfig 172.16.0.1 172.16.0.2

# Les fichiers de logs
status /var/log/openvpn/branchoffice_status.log
log-append /var/log/openvpn/branchoffice.log

# On compresse le traffic
comp-lzo

# Sur l'extrémité qui est considéré comme serveur, il faudra le fichier dh1024.pem
dh /etc/openvpn/dh1024.pem
# Le certificat du CA
ca /etc/openvpn/ssl/ca_cert.pem
# Le certificat de la gateway locale
cert /etc/openvpn/ssl/gateway_a_cert.pem
# La clef de la gateway locale
key /etc/openvpn/ssl/gateway_a_key.pem

Cela est suffisant pour la gateway A qui sera donc considéré comme le serveur

Par contre, il faudra mettre une route pour dire que si la gateway A souhaite joindre le réseau 192.168.1.0/24, elle doit aller à l’IP 172.16.0.2. Pour cela, on utilise la commande suivante:

route add -net 192.168.1.0/24 gw 172.16.0.2

 

Gateway B

Sur la Gateway B, nous allons devoir lui dire d’établir un tunnel vers la gateway A, puis nous lui dirons d’emprunter ce tunnel pour joindre le réseau 192.168.0.0/24.

Le fichier de configuration assez bien commenté est juste en dessous.

Fichier /etc/openvpn/openvpn.conf:

# La gateway distante
remote 1.2.3.4
 
# On utilise un device de type tun
dev tun

# Si aucun paquet n'est envoyé pendant 30 secondes
# on envoie un ping pour maintenir la connexion
ping 30

# L'IP local et remote des interfaces tun
# Ces IP servent pour le lien point à point créé par OpenVPN
# elles n'ont rien à voir avec les LANs derrière chaque gateway
ifconfig 172.16.0.2 172.16.0.1

# Les fichiers de logs
status /var/log/openvpn/branchoffice_status.log
log-append /var/log/openvpn/branchoffice.log

# On compresse le traffic
comp-lzo

# Sur l'extrémité qui est considéré comme client, il ne faudra pas le fichier dh1024.pem
# Le certificat du CA
ca /etc/openvpn/ssl/ca_cert.pem
# Le certificat de la gateway locale
cert /etc/openvpn/ssl/gateway_b_cert.pem
# La clef de la gateway locale
key /etc/openvpn/ssl/gateway_b_key.pem

Cela est suffisant pour la gateway B qui sera donc considéré comme le client

Par contre, il faudra mettre une route pour dire que si la gateway B souhaite joindre le réseau 192.168.0.0/24, elle doit aller à l’IP 172.16.0.1. Pour cela, on utilise la commande suivante:

route add -net 192.168.0.0/24 gw 172.16.0.1

 

Application des modifications

Il ne reste plus qu’à redémarrer les daemons OpenVPN sur les deux serveurs. Pour cela, on tape la commande suivante:

/etc/init.d/openvpn restart

 

Tests

Après tout cela, notre VPN devrait fonctionner sans soucis. Pour tester, il faut se mettre sur une machine d’un des deux réseaux privés et faire un ping vers une machine du réseau qui est derrière l’autre gatewau.

 

Configurations annexes

Elles sont donc annexes mais pas forcement facultatives !!!

Si vous vous placez sur la gateway A et que vous faites un ping vers une adresse IP du réseau privé de la gateway B, cela ne répondra pas… car la gateway A prend comme IP source son IP publique qui est « plus proche » du réseau d’en face que son IP privée.

Pour remédier à cela, il faut mettre une route au niveau des gateways pour lui spécifier l’interface et l’IP source à utiliser selon la destination.

Pour cela, vous aurez besoin de la commande ip qui se trouve dans le paquet iproute sur une Debian.

Pour placer la route sur la gateway A:

ip route add 192.168.1.0/24 via 172.16.0.2 src 192.168.0.254

et pour la gateway B:

ip route add 192.168.0.0/24 via 172.16.0.1 src 192.168.1.254

 

Mot de la fin

N’oubliez pas les règles Iptables si jamais les gateways servent aussi de firewalls !!!

il faudra autoriser le port suivant suivant:

  • UDP/1194

D’autres parts, le traitement IPsec est fait, puis les paquets passent dans les règles iptables sur Linux. Donc iptables verra des paquets avec comme ip source 192.168.0.0/24 sur l’interface publique… ce qui pourrait lui paraître étrange…

Il faut donc penser à accepter dans la table nat dans la chaine prerouting sur l’interface externe les paquets ayant comme ip source celle du réseau privé de la gateway d’en face.

A vous de voir les restrictions à mettre en place si vous ne souhaitez pas autoriser tous les traffics venant des réseaux distants !

Les filtrages peuvent être fait à la source ou à l’arrivée dans le mesure où les paquets passent par iptables puis dans le traitement IPsec pour sortir et inversement à l’arrivée.

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s