Meraki to Microsoft Azure - Full Tunnel

Summary

Cette vidéo démontre comment utiliser un MX virtuel pour créer des tunnels sécurisés vers Azure et permettre aux branches distantes de sortir vers Internet via ce dernier. Le MX virtuel agit comme concentrateur VPN, acheminant le trafic des branches vers Azure. Un routeur Cisco est utilisé comme passerelle pour effectuer du NAT et diriger le trafic vers Internet. La vidéo explique également la création de groupes de ressources, de réseaux virtuels, et de tables de routage dans Azure pour gérer efficacement le trafic, avec des détails sur la configuration et les meilleures pratiques.

Takeaways

• 🔐 Création de tunnels sécurisés vers Azure pour toutes les succursales distantes avec l'usage de MX virtuels.
• 📡 Utilisation d'un MX virtuel comme concentrateur VPN pour acheminer le trafic des succursales.
• ⚙️ Mise en place d'un routeur Cisco traditionnel pour assurer le NAT et le routage vers Internet, bien que l'utilisation d'un pare-feu comme ASA soit recommandée.
• 🏗️ Création d'un groupe de ressources séparé pour le MX virtuel afin de personnaliser le routage et le sous-réseautage.
• 🌐 Configuration d'un réseau virtuel dans Azure avec une plage d'adresses IP 192.168.0.0/16 et création d'un sous-réseau pour le MX virtuel.
• 🔑 Génération et ajout d'un jeton d'authentification depuis le tableau de bord Meraki pour connecter le MX virtuel à Azure.
• 🔄 Peering entre le réseau virtuel du routeur Cisco et le réseau virtuel du MX pour permettre le routage entre les deux réseaux.
• 🛠️ Ajout de tables de routage pour rediriger le trafic du MX vers le côté LAN du routeur, et configuration du NAT pour l'accès à Internet.
• 🔧 Création et gestion des règles NAT pour permettre la communication entre les sous-réseaux des succursales et l'Internet via Azure.
• 🖥️ Vérification de la connectivité et de la latence avec l'Internet via le réseau Azure après configuration complète des routes et des règles NAT.

Q & A

Quel est le rôle principal du MX virtuel dans cette démonstration ?

Le MX virtuel agit comme un concentrateur VPN pour tunneliser tout le trafic des succursales vers Azure, et ensuite il passe par un routeur pour sortir sur Internet.

Pourquoi est-il nécessaire de créer un nouveau groupe de ressources pour le MX virtuel ?

Le groupe de ressources créé automatiquement par Meraki est verrouillé, ce qui empêche de modifier le routage ou le sous-réseautage. Créer un nouveau groupe de ressources permet de contrôler ces aspects.

Quel rôle joue le routeur Cisco dans cette architecture ?

Le routeur Cisco est utilisé comme passerelle pour effectuer la NAT (traduction d'adresses réseau) et le routage vers Internet. Bien que l’utilisation d’un pare-feu soit recommandée, un routeur est utilisé pour la démonstration.

Quel est l'intérêt de la fonction 'peering' entre les réseaux virtuels ?

Le 'peering' permet aux deux réseaux virtuels (celui du MX virtuel et celui du routeur Cisco) de communiquer entre eux, ce qui est essentiel pour que le trafic circule correctement.

Pourquoi l'auteur mentionne-t-il l'importance de choisir une région correcte lors de la création du réseau virtuel et des ressources associées ?

Choisir la bonne région garantit que les ressources sont bien localisées ensemble, facilitant ainsi la gestion du routage et évitant des erreurs ou des incompatibilités lors du déploiement.

Quel est l'objectif du routage par défaut vers le routeur virtuel dans le tableau de routage du MX virtuel ?

Le routage par défaut vers le routeur virtuel permet de rediriger tout le trafic passant par le MX virtuel vers l'interface LAN du routeur pour être traité avant de sortir sur Internet.

Que se passe-t-il si le routage n'est pas configuré correctement entre le MX virtuel et le routeur ?

Le trafic ne pourra pas circuler correctement entre les différents réseaux, ce qui peut entraîner une perte de connexion, comme illustré par l'incapacité de ping dans certaines étapes de la démonstration.

Quel est le but de la création d'une règle NAT sur le routeur Cisco ?

La règle NAT permet de traduire les adresses IP internes (du réseau local) en une adresse IP publique pour permettre au trafic de sortir sur Internet.

Pourquoi la latence est-elle élevée lors du test de ping vers Internet depuis l'Australie ?

La latence est élevée parce que le trafic passe par Azure, qui est situé aux États-Unis, tandis que l’utilisateur effectue le test depuis l'Australie, ce qui allonge la distance parcourue par les données.

Quel est l'intérêt de désactiver le Wi-Fi et de se connecter via Ethernet lors de la vérification de l'adresse IP publique ?

Cela permet de s'assurer que l'adresse IP publique correspond à celle du tunnel VPN passant par Azure et non à une adresse locale provenant du Wi-Fi.