Documentation Oracle Cloud Infrastructure

Dépannage de VPN site à site

Créez une demande de service sur My Oracle Support

Cette rubrique traite du dépannage des problèmes les plus courants pour un VPN site à site. Certaines suggestions supposent que vous êtes ingénieur réseau et que vous avez accès à la configuration du dispositif CPE.

Messages de journal

L'affichage des messages du journal générés pour divers aspects opérationnels d'un VPN site à site peut s'avérer une aide précieuse afin de résoudre le grand nombre des problèmes qui se présentent pendant le fonctionnement. L'activation des messages du journal VPN site à site et l'accès à ces messages peuvent s'effectuer via le VPN site à site ou le service Logging.

  • Pour une présentation générale du service Logging, reportez-vous à Présentation de Logging.
  • Pour plus d'informations sur l'activation des messages du journal VPN site à site et l'accès à ces derniers par le service de journalisation, reportez-vous à Journaux de services.
  • Pour plus d'informations sur l'activation des messages du journal VPN site à page et l'accès à ces derniers par le biais du service Networking, reportez-vous à Messages du journal VPN site à page.

  • Pour plus d'informations sur le schéma des messages de journal de VPN site à site, reportez-vous à Détails relatifs à un VPN site à site.

Reportez-vous au tableau suivant pour une meilleure interprétation des messages de journal de VPN site à site, qui répertorie les différents scénarios de tunnel vers le bas et les journaux possibles affichés sur la console OCI.

Interprétation des journaux de console
Motif d'arrêt du tunnel Journaux renseignés dans la section de journalisation OCI
Version IKE non concordante

STATE_V2_PARENT_I1: 60 second timeout exceeded after 7 retransmits. No response (or no acceptable response) to our first IKEv2 message

dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni

received and ignored notification payload: NO_PROPOSAL_CHOSEN_date_time ep_85 pluto[68971]: "xxxxxxx" #xxx: set ikev1 error <14>
Sous-réseaux non concordants

No IKEv2 connection found with compatible Traffic Selectors

responding to CREATE_CHILD_SA message (ID 30) from CPE_PUBLIC_IP:4500 with encrypted notification TS_UNACCEPTABLE

cannot respond to IPsec SA request because no connection is known for MISMATCHED_SOURCE_SUBNET===VPN_PUBLIC_IP[+S?C]...VPN_PUBLIC_IP[+S?C]===MISMATCHED_DESTINATION_SUBNET
Non-concordance de la clé prépartagée

STATE_MAIN_I3: 60 second timeout exceeded after 7 retransmits. Possible authentication failure: no acceptable response to our first encrypted messag

IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED

authentication failed: computed hash does not match hash received from peer ID_IPV4_ADDR 'VPN_PUBLIC_IP'

responding to IKE_AUTH message (ID 1) from VPN_PUBLIC_IP:4500 with encrypted notification AUTHENTICATION_FAILED
Non-concordance de la proposition

OAKLEY proposal refused: missing encryption

Oakley Transform [AES_CBC (128), HMAC_SHA2_256, DH19] refused

no acceptable Oakley Transform

sending notification NO_PROPOSAL_CHOSEN to VPN_PUBLIC_IP:500

failed to add connection: ESP DH algorithm 'modp1024' is not supported

received unauthenticated v2N_NO_PROPOSAL_CHOSEN - ignored
Non-concordance PFS

ignoring informational payload NO_PROPOSAL_CHOSEN, msgid=xxxxxx, length=12

received and ignored notification payload: NO_PROPOSAL_CHOSEN

dropping unexpected ISAKMP_v2_CREATE_CHILD_SA message containing v2N_INVALID_SYNTAX notification; message payloads: SK; encrypted payloads: N; missing payloads: SA,Ni,TSi,TSr

"xxxxxxxx"[1] VPN_PUBLIC_IP #580: encountered fatal error in state STATE_V2_REKEY_CHILD_I
ID IKE non concordant

Peer ID 'MISMATCHED_IKE_ID_IP_ADDRESS' mismatched on first found connection and no better connection found

sending encrypted notification INVALID_ID_INFORMATION to VPN_PUBLIC_IP:4500

Tunnel fluctuant

Trafic intéressant à tout moment : nous vous recommandons de toujours exécuter du trafic intéressant via les tunnels IPSec si le CPE le prend en charge. Cisco ASA exige que vous configuriez la surveillance du contrat de niveau de service, qui maintient le trafic intéressant en cours d'exécution via les tunnels IPSec. Pour plus d'informations, reportez-vous à la section sur la configuration d'un contrat de niveau de service IP dans le modèle de configuration basée sur une stratégie Cisco ASA.

Connexions IPSEC multiples : vous pouvez utiliser deux connexions IPSec pour la redondance. Si les deux connexions IPSec ne comportent qu'un routage par défaut (0.0.0.0/0) configuré, le trafic est acheminé vers l'une ou l'autre de ces connexions, car Oracle utilise le routage asymétrique. Si vous souhaitez qu'une connexion IPSec soit la connexion principale et l'autre la connexion de sauvegarde, configurez des routages plus spécifiques pour la connexion principale et des routages moins spécifiques (ou le routage par défaut 0.0.0.0/0) pour la connexion de sauvegarde.

Identificateur IKE local : certaines plates-formes CPE ne vous permettent pas de modifier l'identificateur IKE local. Si tel n'est pas le cas, vous devez modifier l'ID IKE distant dans la console Oracle pour qu'elle corresponde à 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.

Unité de transmission maximale (MTU) : la taille MTU Internet standard est de 1500 octets. Pour plus d'informations sur la recherche de la MTU, reportez-vous à Présentation de la MTU.

Configuration du CPE

Identificateur IKE local : certaines plates-formes CPE ne vous permettent pas de modifier l'identificateur IKE local. Si tel n'est pas le cas, vous devez modifier l'ID IKE distant dans la console Oracle pour qu'elle corresponde à 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.

Cisco ASA : base sur une stratégie : nous recommandons d'utiliser une configuration basée sur un routeur afin d'éviter les problèmes d'interopérabilité et d'assurer une redondance de tunnel avec un appareil Cisco ASA unique.

Cisco ASA ne prend en charge aucune configuration basée sur un routage pour les versions de logiciel antérieures à 9.7.1. Pour obtenir les meilleurs résultats, si le périphérique le prend en charge, nous vous recommandons d'effectuer une mise à niveau vers une version logicielle prenant en charge la configuration basée sur les routes.

Avec la configuration basée sur une stratégie, vous ne pouvez configurer qu'un seul tunnel entre un Cisco ASA et une passerelle de routage dynamique (DRG).

Plusieurs tunnels Si plusieurs tunnels sont démarrés simultanément, 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, etc. Pour plus d'informations sur la configuration appropriée, contactez l'assistance technique du fournisseur du CPE.

Problèmes de domaine de cryptage

Les têtes de réseau du VPN Oracle utilisent des tunnels basés sur un routage mais peuvent fonctionner avec des tunnels basés sur une stratégie, donnant lieu à des avertissements. Pour plus d'informations, reportez-vous à Domaines de cryptage pour les tunnels basés sur une stratégie.

Règles de liste d'accès avec conservation de statut : si vous utilisez des règles d'une liste d'accès avec conservation de statut (pour le trafic TCP, UDP ou ICMP), vous n'avez pas besoin de s'assurer qu'une liste d'accès avec conservation de statut dispose d'une règle explicite autorisant les messages ICMP de type 3 ou de code 4, car le service Networking suit les connexions et autorise automatiquement ces messages. Les règles sans conservation de statut requièrent une règle explicite de liste de sécurité entrante pour les messages ICMP de type 3 et de code 4. Vérifiez que les pare-feu d'instance sont correctement configurés.

Problèmes de VPN site à site d'ordre général

Le tunnel IPSec est DOWN

Vérifiez les éléments suivants :

Le tunnel IPSec est UP, mais aucun trafic ne circule

Vérifiez les éléments suivants :

Le tunnel IPSec est UP, mais le trafic circule dans une seule direction

Vérifiez les éléments suivants :

  • Routage asymétrique : Oracle utilise le routage asymétrique sur les divers tunnels qui constituent la connexion IPSec. Même si vous configurez un tunnel comme principal et un autre comme sauvegarde, le trafic d'un VCN vers un réseau sur site peut utiliser n'importe quel tunnel démarré sur un périphérique. Configurez les pare-feu selon vos besoins. Sinon, les tests ping ou le trafic d'application sur la connexion ne fonctionnent pas de façon fiable.
  • Tunnel préféré : si vous voulez utiliser un seul des tunnels, veillez à employeur la bonne stratégie ou le bon routage sur le CPE afin de préférer ce tunnel.
  • Plusieurs connexions IPSec : si vous disposez de plusieurs connexions IPSec avec Oracle, assurez-vous d'indiquer des routages statiques plus spécifiques pour la connexion IPSec préférée.
  • Listes de sécurité VCN : assurez-vous que les listes de sécurité VCN autorisent le trafic dans les deux sens (entrée et sortie).
  • Règles de pare-feu : assurez-vous que les règles de pare-feu autorisent le trafic dans les deux directions avec les adresses IP de tête de réseau du VPN Oracle et le bloc CIDR du VCN.

Dépannage d'un VPN site à site à l'aide d'une configuration basée sur une stratégie

Le tunnel IPSec est DOWN

Vérifiez les éléments suivants :

Le tunnel IPSec est UP, mais est fluctuant

Vérifiez les éléments suivants :

  • Initiation de la connexion : assurez-vous que le dispositif CPE démarre la connexion.
  • ID de proxy local et distant : si vous utilisez une configuration basée sur une stratégie, vérifiez si la configuration du CPE est configurée avec plusieurs paire d'ID de proxy local et distant (sous-réseaux). Le routeur VPN Oracle ne prend en charge qu'une seule paire sur les anciennes connexions. Si un CPE possède plusieurs paires, mettez à jour la configuration pour en inclure une seule et sélectionnez l'une des deux options suivantes :
    Option ID de proxy local ID de proxy distant
    1 Tous (ou 0.0.0.0/0) Tous (ou 0.0.0.0/0)
    2 CIDR sur site (agrégation couvrant tous les sous-réseaux souhaités) CIDR du réseau cloud virtuel
  • Trafic intéressant à tout moment : nous vous recommandons de toujours exécuter du trafic intéressant via les tunnels IPSec si le CPE le prend en charge. Cisco ASA exige que vous configuriez la surveillance du contrat de niveau de service, qui maintient le trafic intéressant en cours d'exécution via les tunnels IPSec. Pour plus d'informations, reportez-vous à la section sur la configuration d'un contrat de niveau de service IP dans le modèle de configuration basée sur une stratégie Cisco ASA.

Le tunnel IPSec est UP, mais le trafic est instable

Vérifiez les éléments suivants :

  • ID de proxy local et distant : si vous utilisez une configuration basée sur une stratégie, vérifiez si la configuration du CPE est configurée avec plusieurs paire d'ID de proxy local et distant (sous-réseaux). Le routeur VPN Oracle ne prend en charge qu'une seule paire sur les anciennes connexions. Si un CPE possède plusieurs paires, mettez à jour la configuration pour en inclure une seule et sélectionnez l'une des deux options suivantes :
    Option ID de proxy local ID de proxy distant
    1 Tous (ou 0.0.0.0/0) Tous (ou 0.0.0.0/0)
    2 CIDR sur site (agrégation couvrant tous les sous-réseaux souhaités) CIDR du réseau cloud virtuel
  • Trafic intéressant à tout moment : nous vous recommandons de toujours exécuter du trafic intéressant via les tunnels IPSec si le CPE le prend en charge. Cisco ASA exige que vous configuriez la surveillance du contrat de niveau de service, qui maintient le trafic intéressant en cours d'exécution via les tunnels IPSec. Pour plus d'informations, reportez-vous à la section sur la configuration d'un contrat de niveau de service IP dans le modèle de configuration basée sur une stratégie Cisco ASA.

Le tunnel IPSec n'est que partiellement démarré

Diagramme montrant plusieurs domaines de chiffrement et comment trouver leur numéro.

Si vous aviez une configuration similaire à 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.

SA en cours d'exécution partielle : nous recommandons de toujours avoir un trafic intéressant en cours d'exécution via les tunnels IPSec. Certains fournisseurs de CPE 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 que le moniteur SLA monitor soit configuré. De même, les fonctionnalités de Palo Alto telles que la surveillance des chemins peuvent être utilisées. Ces fonctionnalités permettent de conserver un trafic intéressant en cours d'exécution via les tunnels IPSec. Des scénarios ont été vus avec des fournisseurs tels que Cisco ASA agissant comme "l'initiateur" n'amène pas la phase 2 jusqu'à ce qu'il n'y ait pas de trafic intéressant. Cela entraîne l'arrêt du SA soit lorsque le tunnel est démarré, soit après la re-saisie de l'association de sécurité.

Dépannage de la session BGP pour le VPN site à site

Le statut BGP est DOWN

Vérifiez les éléments suivants :

  • Statut IPSec : pour que la session BGP soit démarrée, le tunnel IPSec lui-même doit être démarré.
  • 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 corrects. Le numéro ASN BGP d'Oracle pour le cloud commercial est 31898, à l'exception de la région Centre de la Serbie (Jovanovac), qui est 14544. Pour Government Cloud, reportez-vous à Numéro ASN BGP d'Oracle.
  • MD5 : vérifiez que l'authentification MD5 est désactivée ou non configurée sur le dispositif CPE. Le VPN site à site ne prend pas en charge l'authentification MD5.

  • Pare-feu : vérifiez que le Pare-feu sur site ou les listes de contrôle d'accès ne bloquent pas le port suivant :

    • Port TCP 179 (BGP)
    • Port UDP 500 (IKE)
    • Port de protocole IP 50 (ESP)

    Si un pare-feu de l'appareil CPE bloque l'accès TCP 179 (BGP), l'état du voisin BGP est toujours arrêté. Le trafic ne peut pas circuler dans le tunnel car le dispositif CPE et le routeur Oracle n'ont aucune route.

Le statut BGP fluctue

Vérifiez les éléments suivants :

  • Statut IPSec : pour que la session BGP soit démarrée et non fluctuante, le tunnel IPSec lui-même doit être démarré et non fluctuant.
  • Nombre maximal de préfixes : vérifiez que vous n'utilisez pas plus de 2000 préfixes. Si vous faites plus de publicité, BGP n'est pas établi.

Le statut BGP est UP, mais aucun trafic ne circule

Vérifiez les éléments suivants :

  • Listes de sécurité VCN : assurez-vous que les listes de sécurité VCN autorisent le trafic approprié (règles entrantes et sortantes). Notez que la liste de sécurité par défaut du VCN n'autorise pas le trafic ping (ICMP type 8 et ICMP type 0). Vous devez ajouter les règles entrantes et sortantes appropriées pour autoriser le trafic ping.
  • Routages corrects aux deux extrémités : vérifiez que vous avez reçu les routages de réseau cloud virtuel corrects d'Oracle et que le dispositif CPE les utilise. De même, vérifiez que vous publiez les routages réseau sur site corrects sur le VPN site à site, et que les tables de routage VCN utilisent ces routages.

Le statut BGP est UP, mais le trafic circule dans une seule direction

Vérifiez les éléments suivants :

  • Listes de sécurité VCN : assurez-vous que les listes de sécurité VCN autorisent le trafic dans les deux sens (entrée et sortie).
  • Pare-feu : vérifiez que les pare-feu ou les listes de contrôle d'accès sur site ne bloquent pas le trafic vers ou depuis l'extrémité Oracle.
  • Routage asymétrique : Oracle utilise un routage asymétrique. Si vous disposez de différentes connexions IPSec, assurez-vous que l'appareil CPE est configuré pour le traitement de routage asymétrique.
  • Connexions redondantes : si vous disposez de connexions IPSec redondantes, assurez-vous qu'elles publient les mêmes routages.

Dépannage des connexions IPSec redondantes

Tenez compte des remarques importantes suivantes :

  • FastConnect utilise le routage dynamique BGP. Les connexions IPSec de VPN site à site peuvent utiliser un routage statique, BGP ou une combinaison des deux.
  • Pour plus d'informations sur le routage et les routages préférés lors de l'utilisation de connexions redondantes, reportez-vous à Routage du VPN site à site.
  • Vous pouvez utiliser deux connexions IPSec à des fins de redondance. Si les deux connexions IPSec ne comportent qu'un routage par défaut (0.0.0.0/0) configuré, le trafic est acheminé vers l'une ou l'autre de ces connexions, car Oracle utilise le routage asymétrique. Si vous souhaitez qu'une connexion IPSec soit la connexion principale et l'autre la connexion de sauvegarde, configurez des routages plus spécifiques pour la connexion principale et des routages moins spécifiques (ou le routage par défaut 0.0.0.0/0) pour la connexion de sauvegarde.

IPSec et FastConnect sont tous les deux configurés, mais le trafic passe uniquement par IPSec

Veillez à utiliser des routages plus spécifiques pour la connexion que vous souhaitez définir comme principale. Si vous utilisez les mêmes routages pour IPSec et FastConnect, reportez-vous à la discussion sur les préférences de routage dans Routing for Site-to-Site VPN.

Deux centres de données sur site disposent chacun d'une connexion IPSec à Oracle, mais un seul transmet le trafic

Vérifiez que les deux connexions IPSec sont démarrées et que le traitement du routage asymétrique est activé sur le CPE.

Si les deux connexions IPSec ne comportent qu'un routage par défaut (0.0.0.0/0) configuré, le trafic est acheminé vers l'une ou l'autre de ces connexions, car Oracle utilise le routage asymétrique. Si vous souhaitez qu'une connexion IPSec soit la connexion principale et l'autre la connexion de sauvegarde, configurez des routages plus spécifiques pour la connexion principale et des routages moins spécifiques (ou le routage par défaut 0.0.0.0/0) pour la connexion de sauvegarde.

Pour plus d'informations sur ce type de configuration, reportez-vous à Exemple de disposition avec des zones géographiques.