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 d’arrêt de filtre interrompt toute évaluation d’un filtre de pare-feu pour un paquet spécifique. Le routeur effectue l’action spécifiée et aucun terme supplémentaire n’est examiné.

REMARQUE :

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

Sur Junos OS et 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é en tant qu’action mais sans aucune condition de correspondance configurée 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 parcourant la MIB SNMP correspondante, par exemple, show snmp mib walk name ascii. Cela oblige Junos à apprendre les compteurs de filtres et à s’assurer que les statistiques des filtres sont affichées. Ces instructions s’appliquent à 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 sous Documentation associée.

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

Tableau 1 : Mesures d’arrêt des filtres de pare-feu
Arrêt de l’action	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 ]`	Au niveau d’une interface client sur un routeur MX Series installé à la périphérie fournisseur (PE) d’un réseau de transport IPv4, activez la désencapsulation des paquets GRE (Generic Routing Encapsulation) transportés via un tunnel GRE basé sur un filtre. 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, incluez la `protocol gre` condition de correspondance (ou `protocol 47`). Connectez 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 port modulaire (MPC) du routeur. Si vous validez une configuration qui attache un filtre de désencapsulation à une interface qui ne prend pas en charge le tunneling GRE basé sur les 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 effectuent les opérations suivantes : Retirez l’en-tête GRE externe. Transférez le paquet de charge utile interne vers sa destination d’origine en effectuant une 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 charge utile vers le réseau de destination. Si la charge utile est MPLS, le moteur de transfert de paquets effectue la recherche de route sur la table de routage de chemin MPLS à l’aide de l’étiquette de route dans l’en-tête MPLS. Si vous spécifiez l’action avec un nom d’instance de routage facultatif, le moteur de transfert de paquets effectue la recherche de route sur l’instance de routage et l’instance `decapsulate` doit être configurée. REMARQUE : Sur les routeurs MX960, cette `decapsulate` action permet de désencapsuler 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, reportez-vous aux sections Comprendre la tunnelisation basée sur les filtres sur les réseaux IPv4 et Composants de la tunnelisation basée sur les 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 ]`	Au niveau d’une interface client sur un routeur MX Series installé à la périphérie fournisseur (PE) d’un réseau de transport IPv4, activez la désencapsulation des paquets L2TP (L2TP L2) de couche 2 acheminés via un tunnel L2TP basé sur un filtre. 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 de pare-feu d’entrée et un filtre `$junos-input-filter$junos-output-filter` de pare-feu de sortie sont attachés à l’interface. Connectez 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 port modulaire (MPC) du routeur. Si vous validez une configuration qui attache un filtre de désencapsulation à une interface qui ne prend pas en charge le tunneling L2TP basé sur les 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 le sens sortant 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 le sens sortant vers le port client. Si le tunnel ne contient pas le cookie de réception configuré, l’injection de paquets ne se produit pas. Dans ce cas, tout paquet de tunnel reçu est compté et abandonné de la même manière que les paquets arrivant avec un cookie erroné 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 charge utile vers le réseau de destination. Si la charge utile est MPLS, le moteur de transfert de paquets effectue la recherche de route sur la table de routage de chemin MPLS à l’aide de l’étiquette de route dans l’en-tête MPLS. Si vous spécifiez l’action avec un nom d’instance de routage facultatif, le moteur de transfert de paquets effectue la recherche de route sur l’instance de routage et l’instance `decapsulate` doit être configurée. `forwarding-class class-name`—(Facultatif) Classer les paquets l2TP dans la classe de transfert spécifiée. `output-interface interface-name`—(Facultatif) Pour les tunnels L2TP, activez la duplication du paquet et l’envoi vers le client ou le réseau (en fonction de l’adresse MAC dans 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é, l’injection de paquets ne se produit pas. Dans ce cas, tout paquet de tunnel reçu est compté et abandonné de la même manière que les paquets arrivant avec un cookie erroné sont comptés et abandonnés. `sample`—(Facultatif) Échantillonnez le paquet. Junos OS néchantillonne pas les paquets provenant du routeur. Si vous configurez un filtre et que vous l’appliquez au côté sortie d’une interface, seuls les paquets de transit passant par cette interface sont échantillonnés. Les paquets envoyés du 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 trafic avec les `[edit firewall family inet filter filter-name term term-name]` options IPv4 et IPv6. Par conséquent, le trafic avec de telles options est écarté par la désencapsulation de la fonctionnalité de paquets L2TP.	`family inet`
`discard`	Rejeter un paquet en mode silencieux, sans envoyer de message ICMP (Internet Control Message Protocol). Les paquets mis au rebut sont disponibles pour l’enregistrement 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`	Au niveau d’une interface client sur un routeur MX Series installé à la périphérie fournisseur (PE) d’un réseau de transport IPv4, activez la tunnelisation GRE (Generic Routing Encapsulation) basée sur un filtre à 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 attacher 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 port modulaire (MPC) dans le routeur. Si vous validez une configuration qui attache un filtre d’encapsulation à une interface qui ne prend pas en charge le tunneling GRE basé sur les 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 : Attachez un en-tête GRE (avec ou sans valeur de clé de tunnel, comme spécifié dans le modèle de tunnel. Attachez un en-tête pour le protocole de transport IPv4. 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` sous le niveau hiérarchique `[edit firewall]` ou `[edit logical-systems logical-system-name firewall]` . Pour plus d’informations, reportez-vous à la section Comprendre la tunnelisation basée sur les filtres sur les réseaux IPv4.	`family inet` `family inet6` `family any` `family mpls`
`encapsulate template-name` (pour les tunnels L2TP)	Au niveau d’une interface client sur un routeur MX Series installé à la périphérie fournisseur (PE) d’un réseau de transport IPv4, activez la tunnelisation L2TP basée sur le filtre à 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 attacher 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 port modulaire (MPC) dans le routeur. Si vous validez une configuration qui attache un filtre d’encapsulation à une interface qui ne prend pas en charge le tunneling GRE basé sur les 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 : Attachez un en-tête L2TP (avec ou sans valeur de clé de tunnel, comme spécifié dans le modèle de tunnel). Attachez un en-tête pour le protocole de transport IPv4. 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 sous la hiérarchie d’instructions `tunnel-end-point[edit firewall]` ou `[edit logical-systems logical-system-name firewall]` .	`family inet`
`exclude-accounting`	Exclure le paquet de l’inclusion dans les statistiques comptables précises pour les abonnés tunnelisés sur un LAC L2TP. Généralement utilisé dans les filtres qui correspondent au trafic de contrôle DHCPv6 ou ICMPv6 Si ces paquets ne sont pas exclus, le mécanisme de détection du délai d’inactivité les considère comme du trafic de données, ce qui fait que le délai d’expiration n’expire jamais. (Le délai d’inactivité est configuré à l’aide des instructions et `client-idle-timeout-ingress-only` dans les options de session du profil d’accès`client-idle-timeout`.) Le terme exclut les paquets d’être inclus dans les dénombrements à la fois pour la comptabilité précise de la famille et la comptabilité exacte du service. Les paquets sont toujours inclus dans les statistiques de l’interface de session. Le terme est disponible pour les `inet` familles et `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 PTX Series Routeurs de transport de paquets.	`family inet` `family inet6`
`reject message-type`	Rejeter le paquet et renvoyer un message ICMPv4 ou ICMPv6 : Si no `message-type` est spécifié, un `destination unreachable` message est renvoyé par défaut. Si `tcp-reset` est spécifié comme , n’est `message-typetcp-reset` renvoyé que si le paquet est un paquet TCP. Dans le cas contraire, le `administratively-prohibited` message, qui a la valeur 13, est renvoyé. Si un autre `message-type` est spécifié, ce message est retourné. REMARQUE : Les paquets rejetés peuvent être échantillonnés ou consignés si vous configurez l’action `sample` ou `syslog` . Pour le MX2K-MPC11E, les messages de rejet ICMP traversent les filtres de sortie, les mécanismes de contrôle et les configurations de classe de service (CoS) et sont donc inclus dans ces statistiques. Il en va de même pour `destination unreachable` les messages. Il `message-type` peut s’agir de l’une des valeurs suivantes : `address-unreachable`, , `administratively-prohibitedbad-host-tosbad-network-tosbeyond-scopefragmentation-neededhost-prohibitedhost-unknownhost-unreachablenetwork-prohibitednetwork-unknownnetwork-unreachableno-routeport-unreachableprecedence-cutoffprecedence-violationprotocol-unreachablesource-host-isolatedsource-route-failedtcp-reset` Sur les routeurs PTX1000, l’action de rejet n’est prise en charge que 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 PTX Series Routeurs de transport de paquets. Chaque instance de routage (principale ou virtuelle) prend en charge une topologie par défaut vers 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é, à une topologie spécifique. Le trafic qui correspond à la classe de transfert spécifiée est ensuite ajouté à la table de routage de cette topologie.	`family inet` `family inet6`

REMARQUE :

Sur les modèles de commutateurs QFX5120-48Y et QFX5120-32C, configurez discard explicitement l’action pour mettre fin à une session BFD. Toutefois, notez que si une port-mirror action est configurée avant l’action discard , la session BFD ne sera pas arrêtée.

Actions de terminaison du filtre de pare-feu

Rubriques connexes