Deux IP publiques sur une seule VM VPN Azure : laquelle fait quoi

Deux IP publiques sur une seule VM VPN Azure créent une attente rarement vérifiée : l'adresse à laquelle les clients se connectent sera aussi l'adresse que voient les sites web. Trois décisions indépendantes produisent ce résultat, et seule la première concerne l'écouteur du tunnel. La deuxième est la source invitée utilisée pour le trafic client transféré, et la troisième est la méthode de sortie Azure qui s'applique à cette source. Changez-en une et les deux autres restent où elles étaient, alors décidez chacune explicitement.

Décision 1 : où le tunnel se termine

Une IP publique Azure est associée à une configuration d'IP privée sur la carte réseau ; ce n'est pas une adresse que vous ajoutez dans le système d'exploitation invité. Lisez la correspondance au lieu de la supposer : az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Quelle que soit l'adresse privée renvoyée par cette requête, c'est celle que l'invité doit réellement porter.

Une carte réseau peut porter plusieurs configurations d'IP, donc deux adresses publiques n'exigent pas deux cartes. Si la conception utilise bien deux cartes, chacune apporte ses propres routes invité et sauts suivants, et vous avez ajouté une décision de routage au lieu d'en simplifier une.

Pour un service avec une liaison locale explicite, liez-vous à la vraie adresse privée de l'invité, jamais à l'espace réservé public. Un écouteur qui accepte toutes les adresses reçoit du trafic par chaque configuration d'IP qui l'atteint, alors restreignez l'entrée avec le groupe de sécurité réseau et le pare-feu de l'hôte au lieu d'espérer que l'ordre de liaison décide.

Décision 2 : quelle source le client transféré utilise

Après que la passerelle a déchiffré une requête client, le paquet qu'elle transfère diffère de celui arrivé à l'écouteur VPN. L'invité a besoin du transfert activé, d'une politique de pare-feu qui autorise le flux et d'une adresse source que la conception du cloud autorise. Si vous traduisez l'adresse interne du client, c'est cette source traduite qu'Azure évaluera, pas l'adresse interne du client.

Une règle SNAT étroite peut choisir une source privée invitée, mais elle ne peut pas supplanter une traduction Azure en aval. Choisissez SNAT lorsque vous avez besoin d'une responsabilité par client dans la VM ; omettez-la lorsque la conception de sortie du sous-réseau fournit déjà une source publique stable et qu'une seconde traduction n'ajouterait que de l'état.

Décision 3 : quelle méthode de sortie Azure l'emporte

Microsoft documentel'ordre de priorité de la sortie: une route applicable vers un équipement ou une passerelle est prioritaire, et la connectivité du sous-réseau via NAT Gateway est prioritaire sur une IP publique au niveau de l'instance sur le chemin concerné. Cet ordre explique pourquoi une traduction vers 10.20.0.5 ne prouve pas qu'un site verra 198.51.100.20. Lisez la table de routage effective, l'association NAT Gateway et l'IP publique de la carte ensemble avant d'accepter la conception de sortie.

Gardezle réglage de transfert de la carte Azuredistinct du transfert Linux. L'indicateur cloud autorise les paquets dont la source ou la destination n'est pas attribuée à la carte ; il n'active pas net.ipv4.ip_forward, et le réglage de l'invité ne donne pas l'autorisation cloud.

Le socket du tunnel a sa propre décision de source

Address de WireGuard sous wg-quick attribue une adresse à l'interface WireGuard ; ce n'est pas une instruction de liaison UDP externe. La source du socket chiffré suit la table de routage, donc une route de politique ou une seconde route par défaut peut la déplacer sans toucher l'adresse de l'interface.OpenVPN: l'option local et UDP multihome se comportent de la même façon : elles concernent l'écouteur et ses réponses, pas la source internet de chaque client transféré.

Préservez la route de dessous qui porte le tunnel et confirmez que le client reçoit toujours des réponses authentifiées depuis la disposition d'entrée attendue. Ne vous fiez pas à l'ordre de la liste d'adresses comme politique permanente de sélection de source, car la prochaine adresse ajoutée à la carte peut changer laquelle l'emporte.

Quoi accepter, et dans quel ordre

Acceptez trois résultats séparément. Premièrement, un client externe atteint l'entrée VPN prévue. Deuxièmement, une nouvelle requête autorisée de ce client VPN sort par la sortie internet documentée. Troisièmement, les chemins d'écoute et de transfert non voulus restent refusés. Consignez les correspondances public-vers-privé et les responsables invité et cloud de chaque décision au même endroit.

Un tunnel réussi ne prouve que la première partie. Testez la sortie avec un nouveau flux, car une connexion en cache peut continuer d'utiliser l'ancienne source longtemps après le changement de route.