Libreswan
Libreswan est une mise en oeuvre IPSec à code source libre basée sur FreeS/WAN et Openswan. La plupart des distributions Linux comprennent Libreswan ou facilitent son installation. Vous pouvez l'installer sur des hôtes dans votre réseau sur place ou celui d'un fournisseur de services infonuagiques. Pour voir un exemple de configuration d'un hôte Libreswan dans un autre fournisseur de services infonuagiques pour vous connecter au réseau en nuage virtuel Oracle Cloud Infrastructure, voir Accès à d'autres nuages avec Libreswan.
Cette rubrique décrit la configuration d'un équipement local d'abonné qui exécute Libreswan. La prise en charge de l'interface de tunnel virtuel pour cette configuration basée sur les routes requiert au moins la version 3.18 de Libreswan, ainsi qu'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 d'appareils. Utilisez la configuration appropriée pour votre fournisseur et votre version de logiciel.
Si la version de l'appareil ou du logiciel utilisée par Oracle pour vérifier la configuration ne correspond pas exactement à votre appareil ou à votre logiciel, vous pouvez tout de même créer la configuration nécessaire sur votre appareil. Consultez la documentation de votre fournisseur et apportez les ajustements nécessaires.
Si le fabricant de votre appareil ne figure pas dans la liste des fournisseurs et des appareils vérifiés, ou si vous êtes déjà familiarisé avec la configuration de votre appareil pour IPSec, consultez la liste des paramètres IPSec pris en charge et la documentation relative à votre fournisseur pour obtenir de l'aide.
Oracle Cloud Infrastructure offre un RPV site à site, connexion IPSec sécurisée entre votre réseau sur place et un réseau en nuage 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 servent uniquement d'exemples.
Meilleures pratiques
Cette section décrit les meilleures pratiques et les points à considérer généraux pour utiliser un RPV site à site.
Configurer tous les tunnels pour chaque connexion IPSec
Oracle déploie deux têtes de réseau IPSec pour chacune des connexions afin d'offrir une haute disponibilité pour les charges de travail critiques. Côté Oracle, ces deux têtes de réseau se trouvent sur différents routeurs à des fins de redondance. Oracle recommande de configurer tous les tunnels disponibles pour une redondance maximale. Il s'agit d'une partie essentielle de la philosophie "Design for Failure" (conçu pour résister aux pannes).
Disposer de CPE redondants dans vos emplacements de réseau sur place
Chacun de vos sites qui se connecte avec IPSec à Oracle Cloud Infrastructure doit disposer d'appareils en périphérie de réseau redondants (également appelés équipements locaux d'abonné (CPE)). Vous ajoutez chaque équipement local d'abonné à la console Oracle et créez une connexion IPSec distincte entre votre passerelle de routage dynamique (DRG) et chaque CPE. Pour chaque connexion PSec, Oracle provisionne deux tunnels pour des têtes de réseau IPSec géographiquement redondantes. Pour plus d'informations, voir Guide sur la redondance de connectivité (PDF).
Considérations relatives au protocole de routage
Lorsque vous créez une connexion IPSec de RPV site à site, elle possède deux tunnels IPSec redondants. Oracle vous encourage à configurer votre équipement local d'abonné pour utiliser les deux tunnels (si votre CPE le prend en charge). Auparavant, Oracle créait des connexions IPSec qui possédaient jusqu'à quatre tunnels IPSec.
Les trois types de routage suivants sont disponibles, et vous en choisissez un séparément pour chaque tunnel du RPV site à site :
- Routage dynamique BGP : Les routes disponibles sont apprises de manière dynamique au moyen de BGP. La passerelle DRG apprend dynamiquement les routes de votre réseau sur place. Côté Oracle, la passerelle DRG annonce les sous-réseaux du VCN.
- Routage statique : Lorsque vous configurez la connexion IPSec à la passerelle DRG, vous spécifiez les routes particulières à votre réseau sur place que le réseau VCN doit connaître. Vous devez également configurer votre CPE avec des routes statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises dynamiquement.
- Routage basé sur des politiques : Lorsque vous configurez la connexion IPSec à la passerelle DRG, vous spécifiez les routes particulières à votre réseau sur place que le réseau VCN doit connaître. Vous devez également configurer votre CPE avec des routes statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises dynamiquement.
Pour plus d'informations sur le routage avec RPV site à site, notamment des recommandations Oracle sur la manipulation de l'algorithme de sélection du meilleur chemin BGP, voir Routage pour RPV site à site.
Autres configurations importantes de l'équipement local d'abonné
Assurez-vous que les listes d'accès sur votre équipement local d'abonné sont configurées correctement pour ne pas bloquer le trafic nécessaire depuis ou vers Oracle Cloud Infrastructure.
Si plusieurs tunnels fonctionnent simultanément, le routage peut être asymétrique. Pour permettre le routage asymétrique, assurez-vous que votre équipement local d'abonné est configuré pour gérer le trafic provenant de votre VCN sur n'importe quel tunnel. Par exemple, vous devez désactiver l'inspection ICMP, configurer le contournement de l'état TCP. Pour plus de détails sur la configuration appropriée, communiquez avec le soutien technique du fournisseur de votre CPE. Pour configurer un routage symétrique, consultez Routage pour RPV site à site.
Restrictions et limites
Cette section décrit les caractéristiques et les limites générales importantes de RPV site à site. Voir Limites de service pour une liste des limites applicables et des instructions pour demander l'augmentation d'une limite.
Routage asymétrique
Oracle utilise un routage asymétrique sur les multiples tunnels qui composent la connexion IPSec. Configurez vos pare-feux en conséquence. Dans le cas contraire, les tests ping ou le trafic d'application sur la connexion ne fonctionnent pas de manière fiable.
Lorsque vous utilisez plusieurs tunnels vers Oracle Cloud Infrastructure, Oracle vous recommande de configurer votre routage de façon à guider le trafic de manière déterministe à travers le tunnel privilégié. Pour utiliser un tunnel IPSec principal et un autre de secours, configurez des routes plus spécifiques pour le tunnel principal (BGP) et des routes moins spécifiques (route sommaire ou par défaut) pour le tunnel de sauvegarde (BGP/statique). Sinon, si vous annoncez la même route (par exemple, une route par défaut) par tous les tunnels, le trafic de retour de votre réseau VCN à votre réseau sur place est dirigé vers n'importe lequel des tunnels disponibles. En effet, Oracle utilise un routage asymétrique.
Pour des recommandations de routage Oracle spécifiques sur la manière de forcer un routage symétrique, voir Routage pour RPV site à site.
RPV site à site basé sur des routes ou sur des politiques
Le protocole IPSec utilise des associations de sécurité (AS) pour déterminer comment chiffrer les paquets. Au sein de chaque association, pour définir comment chiffrer ou déchiffrer un paquet, il vous faut paramétrer des domaines de chiffrement pour mapper les adresses IP source et cible d'un paquet, ainsi que le type de protocole, sur une entrée de la base de données des associations de sécurité.
Il est possible que d'autres fournisseurs ou que la documentation sectorielle utilisent le terme ID mandataire, index de paramètre de sécurité (SPI) ou sélecteur de trafic pour désigner les associations de sécurité ou les domaines de chiffrement.
Il existe deux méthodes générales pour mettre en oeuvre les tunnels IPSec :
- Tunnels basés sur des routes : Également appelés tunnels basés sur les sauts suivants. Une consultation de la table de routage est effectuée sur l'adresse IP de destination d'un paquet. Si l'interface de sortie de cette route est un tunnel IPSec, le paquet est chiffré et envoyé à l'autre extrémité du tunnel.
- Tunnels basés sur des politiques : Les adresses IP source et cible du paquet sont comparées à une liste d'énoncés de politique. Si une correspondance est trouvée, le paquet est chiffré en fonction des règles de cet énoncé.
Les têtes de réseau du RPV site à site Oracle utilisent des tunnels basés sur des routes, mais fonctionnent avec les tunnels basés sur des politiques. Il existe toutefois certaines restrictions indiquées dans les sections suivantes.
Restriction pour Libreswan 3.25
Si votre équipement local d'abonné utilise Libreswan 3.25 ou une version antérieure et que vous tentez de configurer une connexion IKEv1 avec votre équipement local d'abonné en tant que répondant, vous devez définir explicitement le paramètre de phase 2 dans la configuration de votre équipement pour que le tunnel IPSec apparaisse. Par exemple, avec l'algorithme de chiffrement recommandé courant AES-256-gcm et PFS group5, vous devez configurer le paramètre de phase 2 phase2alg="aes_gcm256;modp1536" sur l'équipement local d'abonné.
Ce problème ne se produit pas dans les versions ultérieures de Libreswan.
Si votre équipement local d'abonné prend en charge les tunnels basés sur des routes, utilisez cette méthode pour configurer le tunnel. Il s'agit de la configuration la plus simple. C'est aussi celle qui offre le plus d'interopérabilité avec la tête de réseau du RPV Oracle.
Une connexion IPSec basée sur des routes utilise un domaine de chiffrement avec les valeurs suivantes :
- Adresse IP source : (0.0.0.0/0)
- Adresse IP de destination : (0.0.0.0/0)
- Protocole : IPv4
Si vous devez être plus spécifique, vous pouvez utiliser une seule route sommaire pour vos valeurs de domaine de chiffrement au lieu d'une route par défaut.
Lorsque vous utilisez des tunnels basés sur des politiques, chaque entrée de politique (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 chiffrement.
Dans ce diagramme, l'extrémité DRG Oracle du tunnel IPSec comporte des entrées de politique pour trois blocs CIDR IPv4 et un bloc CIDR IPv6. L'extrémité CPE sur place du tunnel en comporte pour deux blocs CIDR IPv4 et deux blocs CIDR IPv6. Chaque entrée génère un domaine de chiffrement avec toutes les entrées possibles à l'autre extrémité du tunnel. Les deux côtés d'une paire SA doivent utiliser la même version d'IP. On obtient un total de huit domaines de chiffrement.
Si l'équipement local d'abonné ne prend en charge que les tunnels basés sur des politiques, tenez compte des restrictions suivantes.
- Le RPV site à site prend en charge plusieurs domaines de chiffrement, mais a une limite supérieure de 50 domaines de chiffrement.
- Si vous avez rencontré une situation similaire à l'exemple précédent et que vous n'avez configuré que trois des six domaines de chiffrement IPv4 possibles côté CPE, le lien serait listé dans un état "Partiellement actif", car tous les domaines de chiffrement possibles sont toujours créés côté DRG.
- Selon le moment où un tunnel a été créé, vous ne pourrez peut-être pas le modifier pour utiliser un routage basé sur des politiques et il vous faudra peut-être le remplacer par un nouveau tunnel IPSec.
- Les blocs CIDR utilisés à l'extrémité DRG Oracle du tunnel ne peuvent pas chevaucher les blocs CIDR utilisés à l'extrémité CPE sur place du tunnel.
- Un domaine de chiffrement doit toujours être compris entre deux blocs CIDR de la même version d'adresse IP.
Si votre équipement local d'abonné est derrière un appareil NAT
En général, l'identificateur IKE de CPE configuré à votre extrémité de la connexion doit correspondre à celui qu'Oracle utilise. Par défaut, Oracle utilise l'adresse IP publique du CPE, que vous fournissez lorsque vous créez l'objet CPE dans la console Oracle. Toutefois, si votre équipement local d'abonné est derrière un appareil NAT, l'identificateur IKE configuré à votre extrémité peut être l'adresse IP privée du CPE, comme illustré dans le diagramme suivant.
Certaines plates-formes CPE ne permettent pas de modifier l'identificateur IKE local. Dans ce cas, vous devez remplacer l'ID IKE distant dans la console Oracle par l'ID IKE local de votre CPE. Vous pouvez entrer cette valeur lorsque vous configurez la connexion à IPSec ou plus tard, lorsque vous la modifiez. Pour Oracle, la valeur doit être une adresse IP ou un nom de domaine complet, tel que cpe.example.com. Pour obtenir des instructions, voir Modification de l'identificateur IKE de CPE utilisé par Oracle.
Paramètres IPSec pris en charge
Pour la liste des paramètres IPSec pris en charge indépendamment du fournisseur pour toutes les régions, voir Paramètres IPSec pris en charge.
Le numéro ASN BGP d'Oracle pour le domaine du nuage commercial est 31898. Si vous configurez un RPV site à site pour le nuage gouvernemental des États-Unis, voir Paramètres de RPV site à site requis pour le nuage gouvernemental et ASN BGP d'Oracle. Pour le nuage gouvernemental du Royaume-Uni, voir Régions.
CPE Configuration (Configuration de l'équipement local d'abonné)
Les instructions de configuration de cette section sont fournies par Oracle Cloud Infrastructure pour votre équipement local d'abonné. Si vous avez besoin d'une assistance supplémentaire, communiquez directement avec le soutien technique de votre fournisseur.
La figure ci-dessous illustre la disposition de base de la connexion IPSec.
Fichiers de configuration Libreswan par défaut
L'installation de Libreswan par défaut crée les fichiers suivants :
etc/ipsec.conf: Racine de la configuration Libreswan./etc/ipsec.secrets: Racine de l'emplacement où Libreswan recherche les secrets (clés prépartagées du tunnel)./etc/ipsec.d/: Répertoire de stockage des fichiers.confet.secretspour vos 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 comprend cette ligne :
include /etc/ipsec.d/*.confLe fichier etc/ipsec.secrets par défaut comprend cette ligne :
include /etc/ipsec.d/*.secretsLes lignes précédentes fusionnent automatiquement tous les fichiers .conf et .secrets du répertoire /etc/ipsec.d dans la configuration principale et les fichiers de secrets utilisés par Libreswan.
À propos de l'utilisation de IKEv2
Oracle prend en charge le protocole Internet Key Exchange version 1 (IKEv1) et version 2 (IKEv2). Si vous configurez la connexion IPSec dans la console pour utiliser IKEv2, vous devez limiter votre CPE aux paramètres de chiffrement IKEv2 et connexes qu'il prend en charge. Pour obtenir la liste des paramètres pris en charge par Oracle pour IKEv1 ou IKEv2, voir Paramètres IPSec pris en charge.
Vous spécifiez la version IKE lors du paramétrage du fichier de configuration IPSec dans la tâche 3 de la section suivante. Dans cet exemple de fichier, un commentaire explique comment configurer IKEv2 plutôt qu'IKEv1.
Processus de configuration
Libreswan prend en charge les tunnels basés sur des routes et sur des politiques. Les types de tunnel peuvent coexister sans interférer les uns avec les autres. Les têtes de réseau du RPV d'Oracle utilisent des tunnels basés sur des routes. Oracle recommande de configurer Libreswan avec la syntaxe de configuration de l'interface de tunnel virtuel.
Pour plus de détails sur les paramètres spécifiques utilisés dans ce document, voir Paramètres IPSec pris en charge.
Selon la distribution Linux que vous utilisez, il vous faudra peut-être activer la transmission IP sur votre interface afin de permettre aux clients d'envoyer et de recevoir du trafic par l'intermédiaire de 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 autre interface qu'eth0, remplacez eth0 dans l'exemple suivant par votre 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 de Libreswan utilise les variables suivantes. Déterminez les valeurs avant de poursuivre la configuration.
${cpeLocalIP}: Adresse IP de votre appareil Libreswan.${cpePublicIpAddress}: Adresse IP publique de Libreswan. Il s'agit de l'adresse IP de votre interface externe. Selon la topologie de votre réseau, la valeur peut être différente de${cpeLocalIP}.${oracleHeadend1}: Pour le premier tunnel, point d'extrémité de l'adresse IP publique Oracle obtenu de la console Oracle.${oracleHeadend2}: Pour le second tunnel, point d'extrémité de l'adresse IP publique Oracle obtenu de la console Oracle.${vti1}: Nom de la première interface VTI utilisée. Par exemple, vti1.${vti2}: Nom de la seconde interface VTI utilisée. Par exemple, vti2.${sharedSecret1}: Clé prépartagée du premier tunnel. Vous pouvez utiliser la clé prépartagée fournie par Oracle par défaut ou fournir votre propre clé lorsque vous configurez la connexion IPSec dans la console Oracle.${sharedSecret2}: Clé prépartagée du second tunnel. Vous pouvez utiliser la clé prépartagée fournie par Oracle par défaut ou fournir votre propre clé lorsque vous configurez la connexion IPSec dans la console Oracle.${vcnCidrNetwork}: Intervalle d'adresses IP du réseau VCN.
La configuration Libreswan utilise le concept de gauche et de droite pour définir les paramètres de configuration de votre équipement local d'abonné (CPE) et de la passerelle distante. N'importe quel côté de la connexion (conn dans la configuration de Libreswan) peut être la gauche ou la droite, mais la configuration de cette connexion doit être cohérente. Dans cet exemple :
- gauche : votre équipement local d'abonné Libreswan
- droite : la tête de réseau RPV Oracle
Utilisez le modèle suivant pour votre fichier /etc/ipsec.d/oci-ipsec.conf. Ce fichier définit les deux tunnels créés par Oracle lors de la configuration de la connexion IPSec.
Si votre équipement local d'abonné est derrière un appareil NAT 1-1, annulez la mise en commentaire du paramètre leftid et réglez-le à ${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 votre 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 paramétré vos fichiers de configuration et de secrets, 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 routes statiques qui envoient le trafic à votre réseau VCN au moyen des tunnels IPSec. Si vous êtes connecté avec un compte d'utilisateur sans privilèges, il vous faudra peut-être ajouter sudo avant la commande.
Les routes statiques créées avec la commande
ip route ne sont pas conservées lors d'un redémarrage. Pour déterminer comment rendre vos 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
Un service Surveillance, également disponible dans Oracle Cloud Infrastructure, vous permet de contrôler vos ressources en nuage de manière active et passive. Pour plus d'informations sur la surveillance de votre RPV site à site, voir Mesures du RPV site à site.
En cas de problèmes, voir Dépannage du RPV site à site.
Vérifier le statut de Libreswan
Vérifiez l'état courant de vos tunnels Libreswan à l'aide de la commande suivante.
ipsec statusLe tunnel est établi si vous voyez une ligne qui inclut ce qui suit :
STATE_MAIN_I4: ISAKMP SA establishedSi vous utilisez IKEv2, vous voyez ce qui suit :
STATE_V2_IPSEC_I (IPsec SA established)Par la suite, si vous devez ouvrir un ticket My Oracle Support concernant votre 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 en ligne ou hors ligne à l'aide de la commande ifconfig ou ip link show. Vous pouvez également utiliser des applications telles que tcdump avec les interfaces.
Voici un exemple de la sortie ifconfig avec une mise en oeuvre Libreswan en cours d'exécution qui présente les interfaces VTI 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 pour 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.51De plus, dans la console Oracle, chaque tunnel IPSec doit maintenant être à l'état UP (Actif).