Comment configurer le sip « tronc » App-ID

Remarque: les clients ne sont pas tenus de modifier les stratégies de pare-feu à moins que les conditions décrites ci-dessous ne soient utilisées.

Problème: les pare-feu sont généralement requis pour agir en tant qu'aig pour créer des trous d'épingle pour les sessions SIP et fournir des capacités de traduction d'adresses. Le « sip » App-ID crée ces piqûres qui permettent le protocole pour fonctionner en toute transparence lorsqu’il rencontre le pare-feu. Lorsqu’un serveur SIP, communiquer à l’aide de NAT statique dans une zone (source) émet le trafic qui est destiné à un serveur SIP dans une autre zone (destination), le pare-feu crée un trou d’épingle qui permet en conséquence un hôte à l’aide de SIP au sein de la zone de destination pour communiquer avec le SIP server dans la zone source. Par exemple, un serveur SIP P.Q.R.S de la source zone statique NAT-ed à la D.E.F.G:5060, dépêches un SIP REGISTER message vers un serveur SIP externe A.B.C.D:5060 dans la zone de destination. Cela se traduit par le pare-feu, créant un trou d’épingle qui accepte les connexions entrantes à partir des hôtes dans la zone de destination adressée au D.E.F.G:5060.

Résolution: le "SIP-Trunk" app-ID désactive la création d'un tel sténopé Lorsqu'il est utilisé en conjonction avec une application override. Cette App-ID est destiné à être utilisé entre les serveurs SIP connus. Les adresses source et de destination de ces serveurs doivent être spécifiés, avec leur trafic SIP substituée à la nouvelle « sip-tronc » App-ID. En outre, compte tenu de l’absence d’un trou d’épingle, les administrateurs sont tenus pour configurer une règle de stratégie de sécurité qui autorise le trafic entre ces serveurs dans le sens inverse. Ceci permet aux serveurs SIP de communiquer entre eux, et l’absence du sténopé empêche le pare-feu accepte les connexions entrantes des autres hôtes au sein de la zone de destination.

Exigences :

• Conservateur SIP ou Proxy est statiquement coordonnée à travers le pare-feu
• Trunking SIP est utilisé dans l’environnement
• Version de base de données contenu 518 ou supérieure

Notez que passer à sip-tronc nécessite effacer tout le trafic SIP actif, alors le processus sera perturbatrice aux utilisateurs.  Nous vous recommandons une fenêtre panne ou maintenance de programmation après des heures à mettre en œuvre ces changements.  Aussi, tous les ports autres qu’udp/5060 qui sont utilisés par votre serveur SIP devront être ajoutés à la nouvelle politique en conséquence.

Comment mettre en œuvre :

1) créer une stratégie de demande de substituer à une règle qui autorise le trafic sip-tronc sur udp/5060 ainsi que tous les autres ports qui sont utilisés par cette application dans votre environnement.  La politique peut être limitée à seulement correspondre le trafic SIP désiré en spécifiant la source et des adresses IP de destination mais aussi les zones.

2) créer une stratégie de sécurité qui bloque l’application « sip ».

3) créer un objet de Service qui contient udp/5060 ainsi que tous les autres ports requis par vos serveurs SIP.

4) créer des stratégies de sécurité sous la règle créée à l’étape précédente qui permet à l’application « sip-tronc ».  Cette politique devrait être limitée à seulement correspondre le trafic SIP désiré en spécifiant la source et des adresses IP de destination mais aussi les zones.

5) créer une source de bi-directionelle statique politique NAT.

6) commettre politique.

7) Effacez toutes les sessions SIP actuelles de l'interface CLI (Remarque: cette commande perturbera tout le trafic SIP actif):

> effacer session tout filtrer sip application

8) effacer le cache de l’application de la CLI :

> clair appinfo2ip