VPN site à site entre AWS et Azure : écrivez d’abord la route de retour
Un tunnel connecté entre deux clouds ne prouve rien tant que chaque sous-réseau de charge n’achemine pas vers le préfixe distant. Déroulez le plan dans l’ordre, puis testez le service.
Le tunnel montera. C’est ce qui arrive d’habitude, car IKE n’a besoin que de propositions concordantes et d’une adresse de pair joignable. Ce qui échoue ensuite, c’est le chemin de retour : la charge AWS envoie des paquets dans un tunnel, mais rien côté Azure ne sait répondre à 10.10.0.0/16, ou la route Azure existe dans une table que le sous-réseau de charge n’utilise pas. Écrivez le plan de routes avant de toucher à l’une des consoles, et le tunnel deviendra la partie la moins intéressante du travail.
Étape 1 : figez le plan d’adressage
Travaillez avec des valeurs concrètes. Une charge AWS se trouve à 10.10.1.20 dans 10.10.0.0/16 et a besoin de TCP 443 vers un service Azure à 10.20.1.30 dans 10.20.0.0/16. Les deux plages ne doivent pas se chevaucher, et le test d’acceptation est la paire de services, pas le tunnel.
Notez ces quatre faits avant tout le reste, car chaque étape suivante est vérifiée par rapport à eux.
Étape 2 : nommez la passerelle qui possède chaque extrémité
AWS Site-to-Site VPN peut se terminer sur une passerelle privée virtuelle ou sur une passerelle de transit, et ce sont des propriétaires de routage différents. Azure propose sa passerelle VPN gérée et, séparément, des appliances basées sur VM que les clients exploitent eux-mêmes. Notez quelle paire vous avez, car le saut suivant diffère dans chaque combinaison.
Pour une passerelle gérée, ne copiez pas une route qui pointe vers une adresse d’appliance privée devinée. Pour une appliance, ne supposez pas que la propagation de routes dans le cloud configure le système d’exploitation invité, car elle ne le fait pas.
Se tromper ici produit un plan qui semble complet et envoie les paquets vers une adresse qui ne répond jamais.
Étape 3 : écrivez la route que chaque charge utilise réellement
Chaque frontière ci-dessous est une recherche distincte, et une route dans l’une d’elles n’est pas une route pour le paquet. Remplissez la table avec vos propres valeurs avant la mise en service du tunnel.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
Sur AWS, la table de routes du sous-réseau de charge est à vous de mettre à jour même une fois BGP ou le tunnel en bonne santé ; l’aperçu du routage considère cela comme faisant partie de la connexion. Sur Azure, une table de routes définies par l’utilisateur est associée à un sous-réseau plutôt que liée au réseau virtuel, vérifiez donc la route effective sur la carte réseau de la charge, et non dans le panneau VNet.
Une passerelle Azure gérée peut apprendre le préfixe distant via la propagation de la passerelle, et une UDR peut annuler cette décision. Ajoutez l’UDR quand vous avez une raison, pas par réflexe. Si vous en ajoutez une, pointez-la vers le saut suivant que la passerelle publie pour le chemin VPN au lieu d’inventer une adresse d’appliance. Relisez ensuite les routes effectives sur la carte réseau, car c’est là que la décision se prend réellement.
Étape 4 : réconciliez la portée
Pour BGP, comparez ce que chaque côté annonce avec ce que l’autre a réellement appris, préfixe par préfixe. Pour le routage statique, comparez les plages distantes configurées avec les routes de charge écrites à l’étape 3.
Une relation IKE d’accord sur la cryptographie ne prouve pas qu’un côté ait appris 10.10.0.0/16 ou 10.20.0.0/16. Deux tunnels peuvent être actifs alors qu’un côté annonce un seul /24 au lieu du /16 prévu. Vérifiez le préfixe dans la table de routage, pas dans l’état du tunnel. L’écart apparaît plus tard comme un sous-réseau qui fonctionne et un autre qui ne répond jamais.
Étape 5 : testez le service depuis la vraie source
Autorisez le flux prévu dans les groupes de sécurité et les ACL réseau d’AWS, dans les NSG Azure et dans tout filtre d’appliance sur le chemin. Ouvrez ensuite une connexion de 10.10.1.20 vers l’adresse et le port approuvés du service et confirmez que la réponse revient à la même source.
Les groupes de sécurité du cloud comme les NSG sont stateful, un paquet de retour refusé est donc un symptôme de routage, pas une règle que vous auriez oublié d’écrire dans l’autre sens.
Un ping depuis une passerelle ne tranche rien. L’ICMP vers l’adresse d’une passerelle exerce le plan de contrôle, pas le service TCP transféré dont la charge a besoin.
Retour arrière et traces
Notez les propriétaires de routes à côté des identifiants de tunnel et conservez les tables de routes d’avant la modification. Si le changement doit être retiré, supprimez les routes de charge avant de démonter le tunnel, pour qu’aucun sous-réseau ne pointe vers un saut qui n’existe plus.
Un déplacement de sous-réseau ou un rattachement spoke ultérieur dispose alors d’un endroit défini où mettre à jour, au lieu d’un tunnel qui fonctionne et porte le blâme d’une route qu’il n’a jamais possédée.