Remarque :

Ce tutoriel nécessite un accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, reportez-vous à Introduction au niveau gratuit d'Oracle Cloud Infrastructure.
Il utilise des exemples de valeur pour les informations d'identification Oracle Cloud Infrastructure, la location et les compartiments. A la fin de votre atelier, remplacez ces valeurs par celles propres à votre environnement cloud.

Utiliser le service VPN site à site d'Oracle Cloud Infrastructure en mode HA avec routage ECMP à partir de Linux et Libreswan

Introduction

Dans le monde interconnecté d'aujourd'hui, il est essentiel de garantir la disponibilité et la sécurité des données transmises sur les réseaux. Pour répondre à ces besoins essentiels, Oracle Cloud offre des fonctionnalités réseau robustes, notamment la possibilité d'établir des tunnels IPSec hautement disponibles. Dans ce tutoriel, nous allons étudier le concept de tunnels IPSec haute disponibilité et vous guider tout au long du processus de configuration d'une architecture réseau résiliente dans Oracle Cloud à l'aide du protocole ECMP (Equal-cost multipath).

Dans ce tutoriel, nous allons nous concentrer sur l'utilisation d'Oracle Linux, un système d'exploitation puissant et sécurisé optimisé pour les environnements Oracle Cloud, ainsi que sur Libreswan, un client IPSec bien établi, pour établir des tunnels IPSec en mode route. Nous tirerons parti des fonctionnalités de la passerelle de routage dynamique (DRG) fournies par Oracle Cloud Infrastructure (OCI) pour permettre un basculement et un équilibrage de charge transparents entre plusieurs tunnels IPSec.

Objectifs

Fournissez un guide complet pour l'implémentation des tunnels IPSec dans OCI à l'aide du protocole de routage ECMP afin d'équilibrer la charge du trafic le long de ces tunnels dans le scénario actif/actif.

Comprendre les bases du protocole IPSec de site à site
Comprendre les différents modes IPSec : transport par rapport au tunnel, stratégie par rapport au routage
Configurer Libreswan dans Oracle Linux avec l'équilibrage de charge ECMP
Configurer DRGv2 pour les tunnels IPSec redondants
Tester la redondance des tunnels et l'équilibrage de charge avec Iperf3

En suivant ce tutoriel, vous acquerrez une compréhension complète de IPSec dans OCI. Vous acquerrez les compétences nécessaires pour interconnecter efficacement votre infrastructure on-premise avec OCI via une connexion redondante.

Prérequis

Une location OCI active. Vous devez disposer des droits d'accès nécessaires pour créer et gérer des ressources réseau dans OCI.
Compréhension de base du système d'exploitation Linux, des concepts de réseau et d'OCI. Cela inclut la connaissance des concepts réseau fondamentaux tels que l'adressage IP, le sous-réseau, le routage et le pare-feu.
Compréhension de base d'Oracle Linux, y compris comment installer et configurer. Si vous ne connaissez pas encore Oracle Linux, vous pouvez suivre un tutoriel ou un guide Oracle Linux de base au préalable.
Un réseau cloud virtuel (VCN) et des sous-réseaux configurés dans OCI, avec les règles de routage appropriées, la passerelle Internet, le DRG et les listes de sécurité configurés.
Bonne compréhension de l'utilisation de la console OCI ou de l'interface de ligne de commande OCI pour créer et gérer des ressources réseau.

Remarque : il est recommandé de configurer un environnement de test dans OCI pour tester les configurations réseau et IPSec avant de les implémenter dans un environnement de production.

Qu'est-ce que le VPN IPSec

La sécurité du protocole Internet (IPSec) est un cadre de normes ouvertes permettant d'assurer des communications privées et sécurisées sur les réseaux IP via l'utilisation de services de sécurité cryptographiques. IPSec prend en charge l'intégrité des données au niveau du réseau, la confidentialité des données, l'authentification de l'origine des données et la protection contre la relecture. Etant donné que IPSec est intégré à la couche Internet (couche 3), il assure la sécurité de presque tous les protocoles de la suite TCP/IP et que IPSec est appliqué de manière transparente aux applications, il n'est pas nécessaire de configurer une sécurité distincte pour chaque application qui utilise TCP/IP.

IPSec contribue à la défense en profondeur contre les attaques basées sur le réseau provenant d'ordinateurs non sécurisés, les attaques qui peuvent entraîner le déni de service des applications, des services ou du réseau.

Altération des données
Vol de données
Vol d'informations d'identification utilisateur
Contrôle administratif des serveurs, des autres ordinateurs et du réseau.

VPN site à site

Un VPN IPSec (Internet Protocol Security), également appelé VPN réseau-à-réseau, établit une connexion sécurisée et chiffrée entre deux réseaux ou plus sur Internet. Il permet la transmission sécurisée des données entre des sites distribués géographiquement, créant un réseau privé virtuel (VPN) qui étend la portée du réseau au-delà de ses limites physiques.

Dans un VPN IPSec site à site, les réseaux participants, appartenant généralement à différentes organisations ou succursales distantes de la même organisation, sont connectés via des tunnels IPSec dédiés. Ces tunnels encapsulent et cryptent le trafic réseau, garantissant ainsi sa confidentialité, son intégrité et son authenticité tout en traversant des réseaux non sécurisés tels qu'Internet.

D'autre part, un VPN point à site (P2S) établit une connexion sécurisée entre des appareils client individuels et un réseau distant. Contrairement aux VPN site à site, qui connectent les réseaux, les VPN P2S permettent un accès distant sécurisé à des appareils individuels pour accéder aux ressources réseau. P2S Les VPN sont généralement utilisés pour permettre un accès sécurisé aux employés distants, aux sous-traitants ou aux utilisateurs mobiles qui doivent se connecter au réseau de l'organisation à partir d'emplacements externes.

Remarque : cette portée de tutoriel est limitée au VPN IPSec de site à site qui est actuellement le seul pris en charge dans OCI DRGv2.

Concepts relatifs aux tunnels VPN IPSec

IPSec signifie Internet Protocol Security ou IP Security. IPSec est une suite de protocoles qui crypte l'intégralité du trafic IP avant que les paquets soient transférés du noeud source vers la destination. IPSec peut être configuré en deux modes :

Mode de transport : IPSec crypte et/ou authentifie uniquement la charge utile réelle du paquet. Les informations d'en-tête restent intactes.
Mode Tunnel : IPSec chiffre et/ou authentifie la totalité du paquet. Après le cryptage, le paquet est encapsulé pour former un nouveau paquet IP UDP possédant des informations d'en-tête différentes.

Les tunnels site à site VPN IPSec offrent les avantages suivants :

Pas besoin d'acheter des lignes de location coûteuses dédiées d'un site à un autre, car les lignes de télécommunication publiques sont utilisées pour transmettre des données.
Les adresses IP internes des noeuds et des réseaux participants sont masquées pour les utilisateurs externes.
L'intégralité de la communication entre les sites source et de destination est cryptée, ce qui réduit considérablement les risques de vol d'informations. OCI prend uniquement en charge le mode Tunnel du VPN IPSec et est proposé en libre-service à l'aide de la console Web.

Remarque : le VPN site à site OCI prend uniquement en charge le mode Tunnel, ce qui constituera le seul mode disponible dans OCI.

Architecture

OCI IPSec avec ECMP se compose de listes qui incluent :

DRGv2 attaché à VCN1 et VCN2 en utilisant les tables de routage par défaut et les tables de routage générées automatiquement RT2 "Table de routage Drg générée automatiquement pour les pièces jointes VCN" dans la région Francfort.
Identique à DRGv2 avec une connexion IPSec comprenant deux tunnels :
- tunnel 1, adresse IP VPN Oracle 193.122.x.x avec table de routage générée automatiquement RT1 "Table de routage Drg générée automatiquement pour les attachements RPC, VC et IPSec".
- tunnel 2, adresse IP VPN Oracle 158.101.x.x avec table de routage générée automatiquement RT1 "Table de routage Drg générée automatiquement pour les attachements RPC, VC et IPSec".
Machine virtuelle Oracle Linux en tant que client IPSec avec prise en charge ECMP sur site, exécutée dans la plage CIDR privée 192.168.0.0/16, adresse IP publique 143.47.48.219.
Iperf3 dans Oracle Linux sur site en tant que client et serveur dans Oracle OCI.
CPE configuré en tant que Libreswan avec l'adresse IP publique 143.47.x.x.
ECMP a activé les côtés Oracle Linux 8 et OCI.

Tâche 1 : configuration des paramètres OCI

Pour ce tutoriel, nous avons créé une instance de machine virtuelle Oracle Linux 7 et y avons installé Libreswan 3.25. Pour installer Libreswan dans Linux, vous pouvez suivre la documentation Oracle suivante : Accès à d'autres clouds avec Libreswan. Vous pouvez installer Libreswan dans l'environnement de votre choix. Pour ce tutoriel, nous avons choisi une autre région distante dans OCI en tant que client Libreswan et initiateur de tunnel.

Une fois que vous avez installé Libreswan (sans le configurer), notez l'adresse IP publique de votre machine virtuelle Linux 7 ainsi que la plage CIDRIPv4 CIDR IPv4 privée dans laquelle vous avez installé Libreswan.

Maintenant, configurons les paramètres OCI

Connectez-vous à votre console OCI et accédez à l'onglet Fonctions de réseau pour créer VCN1 et VCN2, comme suit : Créer votre VCN.
Créez VCN1 avec CIDR 10.0.0.0/16 et deux sous-réseaux : le sous-réseau A 10.0.1.0/24 et le sous-réseau B 10.0.0.0/24.
Créez VCN2 avec CIDR 172.20.0.0/16 et deux sous-réseaux : le sous-réseau C 172.20.1.0/24 et le sous-réseau D 172.20.2.0/24.
Créez des machines virtuelles dans les sous-réseaux cible dans OCI afin de tester les tunnels IPSec. Dans ce tutoriel, nous avons créé 3 machines virtuelles (origin1, origin2 et origin3).
Créons maintenant un DRG, sous Fonctions de réseau, Connectivité client, Passerelles de routage dynamique.
Une fois DRG créé, vous devez créer un attachement de réseau cloud virtuel à VCN1 et VCN2.
- Une fois créés, nous aurons deux attachements réseau (un par VCN) connectant les deux réseaux cloud virtuels au DRG avec une table de routage DRG AutoGenerated pour les attachements VCN (table de routage RT2 dans l'architecture principale).
- Cette table de routage indique à DRG où envoyer/acheminer le trafic entrant à partir des réseaux cloud virtuels connectés uniquement : tout trafic destiné à "CIDR de destination" sera envoyé/acheminé vers "Pièce jointe de saut suivante" comme suit :
- Plus tard, lors de la création des tunnels IPSec, nous disposerons d'une table de routage générée automatiquement similaire pour le trafic entrant à partir d'un environnement sur site via le tunnel IPSec.
Maintenant, créons la connectivité IPSec. Avant de créer le IPSec, nous devons créer le CPE (Customer-Premise Equipment) qui représente le dispositif sur site se connectant à OCI via IPSec, sous Networking, Customer connectivity, Customer-Premise Equipment, Create CPE :
- X.X.X.X doit être l'adresse IP PUBLIC à partir de laquelle votre appareil sur site se connecte. Ne le confondez PAS avec l'adresse IP privée affectée à la machine Oracle Linux Libreswan que vous avez installée aux étapes précédentes. Il est très probable que votre machine virtuelle Oracle Linux se trouve derrière NAT (sans posséder directement l'adresse IP publique). Si vous ne connaissez pas l'adresse IP publique, vous pouvez toujours exécuter la commande suivante à partir de la console Linux pour le savoir : curl ifconfig.co.
- Pour ce tutoriel, choisissez Vendor Libreswan version 3.18 ou ultérieure.
Accédez à Networking, Customer connectivity, Site-to-Site VPN, Create IPSec connection et fournissez les détails suivants.

Remarque : vous pouvez utiliser l'assistant VPN, mais il est hors de portée de ce tutoriel.
- Nom de votre configuration IPSec
- Créer dans le compartiment : compartiment
- Equipement sur site client dans votre compartiment : choisissez le CPE que vous avez créé à l'étape précédente
  - Ce CPE se trouve derrière un dispositif NAT : cela aura une incidence directe sur la manière dont l'ID Internet Key Exchange (IKE) sera "présenté" à OCI sur site. En supposant que Libreswan s'exécute derrière NAT, si vous souhaitez utiliser l'adresse IP privée à partir de laquelle Libreswan s'exécute en tant qu'ID IKE, marquez cette option. Sinon, si vous souhaitez utiliser l'adresse IP publique à partir de laquelle Libreswan se connecte, ne cochez pas cette case. Nous allons configurer cet ID IKE ultérieurement à partir de la configuration Libreswan.
- Compartiment de passerelle de routage dynamique : choisissez le DRG que vous avez configuré aux étapes précédentes.
- Routages vers votre réseau sur site : le routage dynamique est hors de portée de ce tutoriel. Nous allons nous concentrer sur ECMP pour l'équilibrage de charge et la redondance, à l'aide de la configuration IPSec basée sur un routage. Nous ajouterons ici manuellement/statiquement les acheminements sur site/CIDRS que nous voulons pouvoir atteindre d'OCI vers les environnements sur site. Dans ce tutoriel, nous utiliserons 192.168.0.0/16 en tant que CIDR sur site.
  - Tunnel 1 :
    - Nom
    - Fournir une clé secrète partagée avec le client : vous pouvez utiliser votre propre clé prépartagée IKE (mot de passe) ou la laisser vide afin qu'OCI en choisisse une (nous l'utiliserons ultérieurement lors de la configuration de Libreswan)
    - Version IKE : pour ce tutoriel, nous utiliserons IKEv1
    - Type de routage : pour ce tutoriel, nous utiliserons le routage statique pour la configuration IPSec basée sur un routage, donc choisissez "Routage statique"
    - IPv4 dans l'interface de tunnel - CPE et Oracle : laissez cette option vide
    - Adressage IPv6 : laissez ce champ vide car IPv6 est hors de portée de ce tutoriel
  - Tunnel 2 : remplissez le tunnel 2 exactement de la même manière que le tunnel 1 (version IKE, type de routage, etc.).
- Cliquez sur Créer une connexion IPSec. Si tout se passe bien, au bout de quelques minutes, une configuration IPSec doit être exécutée avec deux tunnels pour la redondance.
- Maintenant que le DRG et IPSec sont en place, nous devons nous assurer que chaque trafic des réseaux cloud virtuels d'OCI vers les systèmes sur site trouvera son chemin vers le DRG. Une fois que le trafic atteint le DRG, il est tunnel vers les environnements sur site via les deux tunnels IPSec récemment configurés. Pour ce faire, nous devons ajouter le CIDR sur site en tant que règle de routage pour chaque table de routage de sous-réseau dans VCN (nous avons choisi la table de routage par défaut dans le tutoriel), le type de cible Passerelle de routage dynamique, le type de destination Bloc CIDR, puis ajouter le routage sur site, dans ce cas 192.168.0.0/16.
Remarque : la raison pour laquelle nous devons ajouter ce routage est qu'OCI n'a pas de routage implicite pour les adresses CIDR en dehors du domaine VCN. Par conséquent, nous devons ajouter manuellement le bloc CIDR pour garantir que le trafic atteint le DRG.

Tâche 2 : configuration des paramètres Linux et Libreswan

Cette partie du tutoriel se concentre sur les étapes de configuration du système d'exploitation Linux et de Libreswan. Le Libreswan précédemment installé agira en tant qu'initiateur du tunnel site à site et OCI DRG en tant que répondeur de tunnel.

Accédez à votre système d'exploitation Oracle Linux via SSH. Augmentez vos privilèges pour exécuter des commandes (admin) importantes.
- sudo su : vous allez devenir utilisateur root.
- Assurez-vous que Libreswan est installé avec la version correcte : ipsec -version. Vous devez voir Libreswan version 3.25 ou supérieure. Sinon, accédez à Tâche 1 : configurer les paramètres OCI et suivez les instructions pour installer Libreswan.
- Accédez au dossier de configuration : cd /etc.
- Libreswan stocke toutes les configurations de tunnels dans le fichier ipsec.conf. Utilisez votre éditeur de fichier préféré. "vi" est une bonne option : vi ipsec.conf
  - Libreswan ipsec.conf :
    - conn [TunnelName1} : nom du tunnel
    - type= tunnel (mode Tunnel)
    - authby=secret (l'authentification utilisera une phrase secrète)
    - pfs=yes (Perfect forward secret enabled)
    - keyexchange=J'aime
    - leftid= n.n.n.n (Il s'agit de l'adresse IP publique à partir de laquelle Libreswan se connecte. Il sera utilisé en tant qu'identificateur d'ID IKE, sauf si vous avez sélectionné l'option "CPE is derrière NAT" lors de la création de IPSec. Dans ce cas, n'importe quelle adresse IP ou nom de domaine qualifié complet peut être défini comme identificateur)
    - leftsourceip= m.m.m.m (Il s'agit de l'adresse IP privée affectée à Libreswan, par exemple 192.168.1.1)
    - leftsubnet= x.x.x.x/x (Il s'agit du bloc CIDR affecté à Libreswan, par exemple 192.168.0.0/16)
    - right= y.y.y.y (Il s'agit de l'adresse IP publique du VPN OCI affectée à tunnel1 lors de la création de IPSec sous Networking, connectivité client, VPN site-à-site, YourIPSEC)
    - rightid= y.y.y.y (ID IKE envoyé à partir d'OCI. Il s'agit généralement de l'adresse IP publique du VPN OCI, normalement identique au paramètre approprié)
    - leftsubnet=0.0.0.0/0 (Il s'agit du bloc CIDR qui sera envoyé vers OCI dans le cadre de la négociation du protocole Internet Key Exchange (IKEv2) 2.2.9 du sélecteur de trafic SA. Cela ne signifie pas que tout le trafic d'OCI sera acheminé vers l'environnement sur site. Au lieu de cela, ce que fait ce bloc CIDR est de déterminer le trafic spécifique qui sera accepté, chiffré et mis en tunnel via le tunnel IPSec. Le tunnel IPSec décrit ici sera représenté par une interface virtuelle appelée interface de tunnel virtuel (VTI), qui agit comme une interface réseau virtuelle (comme une carte réseau virtuelle) représentant le tunnel lui-même. Supposons que le VTI soit appelé vti01. Tout trafic acheminé vers l'interface vti01 fera partie du tunnel IPSec et sera envoyé de manière sécurisée à l'autre extrémité de la connexion. Cette approche, dans laquelle les décisions de routage sont prises en fonction du tunnel IPSec spécifique et de son interface de tunnel virtuel associée, est appelée routage basé sur un routage IPSec.
    - rightsubnet=0.0.0.0/0 (identique à ce qui précède pour le trafic accepté vers OCI à partir d'un environnement sur site)
    - mark=n/0xffffff (*option nécessaire à l'utilisation avec les interfaces VTI pour marquer les paquets encapsulés dans le tunnel IPSec associé à cette interface VTI). Doit être unique dans tous les tunnels, c'est-à-dire 5/0xffffffffff*)
    - vti-interface=vtinn (*Nom de l'interface VTI, par exemple vti01*)
    - vti-routing=no (Indique si les routes doivent être créées automatiquement dans le périphérique VTI. Choisissez NO (Non) car nous ne voulons pas créer le routage 0.0.0.0/0 automatiquement.
    - encapsulation= yes/auto (yes force le code de détection NAT à s'allonger et indique au pair distant que l'encapsulation RFC-3948 (ESP dans les paquets UDP du port 4500). Auto, la détection automatique NAT sera forcée)
    - aggrmode = non
    - ike=aes_cbc256-sha2_384 ;modp1536 (algorithme de chiffrement/authentification IKE à utiliser pour la connexion (phase 1 aka ISAKMP SA). Le format est "cipher-hash ;modpgroup, cipher-hash ;modpgroup, ...)
    - esp=aes_gcm256 ;modp1536 (Indique les algorithmes qui seront proposés/acceptés pour une négociation d'élément de contrat enfant. Le format de l'ESP est ENC-AUTH suivi d'un PFSgroup facultatif. Par exemple, "aes_gcm256" ou "aes256-sha2_512-dh14" ou "aes-sha2_512+sha2_256")
    - ikev2= no (Pour utiliser IKEv2, passez à ikev2=insist)
- Accédez au dossier de configuration : cd /etc/ipsec.d.
- Libreswan stocke tous les tunnels partagent des clés secrètes (mots de passe) dans le fichier shared.secrets.
  - Format shared.secrets Libreswan : leftid right : PSK "secret"
    - leftid : ID IKE configuré dans IPSec.conf (leftid). Normalement, l'adresse IP publique Libreswan.
    - right : adresse IP publique du tunnel OCI.
    - "secret" : clé secrète/mot de passe partagé de tunnel en cours configuré dans OCI. Vous pouvez obtenir ces informations à partir de la console OCI sous Networking, connectivité client, VPN site à site, YourIPSEC, TunnelName, informations de tunnel, clé secrète partagée, afficher.
Pour ce tutoriel, nous avons créé les éléments ipsec.conf et shared.secrets suivants (les adresses IP publiques sont masquées) :

ipsec.conf

shared.secrets
Essayons maintenant d'établir les deux tunnels HA sur OCI.
- Redémarrez le service Libreswan : en tant qu'utilisateur root, exécutez ipsec restart. Si tout va bien, aucune erreur ne sera affichée, sinon vous verrez quelque chose comme ceci :
  
  Le travail pour ipsec.service a échoué car le processus de contrôle s'est arrêté avec un code d'erreur. Pour plus d'informations, reportez-vous à "systemctl status ipsec.service" et "journalctl -xe".
- Examinons maintenant le statut en cours des tunnels IPSec : exécutez ipsec status. Vous verrez de nombreuses informations sur les tunnels actuels configurés autour d'ESP(plan de données) et d'IKE(plan de signalisation), les sous-réseaux autorisés, etc. Pour l'instant, nous allons nous concentrer sur la liste des connexions.
  
  000 Liste des connexions :
  
  000
  
  000 Nombre total de connexions IPSec : *loaded 0, active 0
- Aucune configuration de tunnel n'est actuellement chargée, ni active.
- Exécutez ipsec auto --add ConnName1, c'est-à-dire ipsec auto --add home_liftvti.
  - 002 a ajouté la description de connexion "home_liftvti" <- Maintenant la connexion est "chargée" pas encore active. Vérifiez-le avec le statut ipsec.
- Exécutez ipsec auto --up ConnName1 pour lancer le tunnel 1, c'est-à-dire ipsec auto --up home_liftvti. Si tout se passe bien, vous verrez IPSec SA établie tunnel mode, sinon vous verrez différentes erreurs IKE/IPSec que vous devrez dépanner.
- Désormais, il s'agit du deuxième tunnel : exécutez ipsec auto -add ConnName2, c'est-à-dire ipsec auto -add home_liftvti2
  - 002 a ajouté la description de connexion "home_liftvti2" <- Maintenant la connexion est "chargée" pas encore active. Vérifiez-le avec le statut ipsec
- Exécutez ipsec auto -up ConnName2 pour lancer le tunnel 1, c'est-à-dire ipsec auto -up home_liftvti2. Si tout va bien, vous verrez "IPSec SA établie tunnel mode", sinon vous verrez différentes erreurs IKE/IPSec dont vous aurez besoin pour dépanner

Tâche 3 : configuration du routage IP et du trafic de tunnel

Cette partie du tutoriel se concentrera sur le routage IP et le trafic de tunnel.

Maintenant que les deux tunnels sont en fonctionnement, essayons d'envoyer une commande ping à une machine dans OCI à partir de Libreswan pour tester les tunnels. Par exemple, envoyez une commande ping à origin1 avec l'adresse IP 10.0.0.109. Vous verrez qu'il échouera.
```
PING 10.0.0.109 (10.0.0.109) 56(84) bytes of data.

  10.0.0.109 ping statistics
  26 packets transmitted, 0 received, 100% packet loss,
```
Vous vous demandez peut-être pourquoi il ne fonctionne pas, même si les tunnels IPSec sont en fonctionnement sur OCI. La réponse est que les deux tunnels que nous avons établis sur OCI sont " basés sur un routage " et que chaque tunnel est représenté par une interface virtuelle (VTI). Vous pouvez voir chaque interface virtuelle en tant que carte d'interface réseau virtuelle qui représente un tunnel IPSec. Tout trafic acheminé vers le VTI est encapsulé à l'aide du protocole ESP (Encapsulating Security Payload) et envoyé à l'autre extrémité du tunnel. Le VTI sert de passerelle pour le trafic qui doit être sécurisé et transmis via le tunnel IPSec.
Dans notre scénario de test, nous avons deux interfaces VTI, vti01 et vti02, chacune représentant home_liftvti et home_liftvti02 par rapport à OCI DRG. Vous pouvez les voir facilement en exécutant la commande Linux ifconfig.
Il ne nous reste plus qu'à ajouter une route de système d'exploitation Linux vers ces interfaces VTI afin de garantir que le trafic atteint OCI via les deux tunnels. N'oubliez pas que tout trafic dirigé vers une interface VTI sera encapsulé dans son tunnel IPSec associé et acheminé vers OCI.
- La commande d'ajout de la route a le format suivant : ip route add {vcnCidrBlock} nexthop dev {vti1} weight {priority}nexthop dev {vti2} weight {priority}`
- Dans notre cas de test, nous voulons être en mesure d'atteindre OCI VCN1 avec CIDR 10.0.0.0/16 : route ip ajouter 10.0.0.0/16 nexthop dev vti01 pondération 1 nexthop dev vti02 pondération 1

Maintenant, le ping devrait fonctionner immédiatement.

ping 10.0.0.109
   PING 10.0.0.109 (10.0.0.109) 56(84) bytes of data.
   64 bytes from 10.0.0.109: icmp_seq=1 ttl=61 time=29.0 ms
   64 bytes from 10.0.0.109: icmp_seq=2 ttl=61 time=29.4 ms
   64 bytes from 10.0.0.109: icmp_seq=3 ttl=61 time=29.0 ms

Deux tunnels fonctionnent maintenant.

Tâche 4 : configuration de l'équilibrage de charge et de la redondance ECMP

Cette partie du tutoriel se concentrera sur l'équilibrage de charge et la redondance ECMP.

A ce stade du tutoriel, deux tunnels IPSec sont actuellement établis et opérationnels avec OCI. Les deux tunnels utilisent le même routage vers notre réseau sur site, comme indiqué dans notre scénario de test 192.168.0.0/16.
- Tunnel 1 192.168.0.0/16 -> Sur site
- Tunnel 2 192.168.0.0/16 -> Sur site
Etant donné que les deux tunnels utilisent le même routage sur site (192.168.0.0/16), ce routage sera propagé vers le reste des attachements réseau DRG afin que les autres éléments réseau (réseaux cloud virtuels, sous-réseaux, etc.) puissent atteindre sur site via IPSec. Comme vous pouvez le voir dans l'image suivante, nous aurons un conflit sur la route 192.168.0.0/16 qui sera identique pour les deux tunnels IP Sec dans la table DRG générée automatiquement pour les attachements VCN.
Avec cette configuration, nous allons utiliser un seul tunnel et ignorer l'autre. L'objectif de ce tutoriel est de pouvoir utiliser les deux tunnels en même temps pour atteindre une haute disponibilité (active/active) et doubler les performances en ajoutant le débit des deux tunnels. C'est là que l'ECMP entre en jeu. Pour activer ECMP, nous devons d'abord l'activer dans la table DRG générée automatiquement pour chaque pièce jointe VCN : Networking, Customer connectivity, Dynamic Routing Gateways, DRGName, DRG route table details, Edit Button (vous devez effectuer cette opération sur chaque table de pièce jointe DRG).
Vous verrez que le conflit de routage dans la table de routage DRG générée automatiquement pour les attachements VCN est résolu.
Activez ECMP dans Linux et Libreswan. Pour prendre en charge le routage à chemins d'accès multiples à coût égal (ECMP), Linux introduit un choix de stratégie de hachage à l'aide de fib_multipath_hash_policy, un nouveau paramètre sysctl qui contrôle la stratégie de hachage à utiliser pour les routages à chemins d'accès multiples. Lorsque fib_multipath_hash_policy est défini sur 1, le noyau exécute le hachage L4, qui est un hachage à chemins d'accès multiples pour les paquets IPv4 en fonction d'un ensemble de valeurs à 5 tuples (adresse IP source, port source, adresse IP de destination, port de destination, type de protocole IP). Lorsque fib_multipath_hash_policy est défini sur 0 (valeur par défaut), seul le hachage L3 est utilisé (adresses IP source et de destination). A partir de la console Linux, en tant qu'utilisateur root, exécutez la commande suivante :

sysctl -w net.ipv4.fib_multipath_hash_policy=1
A présent, ECMP est activé aux deux extrémités. Par conséquent, les deux tunnels seront utilisés en mode actif/actif, ajoutant un débit total de deux tunnels IPSec. Pour nos tests, nous avons utilisé la commande iperf3 pour inspecter le trafic et obtenu les résultats suivants :
```
 From Libreswan: iperf3 -c 10.0.0.109  -b 1100Mb  -P  8 -t 300

 From OCI Origin1: iperf3 -s

 [SUM]   0.00-1.75   sec   249 MBytes  1.20 Gbits/sec  7122             sender
```

Remerciements

Auteurs - Luis Catalán Hernández (Spécialiste du réseau cloud OCI et Multi Cloud), Antonio Gamir (Spécialiste du réseau cloud OCI)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à davantage de contenu de formation gratuit sur le canal Oracle Learning YouTube. En outre, accédez à education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour consulter la documentation produit, consultez Oracle Help Center.

Informations relatives au titre et au copyright

Use Oracle Cloud Infrastructure Site-to-Site VPN service in HA mode with ECMP routing from Linux and Libreswan

F84216-01

July 2023