| Les deux révisions précédentes Révision précédente | |
| linux_strongswan [2019/12/05 14:44] – nekan | linux_strongswan [2021/03/05 14:15] (Version actuelle) – nekan |
|---|
| ~~CLOSETOC~~ | |
| ====== Installation d'un VPN site à site avec StrongSwan ====== | ====== Installation d'un VPN site à site avec StrongSwan ====== |
| | <label type="info">Création</label> --- //[[nekan@shyrkasystem.com|Nicolas THOREZ]] 2019/05/15 20:20// |
| |
| Le recours à un VPN est très utile dans différents cas. Les plus importants sont : | Le recours à un VPN est très utile dans différents cas. Les plus importants sont : |
| Sous linux, il existe plusieurs possibilités pour établir un tunnel VPN. Les plus courantes seront OpenVPN, intéressant dans le cadre d'un poste itinérant, et StrongSwan, pour les tunnel IPSec site à site. | Sous linux, il existe plusieurs possibilités pour établir un tunnel VPN. Les plus courantes seront OpenVPN, intéressant dans le cadre d'un poste itinérant, et StrongSwan, pour les tunnel IPSec site à site. |
| |
| <note important>Ce tutoriel a été réalisé sur deux debian stretch (version 9.4 et 9.7) et en tant que root. Les adresses IP choisies sont volontairement fausses.</note> | <callout type="danger" icon="true" title="Droits">Ce tutoriel a été réalisé sur deux debian stretch (version 9.4 et 9.7) et en tant que root. Les adresses IP choisies sont volontairement fausses.</callout> |
| |
| ===== Installation ===== | ===== Installation ===== |
| * La plage d'adressage à utiliser pour attribuer une adresse IP locale aux postes distants (on peut aussi une adresse unique si une seule machine (la tête de pont donc) doit se connecter). | * La plage d'adressage à utiliser pour attribuer une adresse IP locale aux postes distants (on peut aussi une adresse unique si une seule machine (la tête de pont donc) doit se connecter). |
| |
| <note warning>Attention aux plages d'adressage. Un VPN ne pourra jamais fonctionner correctement si une plage d'adressage (par exemple : 192.168.0.0/24) existe des deux côtés du tunnel. En effet, les routeurs chercherons toujours à utiliser les routes les plus courtes et si une plage correspond aussi bien à du local qu'à du distant, la route locale sera toujours plus courte.</note> | <callout type="warning" icon="true" title="Adressage IP">Attention aux plages d'adressage. Un VPN ne pourra jamais fonctionner correctement si une plage d'adressage (par exemple : 192.168.0.0/24) existe des deux côtés du tunnel. En effet, les routeurs chercherons toujours à utiliser les routes les plus courtes et si une plage correspond aussi bien à du local qu'à du distant, la route locale sera toujours plus courte.</callout> |
| |
| Voici donc mon tableau récapitulatif : | Voici donc mon tableau récapitulatif : |
| 78.79.1.2 89.90.3.4 : PSK "Azerty123"</sxh> | 78.79.1.2 89.90.3.4 : PSK "Azerty123"</sxh> |
| |
| <note important>Il faut obligatoirement ouvrir les port UDP 500 et UDP 4500 sur votre solution de pare-feu et ce, pour chaque tête de pont.</note> | <callout type="danger" icon="true" title="Pare-feu">Il faut obligatoirement ouvrir les port UDP 500 et UDP 4500 sur votre solution de pare-feu et ce, pour chaque tête de pont.</callout> |
| |
| Notre première tête de pont est paramétrée. Passons à la seconde. | Notre première tête de pont est paramétrée. Passons à la seconde. |
| </sxh> | </sxh> |
| |
| <note>On remarque bien que les parties "left" et "right" ont été inversées entre les deux configurations.</note> | <callout type="info" icon="true" title="Configurations inversées">On remarque bien que les parties "left" et "right" ont été inversées entre les deux configurations.</callout> |
| |
| * Une fois ce fichier de configuration enregistrée, il faut éditer le fichier qui contiendra le PSK : | * Une fois ce fichier de configuration enregistrée, il faut éditer le fichier qui contiendra le PSK : |
| 89.90.3.4 78.79.1.2 : PSK "Azerty123"</sxh> | 89.90.3.4 78.79.1.2 : PSK "Azerty123"</sxh> |
| |
| <note important>Il faut obligatoirement ouvrir les port UDP 500 et UDP 4500 sur votre solution de pare-feu et ce, pour chaque tête de pont.</note> | <callout type="danger" icon="true" title="Pare-feu">Il faut obligatoirement ouvrir les port UDP 500 et UDP 4500 sur votre solution de pare-feu et ce, pour chaque tête de pont.</callout> |
| |
| La configuration des deux têtes de pont est maintenant terminée. Il ne reste plus qu'à lancer la connexion. | La configuration des deux têtes de pont est maintenant terminée. Il ne reste plus qu'à lancer la connexion. |
| Pour établir la connexion, il faut d'abord prendre en compte les configurations établies. Le plus simple est de redémarrer le daemon ipsec. Sinon il faut recharger la configuration. | Pour établir la connexion, il faut d'abord prendre en compte les configurations établies. Le plus simple est de redémarrer le daemon ipsec. Sinon il faut recharger la configuration. |
| |
| <note warning>Attention : si vous avez plusieurs tunnel VPN et que vous redémarrer le daemon, la connexion des autres tunnels sera coupée. La première méthode est donc réservée aux postes ne gérant qu'un seul tunnel.</note> | <callout type="warning" icon="true" title="Redémarrage">Attention : si vous avez plusieurs tunnel VPN et que vous redémarrer le daemon, la connexion des autres tunnels sera coupée. La première méthode est donc réservée aux postes ne gérant qu'un seul tunnel.</callout> |
| |
| * Du coup, pour redémarrer le daemon ipsec : | * Du coup, pour redémarrer le daemon ipsec : |
| connection 'test-vpn' established successfully</sxh> | connection 'test-vpn' established successfully</sxh> |
| |
| <note tip>Félicitation, votre tunnel est monté!</note> | <callout type="success" icon="true" title="Installation">Félicitation, votre tunnel est monté!</callout> |
| |
| ===== Résolution des pannes ===== | ===== Résolution des pannes ===== |
| |
| Si le tunnel ne veux pas se monter, il est intéressant d'observer les logs de la tête de pont distante lors de l'initialisation de la connexion : | <panel type="danger" title="Problème"> |
| | Si le tunnel ne veux pas se monter. |
| | </panel> |
| | <panel type="info" title="Vérification"> |
| | Il est intéressant d'observer les logs de la tête de pont distante lors de l'initialisation de la connexion : |
| <sxh bash>tail -f /var/log/kern.log</sxh> | <sxh bash>tail -f /var/log/kern.log</sxh> |
| |
| Une autre bonne source d'information est d'observer sur le pare-feu, le flux de paquets sur les ports UDP 500. Par exemple sur un pare-feu de type IPTables sous debian : | Une autre bonne source d'information est d'observer sur le pare-feu, le flux de paquets sur les ports UDP 500. Par exemple sur un pare-feu de type IPTables sous debian : |
| <sxh bash>tcpdump -i any host 78.79.1.2 and port 500</sxh> | <sxh bash>tcpdump -i any host 78.79.1.2 and port 500</sxh> |
| | </panel> |
| --- //[[nekan@shyrkasystem.com|Nicolas THOREZ]] 2019/05/15 20:20// | |
| |
| ~~DISCUSSION~~ | ~~DISCUSSION~~ |