Google HA VPN vers un routeur Cisco : planifiez d’abord la ressource de pair
Nommez les deux interfaces Google, la ressource de pair, le contrat IKEv2 et chaque session BGP avant de configurer le routeur Cisco, puis choisissez un pair ou deux.
La première décision dans un HA VPN de Cisco vers Google n’est pas quel profil cryptographique utiliser, mais si un équipement local ou deux termineront les tunnels. La passerelle HA VPN de Google a deux interfaces, et chacune attend un tunnel de pair correspondant. Cela vous donne deux tunnels que vous ayez deux routeurs ou non, et la différence est de savoir si une seule alimentation ou une mise à jour logicielle peut faire tomber toute la conception.
La décision est un équipement de pair ou deux
Choisissez la disposition à partir de trois conditions : si vous pouvez accepter un point de défaillance local, si les deux interfaces cloud doivent être utilisées et combien de reconvergence vos charges de travail tolèrent. Si l’une des trois est une exigence stricte, deux équipements de pair est la réponse honnête.
Décidez-le avant d’ouvrir une console, car la réponse change le nombre de tunnels et de sessions BGP que la feuille de travail doit décrire.
Écrivez la feuille de travail avant toute commande
La feuille de travail comporte cinq lignes, et chacune a besoin d’un responsable :
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
La ressource de pair externe décrit vos interfaces dans Google Cloud, et sa création ne configure pas le routeur Cisco. Cette asymétrie surprend ceux qui attendent de la console cloud qu’elle soit la source de vérité pour les deux extrémités. C’est une déclaration de ce que Google doit attendre, et le routeur doit encore y correspondre. Le guide de passerelle de pair de Google associe cette déclaration au travail de tunnel, BGP, pare-feu et IKE qu’il vous reste à faire.
Si une ligne n’a pas de responsable, elle sera remplie par la personne de permanence pendant la bascule.
Gardez les trois rôles d’adresse séparés
Les adresses publiques de pair portent l’échange IPsec externe. La paire BGP interne appartient à la connexion logique protégée qui passe par-dessus. Les préfixes LAN et VPC annoncés décrivent les charges de travail derrière cette connexion. Copier l’adresse interne d’une VM dans le champ de pair externe mélange les deux premiers rôles, et la panne ressemble à un problème de négociation plutôt qu’à une erreur de saisie.
Planifiez deux tunnels de pair correspondants, un pour chaque interface HA VPN. Utiliser les deux interfaces cloud n’élimine pas en soi le point de défaillance local, car les deux tunnels peuvent encore aboutir sur le même châssis.
Écrivez le rôle de l’adresse à côté de chaque valeur de la feuille de travail. Cette seule habitude évite la majeure partie du mélange.
Traduisez la feuille de travail en version Cisco
Partez de la documentation de pair prise en charge ou d’un modèle de configuration Google adapté à votre plateforme, puis rapprochez chaque espace réservé de la feuille de travail. Vérifiez l’authentification IKEv2, les propositions ESP, le PFS et le modèle de tunnel et de routage ensemble, car un écart dans l’un d’eux se présente généralement comme un écart dans un autre. Utilisez la plateforme et la version logicielle réelles pour choisir ce qui est pris en charge, car une recette Classic VPN est un point de départ différent.
Gardez le secret partagé hors des captures d’écran, des pièces jointes de tickets et des notes de support. Une clé pré-partagée collée dans un commentaire de cas est une divulgation d’identifiants, pas un artefact de dépannage.
Si le modèle et la feuille de travail ne concordent pas, arrêtez-vous et résolvez-le sur papier. L’équipement ne tranchera pas pour vous.
Acceptez chaque tunnel sur ses propres preuves
Le HA VPN a besoin de sessions BGP, et une négociation IKE réussie n’établit que la première étape. La session interne doit monter, les préfixes prévus doivent être annoncés et acceptés, et des routes utiles ainsi que des autorisations de pare-feu doivent exister avant que le trafic des charges de travail ne circule. Consigner cela comme un seul feu vert masque quelle étape a réellement échoué.
Consignez les preuves d’acceptation par tunnel : associations de sécurité négociées, état du voisin BGP, préfixes appris attendus et chemin de charge de travail prévu. Exécutez ensuite un test contrôlé de panne et de reprise, car un tunnel qui n’a jamais échoué est un tunnel dont le chemin de reprise n’a pas été testé.
Cet enregistrement est réutilisable la prochaine fois que la conception change, et c’est la différence entre une interopérabilité et un fragment de commande dont les hypothèses ont été perdues.