j'ai compris

À propos du pare-feu SIP ASPF/ALG

publié il y a  2021-8-19 12:32:22 229 0 0 0 0

Salut à tous! Aujourd'hui je vais vous présenter l'application de SIP ALG sur le firewall.

1. Protocole SIP

1.1 Principes de base du protocole SIP

Le protocole d'initiation de session (SIP) est un protocole standard de l'IETF utilisé pour créer, modifier et libérer des sessions d'un ou plusieurs participants. Ces sessions peuvent être des sessions utilisateur interactives d'éléments multimédias tels que des appels vocaux, des conférences multimédias et de la réalité virtuelle.


Dans un réseau SIP typique, il existe plusieurs clients SIP et serveurs proxy SIP. Les clients SIP sont classés en UAC et UAS. Le client qui initie un appel est un client d'agent d'utilisateur (UAC), le client appelé est un serveur d'agent d'utilisateur (UAS) et le serveur proxy SIP est un proxy SIP qui transmet les demandes ou les réponses au nom de l'UA. Les User-Agents (UA) peuvent être des téléphones portables, des téléphones fixes et des softphones. Les rôles de l'UAC et de l'UAS correspondent à un seul appel.


SIP est également un protocole multicanal. Plusieurs canaux sont établis entre les interlocuteurs. Le canal de signalisation est utilisé pour transmettre la signalisation et le canal de données est utilisé pour transmettre des données multimédias telles que la voix et la vidéo. Par conséquent, le trafic SIP est classé en flux de signalisation et en flux multimédias. Les flux de signalisation sont transmis via UDP ou TCP. SIP peut utiliser le port UDP 5060 (non crypté) ou le port TCP 5061 (crypté TLS) pour transmettre les flux de signalisation, y compris les paquets de demande et de réponse des correspondants. Les flux multimédias, y compris les paquets de données vocales et vidéo, sont transmis via RTP et RTCP.

1.2 Processus d'échange de messages SIP

La figure suivante montre l'interaction de message SIP typique.


1



1. Le client 1 envoie une demande INVITE au proxy SIP, demandant au proxy d'inviter le client 2 à rejoindre la session. Le client 1 envoie sa propre adresse IP et son numéro de port au proxy via la description de session du message INVITE (la clé est l'information de contrôle multimédia décrite par le protocole SDP (Session Description Protocol) dans le corps du message).


Comme le montre la figure ci-dessous, le champ Informations de connexion du corps du message contient sa propre adresse IP et le champ Description du support contient le numéro de port, qui est utilisé pour indiquer à l'autre partie où envoyer les données multimédia.


1



2. Le proxy répond par 100 Trying to Client 1 pour indiquer que le message de demande a été reçu et est en cours de traitement.


3. Le proxy transmet le message INVITE au client 2, demandant au client 2 de rejoindre la session. Le message INVITE transporte la description de session du client 1 au client 2.


4. Le client 2 renvoie 100 Trying au proxy pour indiquer que le message de demande a été reçu et est en cours de traitement.


5. Le client 2 sonne et une réponse 180 Ringing est renvoyée au proxy pour notifier le proxy.


6. Le proxy répond avec une réponse de sonnerie 180 au client 1 et le client 1 entend la tonalité de retour d'appel.


7. L'utilisateur du client 2 décroche le téléphone pour répondre à l'appel, et le client 2 renvoie une réponse 200 OK au proxy, indiquant que la demande INVITE envoyée par celui-ci a été acceptée et traitée avec succès. Le message porte la description de session du client 2 (informations de contrôle de média décrites par le protocole SDP, principalement sa propre adresse IP et numéro de port pour les connexions média ultérieures) et l'envoie au proxy.


8. Le proxy envoie une réponse 200 OK au client, indiquant que la demande INVITE qu'il a envoyée a été acceptée et traitée avec succès, et la description de session du client 2 est envoyée au client 1.


9. Le client 1 envoie un message ACK au proxy, indiquant qu'il a reçu la réponse finale du proxy à la demande INVITE.


10. Le proxy envoie un message ACK au client 2, indiquant qu'il a reçu la réponse finale du client 2 à la demande INVITE. À ce stade, l'appelant et l'appelé connaissent la description de la conversation de l'autre partie et démarrent la conversation.


11. Pendant la conversation entre le Client 1 et le Client 2, des données multimédias sont échangées.


2 Présentation de SIP ALG

Comme mentionné précédemment, SIP peut utiliser le port UDP 5060 ou le port TCP 5060 (non crypté)/le port 5061 (cryptage TLS) pour transmettre le flux de signalisation. Pour que le flux de signalisation passe en douceur à travers les dispositifs de sécurité tels que le FW, il faut que celui-ci soit configuré dans FW. La politique de sécurité permet au flux de signalisation SIP de passer. Cependant, le flux multimédia est transmis via le port négocié par la couche application en utilisant des paquets de signalisation, et l'administrateur du numéro de port ne peut pas prédire à l'avance, et ne peut donc pas libérer le flux multimédia en configurant des politiques de sécurité sophistiquées.

D'autre part, dans le scénario NAT, le NAT ordinaire ne peut traduire que l'adresse IP de la couche réseau du message et le port de la couche transport, mais ne peut pas traduire l'adresse IP et les informations de port dans la couche application, provoquant une signalisation ultérieure. et les interactions de flux multimédia échouent. monter.

À ce stade, vous devez activer la fonction SIP ASPF/ALG sur le micrologiciel, détecter et convertir les informations IP et de port contenues dans les informations de couche application de message et les enregistrer dans la carte du serveur. Lorsque le message de données multimédia passe par le micrologiciel, il atteint la carte du serveur. Il est libéré et n'est plus contrôlé par la politique de sécurité.


2.1 Comment traiter avec SIP ALG

La figure suivante utilise le scénario NAT source dans lequel le client A est sur l'intranet et le client B et le proxy SIP sont sur l'extranet comme exemple pour décrire le processus d'interaction clé entre le client A, le client B et le proxy SIP et comment le pare-feu traite paquets après l'activation d'ASPF/ALG.


2

1. Le client A envoie une demande INVITE au port 5060 du proxy SIP pour appeler le client B. Le champ Via dans l'en-tête de la demande INVITE contient l'adresse de l'expéditeur (en supposant que l'adresse est 192.168.1.1:2000), et le corps du message contient les informations de contrôle multimédia décrites par le protocole de description de session (SDP). (L'adresse IP et le numéro de port indiqués par les champs Informations de connexion et Description du support indiquent l'adresse IP et le numéro de port auxquels l'homologue envoie les flux multimédias. Supposons que l'adresse IP et le numéro de port sont 192.168. 1.1:3000.)


2. Après avoir reçu la demande INVITE, le pare-feu traduit l'adresse IP et le numéro de port, transmet la demande au proxy SIP, crée une session de canal de signalisation et crée une carte de serveur basée sur l'adresse IP et le numéro de port dans l'en-tête et le corps de la demande INVITE pour autoriser les paquets d'interaction suivants.

Le pare-feu crée deux mappages de serveur en fonction de l'adresse de connexion multimédia dans le corps du message pour autoriser les flux RTP et RTCP. Numéro de port utilisé par le flux RTCP = Numéro de port du flux RTP + 1.


<sysname> display firewall session-table

sip  VPN:public --> public 192.168.1.1:2000[1.1.1.10:2222] +-> 1.1.1.1:5060

<sysname> display firewall server-map aspf

Type: ASPF, ANY -> 1.1.1.10:2222[192.168.1.1:2000], Zone: ---

Protocol: tcp(Appro: sip), Left-Time: 00:02:00

VPN: public -> public

Type: ASPF, ANY -> 1.1.1.10:3333[192.168.1.1:3000], Zone: ---

Protocol: tcp(Appro: sip-rtp), Left-Time: 00:00:50

VPN: public -> public

Type: ASPF, ANY -> 1.1.1.10:3334[192.168.1.1:3001], Zone: ---

Protocol: tcp(Appro: sip-rtcp), Left-Time: 00:00:50

 VPN: public -> public


Le micrologiciel crée une carte de serveur (la première carte de serveur) pour les flux de signalisation afin de permettre aux données de signalisation ultérieures envoyées du client B au client A. De plus, deux cartes de serveur (la deuxième carte de serveur et la troisième carte de serveur) sont créées pour les données. pour autoriser les données multimédias suivantes envoyées par le client B au client A.


3. Le proxy SIP transmet le message INVITE au client B, demandant au client B de se joindre à l'appel, et envoie le message INVITE portant la description de session du client A au client B.


4. Le client B est alerté et envoie une réponse 180 au proxy SIP.


5. Le proxy SIP transmet la réponse 180.


6. Après avoir reçu la réponse 180, le pare-feu correspond à la session du canal de signalisation, convertit l'adresse de destination du paquet en adresse IP et numéro de port réels du client A, et transfère le paquet au client A. Le client A entend la tonalité de rappel.


7. Le client B répond à l'appel. Le client B envoie une réponse 200 OK au proxy SIP, indiquant que la demande INVITE du proxy SIP a été acceptée et traitée avec succès. Le champ Via dans l'en-tête du message contient les informations d'adresse de l'expéditeur (supposons que la valeur est 1.1.1.2:3000), et le corps du message contient les informations de contrôle multimédia décrites par le protocole de description de session (SDP) (adresse IP et port numéro indiqué par les champs Connection Information et Media Description). Indique l'adresse et le numéro de port auxquels le flux multimédia est envoyé. Supposons que l'adresse et le numéro de port sont 1.1.1.2:4000.


8. Le proxy SIP transmet la réponse 200 OK, indiquant que la demande INVITE a été acceptée et traitée avec succès. La réponse 200 OK porte la description de session du client B.


9. Après avoir reçu la réponse 200 OK, le pare-feu traduit l'adresse de destination du paquet en l'adresse IP réelle et le numéro de port du client A et transmet le paquet au client A. De plus, une carte de serveur est créée en fonction de l'adresse IP. et le numéro de port dans l'en-tête et le corps du message des 200 messages OK pour permettre les paquets d'interaction suivants.


<sysname> display firewall session-table

sip  VPN:public --> public 1.1.1.2:3000 +-> 1.1.1.10:2222[192.168.1.1:2000]

 <sysname> display firewall server-map aspf

Type: ASPF, ANY -> 1.1.1.2:3000, Zone: ---

Protocol: tcp(Appro: sip), Left-Time: 00:02:00

VPN: public -> public

Type: ASPF, ANY -> 1.1.1.2:4000, Zone: ---

Protocol: tcp(Appro: sip-rtp), Left-Time: 00:00:50

VPN: public -> public

Type: ASPF, ANY -> 1.1.1.2:4001, Zone: ---

Protocol: tcp(Appro: sip-rtcp), Left-Time: 00:00:50

VPN: public -> public



Le FW crée une carte de serveur (la première carte de serveur) pour les flux de signalisation afin de permettre aux données de signalisation ultérieures envoyées du client A au client B. De plus, deux cartes de serveur (la deuxième carte de serveur et la troisième carte de serveur) sont créées pour les données. pour autoriser les données multimédias suivantes envoyées du client A au client B.


10. Le client A envoie un message ACK au proxy SIP, indiquant que le proxy SIP a reçu la réponse finale à la demande INVITE.


11. Après avoir reçu le message ACK, le pare-feu traduit l'adresse IP et le numéro de port et transmet le message au proxy SIP.


12. Le proxy SIP transmet le message ACK au client B, indiquant que le client B a reçu la réponse finale à la demande INVITE. Dans ce cas, l'appelant et l'appelé connaissent l'adresse de connexion multimédia de l'autre partie et peuvent démarrer la conversation.


13. Pendant l'appel entre le client A et le client B, le flux multimédia correspond à la carte du serveur. Le fw crée deux sessions (session RTP et session RTCP) pour la direction du client A vers le client B et du client B vers le client A.


<sysname> display firewall session-table

sip-rtp  VPN:public --> public 192.168.1.1:10004[1.1.1.10:12314] --> 1.1.1.2:4000

sip-rtcp  VPN:public --> public 192.168.1.1:10005[1.1.1.10:12315] --> 1.1.1.2:4001

sip-rtp  VPN:public --> public 1.1.1.2:3334 --> 1.1.1.10:3333[192.168.1.1:3000]

sip-rtcp  VPN:public --> public 1.1.1.2:3335 --> 1.1.1.10:3334[192.168.1.1:3001]


C'est ce dont je veux parler/partager avec vous aujourd'hui, merci !


  • x
  • Standard:

Commentaire

Connectez-vous pour répondre. Se connecter | Enregistrer
envoyer

Remarque : Afin de protéger vos droits et intérêts légitimes, ceux de la communauté et des tiers, ne divulguez aucun contenu qui pourrait présenter des risques juridiques pour toutes les parties. Le contenu interdit comprend, sans toutefois s'y limiter, le contenu politiquement sensible, le contenu lié à la pornographie, aux jeux d'argent, à l'abus et au trafic de drogues, le contenu qui peut divulguer ou enfreindre la propriété intellectuelle d'autrui, y compris les secrets professionnels, les marques commerciales, les droits d'auteur et les brevets, ainsi que la vie privée personnelle. Ne partagez pas votre nom d'utilisateur ou votre mot de passe avec d'autres personnes. Toutes les opérations effectuées à partir de votre compte seront considérées comme vos propres actions, et toutes les conséquences en découlant vous seront imputées. Pour plus de détails, voir « Accord utilisateur ».

My Followers

Connectez-vous pour participer à la communication et au partage

S'identifier

Bloquer
Êtes-vous sûr de bloquer cet utilisateur?
Les utilisateurs de votre liste noire ne peuvent ni commenter votre publication,ni vous mentionner, ni vous envoyer de messages privés.
Rappel
Veuillez lier votre numéro de téléphone pour obtenir un bonus d'invitation.
Guide de Protection de L'information
Merci d'utiliser la Communauté D'assistance Huawei Enterprise ! Nous vous aiderons à savoir comment nous recueillons, utilisons, stockons et partageons vos informations personnelles et les droits que vous avez conformément à Politique de Confidentialité et Contrat D'utilisation.