ALG Applications
Configuration des propriétés de l’application
Pour configurer les propriétés de l’application, incluez l’instruction application au niveau de la [edit applications] hiérarchie :
[edit applications] application application-name { application-protocol protocol-name; child-inactivity-timeout seconds; destination-port port-number; gate-timeout seconds; icmp-code value; icmp-type value; inactivity-timeout value; protocol type; rpc-program-number number; snmp-command command; source-port port-number; ttl-threshold value; uuid hex-value; }
Vous pouvez regrouper des objets d’application en configurant l’instruction application-set . Pour plus d’informations, consultez Configuration des ensembles d’applications.
Cette section comprend les tâches suivantes pour configurer les applications :
- Configuration d’un protocole d’application
- Configuration du protocole réseau
- Configuration du code et du type ICMP
- Configuration des ports source et de destination
- Configuration du délai d’inactivité
- Configuration d’une application ALG IKE
- Configuration de SIP
- Configuration d’une commande SNMP pour la correspondance de paquets
- Configuration d’un numéro de programme RPC
- Configuration du seuil TTL
- Configuration d’un identificateur unique universel
Configuration d’un protocole d’application
L’instruction application-protocol vous permet de spécifier les protocoles d’application (ALG) pris en charge à configurer et à inclure dans un ensemble d’applications pour le traitement des services. Pour configurer les protocoles d’application, incluez l’instruction application-protocol au niveau de la [edit applications application application-name] hiérarchie :
[edit applications application application-name] application-protocol protocol-name;
Le Tableau 1 présente la liste des protocoles pris en charge. Pour plus d’informations sur des protocoles spécifiques, consultez Descriptions des ALG.
Nom du protocole |
Valeur de la CLI |
Commentaires |
|---|---|---|
Protocole d’amorçage (BOOTP) |
|
Prend en charge BOOTP et le protocole DHCP (Dynamic Host Configuration Protocol). |
Appel de procédure à distance (RPC) de l’environnement informatique distribué (DCE) |
|
Nécessite que l’instruction |
Plan de port RPC DCE |
|
Nécessite que l’instruction |
Système de noms de domaine (DNS) |
|
Nécessite que l’instruction |
Exécutif |
|
Exige que l’instruction |
FTP (en anglais) |
|
Exige que l’instruction |
H.323 |
|
– |
IKE ALG |
|
Nécessite que l’instruction |
ICMP (Internet Control Message Protocol) |
|
Exige que l’instruction |
Protocole inter-ORB Internet |
|
– |
IP |
|
– |
Connectez-vous |
|
– |
NetBIOS |
|
Exige que l’instruction |
NetShow |
|
Exige que l’instruction |
Protocole de tunnelisation point à point |
|
– |
RealAudio |
|
– |
RTSP (Real-Time Streaming Protocol) |
|
Exige que l’instruction |
RPC User Datagram Protocol (UDP) ou TCP |
|
Nécessite que l’instruction |
Mappage des ports RPC |
|
Nécessite que l’instruction |
Coquille |
|
Exige que l’instruction |
Protocole de lancement de session |
|
– |
SNMP |
|
Exige que l’instruction |
SQLNet |
|
Exige que l’instruction |
Programme de discussion |
|
|
Itinéraire de traçage |
|
Exige que l’instruction |
FTP trivial (TFTP) |
|
Exige que l’instruction |
WinFrame |
|
– |
Vous pouvez configurer des passerelles de niveau d’application (ALG) pour ICMP et tracer la route sous un pare-feu dynamique, des règles NAT ou CoS lorsque deux fois le NAT est configuré dans le même ensemble de services. Ces ALG ne peuvent pas être appliquées aux flux créés par le protocole PGCP (Packet Gateway Controller Protocol). Twice NAT ne prend pas en charge les autres ALG. 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 deux fois du 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 à mettre en correspondance dans une définition d’application. Pour configurer les protocoles réseau, incluez l’instruction protocol au niveau de la [edit applications application application-name] hiérarchie :
[edit applications application application-name] protocol type;
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.
Type de protocole réseau |
Valeur de la CLI |
Commentaires |
|---|---|---|
En-tête d’authentification de la Sécurité IP (IPsec) |
|
– |
External Gateway Protocol (EGP) |
|
– |
Encapsulation IPsec de la charge utile de sécurité (ESP) |
|
– |
Encapsulation de routage générique (GR) |
|
– |
L’ICMP |
|
Nécessite une |
ICMPv6 |
|
Nécessite une |
Protocole IGMP (Internet Group Management Protocol) |
|
– |
IP dans IP |
|
– |
OSPF |
|
– |
Protocol Independent Multicast (PIM) |
|
– |
Protocole de réservation des ressources (RSVP) |
|
– |
Protocole TCP |
|
Nécessite une valeur ou |
UDP |
|
Nécessite une valeur ou |
Pour obtenir la liste complète des valeurs numériques possibles, reportez-vous à la section RFC 1700, Assigned Numbers (for the Internet Protocol Suite).
La version IP 6 (IPv6) n’est pas prise en charge en tant que protocole réseau dans les définitions d’application.
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 and protocol udp avec l’instruction application pour les configurations deux fois NAT. Pour plus d’informations sur la configuration deux fois du 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 une spécification supplémentaire, conjointement avec le protocole réseau, pour la correspondance des paquets dans une définition d’application. Pour configurer les paramètres ICMP, incluez les icmp-code instructions et au icmp-type niveau de la [edit applications application application-name] hiérarchie :
[edit applications application application-name] icmp-code value; icmp-type value;
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.
Déclaration CLI |
Descriptif |
|---|---|
|
Cette valeur ou mot-clé fournit des informations plus spécifiques que À la place de la valeur numérique, vous pouvez spécifier l’un des synonymes textuels 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 : Redirection : Dépassement dans le temps : Injoignables : |
|
Normalement, vous spécifiez cette correspondance conjointement avec l’instruction À la place de la valeur numérique, vous pouvez spécifier l’un des synonymes textuels suivants (les valeurs de champ sont également répertoriées) : |
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 le sens d’entrée.
Les solutions de contournement possibles consistent notamment à 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 vers le service de pare-feu dynamique.
Configuration des ports source et de destination
Les ports source et de destination TCP ou UDP fournissent une spécification supplémentaire, conjointement 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 au source-port niveau de la [edit applications application application-name] hiérarchie :
[edit applications application application-name] destination-port value; source-port value;
Vous devez définir un port source ou de destination. Normalement, vous spécifiez cette correspondance conjointement avec l’instruction match protocol pour déterminer le protocole utilisé sur le port. Pour connaître les contraintes, reportez-vous au Tableau 1.
Vous pouvez spécifier une valeur numérique ou l’un des synonymes textuels répertoriés dans le Tableau 4.
Nom du port |
Numéro de port correspondant |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pour plus d’informations sur les critères de correspondance, consultez le 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’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 :
[edit applications application application-name] inactivity-timeout seconds;
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, consultez 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 ALG IKE
Avant la version 17.4R1 de Junos OS, la traduction d’adresses réseau (NAT-Traversal) n’était pas prise en charge pour la suite de fonctionnalités IPsec de Junos VPN Site Secure sur les routeurs MX Series. L’ALG IKE permet de faire passer des paquets IKEv1 et IPsec à travers les filtres NAPT-44 et NAT64 entre homologues IPsec qui ne sont pas conformes à la norme NAT-T. Cet ALG prend uniquement en charge le mode tunnel ESP. Vous pouvez utiliser l’application junos-ikeIKE ALG prédéfinie , qui a 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’ALG IKE avec des valeurs différentes de l’application prédéfinie junos-ike , vous devez configurer une nouvelle application ALG IKE.
Pour configurer une application IKE ALG :
Spécifiez un nom pour l’application.
[edit applications] user@host# set application junos-ike
Spécifiez l’ALG IKE.
[edit applications application junos-ike] user@host# set application-protocol ike-esp-nat
Spécifiez le protocole UDP.
[edit applications application junos-ike] user@host# set protocol udp
Spécifiez 500 pour le port de destination.
[edit applications application junos-ike] user@host# set destination-port 500
-
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.
[edit applications application junos-ike] user@host# set inactivity-timeout seconds
Spécifiez le nombre de secondes qui peuvent s’écouler après qu’IKE a établi l’association de sécurité entre le client et le serveur IPsec 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.
[edit applications application junos-ike] user@host# set gate-timeout seconds
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 délai, la session est supprimée. La valeur par défaut est de 800 secondes.
[edit applications application junos-ike] user@host# set child-inactivity-timeout seconds
Configuration de SIP
Le protocole SIP (Session Initiation Protocol) est un protocole généralisé pour la communication entre les points de terminaison 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 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).
Avant de mettre en œuvre Junos OS SIP ALG, vous devez connaître certaines limitations, décrites dans Limitations de Junos OS SIP ALG
L’utilisation de NAT en conjonction avec l’ALG SIP entraîne des changements dans les champs d’en-tête SIP en raison de la traduction de l’adresse. Pour une explication de ces traductions, reportez-vous à la section Interaction SIP ALG avec la traduction d’adresses réseau.
Pour implémenter SIP sur des interfaces de services adaptatives, 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, consultez Configuration d’un protocole d’application. En outre, vous pouvez configurer deux autres instructions pour modifier la façon dont SIP est implémenté :
Vous pouvez permettre au routeur d’accepter 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-registerest 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 derrière le pare-feu peuvent appeler les périphériques à l’extérieur du pare-feu.Pour configurer l’enregistrement SIP, incluez l’instruction
learn-sip-registerau niveau de la[edit applications application application-name]hiérarchie :[edit applications application application-name] learn-sip-register;
Remarque :Cette
learn-sip-registerdéclaration ne s’applique pas au MX-SPC3 des services de nouvelle génération.Vous pouvez également inspecter manuellement le registre SIP en exécutant la
show services stateful-firewall sip-registercommande ; pour plus d’informations, reportez-vous à la référence des commandes de base et de services du système Junos OS. Lashow services stateful-firewall sip-registercommande 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, entraînant la suppression de l’état de l’appel. Pour éviter cela, lorsqu’un appel est mis en attente, le minuteur de flux est réinitialisé ausip-call-hold-timeoutcycle pour préserver l’état de l’appel et les flux plus longtemps que lainactivity-timeoutpériode.Remarque :Cette
sip-call-hold-timeoutdéclaration ne s’applique pas au MX-SPC3 des services de nouvelle génération.Pour configurer un délai d’expiration, incluez l’instruction
sip-call-hold-timeoutau niveau de la[edit applications application application-name]hiérarchie :[edit applications application application-name] sip-call-hold-timeout seconds;
La valeur par défaut est de 7200 secondes et la plage est de 0 à 36 000 secondes (10 heures).
Interaction SIP ALG avec 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 destinataire, et l’appareil traduit ces informations pour les cacher au réseau externe. Le corps SIP contient les informations du protocole de description de session (SDP), 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 dans les messages SIP sont remplacés dépend de la direction du message. Pour 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’appel, 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 un 200 OK, l’ALG compare les champs « De :, À : et ID-appel : » à 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 une REINVITATION.
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 demande SIP du réseau interne au 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 correspondances pour les retransmissions et les messages de réponse SIP.
L’ALG SIP ouvre ensuite des trous d’épingle dans le pare-feu pour laisser passer les médias sur les ports attribués dynamiquement négociés en fonction des informations du SDP et des champs d’en-tête Via, Contact et Record-Route. Les sténopés 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 d’origine Contact, Via, Route et Record-Route dans les paquets.
Appels entrants
Les appels entrants sont initiés depuis le 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 des interfaces 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’appareil reçoit un paquet SIP entrant, il établit une session et transmet la charge utile du paquet à l’ALG SIP.
L’ALG examine le message de demande SIP (initialement une invitation) et, sur la base des informations fournies 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 la direction sortante. (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 de 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 sur l’appareil effectue des 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 pour les portes dans le sens entrant.
Lorsque l’ACK arrive pour le 200 OK, il passe également par le SIP ALG. Si le message contient des informations SDP, l’ALG SIP garantit que les adresses IP et les numéros de port ne sont pas modifiés par rapport à l’INVITE précédente - si c’est le cas, l’ALG supprime les anciens sténopés et crée de nouveaux sténopés pour permettre le passage des supports. L’ALG surveille également les champs SIP Via, Contact et Record-Route et ouvre de nouveaux sténopés s’il détermine que ces champs ont changé.
Appels transférés
Un appel transféré se produit lorsque, par exemple, l’utilisateur A en dehors du réseau appelle l’utilisateur B à l’intérieur du réseau et l’utilisateur B transfère l’appel à l’utilisateur C en dehors du réseau. L’ALG SIP traite l’INVITATION de l’utilisateur A comme un appel entrant normal. Mais lorsque l’ALG examine l’appel transféré de B à C en dehors du réseau et remarque que B et C sont atteints en utilisant 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.
Terminaison 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 n’importe quel autre message. Mais comme un message BYE doit être accusé de réception par le destinataire avec un OK de 200, l’ALG retarde le retrait de l’appel de cinq secondes pour laisser le temps de transmettre le OK de 200.
Messages de réinvitation d’appel
Messages de nouvelle invitation, ajoutez de nouvelles sessions multimédias à un appel et supprimez les 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’adresses 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 pour un message BYE.
Minuteurs de session d’appel
L’ALG SIP utilise la valeur Session-Expires pour expirer une session si un message Re-INVITE ou UPDATE n’est pas reçu. L’ALG obtient la valeur Session-Expires, le cas échéant, de la réponse 200 OK à l’INVITE et utilise cette valeur pour signaler le délai d’expiration. Si l’ALG reçoit une autre INVITE avant l’expiration de la session, il réinitialise toutes les valeurs de délai d’expiration à cette nouvelle 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 d’un appel. Cela garantit que l’équipement est protégé si l’un des événements suivants se produit :
Les systèmes de terminaison plantent pendant un appel et aucun message BYE n’est reçu.
Les utilisateurs malveillants n’envoient jamais de BYE pour tenter d’attaquer un ALG SIP.
Les mauvaises implémentations du proxy SIP ne parviennent pas à traiter Record-Route et n’envoient jamais de message BYE.
Les défaillances du 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 CANCEL. À la réception d’un message CANCEL, l’ALG SIP ferme les trous d’épingle à travers le pare-feu, s’il y en a un, et libère les liaisons d’adresse. Avant de libérer les ressources, l’ALG retarde l’âge du canal de contrôle d’environ cinq secondes pour laisser le temps au passage des 200 derniers OK. L’appel prend fin à l’expiration du délai de cinq secondes, qu’une réponse 487 ou non-200 arrive.
Duplication
Le forking permet à un proxy SIP d’envoyer un seul message INVITE à plusieurs destinations simultanément. Lorsque les 200 messages de réponse OK arrivent pour un seul appel, l’ALG SIP analyse mais met à jour les informations d’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 du 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 prend uniquement en charge 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 demande SIP suivant, NAT remplace les adresses IP dans les champs d’en-tête pour les masquer au réseau externe.
INVITE bob@10.150.20.5SIP/2.0 Via: SIP/2.0/UDP10.150.20.3:5434 From: alice@10.150.20.3To: bob@10.150.20.5Call-ID: a12abcde@10.150.20.3Contact: alice@10.150.20.3:5434 Route: <sip:netscreen@10.150.20.3:5060> Record-Route: <sip:netscreen@10.150.20.3:5060>
La traduction des adresses IP dépend du type et de la direction du message. Un message peut être l’un des suivants :
Requête entrante
Réponse sortante
Requête sortante
Réponse entrante
Le tableau 5 montre comment le NAT est effectué dans chacun de ces cas. Notez que pour plusieurs des 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 s’il s’agit d’une demande ou d’une réponse.
Requête entrante (du public au privé) |
À: |
Remplacer le domaine par l’adresse locale |
De: |
Aucun |
|
ID d’appel : |
Aucun |
|
Via : |
Aucun |
|
URI de requête : |
Remplacer l’adresse ALG par l’adresse locale |
|
Personne-ressource : |
Aucun |
|
Itinéraire d’enregistrement : |
Aucun |
|
Itinéraire : |
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 requête : |
S.O. |
|
Personne-ressource : |
Remplacer l’adresse locale par l’adresse ALG |
|
Itinéraire d’enregistrement : |
Remplacer l’adresse locale par l’adresse ALG |
|
Itinéraire : |
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 requête : |
Aucun |
|
Personne-ressource : |
Remplacer l’adresse locale par l’adresse ALG |
|
Itinéraire d’enregistrement : |
Remplacer l’adresse locale par l’adresse ALG |
|
Itinéraire : |
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 requête : |
S.O. |
|
Personne-ressource : |
Aucun |
|
Itinéraire d’enregistrement : |
Remplacer l’adresse ALG par l’adresse locale |
|
Itinéraire : |
Remplacer l’adresse ALG par l’adresse locale |
Corps SIP
Les informations SDP dans le corps du SIP comprennent 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 envoyer et recevoir les médias.
L’extrait suivant d’un exemple de section SDP montre les champs traduits pour l’allocation des ressources.
o=user 2344234 55234434 IN IP410.150.20.3c=IN IP410.150.20.3m=audio43249RTP/AVP 0
Les messages SIP peuvent contenir plus d’un flux multimédia. Le concept est similaire à joindre plusieurs fichiers à un message électronique. Par exemple, un message INVITE envoyé d’un client SIP à un serveur SIP peut comporter les champs suivants :
c=IN IP410.123.33.4m=audio33445RTP/AVP 0 c=IN IP410.123.33.4m=audio33447RTP/AVP 0 c=IN IP410.123.33.4m=audio33449RTP/AVP 0
Junos OS prend en charge jusqu’à 6 canaux SDP négociés pour chaque direction, pour un total de 12 canaux par appel.
Limites de Junos OS SIP ALG
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 SIP 2 est prise en charge.
TCP n’est pas pris en charge comme mécanisme de transport pour les messages de signalisation 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 dispositifs 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 conjointement avec l’ALG SIP. Des erreurs en résulteront. Cela ne s’applique pas aux services nouvelle génération.
Les données de signalisation IPv6 ne sont pas prises en charge pour les MS-MPC, mais pour les services 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 par les MS-MPC, mais par les services nouvelle génération.
La taille maximale des paquets UDP contenant un message SIP est supposée être de 9 Ko. Les messages SIP plus grands ne sont pas pris en charge.
Le nombre maximum 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 en mode veille à chaud.
Le paramètre de délai d’attente never n’est pas pris en charge sur SIP ou NAT.
Le multicast (proxy de duplication) 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 snmp-command au niveau de la [edit applications application application-name] hiérarchie :
[edit applications application application-name] snmp-command value;
Les valeurs prises en charge sont get, get-next, setet trap. Vous ne pouvez configurer qu’une seule valeur pour la 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, consultez 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 rpc-program-number au niveau de la [edit applications application application-name] hiérarchie :
[edit applications application application-name] rpc-program-number number;
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, consultez Configuration d’un protocole d’application.
Configuration du seuil TTL
Vous pouvez spécifier une valeur seuil de durée de vie (TTL) de routage de trace, qui contrôle le niveau de pénétration du réseau acceptable pour le routage de trace. Pour configurer une valeur TTL, incluez l’instruction ttl-threshold au niveau de la [edit applications application application-name] hiérarchie :
[edit applications application application-name] ttl-threshold value;
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, consultez Configuration d’un protocole d’application.
Configuration d’un identificateur unique universel
Vous pouvez spécifier un UUID (Universal Unique Identifier) pour les objets RPC DCE. Pour configurer une valeur UUID, incluez l’instruction uuid au niveau de la [edit applications application application-name] hiérarchie :
[edit applications application application-name] uuid hex-value;
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, consultez 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.
Voir aussi
Configuration des 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 :
[edit applications]
application-set application-set-name {
application application;
}
Pour obtenir un exemple d’ensemble d’applications typique , consultez Exemples : configuration de protocoles d’application.
Exemples : configuration des protocoles d’application
L’exemple suivant montre une définition de protocole d’application décrivant une application FTP spéciale s’exécutant sur le port 78 :
[edit applications]
application my-ftp-app {
application-protocol ftp;
protocol tcp;
destination-port 78;
timeout 100; # inactivity timeout for FTP service
}
L’exemple suivant montre un protocole ICMP spécial (application-protocol icmp) de type 8 (écho ICMP) :
[edit applications]
application icmp-app {
application-protocol icmp;
protocol icmp;
icmp-type icmp-echo;
}
L’exemple suivant illustre un ensemble d’applications possibles :
[edit applications]
application-set basic {
http;
ftp;
telnet;
nfs;
icmp;
}
Le logiciel comprend un ensemble prédéfini de protocoles applicatifs connus. L’ensemble comprend les applications pour lesquelles les ports de destination TCP et UDP sont déjà reconnus par les filtres de pare-feu sans état.
Vérification des résultats des sessions ALG
Cette section contient des exemples de sorties réussies 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 pendant 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 parties suivantes :
Exemple de sortie
Carte MS-MPC
Pour les MS-MPC, voici un exemple complet de sortie de la show services stateful-firewall conversations application-protocol ftp commande du mode opérationnel :
user@host>show services stateful-firewall conversations application-protocol ftp
Interface: ms-1/3/0, Service set: CLBJI1-AAF001
Conversation: ALG protocol: ftp
Number of initiators: 2, Number of responders: 2
Flow State Dir Frm count
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13
NAT source 1.1.79.2:14083 -> 194.250.1.237:50118
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12
NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
Pour chaque flux, la première ligne affiche les informations sur le flux, y compris 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,ForwardouDrop: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 selon les besoins.Un
Forwardflux transfère les paquets sans surveiller la charge utile. Le NAT est effectué sur l’en-tête selon les besoins.Un
Dropflux abandonne tout paquet correspondant au tuple 5.
Le nombre d’images (
Frm count) indique le nombre de paquets traités dans ce flux.
La deuxième ligne affiche les informations NAT.
sourceindique le NAT source.destindique le NAT de destination.La première adresse et le premier port de la ligne NAT sont l’adresse et le port d’origine traduits pour ce flux.
La deuxième adresse et le deuxième port de la ligne NAT sont l’adresse et le port traduits pour 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 mode opérationnel :
user@host>show services sessions application-protocol ftp Session ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239, Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650, Total sessions: 2
Pour chaque session :
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 1 et 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
Inest le flux direct et la quatrième ligneOutle 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 etInsortanteOut, 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 suivants du journal système sont générés lors de la création du flux de contrôle FTP :
Règle d’acceptation du journal système :
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, Match SFW accept rule-set:, rule: ftp, term: 1Créer un journal système de flux d’acceptation :
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, creating forward or watch flowJournal système pour la création de flux de données :
Oct 27 11:43:30 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_FTP_ACTIVE_ACCEPT: proto 6 (TCP) application: ftp, so-2/1/2.0:2.2.2.2:20 -> 1.1.1.2:50726, Creating FTP active mode forward flow
Carte MX-SPC3
Les messages suivants du journal système sont générés lors de la création du flux de contrôle FTP :
Journal système pour la création de sessions de contrôle FTP :
Mar 23 23:58:54 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 N/A(N/A) ge-1/0/2.0 UNKNOWN UNKNOWN UNKNOWN N/A N/A -1 N/A Mar 23 23:59:00 esst480r junos-alg: RT_ALG_FTP_ACTIVE_ACCEPT: application:ftp data, vms-3/0/0.0 30.1.1.2:20 -> 20.1.1.2:33947 (TCP)
Journal système pour la création de sessions de données FTP :
Mar 23 23:59:00 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 N/A(N/A) ge-1/1/6.0 FTP-DATA UNKNOWN UNKNOWN Infrastructure File-Servers 2 N/A
Journal système pour les données FTP Destruction de session :
Mar 23 23:59:02 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed TCP FIN: 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 2954(4423509) 281(14620) 2 FTP-DATA UNKNOWN N/A(N/A) ge-1/1/6.0 No Infrastructure File-Servers 2 N/A
Journal système pour la destruction de session de contrôle FTP :
Mar 23 23:59:39 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed Closed by junos-tcp-clt-emul: 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 23(1082) 18(1176) 45 UNKNOWN UNKNOWN N/A(N/A) ge-1/0/2.0 No N/A N/A -1 N/A
Analyse
Contrôle des flux
Carte MS-MPC
Les flux de contrôle sont établis une fois l’établissement de liaison tripartite terminé.
Contrôlez le flux du client FTP vers le serveur FTP. Le port de destination TCP est le 21.
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13 NAT source 1.1.79.2:14083 -> 194.250.1.237:50118Contrôlez le flux du serveur FTP vers le client FTP. Le port source TCP est 21.
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12 NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
Carte MX-SPC3
Les flux de contrôle sont établis une fois l’établissement de liaison tripartite terminé.
Contrôlez la session du client FTP au serveur FTP, le port de destination TCP est 21.
Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650,
Session de données du client FTP au serveur FTP, c’est pour le mode passif FTP.
Session ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239,
Session de données du serveur FTP au client FTP, c’est pour le mode FTP actif :
Session ID: 549978117, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 22.20.20.3/20 --> 60.1.1.3/6049;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 10, Bytes: 8291, Out: 12.10.10.10/33203 --> 22.20.20.3/20;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 5, Bytes: 268,
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 :
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
Questions de dépannage
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 qu’un transfert de données a eu lieu.
Que dois-je 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 interrompue.
Vérifiez la sortie des conversations pour déterminer si les flux de contrôle et de données sont présents.
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 FTP : flux avec le port de destination 20
Flux de répondeur de flux FTP : flux avec le port source 20
Exemple d’ALG RTSP
Voici un exemple de conversation RTSP. L’application utilise le protocole RTSP pour la connexion de contrôle. 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
- Exemple de sortie pour la carte de services MX-SPC3
- Analyse
- Questions de dépannage
Exemple de sortie pour les MS-MPC
Voici le résultat de la show services stateful-firewall conversations commande du mode opérationnel :
user@host# show services stateful-firewall conversations Interface: ms-3/2/0, Service set: svc_set Conversation: ALG protocol: rtsp Number of initiators: 5, Number of responders: 5 Flow State Dir Frm count TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 UDP 1.1.1.3:1028 -> 2.2.2.2:1028 Forward I 0 UDP 1.1.1.3:1029 -> 2.2.2.2:1029 Forward I 0 UDP 1.1.1.3:1030 -> 2.2.2.2:1030 Forward I 0 UDP 1.1.1.3:1031 -> 2.2.2.2:1031 Forward I 0 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5 UDP 2.2.2.2:1028 -> 1.1.1.3:1028 Forward O 6 UDP 2.2.2.2:1029 -> 1.1.1.3:1029 Forward O 0 UDP 2.2.2.2:1030 -> 1.1.1.3:1030 Forward O 3 UDP 2.2.2.2:1031 -> 1.1.1.3:1031 Forward O 0
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 :
user@host# run show services sessions application-protocol rtsp Session ID: 1073741828, Service-set: sset1, Policy name: p1/131081, Timeout: 116, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 0 In: 31.0.0.2/33575 --> 41.0.0.2/554;tcp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 8, Bytes: 948, Out: 41.0.0.2/554 --> 131.10.0.1/7777;tcp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 6, Bytes: 1117, Session ID: 1073741829, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 1 In: 41.0.0.2/35004 --> 131.10.0.1/7780;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 79200, Out: 31.0.0.2/30004 --> 41.0.0.2/35004;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Session ID: 1073741830, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 4 In: 41.0.0.2/35006 --> 131.10.0.1/7781;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 174240, Out: 31.0.0.2/30006 --> 41.0.0.2/35006;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Total sessions: 3
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 au serveur et du serveur au client :
TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5
La connexion de contrôle RTSP pour le flux 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
Le média ne fonctionne pas lorsque l’ALG RTSP est configuré. Comment 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.
Remarque :L’état du flux s’affiche sous la forme
Watch, car le traitement ALG est en cours et le client « surveille » ou traite la charge utile correspondant à l’application. Pour les flux FTP et RTSP ALG, les connexions de contrôle sont toujoursWatchdes flux.Comment vérifier les erreurs ALG ?
Vous pouvez vérifier les erreurs en exécutant la commande suivante. Chaque ALG a un champ distinct pour les erreurs de paquets ALG.
user@host# show services stateful-firewall statistics extensive Interface: ms-3/2/0 Service set: svc_set New flows: Accepts: 1347, Discards: 0, Rejects: 0 Existing flows: Accepts: 144187, Discards: 0, Rejects: 0 Drops: IP option: 0, TCP SYN defense: 0 NAT ports exhausted: 0 Errors: IP: 0, TCP: 276 UDP: 0, ICMP: 0 Non-IP packets: 0, ALG: 0 IP errors: IP packet length inconsistencies: 0 Minimum IP header length check failures: 0 Reassembled packet exceeds maximum IP length: 0 Illegal source address: 0 Illegal destination address: 0 TTL zero errors: 0, Illegal IP protocol number (0 or 255): 0 Land attack: 0 Non-IPv4 packets: 0, Bad checksum: 0 Illegal IP fragment length: 0 IP fragment overlap: 0 IP fragment reassembly timeout: 0 Unknown: 0 TCP errors: TCP header length inconsistencies: 0 Source or destination port number is zero: 0 Illegal sequence number and flags combinations: 0 SYN attack (multiple SYN messages seen for the same flow): 276 First packet not a SYN message: 0 TCP port scan (TCP handshake, RST seen from server for SYN): 0 Bad SYN cookie response: 0 UDP errors: IP data length less than minimum UDP header length (8 bytes): 0 Source or destination port number is zero: 0 UDP port scan (ICMP error seen for UDP flow): 0 ICMP errors: IP data length less than minimum ICMP header length (8 bytes): 0 ICMP error length inconsistencies: 0 Duplicate ping sequence number: 0 Mismatched ping sequence number: 0 ALG errors: BOOTP: 0, DCE-RPC: 0, DCE-RPC portmap: 0 DNS: 0, Exec: 0, FTP: 0 ICMP: 0 Login: 0, NetBIOS: 0, NetShow: 0 RPC: 0, RPC portmap: 0 RTSP: 0, Shell: 0 SNMP: 0, SQLNet: 0, TFTP: 0 Traceroute: 0
Messages du journal système
L’activation de la génération de journaux système et la vérification du journal système sont également utiles pour l’analyse de 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 la CLI de Junos OS. Comme indiqué 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 de détails sur les options de configuration, reportez-vous à la bibliothèque d’administration de Junos OS pour les équipements de routage (niveau système) ou à la bibliothèque d’interfaces de services Junos OS pour les équipements de routage (tous les autres niveaux).
Au plus haut niveau mondial :
user@host# show system syslog file messages { any any; }Au niveau de l’ensemble de services :
user@host# show services service-set svc_set syslog { host local { services any; } } stateful-firewall-rules allow_rtsp; interface-service { service-interface ms-3/2/0; }Au niveau des règles de service :
user@host# show services stateful-firewall rule allow_rtsp match-direction input-output; term 0 { from { applications junos-rtsp; } then { accept; syslog; } }
Sortie du journal système
Les 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 suivant du journal système indique que l’ASP a correspondu à une règle d’acceptation :
Oct 25 16:11:37 (FPC Slot 3, PIC Slot 2) {svc_set}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: rtsp, ge-2/0/1.0:1.1.1.2:35595 -> 2.2.2.2:554, Match SFW accept rule-set: , rule: allow_rtsp, term: 0
Pour obtenir la liste complète des messages du journal système, reportez-vous à l’explorateur du journal système.