العلامة النجمية: جذوع خارجية في حالة إرسال الطلب

صورة مألوفة؟

[root@pbx scripts]# asterisk -x "sip show registry"
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

مرة واحدة حصلت لي أيضا ، وكتبت سيناريو.

حاولت البحث عن وصفات جاهزة ، وأغلقت الأغلبية على ذلك: حصلت على أمر ping من العناوين ، وشغلت التصحيح ورأيت فيه بالضبط ما قيل في الجملة الأولى من الاقتباس "الحزم تذهب ، لكن الإجابات لم تأت". لكن لماذا؟ تم استبعاد النقطة رقم 1 الابتدائية. النقطة رقم 2 - أيضًا ، لأن اتصال اختبار من نفس عنوان IP ولكن عمل مضيف داخلي مختلف. النقطة رقم 4 هي بالتأكيد "zhost". لكن الرقم 3 أقرب بالفعل. لا يتم حظره ، ولكن لسبب ما لا يسمح للمضيف بتبادل الحزم مع العلامة النجمية. ويحدث هذا في 99٪ من الحالات بعد النقطة 2 ، عندما تنقطع جلسة PPPoE. ثم يتم استعادة الجلسة ، كما يتوفر الوصول إلى الإنترنت من شبكة LAN ، ولكن جلسات UDP عالقة. إليك ما يخبرنا Mikrotik من خلاله هذه الجلسات:

, .

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
 #          PR.. SRC-ADDRESS           DST-ADDRESS           TCP-STATE   TIMEOUT     ORIG-RATE REPL-RATE ORIG-PACKETS REPL-PACKETS      ORIG-BYTES
 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

هذه هي حالة الجلسات في الوضع العادي عندما يعمل كل شيء. في حالة عدم وجود تسجيلات ، إذا كانت الذاكرة تخدمني بشكل صحيح ، فلا يوجد إشارة S - رؤية - رد.

نحاول قطع الجلسات العالقة باستخدام الأمر:

[admin@MikroTik] > ip firewall connection remove [find where dst-address~":5060" and srcnat]

وها ، ها هي حرفيا في جذوع ثانية يتم استعادتها ، مكالمات مستمرة ، تزهر الحياة بألوان زاهية! لذلك نحن نكتب سيناريو!

أولاً ، نحتاج إلى التحكم في Mikrot بناءً على معلومات من النجمة. لذلك ، سيتم تشغيل البرنامج النصي في cron كل 5 دقائق على المضيف مع النجمة ، وسندير Mikrot عبر ssh بشهادة. هنا هناك تماما رسمت كل شيء - كيفية إنشاء مفتاح وربطه إلى مستخدم جديد على صغر صيوان الأذن.

حسنًا ، النص نفسه:

#!/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

فقط في حالة ، بعد ثانيتين من إعادة تعيين جلسات المكالمة ، نقوم بتحديث التسجيل - بحيث يعمل بالتأكيد!

اعتبارًا من 4 سبتمبر 2019 ، عمل البرنامج النصي 273 مرة ، بناءً على السجل. يمكنك حساب مقدار ما أنقذني من وقت ، وأعصاب المديرين وعملائهم.

ملاحظة: يحدث وضع مماثل على جميع أجهزة التوجيه التي صادفتها بالتزامن مع العلامة النجمية. ويمكن فقط لـ Mikrot حل المشكلة دون التأثير على الخدمات الأخرى. يجب أن يتم تحميل بقية أجهزة التوجيه بشكل زائد بغباء.

All Articles