Estado NAT64
Configuración de NAT64 con estado
Para configurar NAT64 con estado, debe configurar una regla en el nivel de [edit services nat] jerarquía para traducir la dirección de origen de forma dinámica y la dirección de destino de forma estática.
Cuando configure el conjunto de servicios que incluye su regla TDR, incluya el set stateful-nat64 clear-dont-fragment-bit [edit services service-set service-set-name] nivel de jerarquía. Esto borra el bit DF (no fragmentar) para evitar la creación innecesaria de un encabezado de fragmentación IPv6 al traducir paquetes IPv4 de menos de 1280 bytes. RFC 6145, Algoritmo de traducción de IP/ICMP, proporciona una discusión completa del uso del indicador DF para controlar la generación de encabezados de fragmentación. Para obtener más información acerca de los conjuntos de servicios para TDR, consulte Configurar conjuntos de servicios para la traducción de direcciones de red.
Para configurar NAT64 con estado:
En el siguiente ejemplo, se configura la traducción de direcciones de origen dinámicas (IPv6 a IPv4) y direcciones de destino estáticas (IPv6 a 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 configura dos reglas NAT64 y las asocia con el mismo conjunto de servicios, junto con reglas de firewall con estado, y aplica el conjunto de servicios en dos interfaces etiquetadas por VLAN, para el tráfico que se transmite que coincide con ambas reglas TDR, se descarta el tráfico destinado a la segunda regla TDR. En tal caso, los flujos de tráfico no se descartan en el motor de enrutamiento. Este comportamiento de caída de tráfico por la segunda regla TDR es esperado. Con paquetes de proveedor de extensiones de Junos OS instalados en un dispositivo, dado que no se admite la asignación independiente del punto de conexión (EIM), EIM por VLAN o por término de regla TDR. La segunda sesión, que se interrumpe por la segunda regla TDR en el escenario de configuración descrito aquí, no se crea debido a la siguiente secuencia de eventos:
El primer paquete que coincida con cualquiera de las reglas crea un EIM y una sesión.
El segundo paquete coincide con la entrada EIM porque el segundo paquete se envía con la misma dirección IP y puerto de origen que el primer paquete (pero con una dirección de destino diferente).
Esta condición provoca la asignación (reutilización) del mismo puerto y dirección IP pública al segundo paquete que al primer paquete. El flujo inverso de esta sesión tiene los mismos datos de 5 tuplas que el flujo inverso de la primera sesión. Este comportamiento provoca un error de adición de flujo porque no se permite un flujo duplicado en el mismo conjunto de servicios.
Para solucionar este problema, desactive EIM en ambas reglas de TDR, lo que hará que ambas sesiones se establezcan y procesen correctamente. Como alternativa, para evitar este problema, especifique las reglas de TDR en diferentes conjuntos de servicios configurados en distintas unidades de la interfaz de medios con EIM habilitado para establecer correctamente ambas sesiones.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.
sequential asignación secuencial de puertos.