Une image familière?[root@pbx scripts]
Host dnsmgr Username Refresh State Reg.Time
sipnet.ru:5060 Y XXXXXXXXXXX 102 Request Sent Fri, 20 Mar 2020 09:19:31
87.103.236.26:5060 N XXXXXX 105 Request Sent Fri, 20 Mar 2020 09:20:55
sbc.megafon.ru:5060 Y XXXXXXXXXXX@ 165 Request Sent Fri, 20 Mar 2020 09:20:28
login.mtt.ru:5060 Y XXXXXXXXXXXXXX 105 Request Sent Fri, 20 Mar 2020 09:19:50
Une fois qu'elle m'a eu aussi, j'ai écrit un script.J'ai essayé de rechercher des recettes prêtes à l'emploi, la majorité se résumait à ceci: j'ai reçu un ping des adresses, allumé le débogage et y ai vu exactement ce qui était dit dans la première phrase de la citation "les paquets vont, mais les réponses ne viennent pas." Mais pourquoi? Le point numéro 1 a été exclu élémentaire. Point numéro 2 - aussi, car une connexion de test à partir de la même adresse IP mais d'un hôte interne différent a fonctionné. Le point numéro 4 est absolument "zhost". Mais le numéro 3 est déjà plus proche. Il ne bloque simplement pas, mais pour une raison quelconque, il ne permet pas à l'hôte d'échanger des paquets avec Asterisk. Et cela se produit dans 99% des cas après le point 2, lorsque la session PPPoE est interrompue. La session est ensuite restaurée et l'accès à Internet à partir du LAN est également disponible, mais les sessions UDP sont bloquées. Voici ce que Mikrotik nous dit à travers lequel ces sessions se déroulent:, .
1) .
2)
3)
4) .
..[admin@MikroTik] > /ip firewall connection print where dst-address~":5060" and srcnat
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
0 SAC s udp 10.X.X.X:5060 80.75.130.83:5060 59m48s 0bps 0bps 2 172 2 191 1 358 335
1 SAC s udp 10.X.X.X:5060 193.201.229.35:5060 59m47s 0bps 0bps 1 611 1 662 996 786
2 SAC s udp 10.X.X.X:5060 212.53.40.40:5060 59m44s 0bps 0bps 1 837 1 830 1 114 259
3 SAC s udp 10.X.X.X:5060 87.103.236.26:5060 59m21s 0bps 0bps 2 501 2 509 1 614 239
Il s'agit de l'état des sessions en mode normal lorsque tout fonctionne. En l'absence d'enregistrement, si la mémoire me sert correctement, il n'y a pas de drapeau S - vu-réponse.Nous essayons de réduire les sessions bloquées avec la commande:[admin@MikroTik] > ip firewall connection remove [find where dst-address~":5060" and srcnat]
Et voilà, littéralement dans un deuxième troncs sont rétablis, les appels continuent, la vie fleurit de couleurs vives! Nous écrivons donc un script!Tout d'abord, nous devons contrôler Mikrot sur la base des informations fournies par Asterisk. Par conséquent, le script sera exécuté en cron toutes les 5 minutes sur l'hôte avec Asterisk, et nous gérerons Mikrot via ssh avec un certificat. Ici , tout a été parfaitement peint - comment créer la clé et la lier à un nouvel utilisateur sur le microtia.Eh bien, le script lui-même:#!/bin/sh
if /usr/sbin/asterisk -x "sip show registry" | grep -q "Request Sent"; then
echo "$(date) Resetting UDP connections on Mikrotik" >> /var/log/asterisk/mikrotik
ssh -l admin-ssh -i /XXXX/.ssh/id_dsa 10.X.X.X 'ip firewall connection remove [find where dst-address~":5060" and srcnat]'
sleep 2
asterisk -x "sip reload"
fi
Juste au cas où, 2 secondes après la réinitialisation des sessions bloquées, nous mettons à jour l'enregistrement - pour que cela fonctionne définitivement!À partir du 4 septembre 2019, le script a fonctionné 273 fois, à en juger par le journal. Vous pouvez calculer combien il m'a fait gagner du temps, ainsi que les gestionnaires et leurs nerfs clients.PS Une situation similaire se produit sur tous les routeurs que j'ai rencontrés avec Asterisk. Et seul Mikrot peut résoudre le problème sans affecter les autres services. Les autres routeurs doivent être bêtement surchargés.