Présentation de la traduction d’adresses réseau (NAT)
Présentation de l’adressage réseau Junos Address Aware
L’adressage réseau Junos Address Aware fournit une fonctionnalité de traduction d’adresses réseau (NAT) pour la traduction des adresses IP. Ceci est particulièrement important car l’Internet Assigned Numbers Authority (IANA) a attribué le dernier grand bloc d’adresses IPv4 au début de 2011.
Cette rubrique comprend les sections suivantes :
- Avantages du NAT
- Présentation du concept et des installations du NAT
- NAT de base IPv4-IPv4
- NAPT déterministe
- NAT de destination statique
- Deux fois la NAT
- IPv6 NAT
- Prise en charge des passerelles applicatives (ALG)
- NAT-PT avec DNS ALG
- NAT dynamique
- NAT64 dynamique
- 464XLAT
- Double pile allégée
- Prise en charge de la carte de ligne d’adressage réseau Junos Address Aware
Avantages du NAT
NAT prend en charge un large éventail d’objectifs réseau, notamment :
-
Dissimuler un ensemble d’adresses d’hôtes sur un réseau privé derrière un pool d’adresses publiques afin de protéger les adresses hôtes contre les attaques réseau directes et d’éviter l’épuisement des adresses IPv4
-
Fournir les outils nécessaires pour passer à IPv6 en fonction des besoins de l’entreprise et pour assurer une croissance ininterrompue du nombre d’abonnés et des services
-
Coexistence IPv4-IPv6
Présentation du concept et des installations du NAT
L’adressage réseau Junos Address Aware fournit une connexion NAT de classe opérateur (CGN) pour les réseaux IPv4 et IPv6 et facilite le transit du trafic entre différents types de réseaux.
L’adressage réseau Junos Address Aware prend en charge un ensemble varié d’options de traduction NAT :
-
Traduction source statique : permet de masquer un réseau privé. Il comporte un mappage un-à-un entre l’adresse d’origine et l’adresse traduite ; Le mappage est configuré de manière statique. Pour plus d’informations, reportez-vous à la section NAT de base .
-
NAPT déterministe : élimine le besoin de journalisation de la traduction d’adresse en garantissant que l’adresse IPv4 ou IPv6 source d’origine et le port correspondent toujours à la même adresse IPv4 post-NAT et à la même plage de ports.
-
Traduction source dynamique : comprend deux options : traduction source d’adresse dynamique et traduction de port d’adresse réseau (NAPT) :
-
Traduction dynamique de la source d’adresse uniquement - mdash ; Une adresse NAT est récupérée dynamiquement à partir d’un pool NAT source et le mappage de l’adresse source d’origine à l’adresse traduite est conservé tant qu’il existe au moins un flux actif qui utilise ce mappage. Pour plus d’informations, voir NAT dynamique.
-
NAPT : l’adresse source d’origine et le port source sont convertis. L’adresse et le port traduits sont récupérés dans le pool NAT correspondant. Pour plus d’informations, voir NAPT .
-
-
Traduction de destination statique : vous permet de rendre les serveurs privés sélectionnés accessibles. Il dispose d’un mappage un-à-un entre l’adresse traduite et l’adresse de destination ; Le mappage est configuré de manière statique. Pour plus d’informations, consultez NAT de destination statique.
-
Traduction de protocole : vous permet d’attribuer des adresses d’un pool sur une base statique ou dynamique lorsque des sessions sont lancées au-delà des limites IPv4 ou IPv6. Pour plus d’informations, consultez Configuration de NAT-PT, NAT-PT avec DNS ALG et NAT64 dynamique.
-
Encapsulation de paquets IPv4 en paquets IPv6 à l’aide de softwires : permet aux paquets de voyager sur des softwires jusqu’à un point de terminaison NAT de classe opérateur où ils subissent un traitement source-NAT pour masquer l’adresse source d’origine. Pour plus d’informations, consultez Présentation des services de tunnelisation pour la transition d’IPv4 à IPv6.
Junos Address Aware Adressage réseau prend en charge NAT fonctionnalités décrites dans IETF RFC et les brouillons Internet, comme indiqué dans « Normes NAT et SIP prises en charge » dans Référence des normes.
Tous les types de NAT ne sont pas pris en charge sur tous les types d’interfaces. Consultez la comparaison des fonctionnalités du NAT de classe opérateur pour Junos Address Aware par type de carte d’interface, qui répertorie les fonctionnalités disponibles sur les interfaces prises en charge.
NAT de base IPv4-IPv4
La traduction d’adresses réseau de base ou NAT de base est une méthode par laquelle les adresses IP sont mappées d’un groupe à un autre, de manière transparente pour les utilisateurs finaux. La traduction de ports d’adresses réseau ou NAPT est une méthode par laquelle de nombreuses adresses réseau et leurs ports TCP/UDP sont traduits en une seule adresse réseau et ses ports TCP/UDP. Ensemble, ces deux opérations, appelées NAT traditionnelles, fournissent un mécanisme permettant de connecter un domaine avec des adresses privées à un domaine externe avec des adresses enregistrées uniques au monde.
Le NAT traditionnel, spécifié dans la norme RFC 3022, Traditional IP Network Address Translator, est entièrement pris en charge par l’adressage réseau Junos Address Aware. De plus, NAPT est pris en charge pour les adresses sources.
NAT de base
Avec le NAT de base, un bloc d’adresses externes est réservé pour traduire les adresses des hôtes d’un domaine privé à mesure qu’elles créent des sessions vers le domaine externe. Pour les paquets sortant du réseau privé, le NAT de base traduit les adresses IP sources et les champs associés tels que les sommes de contrôle d’en-tête IP, TCP, UDP et ICMP. Pour les paquets entrants, le NAT de base traduit l’adresse IP de destination et les sommes de contrôle répertoriées ci-dessus.
L’épinglage est pris en charge pour le NAT de base.
NAPT
Utilisez NAPT pour permettre aux composants du réseau privé de partager une seule adresse externe. NAPT traduit l’identifiant de transport (par exemple, numéro de port TCP, numéro de port UDP ou ID de requête ICMP) du réseau privé en une adresse externe unique. NAPT peut être combiné avec le NAT de base pour utiliser un pool d’adresses externes en conjonction avec la traduction de ports.
Pour les paquets sortant du réseau privé, NAPT traduit l’adresse IP source, l’identifiant de transport source (port TCP/UDP ou ID de requête ICMP) et les champs associés, tels que les sommes de contrôle d’en-tête IP, TCP, UDP et ICMP. Pour les paquets entrants, NAPT traduit l’adresse IP de destination, l’identifiant de transport de destination et les sommes de contrôle des en-têtes IP et de transport.
Sur les routeurs MX Series avec MS-MIC et MS-MPC, si vous configurez une règle de NAT NAPT44 et que l’adresse IP source d’un paquet usurpé est égale au pool NAT et que la condition de correspondance de la règle NAT échoue, le paquet est continuellement bouclé entre le PIC de services et le moteur de transfert de paquets. Nous vous recommandons d’effacer manuellement la session et de créer un filtre pour bloquer l’usurpation d’adresse IP du pool NAT dans de telles conditions.
L’épingle à cheveux est prise en charge pour le NAPT.
NAPT déterministe
Utilisez le protocole déterministe NAPT44 pour vous assurer que l’adresse IPv4 et le port sources d’origine correspondent toujours à la même adresse IPv4 et à la même plage de ports post-NAT, et que le mappage inverse d’une adresse IPv4 et d’un port IPv4 externes traduits sont toujours mappés à la même adresse IP interne. Il n’est donc plus nécessaire d’enregistrer les traductions d’adresses. À partir de la version 17.4R1 de Junos OS, le NAPT64 déterministe est pris en charge sur les MS-MPC et MS-MIC. Le protocole déterministe NAPT64 garantit que l’adresse IPv6 et le port source d’origine correspondent toujours à la même adresse IPv4 et à la même plage de ports post-NAT, et que le mappage inverse d’une adresse IPv4 externe traduite et d’un port donné est toujours mappé à la même adresse IPv6 interne.
NAT de destination statique
Utilisez la NAT de destination statique pour convertir l’adresse de destination du trafic externe en une adresse spécifiée dans un pool de destination. Le pool de destination contient une adresse et aucune configuration de port.
Pour plus d’informations sur le NAT de destination statique, consultez RFC 2663, Terminologie et considérations relatives au traducteur d’adresses réseau IP (NAT).
Deux fois la NAT
Dans Twice NAT, les adresses source et de destination sont sujettes à traduction lorsque les paquets traversent le routeur NAT. Les informations de source à traduire peuvent être soit l’adresse seule, soit l’adresse et le port. Par exemple, vous pouvez utiliser Twice NAT lorsque vous connectez deux réseaux dans lesquels toutes ou certaines adresses d’un réseau se chevauchent avec des adresses d’un autre réseau (que le réseau soit privé ou public). Dans le NAT traditionnel, une seule des adresses est traduite.
Pour configurer Twice NAT, vous devez spécifier à la fois une adresse de destination et une adresse source pour la direction de correspondance, le pool ou le préfixe et le type de conversion.
Vous pouvez configurer des passerelles de niveau d’application (ALG) pour ICMP et traceroute sous des règles de pare-feu dynamique, de NAT ou de classe de service (CoS) lorsque Twice NAT est configuré dans le même ensemble de services. Ces ALG ne peuvent pas être appliqués aux flux créés par le protocole PGCP (Packet Gateway Control Protocol). Twice NAT ne prend pas en charge les autres ALG. Par défaut, la fonctionnalité Twice NAT peut affecter les en-têtes IP, TCP et UDP intégrés dans la charge utile des messages d’erreur ICMP.
Le NAT à deux reprises, spécifié dans la RFC 2663, Terminologie et considérations du traducteur d’adresses réseau IP (NAT), est entièrement pris en charge par l’adressage réseau Junos Address Aware.
IPv6 NAT
Le NAT IPv6-to-IPv6 (NAT66), défini dans le projet Internet draft-mrw-behave-nat66-01, IPv6-to-IPv6 Network Address Translation (NAT66), est entièrement pris en charge par Junos Address Aware Adressage réseau.
Prise en charge des passerelles applicatives (ALG)
L’adressage réseau Junos Address Aware prend en charge un certain nombre d’ALG. Vous pouvez utiliser des règles NAT pour filtrer le trafic entrant en fonction des ALGS. Pour plus d’informations, consultez Présentation des règles de traduction d’adresses réseau.
NAT-PT avec DNS ALG
Le NAT-PT et l’ALG DNS (Domain Name System) sont utilisés pour faciliter la communication entre les hôtes IPv6 et IPv4. À l’aide d’un pool d’adresses IPv4, NAT-PT attribue dynamiquement les adresses de ce pool aux nœuds IPv6 lorsque des sessions sont lancées au-delà des limites IPv4 ou IPv6. Les sessions entrantes et sortantes doivent passer par le même routeur NAT-PT pour qu’il puisse suivre ces sessions. La RFC 2766, Traduction d’adresses réseau - Traduction de protocoles (NAT-PT), recommande l’utilisation de NAT-PT pour la traduction entre nœuds IPv6 uniquement et nœuds IPv4 uniquement, et non pour la traduction IPv6-IPv6 entre nœuds IPv6 ou la traduction IPv4-IPv4 entre nœuds IPv4.
Le DNS est un système de dénomination hiérarchique distribué pour les ordinateurs, les services ou toute ressource connectée à Internet ou à un réseau privé. L’ALG DNS est un agent spécifique à l’application qui permet à un nœud IPv6 de communiquer avec un nœud IPv4 et vice versa.
Lorsque DNS ALG est utilisé avec NAT-PT, le DNS ALG traduit les adresses IPv6 dans les requêtes DNS et les réponses aux adresses IPv4 correspondantes et vice versa. Les correspondances nom-adresse IPv4 sont conservées dans le DNS avec les requêtes « A ». Les correspondances nom-adresse IPv6 sont conservées dans le DNS avec les requêtes « AAAA ».
Pour les requêtes DNS IPv6, utilisez l’instruction do-not-translate-AAAA-query-to-A-query au niveau de la [edit applications application application-name] hiérarchie.
NAT dynamique
Le flux NAT dynamique est illustré à la Figure 1.
NAT dynamique
Avec le NAT dynamique, vous pouvez mapper une adresse IP privée (source) à une adresse IP publique à partir d’un pool d’adresses IP enregistrées (publiques). Les adresses NAT du pool sont attribuées dynamiquement. L’attribution dynamique d’adresses permet également à quelques adresses IP publiques d’être utilisées par plusieurs hôtes privés, contrairement à un pool de taille égale requis par le NAT statique source.
Pour plus d’informations sur la traduction dynamique des adresses, consultez RFC 2663, Terminologie et considérations relatives au traducteur d’adresses réseau IP (NAT).
NAT64 dynamique
Le flux NAT64 dynamique est illustré à la Figure 2.
NAT64 dynamique
Le NAT64 dynamique est un mécanisme permettant de passer à un réseau IPv6 tout en gérant l’épuisement des adresses IPv4. En permettant aux clients IPv6 uniquement de contacter des serveurs IPv4 à l’aide d’UDP, TCP ou ICMP unicast, plusieurs clients IPv6 uniquement peuvent partager la même adresse de serveur IPv4 publique. Pour permettre le partage de l’adresse du serveur IPv4, NAT64 traduit les paquets IPv6 entrants en IPv4 (et vice versa).
Lorsque NAT64 dynamique est utilisé conjointement avec DNS64, aucune modification n’est généralement requise dans le client IPv6 ou le serveur IPv4. DNS64 n’entre pas dans le champ d’application du présent document car il est normalement implémenté en tant qu’amélioration des serveurs DNS actuellement déployés.
Le NAT64 dynamique, spécifié dans la norme RFC 6146, NAT64 dynamique : Traduction des adresses réseau et des protocoles des clients IPv6 vers les serveurs IPv4, est entièrement pris en charge par Junos Address Aware Adressage réseau.
464XLAT
À partir de la version 17.1R1 de Junos OS, vous pouvez configurer un convertisseur côté fournisseur (PLAT) 464XLAT. Cette approche n’est prise en charge que sur les MS-MIC et les MS-MPC. Le modèle 464XLAT offre une technique simple et évolutive permettant à un client IPv4 disposant d’une adresse privée de se connecter à un hôte IPv4 sur un réseau IPv6. Le modèle 464XLAT ne prend en charge IPv4 que dans le modèle client-serveur. Il ne prend donc pas en charge la communication IPv4 de pair à pair ni les connexions IPv4 entrantes.
Un traducteur côté client (CLAT), qui n’est pas un produit de Juniper Networks, traduit le paquet IPv4 en IPv6 en incorporant les adresses source et de destination IPv4 dans des préfixes IPv6/96, et envoie le paquet au PLAT, via un réseau IPv6. Le PLAT traduit le paquet en IPv4 et l’envoie à l’hôte IPv4 sur un réseau IPv4 (voir Figure 3).
filaire 464XLAT
XLAT464 offre l’avantage de ne pas avoir à maintenir un réseau IPv4 et à ne pas avoir à attribuer d’adresses IPv4 publiques supplémentaires.
Le CLAT peut résider sur l’appareil mobile de l’utilisateur final dans un réseau mobile IPv6 uniquement, ce qui permet aux fournisseurs de réseaux mobiles de déployer IPv6 pour que leurs utilisateurs and prennent en charge des applications IPv4 uniquement sur les appareils mobiles (voir Figure 4).
sans fil 464XLAT
Double pile allégée
Le flux DS-Lite (Dual-Stack Lite) est illustré à la Figure 5.
DS-Lite
DS-Lite utilise des tunnels IPv4 sur IPv6 pour traverser un réseau d’accès IPv6 afin d’atteindre un NAT IPv4-IPv4 de classe opérateur. Cela facilite l’introduction progressive d’IPv6 sur Internet en assurant la rétrocompatibilité avec IPv4.
DS-Lite est pris en charge sur les routeurs MX Series avec MS-DPC et sur les routeurs M Series avec MS-100, MS-400 et MS-500 MultiServices PICS. À partir de Junos OS version 17.4R1, DS-Lite est pris en charge sur les routeurs MX Series avec MS-MPC et MS-MIC.À partir de Junos OS version 19.2R1, DS-Lite est pris en charge sur les routeurs MX Virtual Chassis et MX Broadband Network Gateway (BNG).
Prise en charge de la carte de ligne d’adressage réseau Junos Address Aware
Les technologies d’adressage réseau Junos Address Aware sont disponibles sur les cartes de ligne suivantes :
-
MultiServices concentracteur de port dense (MS-DPC)
-
MS-100, MS-400 et MS-500 PICS multiservices
-
Concentrateur de ports modulaires multiservices (MS-MPC) et carte d’interface modulaire multiservices (MS-MIC)
-
Concentrateurs de ports modulaires (NAT en ligne).
Pour obtenir une liste des types de NAT spécifiques pris en charge sur chaque type de carte, consultez Comparaison des fonctionnalités NAT de classe opérateur pour Junos Address Aware par type de carte d’interface.
Voir aussi
Exemples de scénarios de transition vers IPv6
Junos OS prend en charge de nombreux scénarios de transition IPv6 requis par les clients Junos OS. Voici des exemples choisis :
- Exemple 1 : Épuisement du protocole IPv4 avec un réseau d’accès non IPv6
- Exemple 2 : Épuisement du protocole IPv4 avec un réseau d’accès IPv6
- Exemple 3 : Épuisement d’IPv4 pour les réseaux mobiles
Exemple 1 : Épuisement du protocole IPv4 avec un réseau d’accès non IPv6
La figure 6 représente un scénario dans lequel le fournisseur d’accès à Internet (FAI) n’a pas modifié de manière significative son réseau IPv4. Cette approche permet aux hôtes IPv4 d’accéder à Internet IPv4 et aux hôtes IPv6 d’accéder à Internet IPv6. Un hôte à double pile peut être traité comme un hôte IPv4 lorsqu’il utilise le service d’accès IPv4 et comme un hôte IPv6 lorsqu’il utilise le service d’accès IPv6.
d’accès IPv4
Deux nouveaux types d’appareils doivent être déployés dans cette approche : une passerelle domestique à double pile et une traduction d’adresses réseau de classe opérateur (NAT) à double pile. La passerelle domestique à double pile intègre des fonctions de transfert IPv4 et de tunnelisation v6 sur v4. Il peut également intégrer une fonction NAT v4-v4. Le NAT de classe opérateur (CGN) à double pile intègre une tunnelisation v6 sur v4 et des fonctions de NAT v4-v4 de classe opérateur.
Exemple 2 : Épuisement du protocole IPv4 avec un réseau d’accès IPv6
Dans le scénario illustré à la Figure 7, le réseau du FAI utilise IPv6 uniquement.
d’accès IPv6
La solution allégée à double pile (DS-Lite) convient aux FAI qui utilisent exclusivement IPv6. Le meilleur modèle économique pour cette approche est que le CPE (Customer Premises Equipment) a intégré les fonctions de tunnelisation IPv6 vers une dorsale IPv4, de tunnelisation IPv4 vers une dorsale IPv6, et peut détecter automatiquement la solution requise.
Tous les clients d’un FAI donné ne doivent pas passer simultanément de l’accès IPv4 à l’accès IPv6 ; En fait, la transition peut être mieux gérée en changeant progressivement de groupe de clients (par exemple, tous ceux qui sont connectés à un seul point de présence). Une telle approche incrémentielle devrait s’avérer plus facile à planifier, à programmer et à exécuter qu’une conversion généralisée.
Exemple 3 : Épuisement d’IPv4 pour les réseaux mobiles
La complexité des réseaux mobiles nécessite une approche de migration flexible pour minimiser les interruptions et maximiser la compatibilité descendante pendant la transition. NAT64 peut être utilisé pour permettre aux périphériques IPv6 de communiquer avec des hôtes IPv4 sans modifier les clients.
Présentation de l’implémentation du NAT de classe opérateur de Junos OS
Junos OS vous permet d’implémenter et de mettre à l’échelle une solution CGNAT (Carrier-grade Network Address Translation) en fonction du type d’interfaces de services utilisées pour votre implémentation :
MS-DPC (MultiServices Denser Port Concentrator) : le package de services de couche 3 est utilisé pour configurer le NAT des PIC de services adaptatifs MS-DPC. Cette solution fournit la fonctionnalité NAT décrite dans Présentation de l’adressage réseau Junos Address Aware.
MS-100, MS-400 et MS-500 MultiServices PICS : le package de services de couche 3 est utilisé pour configurer le NAT pour les PIC multiservices. Cette solution fournit la fonctionnalité NAT décrite dans Présentation de l’adressage réseau Junos Address Aware.
Concentrateur de ports modulaires multiservices (MS-MPC) et carte d’interface modulaire multiservices (MS-MIC) : MS-MPC et MS-MICs sont préconfigurés pour permettre la configuration de NAT de classe opérateur. Cette solution fournit la fonctionnalité NAT décrite dans Présentation de l’adressage réseau Junos Address Aware.
NAT en ligne pour les cartes de ligne MPC (Modular Port Concentrator) : le NAT en ligne exploite les capacités de services des cartes de ligne MPC, permettant une implémentation rentable de la fonctionnalité NAT sur le plan de données, comme décrit dans Présentation de la traduction d’adresses réseau en ligne.
Voir aussi
Comparaison des fonctionnalités NAT de classe opérateur pour Junos Address Aware par type de carte d’interface
Le Tableau 1 récapitule les différences entre les différentes fonctionnalités des implémentations NAT de classe opérateur de Junos OS.
À partir de la version 17.2R1 de Junos OS, le NAT en ligne est pris en charge sur les MPC5E et MPC6E.
À partir de la version 17.4R1 de Junos OS, le NAT en ligne est pris en charge sur les MPC7E, MPC8E et MPC9E.
Fonctionnalité |
MS-DPC MS-100 MS-400 MS-500 |
MS-MPC MS-MIC |
MPC1, MPC2, MPC3, MPC5E, MPC6E, MPC7E, MPC8E et MPC9E NAT en ligne |
|---|---|---|---|
NAT source statique |
Oui |
Oui |
Oui |
Dynamic Source NAT - Adresse uniquement |
Oui |
Oui |
Non |
Dynamic Source NAT - Traduction de ports NAPT avec attribution de blocs de ports sécurisés |
Oui |
oui (NAT source dynamique - Traduction de ports NAPT avec attribution de blocs de ports sécurisée prise en charge pour MS-MPC et MS-MIC à partir de Junos OS version 14.2R2) |
Non |
Dynamic Source NAT - Traduction de ports NAPT44 avec attribution déterministe du bloc de ports |
Oui |
oui (NAT source dynamique - Traduction de ports NAPT44 avec attribution déterministe de blocs de ports prise en charge pour MS-MPC et MS-MIC à partir de Junos OS version 17.3R1, dans Junos OS version 14.2R7 et versions ultérieures 14.2, dans 15.1R3 et versions ultérieures 15.1, et dans 16.1R5 et versions ultérieures 16.1) |
Non |
NAT source dynamique - Traduction de ports NAPT64 avec attribution déterministe du bloc de ports |
Non |
oui (NAT source dynamique - Traduction de ports NAPT64 avec attribution déterministe du bloc de ports prise en charge pour MS-MPC et MS-MIC à partir de Junos OS version 17.4R1) |
Non |
NAT de destination statique |
Oui |
Oui |
Oui
Remarque :
Le NAT de destination peut être implémenté indirectement. Voir Présentation de la traduction d’adresses réseau en ligne |
Deux fois la NAT |
Oui |
oui (deux fois le NAT pris en charge pour MS-MPC et MS-MIC à partir de Junos OS version 15.1R1) |
Oui
Remarque :
Twice NAT peut être implémenté indirectement. Voir Présentation de la traduction d’adresses réseau en ligne |
NAPT - Préserver la parité et l’autonomie |
Oui |
oui (NAPT : préserver la parité et la plage prises en charge pour MS-MPC et MS-MIC à partir de Junos OS version 15.1R1) |
Non |
NAPT - APPLICATION/FEI/EIM |
Oui |
Oui |
Non |
IKE ALG |
Non |
oui (à partir de Junos OS versions 14.2R7, 15.1R5, 16.1R2 et 17.1R1) |
Non |
NAT64 dynamique |
Oui |
Oui |
Non |
NAT64 dynamique avec APP/EIM/EIF |
Non |
Oui |
Non |
NAT64 dynamique avec ALG
|
Non |
Oui |
Non |
DS-Lite |
Oui |
oui (DS-Lite pris en charge pour MS-MPC et MS-MIC à partir de Junos OS version 17.4R1) |
Non |
6ème |
Oui |
Non |
Non |
6to4 |
Oui |
Non |
Non |
464XLAT |
Non |
oui (à partir de Junos OS version 17.1R1) |
Non |
Adresse de chevauchement sur le pool NAT |
Oui |
Oui |
Non |
| Pool de surcharges |
Oui |
Non |
Non |
Protocole de contrôle de port |
Oui |
oui (Le protocole de contrôle de port avec NAPT44 est pris en charge pour MS-MPC et MS-MIC à partir de la version 17.4R1 de Junos OS. À partir de la version 18.2R1 de Junos OS, le protocole de contrôle de port sur les MS-MPC et MS-MIC prend en charge DS-Lite. Le PCP fournit un mécanisme pour contrôler le transfert de paquets entrants par les périphériques en amont tels que les NAT44 et les pare-feu, et un mécanisme pour réduire le trafic keepalive des applications. |
Non |
CGN-PIC |
Oui |
Non |
Non |
Assistance AMS |
Non |
Oui |
Non |
Transfert de port |
Oui |
oui (Le transfert de port est pris en charge pour MS-MPC et MS-MIC à partir de Junos OS version 17.4R1.) |
Non |
Pas de traduction |
Oui |
oui (aucune traduction prise en charge pour MS-MPC et MS-MIC à partir de Junos OS version 15.1R1) |
Oui |
Le Tableau 2 récapitule la disponibilité des types de traduction par type de carte de ligne.
Type de traduction |
MS-DPC MS-100 MS-400 MS-500 |
MS-MPC MS-MIC |
MPC1, MPC2, MPC3, MPC5E, MPC6E, MPC7E, MPC8E et MPC9E NAT en ligne |
|---|---|---|---|
|
Oui |
Oui |
Oui |
|
Oui |
Non |
Non |
|
Oui |
Non |
Non |
|
Oui |
oui ( |
Non |
|
Non |
oui ( |
Non |
|
Oui |
Oui |
Non |
|
Oui |
Oui |
Non |
|
Oui |
Oui |
Non |
|
Oui |
Non |
Non |
|
Oui |
Non |
Non |
|
Non |
oui (à partir de Junos OS version 17.1R1) |
Non |
|
Oui |
Oui |
Non |
|
Oui |
oui ( |
oui ( |
|
Oui |
oui ( |
Non |
|
Oui |
oui ( |
Non |
ALG disponibles pour Junos OS Address Aware NAT
Les passerelles de niveau d’application (ALG) suivantes, répertoriées dans le tableau 3 , sont prises en charge pour le traitement NAT sur les plates-formes répertoriées.
Pour afficher les détails d’implémentation (port, protocole, etc.) de ces applications par défaut de Junos OS, recherchez le nom ALG par défaut de Junos OS dans le tableau, puis recherchez le nom répertorié dans le groups. Par exemple, pour plus de détails sur TFTP, recherchez junos-tftp comme indiqué.
Junos OS fournit le junos-alg, qui permet à d’autres ALG de fonctionner en gérant les enregistrements ALG, en ralentissant le passage des paquets à travers les ALG enregistrés et en transférant les événements ALG vers les plug-ins ALG. L’ALG junos-alg est automatiquement disponible sur les plates-formes MS-MPC et MS-MIC et ne nécessite aucune configuration supplémentaire.
Les passerelles de couche application (ALG) de shell distant (RSH) et de connexion à distance (rlogin) ne sont pas prises en charge avec la traduction de ports d’adresse réseau (NAPT) sur les routeurs MX Series avec MS-MIC et MS-MPC.
user@host# show groups junos-defaults applications application junos-tftp application-protocol tftp; protocol udp; destination-port 69;
Le Tableau 3 récapitule les ALG disponibles pour les cartes d’interface NAT Junos OS Address Aware pour les interfaces de services.
ALG |
MS-DPC |
MS-MPC, MS-MIC |
Nom ALG par défaut de Junos OS |
|---|---|---|---|
ALG TCP de base |
Oui |
Oui |
Remarque :
Les ALG spécifiques de Junos OS ne sont pas pris en charge. Cependant, une fonctionnalité appelée tracker TCP, disponible par défaut, effectue l’ordonnancement des segments et le suivi des retransmissions et des connexions, les validations pour les connexions TCP. |
ALG UDP de base |
Oui |
Oui |
Remarque :
Le traqueur TCP effectue des contrôles d’intégrité et de validation limités pour UDP. |
BOOTP |
Oui |
Non |
|
DCE RPC Services |
Oui |
Oui |
|
DNS (en anglais) |
Oui |
Oui |
|
DNS (en anglais) |
Non |
Non |
|
FTP (en anglais) |
Oui |
Oui |
|
RAS Gatekeeper (à partir de Junos OS version 17.1R1) |
Non |
Oui |
|
H323 |
Non |
Oui |
|
L’ICMP |
Oui |
Oui
Remarque :
Dans Junos OS version 14.1 et antérieure, les messages ICMP sont gérés par défaut, mais la prise en charge de PING ALG n’est pas fournie. À partir de Junos OS 14.2, les messages ICMP sont gérés par défaut et la prise en charge de PING ALG est fournie. |
|
L’IIOP |
Oui |
Non |
|
IKE ALG |
Non |
Oui
Remarque :
À partir de Junos OS versions 14.2R7, 15.1R5, 16.1R2 et 17.1R1, l’ALG IKE est pris en charge sur les MS-MPC et MS-MIC. |
|
IP |
Oui |
Le tracker TCP, disponible par défaut sur ces plateformes, effectue des contrôles d’intégrité et de validation limités. |
|
NETBIOS |
Oui |
Non |
|
NETSHOW |
Oui |
Non |
|
PPTP |
Oui |
Oui |
|
REALAUDIO |
Oui |
Non |
|
Services de carte de port Sun RPC et RPC |
Oui |
Oui |
|
RTSP |
Oui |
Oui |
|
SIP |
Oui |
Oui |
Le SIP
Remarque :
Les sessions SIP sont limitées à 12 heures (720 minutes) pour le traitement NAT sur les cartes d’interface MS-MIC et MS-MPC. Les sessions SIP sur le MS-DPC n’ont pas de limite de temps. |
SNMP |
Oui |
Non |
|
SQLNET |
Oui |
Oui |
|
TFTP |
Oui |
Oui |
|
Traceroute |
Oui |
Oui |
|
Service shell distant Unix |
Oui |
Oui
Remarque :
Remote Shell (RSH) L’ALG n’est pas pris en charge pour la traduction de ports d’adresses réseau (NAPT). |
|
WINFrame |
Oui |
Non |
|
DISCUSSION-UDP |
Non |
Oui |
|
MS RPC |
Non |
Oui |
|
Voir aussi
ALG disponibles par défaut pour le NAT sensible aux adresses Junos OS sur le routeur ACX500
Les passerelles de niveau d’application (ALG) suivantes, répertoriées dans le tableau 4 , sont prises en charge pour le traitement NAT sur les routeurs ACX500.
Pour afficher les détails d’implémentation (port, protocole, etc.) de ces applications par défaut de Junos OS, recherchez le nom ALG par défaut de Junos OS dans le tableau, puis recherchez le nom répertorié dans le groups. Par exemple, pour plus de détails sur TFTP, recherchez junos-tftp comme indiqué.
L’ALG pour NAT n’est pris en charge que sur les routeurs intérieurs ACX500.
Junos OS fournit le junos-alg, qui permet à d’autres ALG de fonctionner en gérant les enregistrements ALG, en ralentissant le passage des paquets à travers les ALG enregistrés et en transférant les événements ALG vers les plug-ins ALG. L’ALG junos-alg est automatiquement disponible sur le routeur ACX500 et ne nécessite aucune configuration supplémentaire.
Les passerelles de couche applicative (ALG) de connexion à distance (rlogin) ne sont pas prises en charge avec la traduction de ports d’adresse réseau (NAPT) sur le routeur ACX500.
| ALG |
Routeur ACX500 |
Nom ALG par défaut de Junos OS |
|---|---|---|
| ALG TCP de base |
Oui |
Remarque :
Les ALG spécifiques de Junos OS ne sont pas pris en charge. Cependant, une fonctionnalité appelée tracker TCP, disponible par défaut, effectue l’ordonnancement des segments et le suivi des retransmissions et des connexions, les validations pour les connexions TCP. |
| ALG UDP de base |
Oui |
Remarque :
Le traqueur TCP effectue des contrôles d’intégrité et de validation limités pour UDP. |
| DNS (en anglais) |
Oui |
|
| FTP (en anglais) |
Oui |
|
| L’ICMP |
Oui
Remarque :
Les messages ICMP sont gérés par défaut, mais la prise en charge de PING ALG n’est pas fournie. |
|
| TFTP |
Oui |
|
| Service shell distant Unix |
Oui
Remarque :
Remote Shell (RSH) L’ALG n’est pas pris en charge pour la traduction de ports d’adresses réseau (NAPT). |
|
Détails de l’assistance ALG
Cette section comprend des détails sur les ALG. Il comprend les éléments suivants :
TCP de base
Cet ALG effectue une vérification d’intégrité de base sur les paquets TCP. S’il détecte des erreurs, il génère les événements d’anomalie et les messages de journal système suivants :
-
Port source ou de destination TCP zéro
-
Échec de la vérification de la longueur de l’en-tête TCP
-
Numéro de séquence TCP zéro et aucun indicateur n’est défini
-
Le numéro de séquence TCP zéro et les indicateurs FIN/PSH/RST sont définis
-
TCP FIN/RST ou SYN(URG|FIN|RST) sont définis
L’ALG TCP effectue les étapes suivantes :
-
Lorsque le routeur reçoit un paquet SYN, l’ALG crée des flux TCP avant et arrière et les regroupe dans une conversation. Il suit l’établissement de liaison TCP à trois voies.
-
Le mécanisme de défense SYN suit l’état d’établissement de la connexion TCP. Elle s’attend à ce que la session TCP soit établie dans un court intervalle de temps (actuellement 4 secondes). Si l’établissement de liaison TCP à trois voies n’est pas établi au cours de cette période, la session est terminée.
-
Un mécanisme keepalive détecte les sessions TCP avec des points de terminaison qui ne répondent pas.
-
Les erreurs ICMP ne sont autorisées que lorsqu’un flux correspond aux informations du sélecteur spécifiées dans les données ICMP.
UDP de base
Cet ALG effectue une vérification d’intégrité de base sur les en-têtes UDP. S’il détecte des erreurs, il génère les événements d’anomalie et les messages de journal système suivants :
-
Port source ou de destination UDP 0
-
Échec de la vérification de la longueur d’en-tête UDP
L’ALG UDP effectue les étapes suivantes :
-
Lorsqu’il reçoit le premier paquet, l’ALG crée des flux bidirectionnels pour accepter le trafic de session UDP aller et arrière.
-
Si la session est inactive plus longtemps que la durée d’inactivité maximale autorisée (la valeur par défaut est de 30 secondes), les flux sont supprimés.
-
Les erreurs ICMP ne sont autorisées que lorsqu’un flux correspond aux informations du sélecteur spécifiées dans les données ICMP.
DNS (en anglais)
L’ALG DNS (Domain Name System) gère les données associées à la localisation et à la traduction des noms de domaine en adresses IP. L’ALG s’exécute généralement sur le port 53. L’ALG surveille les paquets de requêtes et de réponses DNS et prend uniquement en charge le trafic UDP. L’ALG ne prend pas en charge la traduction des charges utiles. L’ALG DNS ferme la session uniquement lorsqu’une réponse est reçue ou qu’un délai d’inactivité est atteint.
Voici un exemple de configuration de DNS ALG :
-
Création d’une interface NAT.
[edit] services { service-set set-dns { nat-rules nat-dns; interface-service { service-interface ms-0/2/0; } } -
Configuration d’un pool NAT.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Définition des règles NAT pour DNS ALG.
[edit] services { nat { rule nat-dns { match-direction input; term term1 { from { source-address { 10.50.50.2/32; } applications junos-dns-udp;; } then { translated { source-pool p-napt; translation-type { basic-nat44; } } } } } } -
Liaison d’ensembles de services à l’interface.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-dns; } output { service-set set-dns; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
FTP (en anglais)
FTP est le protocole de transfert de fichiers, spécifié dans RFC 959. En plus de la connexion de contrôle principale, des connexions de données sont également établies pour tout transfert de données entre le client et le serveur ; et l’hôte, le port et la direction sont négociés via le canal de contrôle.
Pour le FTP en mode non passif, le service de pare-feu dynamique de Junos OS analyse les données de l’application client-serveur à la recherche de la commande PORT, qui fournit l’adresse IP et le numéro de port auxquels le serveur se connecte. Pour le FTP en mode passif, le service de pare-feu dynamique de Junos OS analyse les données d’application client-serveur à la recherche de la commande PASV, puis analyse les réponses serveur-client à la recherche de la réponse 227, qui contient l’adresse IP et le numéro de port auxquels le client se connecte.
Il y a une complication supplémentaire : FTP représente ces adresses et numéros de port en ASCII. Par conséquent, lorsque les adresses et les ports sont réécrits, le numéro de séquence TCP peut être modifié, et par la suite, le service NAT doit maintenir ce delta dans les numéros SEQ et ACK en exécutant une séquence NAT sur tous les paquets suivants.
La prise en charge des services de pare-feu dynamiques et de NAT nécessite que vous configuriez l’ALG FTP sur le port TCP 21 pour activer le protocole de contrôle FTP. L’ALG effectue les tâches suivantes :
-
Attribue automatiquement les ports de données et les autorisations de pare-feu pour une connexion dynamique des données
-
Crée des flux pour la connexion de données négociée dynamiquement
-
Surveille la connexion de commande en mode actif et passif
-
Réécrit les paquets de contrôle avec l’adresse NAT et les informations de port appropriées
Sur l’ACX500, pour que le FTP passif fonctionne correctement sans la passerelle de couche application (ALG) FTP activée (en ne spécifiant pas l’instruction application junos-ftp au niveau de la [edit services nat rule rule-name term term-name from] hiérarchie), vous devez activer la fonctionnalité de regroupement d’adresses jumelées (APP) activée (en incluant l’instruction address-pooling au niveau de la [edit services nat rule rule-name term term-name then translated] hiérarchie). Une telle configuration fait que les sessions FTP de données et de contrôle reçoivent la même adresse NAT.
Voici un exemple de configuration de FTP ALG :
-
Création d’une interface NAT.
[edit] services { service-set set-ftp { nat-rules nat-ftp; interface-service { service-interface ms-0/2/0; } } -
Configuration d’un pool NAT.
[edit] services { nat { pool p-napt { address 10.30.30.0/24; port { range low 9000 high 9010; } } } -
Définition des règles NAT pour FTP ALG.
[edit] services { nat { rule nat-ftp { match-direction input; term term1 { from { source-address { 10.10.10.0/24; } applications junos-ftp; } then { translated { source-pool p-napt; translation-type { napt-44; } } } } } } -
Liaison d’ensembles de services à l’interface.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-ftp; } output { service-set set-ftp; } } address 10.10.10.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.10.10.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
L’ICMP
L’Internet Control Message Protocol (ICMP) est défini dans le document RFC 792. Junos OS permet de filtrer les messages ICMP par type spécifique ou par valeur de code de type spécifique. Les paquets d’erreur ICMP qui n’ont pas de type et de code spécifiquement configurés sont mis en correspondance avec tout flux existant dans la direction opposée pour vérifier la légitimité du paquet d’erreur. Les paquets d’erreur ICMP qui réussissent la correspondance de filtre sont sujets à la traduction NAT.
L’ALG ICMP suit toujours le trafic ping avec état à l’aide du numéro de séquence ICMP. Chaque réponse d’écho n’est transmise que s’il existe une demande d’écho portant le numéro de séquence correspondant. Pour tout flux ping, seules 20 demandes d’écho peuvent être transférées sans recevoir de réponse d’écho. Lorsque vous configurez le NAT dynamique, l’identificateur de paquet PING est traduit pour permettre à d’autres hôtes du pool NAT d’utiliser le même identifiant.
La prise en charge des services NAT nécessite que vous configuriez l’ALG ICMP si le protocole est nécessaire. Vous pouvez configurer le type et le code ICMP pour un filtrage supplémentaire.
TFTP
Le protocole TFTP (Trivial File Transfer Protocol) est spécifié dans la RFC 1350. Les requêtes TFTP initiales sont envoyées au port de destination UDP 69. Des flux supplémentaires peuvent être créés pour obtenir ou placer des fichiers individuels. La prise en charge des services NAT nécessite que vous configuriez l’ALG TFTP pour le port de destination UDP 69.
Voici un exemple de configuration de TFTP ALG :
-
Création d’une interface NAT.
[edit] services { service-set set-tftp { nat-rules nat-tftp; interface-service { service-interface ms-0/2/0; } } -
Configuration d’un pool NAT.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Définition des règles NAT pour TFTP ALG.
[edit] services { nat { rule nat-tftp { match-direction input; term term1 { from { source-address { 10.50.50.2/32; } applications junos-tftp; } then { translated { source-pool p-napt; translation-type { dynamic-nat44; } } } } } } -
Liaison d’ensembles de services à l’interface.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-tftp; } output { service-set set-tftp; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
UNIX Remote-Shell Services
Trois protocoles forment la base des services de shell distant UNIX :
-
Exécutif : exécution de commandes à distance ; permet à un utilisateur du système client d’exécuter une commande sur le système distant. La première commande du client (
rcmd) au serveur (rshd) utilise le port TCP 512 bien connu. Une deuxième connexion TCP peut être ouverte à la demande dercmd. Le numéro de port client de la deuxième connexion est envoyé au serveur sous forme de chaîne ASCII. -
Connexion—Mieux connu sous
rloginle nom de ; utilise le port TCP 513 bien connu. Pour plus de détails, voir RFC 1282. Aucun traitement spécial du pare-feu n’est requis. -
Shell : exécution de commandes à distance ; permet à un utilisateur du système client d’exécuter une commande sur le système distant. La première commande du client (
rcmd) au serveur (rshd) utilise le port TCP 514 bien connu. Une deuxième connexion TCP peut être ouverte à la demande dercmd. Le numéro de port client de la deuxième connexion est envoyé au serveur sous forme de chaîne ASCII.
Les services de shell distant NAT exigent que tout port source dynamique attribué soit compris entre 512 et 1023. Si vous configurez un pool NAT, cette plage de ports est réservée exclusivement aux applications shell distantes.
Voici un exemple de configuration de RSH ALG :
-
Création d’une interface NAT.
[edit] services { service-set set-rsh { nat-rules nat-rsh; interface-service { service-interface ms-0/2/0; } } -
Configuration d’un pool NAT.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Définition des règles NAT pour RSH ALG.
[edit] services { nat { rule nat-rsh { match-direction input; term term1 { from { source-address { 510.0.50.2/32; } applications junos-rsh; } then { translated { source-pool p-napt; translation-type { dynamic-nat44; } } } } } } -
Liaison d’ensembles de services à l’interface.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-rsh; } output { service-set set-rsh; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
Voir aussi
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
deterministic-napt64 pris en charge pour MS-MPC et MS-MIC
stateful-nat464
twice-dynamic-nat-44 pris en charge pour MS-MPC et MS-MIC
twice-basic-nat-44 pris en charge pour le NAT en ligne
twice-dynamic-nat-44 pris en charge pour MS-MPC et MS-MIC
twice-dynamic-napt-44 pris en charge pour MS-MPC et MS-MIC
deterministic-napt44 pris en charge pour MS-MPC et MS-MIC