Pourquoi une VM Azure avec appliance VPN perd le chemin de retour
Une appliance VPN dans une VM Azure a besoin que l’UDR, l’indicateur de transfert de la carte réseau et la stratégie de l’invité concordent. Suivez une requête de succursale à travers les trois.
Une VM Azure qui exécute une appliance VPN se trouve dans deux systèmes de décision indépendants. Azure décide par où un paquet quitte un sous-réseau, à l’aide des tables de routage et du réglage de transfert de la carte réseau. Le système d’exploitation de l’appliance décide s’il transmet le paquet déchiffré. Un tunnel qui monte parfaitement peut encore échouer sur le second système, et c’est là que s’arrêtent la plupart de ces déploiements.
Trois propriétaires d’un même chemin
Prenez un réseau de succursale 192.168.50.0/24 et un sous-réseau de charge de travail 10.0.10.0/24, l’appliance étant à 10.0.0.4 dans son propre sous-réseau. Une seule requête touche trois configurations distinctes.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Chaque ligne appartient à une équipe différente dans la plupart des organisations, et c’est pourquoi cette panne arrive généralement sous forme de trois tickets au lieu d’un.
La route qui pointe vers l’appliance
Associez une table de routage au sous-réseau de charge de travail et donnez au préfixe de succursale un prochain saut de type Virtual appliance avec 10.0.0.4 comme adresse. Utilisez l’adresse privée joignable de l’appliance, jamais son point d’entrée VPN public. Le prochain saut doit être une adresse que le sous-réseau de charge de travail peut déjà atteindre. Laissez le reste du routage de la charge de travail tranquille, sauf si vous avez délibérément décidé de remplacer la route par défaut.
Gardez l’appliance dans son propre sous-réseau et assurez-vous que la route qui envoie le trafic de succursale vers l’appliance ne capture pas aussi le chemin sortant de l’appliance. Une telle boucle ressemble à un tunnel sain sans aucune réponse, et c’est une chose très désagréable à déboguer à 2 heures du matin.
L’indicateur de carte réseau que tout le monde oublie
Azure dispose d’un réglage de transfert IP par carte réseau, et il est désactivé par défaut. Il existe parce qu’une carte qui transfère reçoit des paquets adressés à autre chose, et les jeter silencieusement est la valeur par défaut sûre pour tous les autres.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true l’active pour une interface. Les conseils de Microsoft sur le transfert sur la carte réseau exigent le réglage sur chaque carte connectée qui transfère du trafic, donc une appliance à une seule carte en a toujours besoin sur cette carte.
L’indicateur n’est pas une route et ce n’est pas une règle de pare-feu. L’activer accorde une autorisation et rien d’autre.
Ce que l’invité fait du paquet déchiffré
Une fois le tunnel terminé, la pile de l’appliance prend la décision suivante. Sur un invité Linux, le transfert IPv4 est un réglage d’exécution, et sysctl -w net.ipv4.ip_forward=1 dure jusqu’au prochain démarrage. Enregistrez-le plutôt dans un fichier sous /etc/sysctl.d/ de façon permanente. Une appliance d’un fournisseur a son propre équivalent, et les instructions Linux collées dans une plateforme de fournisseur ne font généralement absolument rien.
La stratégie de pare-feu de l’invité est encore distincte, tout comme le groupe de sécurité réseau de la charge de travail. Autoriser UDP 500 et 4500 vers l’adresse publique de la VM protège le tunnel ; cela ne dit rien sur la possibilité qu’une requête de succursale déchiffrée atteigne un port de la charge de travail.
Suivez une requête et sa réponse
Choisissez un flux autorisé et suivez-le de bout en bout. La succursale a besoin d’une route pour 10.0.10.0/24 via la connexion de site, l’appliance a besoin d’un chemin de livraison vers le sous-réseau de charge de travail, et le sous-réseau de charge de travail a besoin d’une route de retour vers la succursale.
Décidez tôt si la conception conserve l’adresse source de la succursale ou la traduit. Le NAT change ce que voit la charge de travail, donc ses règles d’accès doivent décrire le modèle que vous avez réellement choisi et non une adresse de passerelle supposée.
Une poignée de main réussie prouve un maillon de cette chaîne. Le chemin est complet lorsque la réponse revient par la même appliance et que la stratégie de la charge de travail elle-même le permet.