Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Actions de terminaison du filtre de pare-feu

Les filtres de pare-feu prennent en charge un ensemble d’actions de terminaison pour chaque famille de protocoles. Une action de terminaison de filtre stoppe toute évaluation d’un filtre de pare-feu pour un paquet spécifique. Le routeur exécute l’action spécifiée et aucune autre conditions n’est examinée.

Remarque :

Vous ne pouvez pas configurer l’action next term avec une action de terminaison dans le même terme de filtre. Toutefois, vous pouvez configurer l’action next term avec une autre action non déterminante dans le même terme de filtre.

Sur Junos OS Evolved, next term ne peut pas apparaître comme le dernier terme de l’action. Un terme de filtre où next term est spécifié comme action, mais sans conditions de correspondance configurées, n’est pas pris en charge.

Pour les routeurs MX Series avec MPC, vous devez initialiser le compteur de filtres pour les filtres de correspondance Trio uniquement en marchant sur la MIB SNMP correspondante, par exemple . show snmp mib walk name ascii Cela force Junos à connaître les compteurs de filtres et à s’assurer que les statistiques des filtres sont affichées. Ce guide s’applique à tous les filtres de pare-feu en mode amélioré, aux filtres avec des conditions flexibles et aux filtres avec certaines actions de terminaison. Pour plus de détails, consultez ces rubriques, répertoriées dans la documentation connexe.

Tableau 1 décrit les actions de terminaison que vous pouvez spécifier dans un terme de filtre de pare-feu.

Tableau 1 : Actions de terminaison pour les filtres de pare-feu

Action de clôture

Description

Protocoles

accept

Acceptez le paquet.

  • family any

  • family inet

  • family inet6

  • family mpls

  • family vpls

  • family ccc

  • family bridge

  • family ethernet-switching (pour les commutateurs EX Series uniquement)

decapsulate gre [ routing-instance instance-name ]

Sur une interface client d’un routeur MX Series installé à la périphérie du fournisseur (PE) d’un réseau de transport IPv4, permettre la déscapsulation des paquets GRE (Generic Routing Encapsulation) transportés par un tunnel GRE basé sur des filtres.

Vous pouvez configurer un terme de filtre qui associe cette action à une condition de correspondance qui inclut une correspondance d’en-tête de paquet pour le protocole GRE. Pour un filtre IPv4, indiquez la condition (ou protocol 47) de protocol gre correspondance. Fixez le filtre à l’entrée d’une interface logique Ethernet ou d’une interface Ethernet agrégée sur une carte d’interface modulaire (MIC) ou un concentrateur de ports modulaire (MPC) du routeur. Si vous validez une configuration qui attache un filtre de décapsulation à une interface qui ne prend pas en charge la tunnelisation GRE basée sur des filtres, le système écrit un message d’avertissement syslog indiquant que l’interface ne prend pas en charge le filtre.

Lorsque l’interface reçoit un paquet correspondant, les processus qui s’exécutent sur le moteur de transfert de paquets exécutent les opérations suivantes :

  • Retirez l’en-tête GRE externe.

  • Transfèrez le paquet de la charge utile interne vers sa destination d’origine en effectuant la recherche de destination.

Par défaut, le moteur de transfert de paquets utilise l’instance de routage par défaut pour transférer les paquets de la charge utile vers le réseau de destination. Si la charge utile est MPLS, le moteur de transfert de paquets effectue une recherche de route sur la table de routage de chemin MPLS à l’aide du label de route dans l’en-tête MPLS.

Si vous spécifiez l’action decapsulate avec un nom d’instance de routage facultatif, le moteur de transfert de paquets effectue une recherche de route sur l’instance de routage et l’instance doit être configurée.

Remarque :

Sur les routeurs MX960, l’action decapsulate décapsule les paquets de tunnelisation GRE, IP-in-IP et IPv6-in-IP. Vous configurez cette action au niveau de la [edit firewall family inet filter filter-name term term-name] hiérarchie .

Pour plus d’informations, voir Comprendre la tunnelisation basée sur des filtres sur les réseaux IPv4 et Composants de la tunnelisation basée sur des filtres sur les réseaux IPv4.

  • family inet

decapsulate l2tp [ routing-instance instance-name ] [ forwarding-class class-name ] [ output-interface interface-name ] [ cookie l2tpv3-cookie ] [ sample ]

Sur une interface client d’un routeur MX Series installé à la périphérie du fournisseur (PE) d’un réseau de transport IPv4, permettre la déscapsulation des paquets L2TP (Layer 2 Tunneling Protocol) transportés par un tunnel L2TP basé sur des filtres.

Vous pouvez configurer un terme de filtre qui associe cette action à une condition de correspondance qui inclut une correspondance d’en-tête de paquet pour le protocole L2TP. Pour le trafic IPv4, un filtre $junos-input-filter de pare-feu d’entrée et un filtre $junos-output-filter de pare-feu de sortie sont joints à l’interface. Fixez le filtre à l’entrée d’une interface logique Ethernet ou d’une interface Ethernet agrégée sur une carte d’interface modulaire (MIC) ou un concentrateur de ports modulaire (MPC) du routeur. Si vous validez une configuration qui attache un filtre de décapsulation à une interface qui ne prend pas en charge la tunnelisation L2TP basée sur des filtres, le système écrit un message d’avertissement syslog indiquant que l’interface ne prend pas en charge le filtre.

Le point de terminaison du tunnel distant envoie un paquet de tunnel IP contenant une adresse MAC Ethernet dans la charge utile. Si l’adresse MAC de destination du paquet de charge utile contient l’adresse MAC du routeur, le paquet Ethernet est envoyé dans la direction sortante vers le réseau et il est traité et transféré comme s’il était reçu sur le port client. Si l’adresse MAC source du paquet de charge utile contient l’adresse MAC du routeur, le paquet Ethernet est transmis dans la direction sortante vers le port client. Si le tunnel ne contient pas le cookie de réception configuré, il n’y a pas d’injection de paquets. Dans ce cas, tout paquet tunnel reçu est compté et abandonné de la même manière que les paquets qui arrivent avec un cookie incorrect sont comptés et abandonnés.

Les paramètres suivants peuvent être spécifiés avec l’action decapsulate l2tp :

  • routing-instance instance-name— Par défaut, le moteur de transfert de paquets utilise l’instance de routage par défaut pour transférer les paquets de la charge utile vers le réseau de destination. Si la charge utile est MPLS, le moteur de transfert de paquets effectue une recherche de route sur la table de routage de chemin MPLS à l’aide du label de route dans l’en-tête MPLS. Si vous spécifiez l’action decapsulate avec un nom d’instance de routage facultatif, le moteur de transfert de paquets effectue une recherche de route sur l’instance de routage et l’instance doit être configurée.

  • forwarding-class class-name—(Facultatif) Classez les paquets L2TP dans la classe de transfert spécifiée.

  • output-interface interface-name—(Facultatif) Pour les tunnels L2TP, activez le doublon du paquet et l’envoyer vers le client ou le réseau (en fonction de l’adresse MAC de la charge utile Ethernet).

  • cookie l2tpv3-cookie—(Facultatif) Pour les tunnels L2TP, spécifiez le cookie L2TP pour les paquets dupliqués. Si le tunnel ne contient pas le cookie de réception configuré, il n’y a pas d’injection de paquets. Dans ce cas, tout paquet tunnel reçu est compté et abandonné de la même manière que les paquets qui arrivent avec un cookie incorrect sont comptés et abandonnés.

  • sample—(Facultatif) Exemple de paquet. Junos OS n’échantillonise pas les paquets provenant du routeur. Si vous configurez un filtre et l’appliquez au côté sortie d’une interface, seuls les paquets de transit transitant par cette interface sont échantillonnés. Les paquets envoyés par le moteur de routage au moteur de transfert de paquets ne sont pas échantillonnés.

Remarque :

L’action decapsulate l2tp que vous configurez au niveau de la hiérarchie ne traite pas le [edit firewall family inet filter filter-name term term-name] trafic avec les options IPv4 et IPv6. En conséquence, le trafic avec de telles options est éliminé par la fonctionnalité de dés encapsulation des paquets L2TP.

family inet

discard

Rejetez un paquet en silence, sans envoyer de message ICMP (Internet Control Message Protocol). Les paquets jetés sont disponibles pour la journalisation et l’échantillonnage.

  • family any

  • family inet

  • family inet6

  • family mpls

  • family vpls

  • family ccc

  • family bridge

  • family ethernet-switching (pour les commutateurs EX Series uniquement)

encapsulate template-name

Sur une interface client d’un routeur MX Series installé à la périphérie du fournisseur (PE) d’un réseau de transport IPv4, activez la tunnelisation GRE (Generic Routing Encapsulation) basée sur des filtres à l’aide du modèle de tunnel spécifié.

Vous pouvez configurer un terme de filtre qui associe cette action aux conditions de correspondance appropriées, puis joindre le filtre à l’entrée d’une interface logique Ethernet ou d’une interface Ethernet agrégée sur une carte d’interface modulaire (MIC) ou un concentrateur de ports modulaire (MPC) du routeur. Si vous validez une configuration qui attache un filtre d’encapsulation à une interface qui ne prend pas en charge la tunnelisation GRE basée sur des filtres, le système écrit un message d’avertissement syslog indiquant que l’interface ne prend pas en charge le filtre.

Lorsque l’interface reçoit un paquet correspondant, les processus qui s’exécutent sur le moteur de transfert de paquets utilisent les informations du modèle de tunnel spécifié pour effectuer les opérations suivantes :

  1. Joindre un en-tête GRE (avec ou sans valeur de clé de tunnel, comme spécifié dans le modèle de tunnel.

  2. Joindre un en-tête pour le protocole de transport IPv4.

  3. Transfèrez le paquet GRE résultant de l’interface source du tunnel vers la destination du tunnel (le routeur PE distant).

Le modèle de tunnel spécifié doit être configuré à l’aide de l’instruction tunnel-end-point au niveau de la [edit firewall] hiérarchie.[edit logical-systems logical-system-name firewall] Pour plus d’informations, reportez-vous à Comprendre la tunnelisation basée sur des filtres sur les réseaux IPv4.

  • family inet

  • family inet6

  • family any

  • family mpls

encapsulate template-name (pour les tunnels L2TP)

Sur une interface client d’un routeur MX Series installé à la périphérie du fournisseur (PE) d’un réseau de transport IPv4, activez la tunnelisation L2TP basée sur des filtres à l’aide du modèle de tunnel spécifié. Vous pouvez configurer un terme de filtre qui associe cette action aux conditions de correspondance appropriées, puis joindre le filtre à l’entrée d’une interface logique Ethernet ou d’une interface Ethernet agrégée sur une carte d’interface modulaire (MIC) ou un concentrateur de ports modulaire (MPC) du routeur. Si vous validez une configuration qui attache un filtre d’encapsulation à une interface qui ne prend pas en charge la tunnelisation GRE basée sur des filtres, le système écrit un message d’avertissement syslog indiquant que l’interface ne prend pas en charge le filtre. Lorsque l’interface reçoit un paquet correspondant, les processus qui s’exécutent sur le moteur de transfert de paquets utilisent les informations du modèle de tunnel spécifié pour effectuer les opérations suivantes :

  1. Fixez un en-tête L2TP (avec ou sans valeur de clé de tunnel, comme spécifié dans le modèle de tunnel).

  2. Joindre un en-tête pour le protocole de transport IPv4.

  3. Transfèrez le paquet L2TP résultant de l’interface source du tunnel vers la destination du tunnel (le routeur PE distant). Le modèle de tunnel spécifié doit être configuré à l’aide de l’instruction tunnel-end-point sous la hiérarchie de l’instruction[edit firewall].[edit logical-systems logical-system-name firewall]

  • family inet

exclude-accounting

Exclut l’inclusion du paquet dans les statistiques de comptabilisation précises pour les abonnés tunnelés sur un LAC L2TP. Généralement utilisés dans les filtres qui correspondent au trafic de contrôle DHCPv6 ou ICMPv6 L’exclusion de ces paquets entraîne un mécanisme de détection du délai d’inactivité qui considère ces paquets comme du trafic de données, ce qui entraîne l’expiration du délai d’expiration. (Le délai d’inactivité est configuré avec les instructions et client-idle-timeout-ingress-only les client-idle-timeout instructions des options de session de profil d’accès.)

Le terme exclut l’inclusion des paquets dans le compte pour la comptabilisation précise de la famille et pour la comptabilisation précise des services. Les paquets sont toujours inclus dans les statistiques de l’interface de session.

Le terme est disponible pour les deux inet familles inet6 , mais n’est utilisé que pour inet6.

  • family inet

  • family inet6

logical-system logical-system-name

Dirigez le paquet vers le système logique spécifié.

Remarque :

Cette action n’est pas prise en charge sur les routeurs de transport de paquets PTX Series.

  • family inet

  • family inet6

reject message-type

Rejetez le paquet et renvoyez un message ICMPv4 ou ICMPv6 :

  • Si aucun message n’est message-type spécifié, un destination unreachable message est renvoyé par défaut.

  • Si tcp-reset le paquet est spécifié comme le message-type, tcp-reset n’est renvoyé que si le paquet est un paquet TCP. Sinon, le administratively-prohibited message, qui a une valeur de 13, est renvoyé.

  • Si un autre message-type message est spécifié, ce message est renvoyé.

Remarque :

Les paquets rejetés peuvent être échantillonnés ou enregistrés si vous configurez l’actionsample.syslog Pour le MX2K-MPC11E, ICMP rejette les messages transitant par les filtres de sortie, les mécanismes de contrôle et les configurations de classe de service (CoS). Ces statistiques sont donc incluses. Il en va de même pour les destination unreachable messages.

Il message-type peut s’agir de l’une des valeurs suivantes : address-unreachable, administratively-prohibited, bad-host-tos, bad-network-tos, beyond-scope, fragmentation-neededhost-prohibited, host-unknown, network-prohibitednetwork-unknownno-routeprecedence-cutoffport-unreachableprecedence-violationprotocol-unreachablenetwork-unreachablehost-unreachable, , source-host-isolated, source-route-failedou .tcp-reset

Sur les routeurs PTX1000, l’action de rejet est prise en charge uniquement sur les interfaces entrantes.

  • family inet

  • family inet6

routing-instance instance-name

Dirigez le paquet vers l’instance de routage spécifiée.

  • family inet

  • family inet6

topology topology-name

Dirigez le paquet vers la topologie spécifiée.

Remarque :

Cette action n’est pas prise en charge sur les routeurs de transport de paquets PTX Series.

Chaque instance de routage (principale ou routeur virtuel) prend en charge une topologie par défaut à laquelle toutes les classes de transfert sont transférées. Pour le routage multitopologique, vous pouvez configurer un filtre de pare-feu sur l’interface d’entrée pour qu’il corresponde à une classe de transfert spécifique, telle que le transfert accéléré, avec une topologie spécifique. Le trafic correspondant à la classe de transfert spécifiée est ensuite ajouté à la table de routage pour cette topologie.

  • family inet

  • family inet6