Ein bekanntes Bild?[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
Einmal hat sie mich auch erwischt und ich habe ein Drehbuch geschrieben.Ich habe versucht, nach vorgefertigten Rezepten zu suchen, die Mehrheit lief darauf hinaus: Ich bekam einen Ping der Adressen, schaltete das Debug ein und sah darin genau das, was im ersten Satz des Zitats "Pakete gehen, aber die Antworten kommen nicht" gesagt wurde. Aber warum? Punkt Nummer 1 wurde elementar ausgeschlossen. Punkt Nummer 2 - auch, weil Eine Testverbindung von derselben IP-Adresse, aber einem anderen internen Host funktionierte. Punkt Nummer 4 ist absolut "zhost". Aber Nummer 3 ist schon näher. Es wird nur nicht blockiert, aber aus irgendeinem Grund kann der Host keine Pakete mit Asterisk austauschen. Und dies geschieht in 99% der Fälle nach Punkt 2, wenn die PPPoE-Sitzung unterbrochen wird. Die Sitzung wird dann wiederhergestellt, und der Zugriff auf das Internet über das LAN ist ebenfalls verfügbar, UDP-Sitzungen bleiben jedoch hängen. Mikrotik sagt uns Folgendes, durch das diese Sitzungen gehen:, .
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
Dies ist der Status der Sitzungen im normalen Modus, wenn alles funktioniert. In Abwesenheit von Registrierungen gibt es, wenn der Speicher mir richtig dient, kein Flag S - gesehene Antwort.Wir versuchen, die festgefahrenen Sitzungen mit dem folgenden Befehl zu reduzieren:[admin@MikroTik] > ip firewall connection remove [find where dst-address~":5060" and srcnat]
Und siehe da, buchstäblich in einer Sekunde werden Stämme wiederhergestellt, Anrufe gehen weiter, das Leben blüht mit leuchtenden Farben! Also schreiben wir ein Skript!Zuerst müssen wir Mikrot basierend auf Informationen von Asterisk steuern. Daher wird das Skript alle 5 Minuten in cron auf dem Host mit Asterisk ausgeführt, und wir werden Mikrot über ssh mit einem Zertifikat verwalten. Hier gibt es alles perfekt gemalt - wie den Schlüssel zu erstellen und sie an einen neuen Benutzer auf der Mikrotie gebunden.Nun, das Skript selbst:#!/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
Nur für den Fall, 2 Sekunden nach dem Zurücksetzen der aufgesetzten Sitzungen aktualisieren wir die Registrierung - damit es definitiv funktioniert!Ab dem 4. September 2019 arbeitete das Skript 273 Mal, gemessen am Protokoll. Sie können berechnen, wie viel er mir Zeit gespart hat, und die Manager und ihre Kundennerven.PS Eine ähnliche Situation tritt bei allen Routern auf, die mir in Verbindung mit Asterisk begegnet sind. Und nur Mikrot kann das Problem lösen, ohne andere Dienste zu beeinträchtigen. Der Rest der Router muss dumm überlastet werden.