NAT64 dynamique
Configuration de NAT64 dynamique
Pour configurer NAT64 dynamique, vous devez configurer une règle au niveau de la [edit services nat] hiérarchie pour traduire dynamiquement l’adresse source et l’adresse de destination de manière statique.
Lorsque vous configurez l’ensemble de services qui inclut votre règle NAT, incluez le set stateful-nat64 clear-dont-fragment-bit au niveau de la [edit services service-set service-set-name] hiérarchie. Cela efface le bit DF (ne pas fragmenter) afin d'éviter la création inutile d'un en-tête de fragmentation IPv6 lors de la traduction de paquets IPv4 de moins de 1280 octets. La RFC 6145, Algorithme de traduction IP/ICMP, fournit une discussion complète sur l’utilisation de l’indicateur DF pour contrôler la génération d’en-têtes de fragmentation. Pour plus d’informations sur les ensembles de services pour le NAT, consultez Configuration des ensembles de services pour la traduction d’adresses réseau.
Pour configurer NAT64 dynamique :
L’exemple suivant configure la traduction d’adresses sources dynamiques (IPv6 vers IPv4) et d’adresses de destination statiques (IPv6 vers IPv4).
[edit services]
user@host# show
nat {
pool src-pool-nat64 {
address 203.0.113.0/24;
port {
automatic;
}
}
rule stateful-nat64 {
match-direction input;
term t1 {
from {
source-address {
2001:db8::0/96;
}
destination-address {
64:ff9b::/96;
}
}
then {
translated {
source-pool src-pool-nat64;
destination-prefix 64:ff9b::/96;
translation-type {
stateful-nat64;
}
}
}
}
}
}
service-set sset-nat64 {
nat-options {
stateful-nat64 {
clear-dont-fragment-bit;
}
}
service-set-options;
nat-rules stateful-nat64;
interface-service {
service-interface ms-0/1/0;
}
}
Si vous configurez deux règles NAT64 et que vous les associez au même ensemble de services, ainsi qu’à des règles de pare-feu dynamiques, et que vous appliquez l’ensemble de services sur deux interfaces balisées VLAN, pour le trafic transmis correspondant aux deux règles NAT, le trafic destiné à la deuxième règle NAT est abandonné. Dans un tel scénario, les flux de trafic ne sont pas abandonnés sur le moteur de routage. Ce comportement d’abandon du trafic par la deuxième règle NAT est attendu. Lorsque les packages Extension-Provider de Junos OS sont installés sur un équipement, car le mappage indépendant des points de terminaison (EIM) n’est pas pris en charge, EIM par VLAN ou par terme de règle NAT. La deuxième session, qui est abandonnée par la deuxième règle NAT dans le scénario de configuration décrit ici, n’est pas créée en raison de la séquence d’événements suivante :
Le premier paquet correspondant à l’une ou l’autre règle crée un EIM et une session.
Le deuxième paquet correspond à l’entrée EIM, car le deuxième paquet est envoyé avec la même adresse IP source et le même port que le premier paquet (mais avec une adresse de destination différente).
Cette condition entraîne l’attribution (réutilisation) de la même adresse IP publique et du même port au deuxième paquet que le premier paquet. Le flux inverse de cette session a les mêmes données à 5 uplets que le flux inverse de la première session. Ce comportement entraîne l’échec de l’ajout de flux, car un flux dupliqué dans le même ensemble de services n’est pas autorisé.
Pour contourner ce problème, désactivez EIM dans les deux règles NAT, ce qui permet d’établir et de traiter correctement les sessions. Pour éviter ce problème, spécifiez également les règles NAT sur différents ensembles de services configurés sur différentes unités de l’interface multimédia avec EIM activé pour établir correctement les deux sessions.
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.
sequential option est introduite pour vous permettre de configurer l’allocation séquentielle des ports.