Libreswan
Libreswan est une implémentation IPSec open source basée sur FreeS/WAN et Openswan. La plupart des distributions Linux incluent Libreswan ou facilitent son installation. Vous pouvez l'installer sur des hôtes dans un réseau sur site ou sur le réseau d'un fournisseur cloud. Pour obtenir un exemple de configuration d'un hôte Libreswan dans un autre fournisseur cloud pour la connexion à un réseau cloud virtuel (VCN) Oracle Cloud Infrastructure, reportez-vous à Accès à d'autres clouds avec Libreswan.
Cette rubrique propose une configuration pour un CPE exécutant Libreswan. La prise en charge de l'interface de tunnel virtuel pour cette configuration basée sur un routage requiert au minimum la version 3.18 de Libreswan et un noyau Linux 3.x ou 4.x récent. Cette configuration a été validée à l'aide de Libreswan version 3.29.
Oracle fournit des instructions de configuration pour un ensemble testé de fournisseurs et de dispositifs. Utilisez la configuration appropriée pour le fournisseur et la version du logiciel.
Si la version de l'appareil ou du logiciel qu'Oracle utilise pour vérifier la configuration ne correspond pas exactement à l'appareil ou au logiciel, vous pouvez néanmoins créer la configuration nécessaire sur l'appareil. Consultez la documentation du fournisseur et apportez les modifications nécessaires.
Si le périphérique provient d'un fournisseur ne figurant pas dans la liste des fournisseurs et des périphériques vérifiés, ou si vous savez déjà configurer le périphérique pour IPSec, reportez-vous à la liste des paramètres IPSec pris en charge et à la documentation du fournisseur pour obtenir de l'aide.
Oracle Cloud Infrastructure propose un VPN site à site, une connexion IPSec sécurisée entre un réseau sur site et un réseau cloud virtuel (VCN).
Le diagramme suivant présente une connexion IPSec de base à Oracle Cloud Infrastructure avec des tunnels redondants. Les adresses IP utilisées dans ce diagramme sont fournies à titre d'exemple uniquement.
Meilleures pratiques
Cette section présente les remarques et les meilleures pratiques générales relatives à l'utilisation d'un VPN site à site.
Configuration de tous les tunnels pour chaque connexion IPSec
Oracle déploie deux têtes de réseau IPSec pour les connexions afin de fournir une haute disponibilité pour les charges de travail stratégiques. Côté Oracle, ces deux têtes de réseau se trouvent sur des routeurs différents à des fins de redondance. Nous vous recommandons de configurer tous les tunnels disponibles pour une redondance maximale. Il s'agit d'une notion clé de la philosophie "Design for Failure".
Présence de CPE redondants dans les emplacements réseau sur site
Nous recommandons que chaque site se connectant à IPSec via Oracle Cloud Infrastructure dispose de dispositifs en périphérie redondants (également appelés CPE). Ajoutez chaque CPE à la console Oracle et créez une connexion IPSec distincte entre une passerelle de routage dynamique (DRG) et chaque CPE. Pour chaque connexion IPSec, Oracle fournit deux tunnels sur des têtes de réseau IPSec géographiquement redondantes. Pour plus d'informations, reportez-vous au guide pour la redondance de la connectivité (PDF).
Remarques concernant le protocole de routage
Lorsque vous créez une connexion de VPN site à site IPSec, celle-ci possède deux tunnels IPSec redondants. Oracle vous encourage à configurer le CPE de sorte qu'il utilise les deux tunnels (si le CPE le prend en charge). Par le passé, Oracle a créé des connexions IPSec comportant jusqu'à quatre tunnels IPSec.
Les trois types de routage suivants sont disponibles. Vous sélectionnez le type de routage de chaque tunnel du VPN site à site séparément :
- Routage dynamique BGP : les routages disponibles sont appris dynamiquement via BGP. Le DRG apprend dynamiquement les routages à partir du réseau sur site. Côté Oracle, la passerelle de routage dynamique publie les sous-réseaux du réseau cloud virtuel.
- Routage statique : lorsque vous configurez la connexion IPSec au DRG, vous spécifiez les routages particuliers vers le réseau sur site que vous souhaitez que le VCN connaisse. Vous devez également configurer le dispositif CPE avec des routages statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises dynamiquement.
- Routage basé sur une stratégie : lorsque vous configurez la connexion IPSec au DRG, vous indiquez les routages spécifiques au réseau sur site que le VCN doit connaître. Vous devez également configurer le dispositif CPE avec des routages statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises dynamiquement.
Pour obtenir plus d'informations sur le routage avec un VPN site à site, notamment des recommandations Oracle sur la façon d'utiliser l'algorithme de sélection du meilleur chemin BGP, reportez-vous à Racheminement du VPN site à site.
Autres configurations de CPE importantes
Assurez-vous que les listes d'accès sur le CPE sont configurées correctement afin de ne pas bloquer le trafic nécessaire depuis et vers Oracle Cloud Infrastructure.
Si plusieurs tunnels fonctionnent simultanément, le routage peut être asymétrique. Pour prendre en compte le routage asymétrique, assurez-vous que le CPE est configuré pour gérer le trafic provenant du VCN sur l'un des tunnels. Par exemple, vous devez désactiver l'inspection ICMP, configurer le contournement de l'état TCP. Pour plus d'informations sur la configuration appropriée, contactez le support technique du fournisseur du CPE. Pour configurer le routage de sorte qu'il soit symétrique, reportez-vous à Routage du VPN site à site.
Avertissements et limites
Cette section présente les caractéristiques et les limites générales importantes du VPN site à site. Reportez-vous aux limites de service pour obtenir la liste des limites applicables et des instructions de demande d'augmentation de limite.
Routage asymétrique
Oracle utilise un routage asymétique sur les tunnels qui constituent la connexion IPSec. Configurez les pare-feu en gardant cela à l'esprit. Sinon, les tests ping ou le trafic d'application sur la connexion ne fonctionnent pas de façon fiable.
Lorsque vous utilisez plusieurs tunnels vers Oracle Cloud Infrastructure, nous vous recommandons de configurer le routage pour acheminer le trafic de manière déterministe via le tunnel préféré. Afin d'utiliser un tunnel IPSec en tant que tunnel principal et un autre en tant que tunnel de sauvegarde, configurez des routages plus spécifiques pour le tunnel principal (BGP) et des routages moins spécifiques (récapitulatif ou par défaut) pour le tunnel de sauvegarde (BGP/statique). Sinon, si vous publiez la même route (par exemple, une route par défaut) via tous les tunnels, renvoyez le trafic d'un VCN vers des routes réseau sur site vers l'un des tunnels disponibles. En effet, Oracle utilise un routage asymétrique.
Pour consulter des recommandations de routage Oracle spécifiques sur la façon de forcer le routage symétrique, reportez-vous à Routage du VPN site à site.
VPN site à site basé sur un routage ou sur une stratégie
Le protocole IPSec utilise des associations de sécurité pour décider comment crypter les paquets. Au sein de chaque association de sécurité, vous définissez des domaines de cryptage pour mettre en correspondance le type de protocole et les adresses IP source et de destination d'un paquet avec une entrée de la base de données d'association de sécurité afin de définir le mode de cryptage ou de décryptage du paquet.
Les termes ID de proxy, index de paramètre de sécurité (SPI) ou sélecteur de trafic peuvent être utilisés par d'autres fournisseurs ou dans la documentation du secteur pour faire référence aux associations de sécurité ou aux domaines de cryptage.
Il existe deux méthodes générales pour l'implémentation des tunnels IPSec :
- Tunnels basés sur un routage : également appelés tunnels basés sur le saut suivant. Une recherche de table de routage est effectuée sur l'adresse IP de destination d'un paquet. Si l'interface sortante du routage est un tunnel IPSec, le paquet est crypté et envoyé à l'autre extrémité du tunnel.
- Tunnels basés sur une stratégie : le protocole et les adresses IP source et de destination du paquet sont mis en correspondance avec la liste des instructions de stratégie. Si une correspondance est trouvée, le paquet est crypté selon les règles de l'instruction de stratégie.
Les têtes de réseau du VPN site à site Oracle utilisent des tunnels basés sur un routage. Elles peuvent fonctionner avec des tunnels basés sur une stratégie, mais cela donne lieu à des avertissements, répertoriés dans les sections suivantes.
Avertissement relatif à Libreswan 3.25
Si un CPE utilise Libreswan 3.25 ou une version antérieure et que vous essayez de configurer une connexion IKEv1 avec un CPE en tant que répondeur, vous devez définir explicitement le paramètre de phase 2 dans une configuration de CPE pour que le tunnel IPSec apparaisse. Par exemple, à l'aide de l'algorithme de cryptage actuellement recommandé AES-256-gcm et du groupe de confidentialité persistante 5, vous devez configurer le paramètre de phase 2 phase2alg="aes_gcm256;modp1536" sur le CPE.
Ce problème n'apparaît pas dans les versions ultérieures de Libreswan.
Si le CPE prend en charge les tunnels basés sur un routage, utilisez cette méthode pour configurer le tunnel. Il s'agit de la configuration la plus simple, qui offre la meilleure interopérabilité avec la tête de réseau du VPN Oracle.
Le tunnel IPSec basé sur un routage utilise un domaine de cryptage présentant les valeurs suivantes :
- Adresse IP source : n'importe laquelle (0.0.0.0/0)
- Adresse IP de destination : n'importe laquelle (0.0.0.0/0)
- Protocole : IPv4
Si vous devez être plus spécifique, vous pouvez utiliser un routage récapitulatif unique pour les valeurs du domaine de cryptage au lieu d'un routage par défaut.
Lorsque vous utilisez des tunnels basés sur une stratégie, chaque entrée de stratégie (bloc CIDR d'un côté de la connexion IPSec) que vous définissez génère une association de sécurité IPSec avec chaque entrée admissible à l'autre extrémité du tunnel. Cette paire est appelée domaine de cryptage.
Dans ce diagramme, l'extrémité Passerelle de routage dynamique Oracle du tunnel IPSec possède des entrées de stratégie pour trois blocs CIDR IPv4 et un bloc CIDR IPv6. L'extrémité CPE sur site du tunnel possède des entrées de stratégie pour deux blocs CIDR IPv4 et deux blocs CIDR IPv6. Chaque entrée génère un domaine de cryptage avec toutes les entrées possibles à l'autre extrémité du tunnel. Les deux côtés d'une paire d'association de sécurité doivent utiliser la même version d'adresse IP. Le résultat est un total de huit domaines de cryptage.
Si le CPE ne prend en charge que les tunnels basés sur une stratégie, tenez compte des restrictions suivantes.
- Le VPN site à site prend en charge plusieurs domaines de cryptage, mais sa limite supérieure est de 50.
- Si vous aviez une situation similaire à celle de l'exemple précédent et que vous n'aviez configuré que trois des six domaines de cryptage IPv4 possibles côté CPE, la liaison serait répertoriée dans un état "Partial UP" car tous les domaines de cryptage possibles sont toujours créés côté DRG.
- En fonction de la date de création d'un tunnel, vous ne pourrez peut-être pas le modifier pour utiliser un routage basé sur une stratégie et devrez le remplacer par un nouveau tunnel IPSec.
- Les blocs CIDR utilisés à l'extrémité Passerelle de routage dynamique Oracle du tunnel ne peuvent pas chevaucher ceux utilisés à l'extrémité CPE sur site.
- Un domaine de cryptage doit toujours se trouver entre deux blocs CIDR de la même version d'adresse IP.
Si le CPE se trouve derrière un périphérique NAT
En général, l'identificateur IKE CPE configuré sur l'extrémité sur site de la connexion doit correspondre à celui utilisé par Oracle. Par défaut, Oracle utilise l'adresse IP publique du CPE, que vous fournissez lors de la création de l'objet CPE dans la console Oracle. Toutefois, si un CPE se trouve derrière un dispositif NAT, l'identificateur IKE CPE configuré sur l'extrémité sur site peut être l'adresse IP privée du CPE, comme indiqué dans le diagramme suivant.
Certaines plates-formes de CPE ne vous permettent pas de modifier l'identificateur IKE local. Si ce n'est pas le cas, vous devez modifier l'ID IKE distant dans la console Oracle pour correspondre à l'ID IKE local du CPE. Vous pouvez fournir cette valeur lors de la configuration de la connexion IPSec ou ultérieurement en modifiant cette dernière. Oracle s'attend à ce que la valeur soit une adresse IP ou un nom de domaine qualifié complet tel que cpe.example.com. Pour obtenir des instructions, reportez-vous à Modification de l'identificateur IKE CPE utilisé par Oracle.
Paramètres IPSec pris en charge
Pour obtenir la liste des paramètres IPSec pris en charge (indépendamment du fournisseur) pour toutes les régions, reportez-vous à Paramètres IPSec pris en charge.
Le numéro ASN BGP Oracle pour le domaine de cloud commercial est 31898. Si vous configurez un VPN site à site pour US Government Cloud, reportez-vous à Paramètres de VPN site à site requis pour Government Cloud et à Numéro ASN BGP d'Oracle. Pour United Kingdom Government Cloud, reportez-vous à Régions.
Configuration du CPE
Les instructions de configuration de cette section sont fournies par Oracle Cloud Infrastructure pour ce CPE. Si vous avez besoin d'assistance ou d'une aide supplémentaire, contactez directement le support du fournisseur du CPE.
La figure suivante illustre la disposition de base de la connexion IPSec.
Fichiers de configuration Libreswan par défaut
L'installation par défaut de Libreswan crée les fichiers suivants :
etc/ipsec.conf: racine de la configuration Libreswan./etc/ipsec.secrets: racine de l'emplacement où Libreswan recherche les clés secrètes (les clés prépartagées du tunnel)./etc/ipsec.d/: répertoire de stockage des fichiers.confet.secretspour les tunnels Oracle Cloud Infrastructure (par exemple,oci-ipsec.confetoci-ipsec.secrets). Libreswan vous encourage à créer ces fichiers dans ce dossier.
Le fichier etc/ipsec.conf par défaut inclut la ligne suivante :
include /etc/ipsec.d/*.confLe fichier etc/ipsec.secrets par défaut inclut la ligne suivante :
include /etc/ipsec.d/*.secretsLes lignes précédentes fusionnent automatiquement tous les fichiers .conf et .secrets du répertoire /etc/ipsec.d dans les fichiers de configuration et de clés secrètes principaux utilisés par Libreswan.
A propos de l'utilisation d'IKEv2
Oracle prend en charge Internet Key Exchange version 1 (IKEv1) et version 2 (IKEv2). Si vous avez configuré la connexion IPSec dans la console pour qu'elle utilise IKEv2, vous devez configurer le CPE afin qu'il utilise uniquement IKEv2 et les paramètres de cryptage IKEv2 associés pris en charge par le CPE. Pour obtenir la liste des paramètres pris en charge par Oracle pour IKEv1 ou IKEv2, reportez-vous à Paramètres IPSec pris en charge.
La version IKE est spécifiée lors de la configuration du fichier de configuration IPSec dans la tâche 3 de la section suivante. Cet exemple de fichier affiche un commentaire illustrant la configuration de IKEv1 par rapport à IKEv2.
Processus de configuration
Libreswan prend en charge les tunnels basés sur un routage et basés sur une stratégie. Les types de tunnel peuvent coexister sans interférer l'un avec l'autre. Les têtes de réseau du VPN Oracle utilisent des tunnels basés sur un routage. Nous vous recommandons de configurer Libreswan avec la syntaxe de configuration d'interface de tunnel virtuel.
Pour plus de détails sur les paramètres spécifiques utilisés dans ce document, reportez-vous à Paramètres IPSec pris en charge.
Selon la distribution Linux que vous utilisez, vous devrez peut-être activer le transfert IP sur une interface pour permettre aux clients d'envoyer et de recevoir du trafic via Libreswan. Dans le fichier /etc/sysctl.conf, définissez les valeurs suivantes et appliquez les mises à jour avec sudo sysctl -p.
Si vous utilisez une interface autre que eth0, remplacez eth0 dans l'exemple suivant par l'interface (lignes 5 et 7).
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0La configuration Libreswan utilise les variables suivantes. Décidez des valeurs avant de procéder à la configuration.
${cpeLocalIP}: adresse IP du dispositif Libreswan.${cpePublicIpAddress}: adresse IP publique pour Libreswan. Il s'agit de l'adresse IP de l'interface externe. Selon la topologie du réseau, la valeur peut être différente de${cpeLocalIP}.${oracleHeadend1}: pour le premier tunnel, adresse IP publique Oracle obtenue à partir de la console Oracle.${oracleHeadend2}: pour le deuxième tunnel, adresse IP publique Oracle obtenue à partir de la console Oracle.${vti1}: nom de la première interface de tunnel virtuel utilisée. Par exemple, vti1.${vti2}: nom de la seconde interface de tunnel virtuel utilisée. Par exemple, vti2.${sharedSecret1}: clé prépartagée du premier tunnel. Vous pouvez utiliser la clé prépartagée par défaut fournie par Oracle ou en indiquer une lors de la configuration de la connexion IPSec dans la console Oracle.${sharedSecret2}: clé prépartagée du deuxième tunnel. Vous pouvez utiliser la clé prépartagée par défaut fournie par Oracle ou en indiquer une lors de la configuration de la connexion IPSec dans la console Oracle.${vcnCidrNetwork}: plage d'adresses IP du réseau cloud virtuel.
La configuration Libreswan utilise le concept de gauche et de droite afin de définir les paramètres de configuration d'un dispositif CPE local et de la passerelle distante. Chaque côté de la connexion (appelée conn dans la configuration Libreswan) peut être un côté gauche ou droit, mais la configuration de cette connexion doit être cohérente. Dans cet exemple :
- left : CPE Libreswan local
- right : tête de réseau du VPN Oracle
Utilisez le modèle suivant pour le fichier /etc/ipsec.d/oci-ipsec.conf. Le fichier définit les deux tunnels créés par Oracle lors de la configuration de la connexion IPSec.
Si le CPE se trouve derrière un dispositif NAT 1 à 1, annulez la mise en commentaire du paramètre leftid et définissez-le sur ${cpePublicIpAddress}.
conn oracle-tunnel-1
left=${cpeLocalIP}
# leftid=${cpePublicIpAddress} # See preceding note about 1-1 NAT device
right=${oracleHeadend1}
authby=secret
leftsubnet=0.0.0.0/0
rightsubnet=0.0.0.0/0
auto=start
mark=5/0xffffffff # Needs to be unique across all tunnels
vti-interface=${vti1}
vti-routing=no
ikev2=no # To use IKEv2, change to ikev2=insist
ike=aes_cbc256-sha2_384;modp1536
phase2alg=aes_gcm256;modp1536
encapsulation=yes
ikelifetime=28800s
salifetime=3600s
conn oracle-tunnel-2
left=${cpeLocalIP}
# leftid=${cpePublicIpAddress} # See preceding note about 1-1 NAT device
right=${oracleHeadend2}
authby=secret
leftsubnet=0.0.0.0/0
rightsubnet=0.0.0.0/0
auto=start
mark=6/0xffffffff # Needs to be unique across all tunnels
vti-interface=${vti2}
vti-routing=no
ikev2=no # To use IKEv2, change to ikev2=insist
ike=aes_cbc256-sha2_384;modp1536
phase2alg=aes_gcm256;modp1536
encapsulation=yes
ikelifetime=28800s
salifetime=3600sUtilisez le modèle suivant pour le fichier /etc/ipsec.d/oci-ipsec.secrets. Il contient deux lignes par connexion à IPSec (une ligne par tunnel).
${cpePublicIpAddress} ${oracleHeadend1}: PSK "${sharedSecret1}"
${cpePublicIpAddress} ${oracleHeadend2}: PSK "${sharedSecret2}"Après avoir configuré les fichiers de configuration et de clés secrètes, vous devez redémarrer le service Libreswan.
Le redémarrage du service Libreswan peut avoir une incidence sur les tunnels existants.
La commande suivante relit le fichier de configuration et redémarre le service Libreswan.
service ipsec restartUtilisez la commande ip suivante pour créer des routages statiques qui envoient du trafic à un VCN via les tunnels IPSec. Si vous êtes enregistré avec un compte utilisateur sans privilège, vous devrez peut-être utiliser sudo avant la commande.
Les routages statiques créés avec la commande
ip route ne sont pas persistants en cas de redémarrage. Pour déterminer comment rendre les routes persistantes, reportez-vous à la documentation de la distribution Linux de votre choix.ip route add ${VcnCidrBlock} nexthop dev ${vti1} nexthop dev ${vti2}
ip route showVérification
Le service Monitoring est également disponible auprès d'Oracle Cloud Infrastructure pour surveiller activement et passivement les ressources cloud. Pour plus d'informations sur la surveillance d'un VPN site à site, reportez-vous à Mesures de VPN site à site.
Si vous rencontrez des problèmes, reportez-vous à Dépannage de VPN site à site.
Vérification du statut de Libreswan
Vérifiez l'état actuel des tunnels Libreswan à l'aide de la commande suivante.
ipsec statusLe tunnel est établi si une ligne comprenant les éléments suivants apparaît :
STATE_MAIN_I4: ISAKMP SA establishedSi vous utilisez IKEv2, la ligne suivante apparaît :
STATE_V2_IPSEC_I (IPsec SA established)A l'avenir, si vous devez créer un ticket de support auprès d'Oracle pour un tunnel Libreswan, incluez la sortie de la commande ipsec status précédente.
Vérification du statut de l'interface de tunnel
Vérifiez que les interfaces de tunnel virtuel sont démarrées ou arrêtées à l'aide de la commande ifconfig ou ip link show. Vous pouvez également utiliser des applications telles que tcpdump avec les interfaces.
Voici un exemple de sortie ifconfig avec une implémentation Libreswan fonctionnelle indiquant les interfaces de tunnel virtuel disponibles.
ifconfig
<output trimmed>
vti01: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
inet6 fe80::5efe:a00:2 prefixlen 64 scopeid 0x20<link>
tunnel txqueuelen 1000 (IPIP Tunnel)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 10 dropped 0 overruns 0 carrier 10 collisions 0
vti02: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
inet6 fe80::5efe:a00:2 prefixlen 64 scopeid 0x20<link>
tunnel txqueuelen 1000 (IPIP Tunnel)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 40 dropped 0 overruns 0 carrier 40 collisions 0
Voici un exemple de sortie ip link show :
ip link show
<output trimmed>
9: vti01@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue
state UNKNOWN mode DEFAULT group default qlen 1000
link/ipip 10.0.0.2 peer 129.213.240.52
10: vti02@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue
state UNKNOWN mode DEFAULT group default qlen 1000
link/ipip 10.0.0.2 peer 129.213.240.51En outre, dans la console Oracle, chaque tunnel IPSec doit maintenant avoir l'état UP.