Dans un contexte où la migration vers le cloud s’accompagne souvent de contraintes d’adressage et de sécurité, le NAT peut être vu comme une solution pouvant résoudre les problématiques de chevauchement d’adresses et de confidentialité. Vraiment ?
Attention ! Recourir au NAT pour masquer des conflits d’adresses n’est pas toujours une approche saine à long terme, car cela peut introduire une complexité opérationnelle accrue et des difficultés de maintenance ; il doit donc être considéré comme une solution transitoire ou de contournement.
Qu’est-ce que le NAT ?
Le NAT ( ou Network Address Translation) est un mécanisme qui permet de faire correspondre des adresses IP privées (non routables sur Internet) à une ou plusieurs adresses IP publiques (routables). Il joue un rôle clé dans la conservation des adresses IPv4 et dans la sécurisation des réseaux privés.
Voici une courte vidéo qui explique le principe du NAT afin de pallier le souci d’adresses IPv4 pour Internet :
Comment fonctionne le NAT ?
Lorsqu’une machine interne (par exemple 10.0.0.1) envoie une requête vers Internet (par exemple 200.100.10.1), le routeur NAT remplace son adresse source privée par une adresse publique (par exemple 150.150.0.1), et stocke dans sa table de traduction la corrélation :
Le routage du trafic impacte alors le traffic de données dans les deux sens :
- Sortant : le paquet quitte le réseau interne avec l’adresse publique.
- Entrant : la réponse revient à l’adresse publique, le routeur NAT consulte sa table et renvoie le paquet à la machine interne d’origine.
Quels sont ses avantages et ses limites au NAT ?
Avantages
- Économie d’adresses IPv4
- Masquage du réseau interne (sécurité renforcée)
- Contrôle centralisé du trafic sortant/entrant
Limites
- Complexité de dépannage (tables de traduction)
- Certains protocoles (FTP actif, SIP, etc.) nécessitent des algorithmes NAT-aware ou des « NAT helpers »
- Impact potentiel sur la latence et le débit
SNAT vs DNAT ?
En pratique, le NAT (Network Address Translation) se décline en deux grands modes :
| Mode | Abréviation | Fonction principale | Exemple d’usage |
|---|---|---|---|
| Source NAT | SNAT (Source NAT) | Modifier l’adresse source et/ou le port d’une connexion sortante | Votre VM privée (10.0.0.5) → Internet apparaît avec l’IP publique du NAT Gateway |
| Destination NAT | DNAT (Destination NAT) | Modifier l’adresse de destination et/ou le port d’une connexion entrante | Internet (51.210.34.12:80) → redirigé vers votre VM privée (10.0.0.5:8080) |
- Règles de NAT sortantes : permettent de présenter votre réseau virtuel Azure à vos sites distants avec un plan d’adressage spécifique.
- Règles de NAT entrantes : permettent à vos sites distants d’accéder au réseau virtuel Azure en utilisant un plan d’adressage différent.
Et le NAT dans Azure c’est possible ?
Un premier service, appelé Azure NAT Gateway, est conçu pour offrir un moyen simple, fiable et évolutif de gérer le trafic sortant depuis vos réseaux virtuels vers Internet ou d’autres services Azure, sans exposer vos machines virtuelles (VM) directement avec des adresses IP publiques :
Une passerelle NAT Azure est un service de traduction d’adresses réseau entièrement managé et hautement résilient. Vous pouvez utiliser Azure NAT Gateway pour autoriser toutes les instances d’un sous-réseau privé à se connecter à Internet, tout en restant entièrement privées. Les connexions entrantes non sollicitées depuis Internet ne sont pas autorisées via une passerelle NAT. Seuls les paquets arrivant en tant que paquets de réponse à une connexion sortante peuvent passer via une passerelle NAT.
Quels services Azure proposent du NAT ?
Oui, plusieurs services Azure permettant de faire du NAT entre votre réseau Azure et votre infrastructure on-premise :
Peut-on donc avoir un chevauchement d’adresses entre le LAN et un réseau virtuel Azure ?
La réponse est oui :
Les organisations utilisent fréquemment des adresses IP privées définies dans le document RFC1918 pour la communication interne dans leurs réseaux privés. Quand ces réseaux sont connectés à l’aide d’un VPN via Internet ou à l’aide d’un WAN privé, les espaces d’adressage ne doivent pas se chevaucher.
Si c’est le cas, la communication échoue. Pour connecter deux réseaux ou plus avec des adresses IP qui se chevauchent, le NAT est déployé sur les appareils de passerelle qui connectent les réseaux.
Voici un exemple d’architecture entre plusieurs sites appliquant différentes règles NAT :
Attention, Microsoft liste ici les contraintes pour la fonctionnalité NAT d’Azure VPN Gateway :
- NAT est pris en charge sur les références (SKU) suivantes : VpnGw2~5, VpnGw2AZ~5AZ.
- NAT est pris en charge pour les connexions intersites IPsec/IKE uniquement. Les connexions de réseau virtuel à réseau virtuel et les connexions P2S (point à site) ne sont pas prises en charge.
- Les règles NAT ne sont pas prises en charge sur des connexions pour lesquelles l’option Utiliser des sélecteurs de trafic basés sur des stratégies est activée.
- La taille maximale du sous-réseau de mappage externe prise en charge pour le NAT dynamique est /26.
- Les mappages de ports ne peuvent être configurés qu’avec des types NAT statiques. Les scénarios NAT dynamiques ne s’appliquent pas aux mappages de ports.
- Les mappages de ports ne peuvent pas prendre de plages pour l’instant. Un port individuel doit être entré.
- Les mappages de ports peuvent servir pour les protocoles TCP et UDP.
Et en pratique ?
Pour valider la fonctionnalité de NAT au sein de mon architecture Azure, j’ai mis en place un petit exercice de démonstration. Mon environnement se compose de deux réseaux distincts :
- Le premier simulant un réseau on-premise
- Le second correspondant à un réseau virtuel Azure
Le schéma ci-dessous présente ces deux réseaux créés dans mon environnement Azure :
Dans le portail Azure, j’ai donc créé deux réseaux virtuels configurés sur la même plage d’adressage (10.0.0.0/16) pour illustrer un cas de chevauchement :
Sur chaque réseau virtuel, j’ai provisionné une machine virtuelle, toutes les deux en 10.0.0.4 pour renforcer l’idée d’adressage complètement identique :
Pour établir la connectivité, j’ai déployé deux VPN Gateway de type VpnGw2, configurées en tunnel IPsec site à site entre elles :
J’ai commencé par ajouter des règles NAT sur la passerelle Azure :
- Egress rules –> pour présenter votre réseau virtuel Azure avec un adressage translaté à votre réseau on-premise :
- adresses internes : l’adressage IP configuré sur votre réseau virtuel Azure
- adresses externes = l’adressage IP translaté vu par votre réseau on-premise
- Ingress rules –> pour accéder à votre réseau on-premise avec des IP différentes de celles configurées :
- adresses internes = l’adressage IP configuré sur votre réseau on-premise
- adresses externes = l’adressage IP translaté vu par votre réseau virtuel Azure
J’ai répliqué la même logique avec une configuration opposée sur la passerelle VPN simulant celle de mon réseau on-premise :
- Egress rules –> pour présenter ton réseau on-premise avec un adressage translaté à ton réseau virtuel Azure :
- adresses internes : l’adressage IP configuré sur ton réseau on-premise
- adresses externes = l’adressage IP translaté vu par ton réseau virtuel Azure
- Ingress rules –> pour accéder à ton réseau virtuel Azure avec des IP différentes de celles configurées :
- adresses internes = l’adressage IP configuré sur ton réseau virtuel Azure
- adresses externes = l’adressage IP translaté vu par ton réseau on-premise
Enfin, j’ai créé deux passerelle de réseau local correspondant à chaque extrémité :
- L’une pour présenter le réseau on-premise à la passerelle Azure
- L’autre pour présenter le réseau Azure la passerelle on-premise
La première passerelle de réseau local contient l’IP publique de la passerelle VPN Azure et la plage d’adresses 10.0.0.0/16 :
La seconde passerelle de réseau local contient l’IP publique de la passerelle VPN on-premise et la plage d’adresses 10.0.0.0/16 :
J’ai ensuite établi la connexion site-à-site entre mes deux VPN Gateways (VpnGw2) en utilisant la clé pré-partagée définie lors de la création des ressources.
Lors de la configuration de la première connexion, j’ai directement rattaché les règles Ingress NAT et Egress NAT définies précédemment à cette connexion, afin que toute session transitant par le tunnel soit automatiquement traduite.
J’ai reproduit la même configuration sur la seconde connexion : la clé PSK identique, la même plage 10.0.0.0/16 et les règles NAT :
Pour faciliter la connexion de la VM hébergée dans le réseau virtuel Azure, j’ai ajouté le service Azure Bastion :
Une fois Azure Bastion en place, je me suis connecté à la machine virtuelle Azure directement depuis le portail :
Depuis la machine virtuelle Azure, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la VM simulée on-premise :
Depuis le même service Azure Bastion déployé sur le réseau virtuel Azure, j’ai ouvert une session RDP vers la machine virtuelle simulée sur le réseau on-premise en utilisant l’adresse IP externe traduite définie dans les règles NAT de la connexion VPN :
Depuis la VM simulée on-premise, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la machine virtuelle Azure :
Conclusion
Grâce à l’association d’Azure VPN Gateway et de règles SNAT, nous avons validé une communication bidirectionnelle transparente entre deux environnements au plan d’adressage identique, sans exposer d’IP publiques aux VM. Cette démonstration illustre la puissance du NAT dans Azure pour contourner le chevauchement d’adresses
Notez toutefois que s’appuyer durablement sur le NAT peut complexifier votre architecture et alourdir le dépannage ; il est donc recommandé de considérer cette solution comme une étape temporaire, en prévoyant à terme une refonte de votre plan d’adressage pour une architecture plus saine.
