Dépannage du RPV site à site
Créer une demande de service sur My Oracle Support
Cette rubrique présente les problèmes de résolution courants liés au RPV site à site. Certaines suggestions supposent que vous êtes un ingénieur réseau ayant accès à la configuration de l'appareil CPE.
Messages du journal
La consultation des messages de journal générés pour divers aspects opérationnels du RPV site à site peut être une aide précieuse pour résoudre de nombreux problèmes de fonctionnement. Vous pouvez activer et accéder aux messages de journal d'un RPV site à site au moyen d'un RPV site à site ou du service de journalisation.
- Pour un aperçu général du service de journalisation, voir Aperçu du service de journalisation.
- Pour plus de détails sur l'activation et la consultation des messages de journal du RPV site à site à l'aide du service de journalisation, voir Journaux de service
- Pour plus de détails sur l'activation et la consultation des messages de journal du RPV site à site au moyen du service de réseau, voir Messages de journal du RPV site à site.
-
Pour plus de détails sur le schéma de message de journal du RPV site à site, voir Informations détaillées sur le RPV site à site.
Consultez le tableau suivant pour une meilleure interprétation des messages de journal du RPV site à site, qui répertorie les différents scénarios de tunnel vers le bas et les journaux possibles affichés dans la console OCI.
| Motif de l'arrêt du tunnel | Journaux alimentés dans la section de journalisation OCI |
|---|---|
| Non-correspondance de la version du protocole IKE |
|
| Sous-réseaux non concordants |
|
| Clé prépartagée non concordante |
|
| La proposition ne correspond pas |
|
| Non-concordance de PFS |
|
| ID IKE non concordant |
|
Instabilité du tunnel
Connexions IPSEC multiples : Vous pouvez utiliser deux connexions IPSec pour la redondance. Si une seule route par défaut (0.0.0.0/0) est configurée pour les deux connexions IPSec, le trafic est acheminé vers l'une de ces connexions car Oracle utilise un routage asymétrique. Pour utiliser une connexion IPSec principale et une autre comme connexion de secours, configurez des routes plus spécifiques pour la connexion principale et des routes moins spécifiques (ou la route par défaut 0.0.0.0/0) pour la connexion de secours.
Identificateur IKE local : Certaines plates-formes CPE ne vous 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 l'équipement local d'abonné. 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.
Unité de transmission maximale (MTU) : La taille standard de la MTU Internet est de 1500 octets. Pour plus d'informations sur la recherche de MTU, voir Aperçu de MTU.
Configuration de l'équipement local d'abonné
Identificateur IKE local : Certaines plates-formes CPE ne vous 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 l'équipement local d'abonné. 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.
Cisco ASA : Basé sur des politiques : Nous vous recommandons d'utiliser une configuration basée sur des routes pour éviter les problèmes d'interopérabilité et pour obtenir la redondance des tunnels avec un seul appareil Cisco ASA.
Cisco ASA ne prend pas en charge la configuration basée sur des routes pour les versions du logiciel antérieures à 9.7.1. Pour de meilleurs résultats, si le périphérique le prend en charge, nous vous recommandons de passer à une version logicielle prenant en charge la configuration basée sur des routes.
Avec une configuration basée sur des politiques, vous ne pouvez configurer qu'un seul tunnel entre Cisco ASA et une passerelle de routage dynamique (DRG).
Tunnels multiples Si plusieurs tunnels fonctionnent simultanément, assurez-vous que l'équipement local d'abonné est configuré pour traiter le trafic provenant du réseau VCN sur n'importe quel tunnel. Par exemple, vous devez désactiver l'inspection ICMP, configurer le contournement de l'état TCP, etc. Pour plus de détails sur la configuration appropriée, communiquez avec le soutien technique du fournisseur du CPE.
Problèmes liés au domaine de chiffrement
Les têtes de réseau du RPV Oracle utilisent des tunnels basés sur des routes, mais fonctionnent avec ceux basés sur des politiques avec certaines restrictions. Pour plus de détails, voir Domaines de chiffrement pour les tunnels basés sur des politiques.
Règles de liste de sécurité avec état : Si vous utilisez des règles de liste de sécurité avec état (pour le trafic TCP, UDP ou ICMP), vous n'avez pas besoin de vous assurer qu'une liste de sécurité a une règle explicite pour autoriser les messages ICMP de type 3 code 4 car le service de réseau suit les connexions et autorise automatiquement ces messages. Les règles sans état exigent une règle de liste de sécurité entrante explicite pour les messages ICMP de type 3 code 4. Confirmez que les pare-feux de l'instance sont configurés correctement.
Problèmes généraux de RPV site à site
Le tunnel IPSec est INACTIF
Vérifiez ces éléments :
-
Configuration de base : Le tunnel IPSec se compose de paramètres de phase 1 et de phase 2. Confirmez que les deux sont correctement configurées. Vous pouvez configurer les paramètres de phase 1 et de phase 2 de l'équipement local d'abonné dans OCI à l'aide de configurations personnalisées. Pour utiliser des configurations personnalisées dans le tunnel, allez aux options avancées et activez définir des configurations personnalisées. Cela vous permet de définir manuellement les paramètres de phase 1 et de phase 2 à l'extrémité OCI.
Oracle a également recommandé certains paramètres pour les phases 1 et 2. Voir les paramètres pour la configuration de phase-1 (ISAKMP) et de phase-2 (IPSec) et utiliser ces paramètres si l'étape précédente n'affiche pas le tunnel. Pour plus d'informations sur la configuration de l'équipement local d'abonné, voir la configuration appropriée pour l'équipement local d'abonné :
-
ID mandataires local et distant : Si vous utilisez une configuration basée sur des politiques, vérifiez si l'équipement local d'abonné est configuré avec plusieurs paires d'ID mandataires locaux et distants (sous-réseaux). Le routeur RPV Oracle ne prend en charge qu'une seule paire sur d'anciennes connexions. Si le CPE comporte plusieurs paires, mettez à jour la configuration pour n'en inclure qu'une, puis sélectionnez une des deux options suivantes :
Option ID mandataire local ID mandataire distant 1 AU CHOIX (ou 0.0.0.0/0) AU CHOIX (ou 0.0.0.0/0) 2 CIDR sur place (agrégat qui couvre tous les sous-réseaux concernés) CIDR du VCN - Appareil NAT : Si l'appareil se trouve derrière un appareil NAT, l'identificateur IKE configuré sur le CPE ne correspond peut-être pas à celui utilisé par Oracle (adresse IP publique du CPE). Si l'équipement local d'abonné ne prend pas en charge la définition de l'identificateur IKE de l'équipement local d'abonné sur place, vous pouvez fournir à Oracle l'identificateur IKE de l'équipement local d'abonné dans la console Oracle. Pour plus d'informations, voir Aperçu des composants de RPV site à site.
Le tunnel IPSec est actif, mais aucun trafic n'y passe
Vérifiez ces éléments :
-
Configuration de phase 2 (IPSec) : Vérifiez que les paramètres de la phase 2 (IPSec) sont configurés correctement sur l'appareil CPE. Voir la configuration appropriée pour le CPE :
Liste des configurations - Listes de sécurité de réseau VCN : Assurez-vous que les listes de sécurité de réseau VCN autorisent le trafic approprié (règles de trafic entrant et sortant). Notez que la liste de sécurité par défaut du réseau VCN ne permet pas le trafic ping (ICMP type 8 et ICMP type 0). Vous devez ajouter les règles de trafic entrant et sortant appropriées pour autoriser le trafic ping.
- Firewall rules: Ensure that the firewall rules allow both ingress and egress traffic with the Oracle VPN headend IPs and the VCN CIDR block.
- Routage asymétrique : Oracle utilise un routage asymétrique dans les tunnels qui constituent la connexion IPSec. Même si vous configurez un tunnel principal et un autre de secours, le trafic d'un réseau VCN vers un réseau sur place peut utiliser n'importe quel tunnel "actif" sur un appareil. Configurez les pare-feu selon le cas. Dans le cas contraire, les tests ping ou le trafic d'application sur la connexion ne fonctionnent pas de manière fiable.
- Cisco ASA : N'utilisez pas l'option originate-only avec un tunnel IPSec de RPV site à site Oracle. Le trafic du tunnel disparaît de manière irrégulière. La commande ne s'applique qu'aux tunnels entre deux appareils Cisco. Voici un exemple de la commande NOT à utiliser pour les tunnels IPSec :
crypto map <map name> <sequence number> set connection-type originate-only
Le tunnel IPSec est actif, mais le trafic n'y passe que dans une direction
Vérifiez ces éléments :
- Routage asymétrique : Oracle utilise un routage asymétrique dans les tunnels qui constituent la connexion IPSec. Même si vous configurez un tunnel principal et un autre de secours, le trafic d'un réseau VCN vers un réseau sur place peut utiliser n'importe quel tunnel "actif" sur un appareil. Configurez les pare-feu selon le cas. Dans le cas contraire, les tests ping ou le trafic d'application sur la connexion ne fonctionnent pas de manière fiable.
- Tunnel simple privilégié : Pour n'utiliser qu'un seul des tunnels, assurez-vous que vous disposez de la politique ou du routage approprié sur le CPE pour privilégier ce tunnel.
- Plusieurs connexions IPSec : Si vous avez plusieurs connexions IPSec avec Oracle, veillez à spécifier des routes statiques plus précises pour la connexion IPSec privilégiée.
- Listes de sécurité VCN : Assurez-vous que les VCN autorisent le trafic dans les deux directions (entrant et sortant).
- Règles du pare-feu : Assurez-vous que ces règles permettent le trafic dans les deux directions avec les adresses IP de tête de réseau RPV d'Oracle et le bloc CIDR du réseau VCN.
Résolution des problèmes du RPV site à site avec une configuration basée sur des politiques
Le tunnel IPSec est INACTIF
Vérifiez ces éléments :
-
Configuration de base : Le tunnel IPSec se compose de la configuration de phase 1 (ISAKMP) et de phase 2 (IPSec). Confirmez que les deux sont correctement configurées sur l'équipement local d'abonné. Voir la configuration appropriée pour le CPE :
Liste des configurations -
ID mandataires local et distant : Si vous utilisez une configuration basée sur des politiques, vérifiez si l'équipement local d'abonné est configuré avec plusieurs paires d'ID mandataires locaux et distants (sous-réseaux). Le routeur RPV Oracle ne prend en charge qu'une seule paire sur d'anciennes connexions. Si le CPE comporte plusieurs paires, mettez à jour la configuration pour n'en inclure qu'une, puis sélectionnez une des deux options suivantes :
Option ID mandataire local ID mandataire distant 1 AU CHOIX (ou 0.0.0.0/0) AU CHOIX (ou 0.0.0.0/0) 2 CIDR sur place (agrégat qui couvre tous les sous-réseaux concernés) CIDR du VCN - Appareil NAT : Si l'appareil se trouve derrière un appareil NAT, l'identificateur IKE configuré sur le CPE ne correspond peut-être pas à celui utilisé par Oracle (adresse IP publique du CPE). Si l'équipement local d'abonné ne prend pas en charge la définition de l'identificateur IKE de l'équipement local d'abonné sur place, vous pouvez fournir à Oracle l'identificateur IKE de l'équipement local d'abonné dans la console Oracle. Pour plus d'informations, voir Aperçu des composants de RPV site à site.
- Cisco ASA : N'utilisez pas l'option originate-only avec un tunnel IPSec de RPV site à site Oracle. Le trafic du tunnel disparaît de manière irrégulière. La commande ne s'applique qu'aux tunnels entre deux appareils Cisco. Voici un exemple de la commande NOT à utiliser pour les tunnels IPSec :
crypto map <map name> <sequence number> set connection-type originate-only
Le tunnel IPSec est actif, mais instable
Vérifiez ces éléments :
- Lancement de la connexion : Assurez-vous que l'appareil CPE démarre la connexion.
-
ID mandataires local et distant : Si vous utilisez une configuration basée sur des politiques, vérifiez si l'équipement local d'abonné est configuré avec plusieurs paires d'ID mandataires locaux et distants (sous-réseaux). Le routeur RPV Oracle ne prend en charge qu'une seule paire sur d'anciennes connexions. Si le CPE comporte plusieurs paires, mettez à jour la configuration pour n'en inclure qu'une, puis sélectionnez une des deux options suivantes :
Option ID mandataire local ID mandataire distant 1 AU CHOIX (ou 0.0.0.0/0) AU CHOIX (ou 0.0.0.0/0) 2 CIDR sur place (agrégat qui couvre tous les sous-réseaux concernés) CIDR du VCN -
Trafic intéressant en tout temps : Nous recommandons de toujours faire passer le trafic intéressant par les tunnels IPSec si le CPE le prend en charge. Cisco ASA exige que vous configuriez la surveillance du CNS, ce qui maintient le trafic intéressant en cours d'exécution à travers les tunnels IPSec. Pour plus d'informations, voir la section "Configuration du contrat de niveau de service IP" dans le modèle de configuration basée sur des politiques Cisco ASA.
Le tunnel IPSec est actif, mais le trafic est intermittent
Vérifiez ces éléments :
-
ID mandataires local et distant : Si vous utilisez une configuration basée sur des politiques, vérifiez si l'équipement local d'abonné est configuré avec plusieurs paires d'ID mandataires locaux et distants (sous-réseaux). Le routeur RPV Oracle ne prend en charge qu'une seule paire sur d'anciennes connexions. Si le CPE comporte plusieurs paires, mettez à jour la configuration pour n'en inclure qu'une, puis sélectionnez une des deux options suivantes :
Option ID mandataire local ID mandataire distant 1 AU CHOIX (ou 0.0.0.0/0) AU CHOIX (ou 0.0.0.0/0) 2 CIDR sur place (agrégat qui couvre tous les sous-réseaux concernés) CIDR du VCN -
Trafic intéressant en tout temps : Nous recommandons de toujours faire passer le trafic intéressant par les tunnels IPSec si le CPE le prend en charge. Cisco ASA exige que vous configuriez la surveillance du CNS, ce qui maintient le trafic intéressant en cours d'exécution à travers les tunnels IPSec. Pour plus d'informations, voir la section "Configuration du contrat de niveau de service IP" dans le modèle de configuration basée sur des politiques Cisco ASA.
Le tunnel IPSec n'est que partiellement actif
Si vous avez eu une configuration similaire à l'exemple précédent et que vous n'avez configuré que trois des six domaines de chiffrement IPv4 possibles du côté de l'équipement local d'abonné, le lien serait répertorié dans un état "Partiellement actif", car tous les domaines de chiffrement possibles sont toujours créés du côté de la passerelle DRG.
Assurance-service partielle : Nous vous recommandons de toujours avoir un trafic intéressant qui passe par les tunnels IPSec. Certains fournisseurs d'équipement local d'abonné exigent que vous ayez toujours un trafic intéressant à travers le tunnel pour maintenir la phase 2. Les fournisseurs tels que Cisco ASA nécessitent la configuration du moniteur de moniteur CNS. De même, les fonctionnalités Palo Alto telles que la surveillance des chemins peuvent être utilisées. De telles fonctions maintiennent le trafic intéressant circulant dans les tunnels IPSec. Des scénarios ont été vus avec des fournisseurs tels que Cisco ASA agissant comme "initiateur" n'amène pas la phase 2 jusqu'à ce qu'il n'y ait pas de trafic intéressant. Cela provoque l'arrêt du SA soit lorsque le tunnel est monté, soit après la clé de sécurité de l'association.
Dépannage de la session BGP pour le RPV site à site
Le statut BGP est inactif
Vérifiez ces éléments :
- Statut IPSec : Pour que la session BGP soit active, le tunnel IPSec doit l'être lui-même.
- Adresse BGP : Vérifiez que les deux extrémités du tunnel sont configurées avec l'adresse IP d'appairage BGP correcte.
- Numéro ASN : Vérifiez que les deux extrémités du tunnel sont configurées avec le numéro ASN local BGP et le numéro ASN BGP Oracle appropriés. Le numéro ASN BGP d'Oracle pour le nuage commercial est 31898, à l'exception de la région Serbie-Centre (Jovanovac), qui est 14544. Pour le nuage gouvernemental, voir ASN BGP Oracle.
- MD5 : Vérifiez que l'authentification MD5 est désactivée ou non configurée sur l'appareil CPE. Le RPV site à site ne prend pas en charge l'authentification MD5.
-
Pare-feu : Vérifiez qu'un pare-feu sur place ou des listes de contrôle d'accès ne bloquent pas les ports suivants :
- Port TCP 179 (BGP)
- Port UDP 500 (IKE)
- Port du protocole IP 50 (ESP)
Si le pare-feu d'un équipement local d'abonné bloque le port TCP 179 (BGP), l'état des voisins BGP est toujours arrêté. Le trafic ne peut pas circuler dans le tunnel, car l'appareil CPE et le routeur Oracle n'ont pas de routes.
Le statut BGP est instable
Vérifiez ces éléments :
- Statut IPSec : Pour que la session BGP soit active et non instable, le tunnel IPSec doit l'être lui-même.
- Nombre maximal de préfixes : Vérifiez que vous n'annoncez pas plus de 2000 préfixes. Si vous faites plus de publicité, BGP n'est pas établi.
Le statut BGP est ACTIF, mais aucun trafic ne passe
Vérifiez ces éléments :
- Listes de sécurité de réseau VCN : Assurez-vous que les listes de sécurité de réseau VCN autorisent le trafic approprié (règles de trafic entrant et sortant). Notez que la liste de sécurité par défaut du réseau VCN ne permet pas le trafic ping (ICMP type 8 et ICMP type 0). Vous devez ajouter les règles de trafic entrant et sortant appropriées pour autoriser le trafic ping.
- Routes correctes des deux côtés : Assurez-vous que vous avez reçu les routes VCN correctes d'Oracle et que le CPE les utilise. Vérifiez également que vous annoncez les routes de réseau sur place correctes sur le RPV site à site et que les tables de routage de VCN utilisent ces routes.
Le statut BGP est ACTIF, mais le trafic passe dans une seule direction
Vérifiez ces éléments :
- Listes de sécurité VCN : Assurez-vous que les VCN autorisent le trafic dans les deux directions (entrant et sortant).
- Pare-feu : Vérifiez que les pare-feu sur place ou les listes de contrôle d'accès ne bloquent pas le trafic vers ou depuis l'extrémité Oracle.
- Routage asymétrique : Oracle utilise un routage asymétrique. Si vous avez plusieurs connexions IPSec, assurez-vous que l'équipement local d'abonné est configuré pour le traitement du routage asymétrique.
- Connexions rouges : Si vous avez des connexions IPSec redondantes, assurez-vous qu'elles annoncent les mêmes routes.
Dépannage des connexions IPSec redondantes
Mémoriser ces remarques importantes :
- FastConnect utilise un routage dynamique BGP. Les connexions du RPV site à site IPSec peuvent utiliser un routage statique, BGP ou une combinaison.
- Pour des détails importants sur le routage et les routes privilégiées lors de l'utilisation des connexions redondantes, voir Routage pour le RPV site à site.
- Vous pouvez utiliser deux connexions IPSec pour la redondance. Si une seule route par défaut (0.0.0.0/0) est configurée pour les deux connexions IPSec, le trafic est acheminé vers l'une de ces connexions car Oracle utilise un routage asymétrique. Pour utiliser une connexion IPSec principale et une autre comme connexion de secours, configurez des routes plus spécifiques pour la connexion principale et des routes moins spécifiques (ou la route par défaut 0.0.0.0/0) pour la connexion de secours.
IPSec et FastConnect sont tous deux configurés, mais le trafic passe uniquement par IPSec
Veillez à utiliser des routes plus spécifiques pour votre connexion principale. Si vous utilisez les mêmes routes pour IPSec et FastConnect, reportez-vous à la description des préférences de routage dans Routage pour RPV site à site.
Deux centres de données sur place ont chacun une connexion IPSec à Oracle, mais le trafic ne passe que par une seule
Vérifiez que les deux connexions IPSec sont actives et que le traitement de routage asymétrique est activé sur le CPE.
Si une seule route par défaut (0.0.0.0/0) est configurée pour les deux connexions IPSec, le trafic est acheminé vers l'une de ces connexions car Oracle utilise un routage asymétrique. Pour utiliser une connexion IPSec principale et une autre comme connexion de secours, configurez des routes plus spécifiques pour la connexion principale et des routes moins spécifiques (ou la route par défaut 0.0.0.0/0) pour la connexion de secours.
Pour plus d'informations sur ce type de configuration, voir Exemple de disposition avec plusieurs zones géographiques.