Publié le: 2013-08-25

CARP, Pfsync, GRE, IPSEC

Nous allons voir dans cette article comment mettre en place de la haute disponibilité sur pare-feu en utilisant CARP et pfsync. Ensuite nous relierons deux sites par un tunnel GRE chiffré en IPSEC.

Ce tutoriel est réalisé sous Virtualbox.

Schéma global de la solution:

Infrastructure

Pour appréhender ce tutoriel vous devez avoir pris connaissance des liens suivants:

Nous allons dans cet exemple mettre en place trois serveurs OpenBSD, dont deux utilisant CARP (avec une IP virtuelle) pour assurer de la haute-disponibilté.

Voici le scénario:

  • Réseau d’entreprise
  • Site distant
  • LAN principal et LAN distant.

Matériel

  • Trois serveurs OpenBSD 5.2 disposant de deux cartes réseau:
    • em0: WAN
    • em1: LAN

Modifications du Noyau

Nous allons configurer le noyau de chaque OpenBSD afin qu’il puisse répondre à nos besoins.

Activez le routage en éditant le fichier /etc/sysctl.conf:

net.ipv4.ip_forward=1

ainsi que les options relatives à CARP:

net.inet.carp.preempt=1
net.inet.carp.log=3

Configuration de CARP et PFSync

Nos machines utilisent le réseau LAN via la plage d’adresses 10.17.0.0/24. Pour mettre en place CARP et pfsync nous allons avoir besoin de plusieurs interfaces que nous allons configurer.

Configuration de CARP

GATEWAY A

/etc/hostname.carp1

inet 10.17.0.12 255.255.255.0 NONE vhid 1 carpdev em1 \
pass unixperience advbase 1 advskew 100

GATEWAY B

/etc/hostname.carp1

inet 10.17.0.12 255.255.255.0 NONE vhid 1 carpdev em1 \
pass unixperience advbase 1 advskew 10

Le paramétrage définit:

  • Les requêtes CARP sont envoyées toutes les secondes entre les deux passerelles afin de définir le “Master” et le “Backup”.
  • Le advbase étant identique, la gateway B sera maître étant donné que sont advskew est le plus faible

Configuration de PFSync

Par souci de sécurité nous allons mettre le trafic de synchronisation pfsync dans un VLAN dédié entre les gateway. Ce VLAN sera encapsulé sur l’interface em0 et tagué VLAN 2.

Gateway A

/etc/hostname.vlan2

inet 172.21.0.31 255.255.255.0 NONE vlan 2 vlandev em1

/etc/hostname.pfsync0

up syncdev vlan2 syncpeer 172.21.0.32

Gateway B

/etc/hostname.vlan2

inet 172.21.0.32 255.255.255.0 NONE vlan 2 vlandev em1

/etc/hostname.pfsync0

up syncdev vlan2 syncpeer 172.21.0.31

Une fois la configuration effectuée, on lance les interfaces dédiées avec le script de lancement d’OpenBSD (vous ne pouvez spécifier qu’une interface en argument, cela évitera de reconfigurer les interfaces physique):

sh /etc/netstart

Vous devez maintenant avoir 2 nouvelles interfaces réseau (carp1 et pfsync0), la première possèdant notre IP 192.168.56.101 de manière partagée.

ifconfig carp1
ifconfig pfsync0

Vous pouvez observer le basculement entre les serveurs en désactivant l’interface carp1 sur le serveur maître. L’autre serveur passera de backup à master (ce changement est visible dans la console tty1, via un message kernel, ou en tapant dmesg).

Connexion au site distant

Mise en place un Tunnel GRE

Vous trouverez plus d’informations sur le Tunnel GRE dans cet article: Tunnel GRE

Configurons maintenant les interfaces GRE sur chaque passerelle.

Gateway A

/etc/hostname.gre0

172.16.0.1 172.16.0.3 netmask 0xffffffff link0 up
tunnel 192.168.56.102 192.168.56.105

Gateway B

172.168.0.2 172.16.0.4 netmask 0xffffffff link0 up
tunnel 192.168.56.103 192.168.56.105

Gateway C (Routeur distant)

/etc/hostname.gre0

172.168.0.3 172.16.0.1 netmask 0xffffffff link0 up
tunnel 192.168.56.105 192.168.56.102

/etc/hostname.gre1

172.168.0.4 172.16.0.2 netmask 0xffffffff link0 up
tunnel 192.168.56.105 192.168.56.103

Chaque interface GRE est connectée à une des gateway de notre LAN.

Tapez ensuite la commande sh /etc/netstart sur chaque machine pour prendre en compte les tunnels. Testez ensuite le fonctionnement du tunnel en pingant “l’autre bout”

Nos sites distants sont désormais connectés. Le principal inconvénient est la sécurité. En effet, ces tunnels ne sont pas sécurisés, n’importe qui peut observer le trafic en clair sur le WAN. Le second problème est le routage, comment rendre cette interconnexion dynamique ? La réponse: OSPF.

Mise en place de OSPF

La mise en place d’ospf est plutôt simple. La lecture du man (article ospfd.conf) vous apportera toute la lumière nécessaire. Nous allons dans le cas présent utiliser l’aire OSPF 1 via les tunnels GRE et utiliser un mot de passe (hashé en MD5): unix-experience.

/etc/ospfd.conf (Gateway A)

router-id 192.168.56.102
redistribute connected
gre_if="gre0"
password="unix-experience"
auth-md 1 $password
auth-type crypt
auth-md-keyid 1
area 0.0.0.1 {
         interface $gre_if {}
}

/etc/ospfd.conf (Gateway C)

router-id 192.168.56.103
redistribute connected
gre_if0="gre0"
gre_if1="gre1"
password="unix-experience"
auth-md 1 $password
auth-type crypt
auth-md-keyid 1
area 0.0.0.1 {
         interface $gre_if0 {}
         interface $gre_if1 {}
}

Pour ceux connaissant la syntaxe de pf vous retrouverez des similitudes.

Après quelques secondes, tapez la commande netstat -nrf -inet afin de visualiser l’état de la table de routage. Elle devrait se remplir avec des champs de poids 32 (OSPF)

N’oubliez pas d’activer OSPF au démarrage via /etc/rc.conf.local

Mise en place d’IPSEC

Le tunnel GRE étant non chiffré, nous allons appliquer une couche de chiffrement IPSec entre nos deux sites. Il faut commencer par activer la prise en charge d’IPSEC dans le noyau:

net.inet.esp.enable=1
net.inet.ah.enable=1

Voici donc le fichier de configuration de GA qui devra être adapté pour chaque gateway.

/etc/ipsec.conf

ike esp transport from 192.168.56.102 to 192.168.56.105 \
psk unix-experience

Il faut ensuite échanger les clés publiques (créée dans le fichier /etc/isakmp/local.pub à l’installation).

Par exemple pour le chiffrement de GA vers GC, copiez le fichier local.pub de GA dans le fichier /etc/isakmpd/pubkeys/ipv4/192.168.56.102 sur GC (le nom de fichier correspondant à l’IP de GA)

Notez que si vous utilisez un nom DNS pour établir le tunnel, il faudra utiliser le répertoire FQDN avec pour nom de fichier le FQDN

Lancez ensuite le chiffrement IPSEC

isakmpd -K
ipsecctl -f /etc/ipsec.conf

Si vous rencontrez des problèmes, un tail sur le fichier /var/log/messages devrait permettre de comprendre les problèmes pouvant être rencontrés.

Si le tunnel est opérationnel, ajoutez l’entrée suivante dans /etc/rc.conf.local afin d’activer IPSEC au boot:

isakmpd_flags="-K"
ipsec=YES

Sources