Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Applications de l’ALG

Configuration des propriétés de l’application

Pour configurer les propriétés de l’application, incluez l’instruction suivante application au niveau de la [edit applications] hiérarchie :

Vous pouvez regrouper des objets d’application en configurant l’instruction ; pour plus d’informations, reportez-vous à la application-set section Configuration des ensembles d’applications.

Cette section comprend les tâches suivantes pour configurer les applications :

Configuration d’un protocole d’application

L’instruction application-protocol vous permet de spécifier les protocoles d’application pris en charge (ALG) à configurer et à inclure dans un ensemble d’applications pour le traitement des services. Pour configurer les protocoles d’application, incluez l’instruction suivante application-protocol au niveau de la [edit applications application application-name] hiérarchie :

Le tableau 1 présente la liste des protocoles pris en charge. Pour plus d’informations sur des protocoles spécifiques, reportez-vous à la section Descriptions ALG.

Tableau 1 : protocoles d’application pris en charge par les interfaces de services

Nom du protocole

Valeur de l’interface de ligne de commande

Commentaires

Protocole d’amorçage (BOOTP)

bootp

Prend en charge BOOTP et DHCP (Dynamic Host Configuration Protocol).

Appel de procédure à distance (RPC) de l’environnement de calcul distribué (DCE)

dce-rpc

Nécessite que l’instruction protocol ait la valeur udp ou tcp. Nécessite une uuid valeur. Vous ne pouvez pas spécifier destination-port de valeurs ou source-port

Carte des ports RPC DCE

dce-rpc-portmap

Nécessite que l’instruction protocol ait la valeur udp ou tcp. Nécessite une destination-port valeur.

Système de noms de domaine (DNS)

dns

Nécessite que l’instruction protocol ait la valeur udp. Ce protocole d’application ferme le flux DNS dès réception de la réponse DNS.

Exec

exec

Exige que l’instruction protocol ait la valeur tcp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur.

FTP

ftp

Exige que l’instruction protocol ait la valeur tcp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur.

H.323

h323

IKE ALG

ike-esp-nat

Exige que l’instruction protocol ait la valeur udp et exige que la destination-port valeur soit 500.

Protocole ICMP (Internet Control Message Protocol)

icmp

Exige que l’instruction protocol ait la valeur icmp ou qu’elle ne soit pas spécifiée.

Protocole Inter-ORB Internet

iiop

IP

ip

Connectez-vous

login

Netbios

netbios

Exige que l’instruction protocol ait la valeur udp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur.

Le NetShow

netshow

Exige que l’instruction protocol ait la valeur tcp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur.

Protocole de tunnelisation point à point

pptp

RealAudio

realaudio

RTSP (Real-Time Streaming Protocol)

rtsp

Exige que l’instruction protocol ait la valeur tcp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur.

Protocole UDP (User Datagram Protocol) RPC ou TCP

rpc

Nécessite que l’instruction protocol ait la valeur udp ou tcp. Nécessite une rpc-program-number valeur. Vous ne pouvez pas spécifier destination-port de valeurs ou source-port

Mappage de ports RPC

rpc-portmap

Nécessite que l’instruction protocol ait la valeur udp ou tcp. Nécessite une destination-port valeur.

Coquille

shell

Exige que l’instruction protocol ait la valeur tcp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur.

Protocole d’initiation de session

sip

SNMP

snmp

Exige que l’instruction protocol ait la valeur udp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur.

SQLNet

sqlnet

Exige que l’instruction protocol ait la valeur tcp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur ou source-port .

Programme Talk

talk

Tracer l’itinéraire

traceroute

Exige que l’instruction protocol ait la valeur udp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur.

FTP trivial (TFTP)

tftp

Exige que l’instruction protocol ait la valeur udp ou qu’elle ne soit pas spécifiée. Nécessite une destination-port valeur.

WinFrame

winframe

Note:

Vous pouvez configurer des passerelles de niveau application (ALG) pour ICMP et tracer le routage sous des règles de pare-feu dynamique, NAT ou CoS lorsque NAT est configuré deux fois 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 Controller Protocol). Twice NAT ne prend pas en charge les autres ALG. Le NAT applique uniquement l’adresse IP et les en-têtes TCP ou UDP, mais pas la charge utile.

Pour plus d’informations sur la configuration de deux NAT, reportez-vous à la section Présentation de l’adressage réseau Junos Address Aware.

Configuration du protocole réseau

L’instruction protocol vous permet de spécifier le protocole réseau pris en charge à faire correspondre dans une définition d’application. Pour configurer des protocoles réseau, incluez l’instruction suivante protocol au niveau de la [edit applications application application-name] hiérarchie :

Vous spécifiez le type de protocole sous la forme d’une valeur numérique ; pour les protocoles les plus couramment utilisés, les noms de texte sont également pris en charge dans l’interface de ligne de commande (CLI). Le tableau 2 présente la liste des protocoles pris en charge.

Tableau 2 : protocoles réseau pris en charge par les interfaces de services

Type de protocole réseau

Valeur de l’interface de ligne de commande

Commentaires

En-tête d’authentification (AH) de sécurité IP (IPsec)

ah

Protocole de passerelle externe (EGP)

egp

ESP (Encapsulating Security Payload) IPsec

esp

Encapsulation de routage générique (GR)

gre

ICMP

icmp

Requiert une application-protocol valeur de icmp.

ICMPv6

icmp6

Requiert une application-protocol valeur de icmp.

Protocole IGMP (Internet Group Management Protocol)

igmp

IP dans IP

ipip

OSPF

ospf

PIM (Protocol Independent Multicast)

pim

Protocole de réservation de ressources (RSVP)

rsvp

TCP

tcp

Nécessite une destination-port valeur ou source-port sauf si vous spécifiez application-protocol rcp ou dce-rcp.

UDP

udp

Nécessite une destination-port valeur ou source-port sauf si vous spécifiez application-protocol rcp ou dce-rcp.

Pour obtenir la liste complète des valeurs numériques possibles, reportez-vous à la RFC 1700, Assigned Numbers (for the Internet Protocol Suite).

Note:

La version IP 6 (IPv6) n’est pas prise en charge en tant que protocole réseau dans les définitions d’applications.

Par défaut, la fonctionnalité deux fois NAT peut affecter les en-têtes IP, TCP et UDP intégrés dans la charge utile des messages d’erreur ICMP. Vous pouvez inclure les protocol tcp instructions et protocol udp avec l’instruction d’application pour les configurations deux fois NAT. Pour plus d’informations sur la configuration de deux NAT, reportez-vous à la section Présentation de l’adressage réseau Junos Address Aware.

Configuration du code et du type ICMP

Le code et le type ICMP fournissent des spécifications supplémentaires, en conjonction avec le protocole réseau, pour l’appariement des paquets dans une définition d’application. Pour configurer les paramètres ICMP, incluez les icmp-code instructions et icmp-type au niveau de la [edit applications application application-name] hiérarchie :

Vous ne pouvez inclure qu’un seul code ICMP et une seule valeur de type. L’instruction application-protocol doit avoir la valeur icmp. Le tableau 3 présente la liste des valeurs ICMP prises en charge.

Tableau 3 : codes et types ICMP pris en charge par les interfaces de services

Déclaration CLI

Description

icmp-code

Cette valeur ou mot-clé fournit des informations plus spécifiques que icmp-type. Étant donné que la signification de la valeur dépend de la valeur associée icmp-type , vous devez spécifier icmp-type avec icmp-code. Pour plus d’informations, reportez-vous au Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.

À la place de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les valeurs de champ sont également répertoriées). Les mots-clés sont regroupés par type ICMP auquel ils sont associés :

problème_paramètre : ip-header-bad (0), required-option-missing (1)

Redirection : redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-host (3), redirect-for-tos-and-net (2)

Temps dépassé : ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)

inaccessible : communication-prohibited-by-filtering (13), destination-host-prohibited (10), destination-host-unknown (7), destination-network-prohibited (9), destination-network-unknown (6), fragmentation-needed (4), host-precedence-violation (14), host-unreachable (1 host-unreachable-for-TOS ), (12), network-unreachable (0), network-unreachable-for-TOS (11), port-unreachable (3), precedence-cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8), source-route-failed (5)

icmp-type

Normalement, vous spécifiez cette correspondance en conjonction avec l’instruction protocol match pour déterminer quel protocole est utilisé sur le port. Pour plus d’informations, reportez-vous au Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.

À la place de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les valeurs de champ sont également répertoriées) : echo-reply (0), echo-request (8), info-reply (16), info-request (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5), router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11), timestamp (13), timestamp-reply (14) ou unreachable (3).

Note:

Si vous configurez une interface avec un filtre de pare-feu d’entrée qui inclut une action de rejet et avec un ensemble de services qui inclut des règles de pare-feu dynamiques, le routeur exécute le filtre de pare-feu d’entrée avant que les règles de pare-feu dynamiques ne soient exécutées sur le paquet. Par conséquent, lorsque le moteur de transfert de paquets envoie un message d’erreur ICMP via l’interface, les règles de pare-feu dynamiques peuvent abandonner le paquet, car il n’a pas été vu dans la direction d’entrée.

Les solutions de contournement possibles consistent à inclure un filtre de table de transfert pour effectuer l’action de rejet, car ce type de filtre est exécuté après le pare-feu dynamique dans le sens d’entrée, ou à inclure un filtre de service de sortie pour empêcher les paquets ICMP générés localement d’aller au service de pare-feu dynamique.

Configuration des ports source et de destination

Le port source et le port de destination TCP ou UDP fournissent des spécifications supplémentaires, en conjonction avec le protocole réseau, pour la correspondance des paquets dans une définition d’application. Pour configurer les ports, incluez les destination-port instructions et source-port au niveau de la [edit applications application application-name] hiérarchie :

Vous devez définir un port source ou de destination. Normalement, vous spécifiez cette correspondance en conjonction avec l’instruction protocol match pour déterminer quel protocole est utilisé sur le port ; pour les contraintes, reportez-vous au Tableau 1.

Vous pouvez spécifier une valeur numérique ou l’un des synonymes de texte répertoriés dans le Tableau 4.

Tableau 4 : noms de ports pris en charge par les interfaces de services

Nom du port

Numéro de port correspondant

afs

1483

bgp

179

biff

512

bootpc

68

bootps

67

cmd

514

cvspserver

2401

dhcp

67

domain

53

eklogin

2105

ekshell

2106

exec

512

finger

79

ftp

21

ftp-data

20

http

80

https

443

ident

113

imap

143

kerberos-sec

88

klogin

543

kpasswd

761

krb-prop

754

krbupdate

760

kshell

544

ldap

389

login

513

mobileip-agent

434

mobilip-mn

435

msdp

639

netbios-dgm

138

netbios-ns

137

netbios-ssn

139

nfsd

2049

nntp

119

ntalk

518

ntp

123

pop3

110

pptp

1723

printer

515

radacct

1813

radius

1812

rip

520

rkinit

2108

smtp

25

snmp

161

snmptrap

162

snpp

444

socks

1080

ssh

22

sunrpc

111

syslog

514

tacacs-ds

65

talk

517

telnet

23

tftp

69

timed

525

who

513

xdmcp

177

zephyr-clt

2103

zephyr-hm

2104

Pour plus d’informations sur les critères de correspondance, reportez-vous au Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.

Configuration du délai d’inactivité

Vous pouvez spécifier un délai d’expiration pour l’inactivité de l’application. Si le logiciel n’a détecté aucune activité pendant la durée, le flux devient invalide à l’expiration du minuteur. Pour configurer un délai d’expiration, incluez l’instruction inactivity-timeout au niveau de la [edit applications application application-name] hiérarchie :

La valeur par défaut est de 30 secondes. La valeur que vous configurez pour une application remplace toute valeur globale configurée au niveau de la hiérarchie ; pour plus d’informations, reportez-vous à la section Configuration des paramètres de délai d’expiration par défaut pour les [edit interfaces interface-name service-options] interfaces de services.

Configuration d’une application IKE ALG

Avant la version 17.4R1 de Junos OS, la traversée d’adresses réseau (NAT-T) n’était pas prise en charge pour la suite de fonctionnalités IPsec Junos VPN Site Secure sur les routeurs MX Series. L’IKE ALG permet de faire passer des paquets IKEv1 et IPsec à travers les filtres NAPT-44 et NAT64 entre des homologues IPsec qui ne sont pas conformes à NAT-T. Cet ALG ne prend en charge que le mode tunnel ESP. Vous pouvez utiliser l’application junos-ikeIKE ALG prédéfinie , qui comporte des valeurs prédéfinies pour le port de destination (500), le délai d’inactivité (30 secondes), le délai d’expiration de la porte (120 secondes) et le délai d’inactivité de la session ESP (800 secondes). Si vous souhaitez utiliser l’IKE ALG avec des valeurs différentes de l’application prédéfinie junos-ike , vous devez configurer une nouvelle application IKE ALG.

Pour configurer une application IKE ALG :

  1. Spécifiez un nom pour l’application.

  2. Spécifiez l’IKE ALG.

  3. Spécifiez le protocole UDP.

  4. Spécifiez 500 pour le port de destination.

  5. Spécifiez le nombre de secondes pendant lesquelles la session IKE est inactive avant d’être supprimée. La valeur par défaut est de 30 secondes.

  6. Spécifiez le nombre de secondes qui peuvent s’écouler après que IKE a établi l’association de sécurité entre le client IPsec et le serveur et avant que le trafic ESP ne démarre dans les deux sens. Si le trafic ESP n’a pas démarré avant cette valeur de délai d’expiration, les portes ESP sont supprimées et le trafic ESP est bloqué. La valeur par défaut est de 120 secondes.

  7. Spécifiez le délai d’inactivité de la session ESP (trafic de données IPsec) en secondes. Si aucun trafic de données IPsec n’est transmis sur la session ESP pendant ce laps de temps, la session est supprimée. La valeur par défaut est de 800 secondes.

Configuration de SIP

Le protocole SIP (Session Initiation Protocol) est un protocole généralisé de communication entre les terminaux impliqués dans les services Internet tels que la téléphonie, le fax, la visioconférence, la messagerie instantanée et l’échange de fichiers.

Junos OS fournit des services ALG conformément à la norme décrite dans la norme RFC 3261, SIP : Session Initiation Protocol. Les flux SIP sous Junos OS sont décrits dans la RFC 3665, Exemples de flux d’appels de base SIP (Session Initiation Protocol).

Note:

Avant d’implémenter Junos OS SIP ALG, vous devez connaître certaines limitations, décrites dans la section Limitations de Junos OS SIP ALG

L’utilisation de NAT en conjonction avec l’ALG SIP entraîne des modifications dans les champs d’en-tête SIP en raison de la traduction de l’adresse. Pour plus d’informations sur ces traductions, reportez-vous à SIP ALG Interaction with Network Address Translation.

Pour implémenter SIP sur les interfaces de services adaptatifs, vous configurez l’instruction application-protocol au niveau de la [edit applications application application-name] hiérarchie avec la valeur sip. Pour plus d’informations sur cette instruction, reportez-vous à la section Configuration d’un protocole d’application. En outre, il existe deux autres instructions que vous pouvez configurer pour modifier la façon dont SIP est implémenté :

  • Vous pouvez activer le routeur pour qu’il accepte tous les appels SIP entrants pour les terminaux qui se trouvent derrière le pare-feu NAT. Lorsqu’un périphérique derrière le pare-feu s’enregistre auprès du proxy qui se trouve à l’extérieur du pare-feu, le PIC AS ou multiservices conserve l’état d’enregistrement. Lorsque l’instruction learn-sip-register est activée, le routeur peut utiliser ces informations pour accepter les appels entrants. Si cette instruction n’est pas configurée, aucun appel entrant n’est accepté ; Seuls les appareils situés derrière le pare-feu peuvent appeler des appareils situés à l’extérieur du pare-feu.

    Pour configurer l’enregistrement SIP, incluez l’instruction suivante learn-sip-register au niveau de la [edit applications application application-name] hiérarchie :

    Note:

    Cette learn-sip-register déclaration ne s’applique pas au MX-SPC3 de services de nouvelle génération.

    Vous pouvez également inspecter manuellement le registre SIP en exécutant la show services stateful-firewall sip-register commande. Pour plus d’informations, reportez-vous au Guide de référence des commandes Junos OS System Basics and Services. La show services stateful-firewall sip-register commande n’est pas prise en charge pour les services de nouvelle génération.

  • Vous pouvez spécifier un délai d’expiration pour la durée des appels SIP mis en attente. Lorsqu’un appel est mis en attente, il n’y a aucune activité et les flux peuvent expirer après l’expiration de la période configurée inactivity-timeout , ce qui entraîne une suppression de l’état de l’appel. Pour éviter cela, lorsqu’un appel est mis en attente, le minuteur de flux est réinitialisé au sip-call-hold-timeout cycle pour préserver l’état et les flux d’appel plus longtemps que la inactivity-timeout période.

    Note:

    Cette sip-call-hold-timeout déclaration ne s’applique pas au MX-SPC3 de services de nouvelle génération.

    Pour configurer un délai d’expiration, incluez l’instruction sip-call-hold-timeout au niveau de la [edit applications application application-name] hiérarchie :

    La valeur par défaut est de 7200 secondes et la plage est comprise entre 0 et 36 000 secondes (10 heures).

Interaction SIP ALG avec la traduction d’adresses réseau

Le protocole NAT (Network Address Translation) permet à plusieurs hôtes d’un sous-réseau privé de partager une seule adresse IP publique pour accéder à Internet. Pour le trafic sortant, NAT remplace l’adresse IP privée de l’hôte dans le sous-réseau privé par l’adresse IP publique. Pour le trafic entrant, l’adresse IP publique est reconvertie en adresse privée et le message est acheminé vers l’hôte approprié dans le sous-réseau privé.

L’utilisation de NAT avec le service SIP (Session Initiation Protocol) est plus compliquée, car les messages SIP contiennent des adresses IP dans les en-têtes SIP ainsi que dans le corps SIP. Lors de l’utilisation de NAT avec le service SIP, les en-têtes SIP contiennent des informations sur l’appelant et le récepteur, et l’appareil traduit ces informations pour les masquer au réseau externe. Le corps SIP contient les informations du protocole SDP (Session Description Protocol), qui comprennent les adresses IP et les numéros de port pour la transmission du support. L’appareil traduit les informations SDP pour allouer des ressources à l’envoi et à la réception des médias.

La façon dont les adresses IP et les numéros de port sont remplacés dans les messages SIP dépend de la direction du message. Dans le cas d’un message sortant, l’adresse IP privée et le numéro de port du client sont remplacés par l’adresse IP publique et le numéro de port du pare-feu Juniper Networks. Pour un message entrant, l’adresse publique du pare-feu est remplacée par l’adresse privée du client.

Lorsqu’un message INVITE est envoyé à travers le pare-feu, la passerelle de couche applicative SIP (ALG) collecte les informations de l’en-tête du message dans une table d’appels, qu’elle utilise pour transférer les messages suivants au point de terminaison approprié. Lorsqu’un nouveau message arrive, par exemple un accusé de réception ou 200 OK, l’ALG compare les champs « From :, To :, et Call-ID : » à la table d’appel pour identifier le contexte d’appel du message. Si un nouveau message INVITE arrive qui correspond à l’appel existant, l’ALG le traite comme un REINVITE.

Lorsqu’un message contenant des informations SDP arrive, l’ALG alloue des ports et crée un mappage NAT entre eux et les ports du SDP. Étant donné que le SDP nécessite des ports séquentiels pour les canaux RTP (Real-Time Transport Protocol) et RTCP (Real-Time Control Protocol), l’ALG fournit des ports pairs-impairs consécutifs. S’il ne parvient pas à trouver une paire de ports, il ignore le message SIP.

Cette rubrique contient les sections suivantes :

Appels sortants

Lorsqu’un appel SIP est lancé avec un message de requête SIP du réseau interne vers le réseau externe, NAT remplace les adresses IP et les numéros de port dans le SDP et lie les adresses IP et les numéros de port au pare-feu Juniper Networks. Les champs d’en-tête SIP Via, Contact, Route et Record-Route, s’ils sont présents, sont également liés à l’adresse IP du pare-feu. L’ALG stocke ces mappages pour les retransmissions et les messages de réponse SIP.

L’ALG SIP ouvre ensuite des trous d’épingle dans le pare-feu pour permettre aux médias de traverser l’équipement sur les ports attribués dynamiquement, négociés en fonction des informations contenues dans le SDP et les champs d’en-tête Via, Contact et Record-Route. Les trous d’épingle permettent également aux paquets entrants d’atteindre les adresses IP et les ports Contact, Via et Record-Route. Lors du traitement du trafic de retour, l’ALG réinsère les champs SIP Contact, Via, Route et Record-Route d’origine dans les paquets.

Appels entrants

Les appels entrants sont lancés à partir du réseau public vers des adresses NAT statiques publiques ou vers des adresses IP d’interface sur l’appareil. Les NAT statiques sont des adresses IP configurées statiquement qui pointent vers des hôtes internes. Les adresses IP de l’interface sont enregistrées dynamiquement par l’ALG lorsqu’il surveille les messages REGISTER envoyés par les hôtes internes au bureau d’enregistrement SIP. Lorsque l’équipement reçoit un paquet SIP entrant, il configure une session et transmet la charge utile du paquet à l’ALG SIP.

L’ALG examine le message de demande SIP (initialement un INVITE) et, en se basant sur les informations contenues dans le SDP, ouvre des portes pour les médias sortants. Lorsqu’un message de réponse 200 OK arrive, l’ALG SIP effectue un NAT sur les adresses IP et les ports et ouvre des trous d’épingle dans le sens sortant. (Les portes ouvertes ont une courte durée de vie, et elles expirent si un message de réponse 200 OK n’est pas reçu rapidement.)

Lorsqu’une réponse 200 OK arrive, le proxy SIP examine les informations SDP et lit les adresses IP et les numéros de port pour chaque session multimédia. L’ALG SIP de l’appareil effectue un NAT sur les adresses et les numéros de port, ouvre des trous d’épingle pour le trafic sortant et actualise le délai d’expiration des portes dans le sens entrant.

Lorsque l’ACK arrive pour le 200 OK, il passe également par l’ALG SIP. Si le message contient des informations SDP, l’ALG SIP s’assure que les adresses IP et les numéros de port ne sont pas modifiés par rapport à l’INVITE précédent ; si c’est le cas, l’ALG supprime les anciens trous d’épingle et en crée de nouveaux pour permettre le passage des médias. L’ALG surveille également les champs SIP Via, Contact et Record-Route et ouvre de nouveaux trous d’épingle s’il détermine que ces champs ont été modifiés.

Appels transférés

Un appel transféré se produit lorsque, par exemple, l’utilisateur A à l’extérieur du réseau appelle l’utilisateur B à l’intérieur du réseau et que l’utilisateur B transfère l’appel à l’utilisateur C à l’extérieur du réseau. L’ALG SIP traite l’INVITE de l’utilisateur A comme un appel entrant normal. Mais lorsque l’ALG examine l’appel transféré de B vers C à l’extérieur du réseau et remarque que B et C sont atteints à l’aide de la même interface, il n’ouvre pas de trous d’épingle dans le pare-feu, car les médias circulent directement entre l’utilisateur A et l’utilisateur C.

Résiliation d’appel

Le message BYE met fin à un appel. Lorsque l’appareil reçoit un message BYE, il traduit les champs d’en-tête comme il le fait pour tout autre message. Mais comme un message BYE doit être accusé de réception par le destinataire avec un OK de 200, l’ALG retarde la suppression de l’appel de cinq secondes pour laisser le temps de transmettre le OK de 200.

Messages Re-INVITE d’appel

Ré-INVITEZ des messages, ajoutez de nouvelles sessions multimédias à un appel et supprimez des sessions multimédias existantes. Lorsque de nouvelles sessions multimédias sont ajoutées à un appel, de nouveaux trous d’épingle sont ouverts dans le pare-feu et de nouvelles liaisons d’adresse sont créées. Le processus est identique à la configuration d’appel d’origine. Lorsqu’une ou plusieurs sessions multimédias sont supprimées d’un appel, les sténopés sont fermés et les liaisons sont libérées, comme dans le cas d’un message BYE.

Minuteurs de session d’appel

L’ALG SIP utilise la valeur Session-Expires pour expirer une session si aucun message Re-INVITE ou UPDATE n’est reçu. L’ALG récupère la valeur Session-Expires, si elle est présente, à partir de la réponse 200 OK à l’INVITE et utilise cette valeur pour signaler le délai d’expiration. Si l’ALG reçoit un autre INVITE avant l’expiration de la session, il réinitialise toutes les valeurs de délai d’expiration à ce nouvel INVITE ou aux valeurs par défaut, et le processus est répété.

Par mesure de précaution, l’ALG SIP utilise des valeurs de délai d’attente strictes pour définir la durée maximale pendant laquelle un appel peut exister. Ainsi, l’équipement est protégé si l’un des événements suivants se produit :

  • Les systèmes d’extrémité se bloquent pendant un appel et un message BYE n’est pas reçu.

  • Les utilisateurs malveillants n’envoient jamais de BYE pour tenter d’attaquer un ALG SIP.

  • Les implémentations médiocres du proxy SIP ne parviennent pas à traiter Record-Route et n’envoient jamais de message BYE.

  • Les pannes réseau empêchent la réception d’un message BYE.

Annulation d’appel

L’une ou l’autre des parties peut annuler un appel en envoyant un message ANNULER. À la réception d’un message CANCEL, l’ALG SIP ferme les trous d’épingle à travers le pare-feu (s’il y en a) et libère les liaisons d’adresse. Avant de libérer les ressources, l’ALG retarde l’extinction du canal de contrôle d’environ cinq secondes pour laisser le temps aux 200 OK restants de passer. L’appel est terminé à l’expiration du délai d’expiration de cinq secondes, qu’une réponse 487 ou non 200 arrive.

Bifurquer

La duplication permet à un proxy SIP d’envoyer un seul message INVITE à plusieurs destinations simultanément. Lorsque les multiples messages de réponse 200 OK arrivent pour l’appel unique, l’ALG SIP analyse mais met à jour les informations de l’appel avec les 200 premiers messages OK qu’il reçoit.

SIP Messages

Le format de message SIP se compose d’une section d’en-tête SIP et du corps SIP. Dans les messages de demande, la première ligne de la section d’en-tête est la ligne de demande, qui comprend le type de méthode, l’URI-de-demande et la version du protocole. Dans les messages de réponse, la première ligne est la ligne d’état, qui contient un code d’état. Les en-têtes SIP contiennent les adresses IP et les numéros de port utilisés pour la signalisation. Le corps SIP, séparé de la section d’en-tête par une ligne vide, est réservé aux informations de description de session, qui sont facultatives. Actuellement, Junos OS ne prend en charge que le SDP. Le corps SIP contient les adresses IP et les numéros de port utilisés pour transporter le support.

En-têtes SIP

Dans l’exemple de message de requête SIP suivant, NAT remplace les adresses IP dans les champs d’en-tête pour les masquer du réseau externe.

La façon dont la traduction des adresses IP est effectuée dépend du type et de la direction du message. Un message peut être l’un des suivants :

  • Demande entrante

  • Réponse sortante

  • Demande sortante

  • Réponse entrante

Le tableau 5 montre comment le NAT est effectué dans chacun de ces cas. Notez que pour plusieurs champs d’en-tête, l’ALG détermine plus que simplement si les messages proviennent de l’intérieur ou de l’extérieur du réseau. Il doit également déterminer quel client a initié l’appel et si le message est une demande ou une réponse.

Tableau 5 : demande de messages avec NAT Table

Demande entrante

(du public au privé)

À:

Remplacer le domaine par l’adresse locale

De:

Aucun

ID d’appel :

Aucun

Via:

Aucun

URI-de-demande :

Remplacer l’adresse ALG par l’adresse locale

Contact:

Aucun

Record-Route :

Aucun

Route:

Aucun

Réponse sortante

(du privé au public)

À:

Remplacer l’adresse ALG par l’adresse locale

De:

Aucun

ID d’appel :

Aucun

Via:

Aucun

URI-de-demande :

N/A

Contact:

Remplacer l’adresse locale par l’adresse ALG

Record-Route :

Remplacer l’adresse locale par l’adresse ALG

Route:

Aucun

Demande sortante

(du privé au public)

À:

Aucun

De:

Remplacer l’adresse locale par l’adresse ALG

ID d’appel :

Aucun

Via:

Remplacer l’adresse locale par l’adresse ALG

URI-de-demande :

Aucun

Contact:

Remplacer l’adresse locale par l’adresse ALG

Record-Route :

Remplacer l’adresse locale par l’adresse ALG

Route:

Remplacer l’adresse ALG par l’adresse locale

Réponse sortante

(du public au privé)

À:

Aucun

De:

Remplacer l’adresse ALG par l’adresse locale

ID d’appel :

Aucun

Via:

Remplacer l’adresse ALG par l’adresse locale

URI-de-demande :

N/A

Contact:

Aucun

Record-Route :

Remplacer l’adresse ALG par l’adresse locale

Route:

Remplacer l’adresse ALG par l’adresse locale

Corps SIP

Les informations SDP dans le corps SIP incluent les adresses IP que l’ALG utilise pour créer des canaux pour le flux multimédia. La traduction de la section SDP alloue également des ressources, c’est-à-dire des numéros de port pour l’envoi et la réception des médias.

L’extrait suivant d’un exemple de section SDP montre les champs qui sont traduits pour l’allocation des ressources.

Les messages SIP peuvent contenir plusieurs flux multimédias. Le concept est similaire à celui de joindre plusieurs fichiers à un message électronique. Par exemple, un message INVITE envoyé d’un client SIP à un serveur SIP peut contenir les champs suivants :

Junos OS prend en charge jusqu’à 6 canaux SDP négociés pour chaque direction, soit un total de 12 canaux par appel.

Junos OS SIP ALG Limitations

Les limitations suivantes s’appliquent à la configuration de l’ALG SIP :

  • Seules les méthodes décrites dans la RFC 3261 sont prises en charge.

  • Seule la version 2 de SIP est prise en charge.

  • TCP n’est pas pris en charge comme mécanisme de transport pour la signalisation des messages pour les MS-MPC, mais il est pris en charge pour les services de nouvelle génération.

  • Ne configurez pas l’ALG SIP lors de l’utilisation de STUN. si les clients utilisent STUN/TURN pour détecter le pare-feu ou les périphériques NAT entre l’appelant et le répondeur ou le proxy, le client tente de deviner au mieux le comportement du périphérique NAT et d’agir en conséquence pour passer l’appel.

  • Sur les MS-MPC, n’utilisez pas l’option de pool NAT de mappage indépendant du point de terminaison en conjonction avec l’ALG SIP. Des erreurs peuvent en résulter. Cela ne s’applique pas aux services de nouvelle génération.

  • Les données de signalisation IPv6 ne sont pas prises en charge pour les MS-MPC, mais sont prises en charge pour les services de nouvelle génération.

  • L’authentification n’est pas prise en charge.

  • Les messages chiffrés ne sont pas pris en charge.

  • La fragmentation SIP n’est pas prise en charge pour les MS-MPC, mais elle l’est pour les services de nouvelle génération.

  • La taille maximale du paquet UDP contenant un message SIP est supposée être de 9 Ko. Les messages SIP de plus grande taille ne sont pas pris en charge.

  • Le nombre maximal de canaux multimédias dans un message SIP est supposé être de six.

  • Les noms de domaine complets (FQDN) ne sont pas pris en charge dans les champs critiques.

  • La QoS n’est pas prise en charge. SIP prend en charge les réécritures DSCP.

  • La haute disponibilité n’est pas prise en charge, sauf pour la veille à chaud.

  • Le paramètre de délai d’attente jamais n’est pas pris en charge sur SIP ou NAT.

  • Le multicast (proxy de bifurcation) n’est pas pris en charge.

Configuration d’une commande SNMP pour la correspondance de paquets

Vous pouvez spécifier un paramètre de commande SNMP pour la correspondance des paquets. Pour configurer SNMP, incluez l’instruction suivante snmp-command au niveau de la [edit applications application application-name] hiérarchie :

Les valeurs prises en charge sont get, get-next, set, et trap. Vous ne pouvez configurer qu’une seule valeur pour la mise en correspondance. L’instruction application-protocol au niveau de la [edit applications application application-name] hiérarchie doit avoir la valeur snmp. Pour plus d’informations sur la spécification du protocole d’application, reportez-vous à la section Configuration d’un protocole d’application.

Configuration d’un numéro de programme RPC

Vous pouvez spécifier un numéro de programme RPC pour la correspondance des paquets. Pour configurer un numéro de programme RPC, incluez l’instruction au rpc-program-number niveau de la [edit applications application application-name] hiérarchie :

La plage de valeurs utilisée pour DCE ou RPC est comprise entre 100 000 et 400 000. L’instruction application-protocol au niveau de la [edit applications application application-name] hiérarchie doit avoir la valeur rpc. Pour plus d’informations sur la spécification du protocole d’application, reportez-vous à la section Configuration d’un protocole d’application.

Configuration du seuil TTL

Vous pouvez spécifier une valeur seuil de durée de vie (TTL) de l’itinéraire de traçage, qui contrôle le niveau de pénétration acceptable du réseau pour le routage de traçage. Pour configurer une valeur TTL, incluez l’instruction suivante ttl-threshold au niveau de la [edit applications application application-name] hiérarchie :

L’instruction application-protocol au niveau de la [edit applications application application-name] hiérarchie doit avoir la valeur traceroute. Pour plus d’informations sur la spécification du protocole d’application, reportez-vous à la section Configuration d’un protocole d’application.

Configuration d’un identificateur unique universel

Vous pouvez spécifier un identifiant unique universel (UUID) pour les objets RPC DCE. Pour configurer une valeur UUID, incluez l’instruction au uuid niveau de la [edit applications application application-name] hiérarchie :

La uuid valeur est en notation hexadécimale. L’instruction application-protocol au niveau de la [edit applications application application-name hiérarchie doit avoir la valeur dce-rpc. Pour plus d’informations sur la spécification du protocole d’application, reportez-vous à la section Configuration d’un protocole d’application. Pour plus d’informations sur les numéros UUID, reportez-vous à la section http://www.opengroup.org/onlinepubs/9629399/apdxa.htm.

Configuration d’ensembles d’applications

Vous pouvez regrouper les applications que vous avez définies dans un objet nommé en incluant l’instruction application-set au niveau de la [edit applications] hiérarchie avec une application instruction pour chaque application :

Pour obtenir un exemple d’un ensemble d’applications typique, reportez-vous à la section Exemples : configuration de protocoles d’application.

Exemples : Configuration de protocoles d’application

L’exemple suivant montre la définition d’un protocole d’application décrivant une application FTP spéciale s’exécutant sur le port 78 :

L’exemple suivant montre un protocole ICMP spécial (application-protocol icmp) de type 8 (écho ICMP) :

L’exemple suivant montre un ensemble d’applications possible :

Le logiciel comprend un ensemble prédéfini de protocoles d’application bien connus. L’ensemble comprend des applications pour lesquelles les ports de destination TCP et UDP sont déjà reconnus par les filtres de pare-feu sans état.

Vérification de la sortie des sessions ALG

Cette section contient des exemples de résultats réussis à partir de sessions ALG et des informations sur la configuration du journal système. Vous pouvez comparer les résultats de vos sessions pour vérifier si les configurations fonctionnent correctement.

Exemple FTP

Cet exemple analyse la sortie au cours d’une session FTP active. Il se compose de quatre flux différents ; deux sont des flux de contrôle et deux sont des flux de données. L’exemple se compose des éléments suivants :

Sortie de l’échantillon

Carte MS-MPC

Pour les MS-MPC, voici un exemple complet de sortie de la show services stateful-firewall conversations application-protocol ftp commande Operational Mode :

Pour chaque flux, la première ligne affiche des informations sur le flux, notamment le protocole (TCP), l’adresse source, le port source, l’adresse de destination, le port de destination, l’état du flux, la direction et le nombre de trames.

  • L’état d’un flux peut être Watch, Forward, ou Drop:

    • Un Watch état de flux indique que le flux de contrôle est surveillé par l’ALG pour obtenir des informations dans la charge utile. Le traitement NAT est effectué sur l’en-tête et la charge utile en fonction des besoins.

    • Un Forward flux transfère les paquets sans surveiller la charge utile. Le NAT est effectué sur l’en-tête selon les besoins.

    • Un Drop flux abandonne tout paquet qui correspond au tuple 5.

  • Le nombre de trames (Frm count) indique le nombre de paquets qui ont été traités sur ce flux.

La deuxième ligne affiche les informations NAT.

  • source indique le NAT source.

  • dest indique le NAT de destination.

  • La première adresse et le premier port de la ligne NAT correspondent à l’adresse et au port d’origine traduits pour ce flux.

  • La deuxième adresse et le deuxième port de la ligne NAT correspondent à l’adresse et au port traduits de ce flux.

Carte MX-SPC3

Sur la carte de services MX-SPC3, voici un exemple complet de sortie de la show services sessions application-protocol ftp commande du mode opérationnel :

Pour chaque séance :

  • La première ligne affiche les informations de flux, notamment l’ID de session, le nom de l’ensemble de services, le nom de la stratégie, le délai d’expiration de la session, le nom du système logique et son état.

  • La deuxième ligne, Resource information, indique que la session est créée par ALG, y compris le nom ALG (FTP ALG) et l’ID de groupe ASL, qui est 1et l’ID de ressource ASL, qui est 0 pour la session de contrôle et 1 pour la session de données.

  • La troisième ligne In est le flux direct et la quatrième ligne Out est le flux inverse, y compris l’adresse source, le port source, l’adresse de destination, le port de destination, le protocole (TCP), la balise de connexion de session, l’interface entrante Inet sortante Out , le nombre de trames reçues et les octets. Le NAT est effectué sur l’en-tête selon les besoins.

Messages du journal système FTP

Les messages du journal système sont générés au cours d’une session FTP. Pour plus d’informations sur les journaux système, consultez Messages du journal système.

Carte MS-MPC

Les messages de journal système suivants sont générés lors de la création du flux de contrôle FTP :

  • Règle d’acceptation du journal système :

  • Créer un journal système d’acceptation de flux :

  • Journal système pour la création de flux de données :

Carte MX-SPC3

Les messages de journal système suivants sont générés lors de la création du flux de contrôle FTP :

  • Journal système pour la création d’une session de contrôle FTP :

  • Journal système pour la création d’une session de données FTP :

  • Le journal système de la session de données FTP détruit :

  • Le journal système de la session de contrôle FTP détruit :

Analyse

Flux de contrôle
Carte MS-MPC

Les flux de contrôle sont établis une fois l’établissement de liaison à trois voies terminé.

  • Contrôlez le flux du client FTP vers le serveur FTP. Le port de destination TCP est 21.

  • Flux de contrôle du serveur FTP vers le client FTP. Le port source TCP est 21.

Carte MX-SPC3

Les flux de contrôle sont établis une fois l’établissement de liaison à trois voies terminé.

  • Session de contrôle du client FTP au serveur FTP, le port de destination TCP est 21.

  • Session de données du client FTP au serveur FTP, c’est pour le mode passif FTP.

  • Session de données du serveur FTP au client FTP, c’est pour le mode actif FTP :

Flux de données

Un port de données de 20 est négocié pour le transfert de données au cours du protocole de contrôle FTP. Ces deux flux sont des flux de données entre le client FTP et le serveur FTP :

Questions de dépannage

  1. Comment savoir si l’ALG FTP est actif ?

    • Le champ Protocole ALG de la conversation doit afficher ftp.

    • Il doit y avoir un nombre d’images valide (Frm count) dans les flux de contrôle.

    • Un nombre d’images valide dans les flux de données indique que le transfert de données a eu lieu.

  2. De quoi ai-je besoin pour vérifier si la connexion FTP est établie mais que le transfert de données n’a pas lieu ?

    • Très probablement, la connexion de contrôle est active, mais la connexion de données est en panne.

    • Vérifiez la sortie des conversations pour déterminer si les flux de contrôle et de données sont présents.

  3. Comment interpréter chaque flux ? Que signifie chaque flux ?

    • Flux initiateur de flux de contrôle FTP : flux avec le port de destination 21

    • Flux de réponse de flux de contrôle FTP : flux avec port source ; 21

    • Flux initiateur de flux de données FTP : flux avec le port de destination 20

    • Flux de réponse de flux de données FTP : flux avec le port source 20

Exemple d’ALG RTSP

Voici un exemple de conversation RTSP. L’application utilise le protocole RTSP pour contrôler la connexion. Une fois la connexion établie, le média est envoyé à l’aide du protocole UDP (RTP).

Cet exemple se compose des éléments suivants :

Exemple de sortie pour les MS-MPC

Voici le résultat de la show services stateful-firewall conversations commande du mode opérationnel :

Exemple de sortie pour la carte de services MX-SPC3

Voici le résultat de la show services sessions application-protocol rtsp commande du mode opérationnel :

Analyse

Une conversation RTSP doit être constituée de flux TCP correspondant à la connexion de contrôle RTSP. Il doit y avoir deux flux, un dans chaque direction, du client vers le serveur et du serveur vers le client :

  • La connexion de contrôle RTSP pour le flux de l’initiateur est envoyée à partir du port de destination 554.

  • La connexion de contrôle RTSP pour le flux de répondeur est envoyée à partir du port source 554.

Les flux UDP correspondent aux médias RTP envoyés via la connexion RTSP.

Questions de dépannage

  1. Le support ne fonctionne pas lorsque l’ALG RTSP est configuré. Que dois-je faire ?

    • Consultez les conversations RTSP pour voir s’il existe des flux TCP et UDP.

    • Le protocole ALG doit être affiché sous la forme rtsp.

    Note:

    L’état du flux s’affiche sous la forme Watch, car le traitement ALG est en cours et le client est essentiellement en train de « surveiller » ou de traiter la charge utile correspondant à l’application. Pour les flux ALG FTP et RTSP, les connexions de contrôle sont toujours Watch des flux.

  2. Comment puis-je vérifier les erreurs ALG ?

    • Vous pouvez vérifier les erreurs en exécutant la commande suivante. Chaque ALG dispose d’un champ distinct pour les erreurs de paquets ALG.

Messages du journal système

L’activation de la génération du journal système et la vérification du journal système sont également utiles pour l’analyse du flux ALG. Cette section contient les éléments suivants :

Configuration du journal système

Vous pouvez configurer l’activation des messages du journal système à différents niveaux dans l’interface de ligne de commande de Junos OS. Comme illustré dans les exemples de configuration suivants, le choix du niveau dépend de la spécificité de la journalisation des événements et des options que vous souhaitez inclure. Pour plus d’informations sur les options de configuration, reportez-vous à la bibliothèque d’administration de Junos OS pour les périphériques de routage (au niveau du système) ou à la bibliothèque d’interfaces de services Junos OS pour les périphériques de routage (tous les autres niveaux).

  1. Au plus haut niveau mondial :

  2. Au niveau de l’ensemble de services :

  3. Au niveau de la règle de service :

Sortie du journal système

Des messages du journal système sont générés lors de la création du flux, comme illustré dans les exemples suivants :

Le message de journal système suivant indique que l’ASP correspond à une règle d’acceptation :

Pour obtenir la liste complète des messages du journal système, reportez-vous à l’Explorateur du journal système.