¿Una foto familiar?[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
Una vez ella también me atrapó y escribí un guión.Traté de buscar recetas preparadas, la mayoría se redujo a esto: obtuve un ping de las direcciones, activé la depuración y vi exactamente lo que se decía en la primera oración de la cita "los paquetes se van, pero las respuestas no llegan". ¿Pero por qué? El punto número 1 se descartó elemental. Punto número 2 - también, porque una conexión de prueba desde la misma dirección IP pero funcionó un host interno diferente. El punto número 4 es absolutamente "zhost". Pero el número 3 ya está más cerca. Simplemente no bloquea, pero por alguna razón no permite que el host intercambie paquetes con Asterisk. Y esto sucede en el 99% de los casos después del punto 2, cuando se rompe la sesión PPPoE. La sesión se restaura y el acceso a Internet desde LAN también está disponible, pero las sesiones UDP están bloqueadas. Esto es lo que Mikrotik nos dice a través de lo que pasan estas sesiones:, .
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
Este es el estado de las sesiones en modo normal cuando todo funciona. En ausencia de registros, si la memoria me sirve correctamente, no hay una bandera S - vista-respuesta.Intentamos reducir las sesiones atascadas con el comando:[admin@MikroTik] > ip firewall connection remove [find where dst-address~":5060" and srcnat]
Y, he aquí, literalmente, en un segundo troncos se restauran, las llamadas continúan, ¡la vida florece con colores brillantes! ¡Entonces estamos escribiendo un guión!Primero, necesitamos controlar a Mikrot según la información de Asterisk. Por lo tanto, el script se ejecutará en cron cada 5 minutos en el host con Asterisk, y administraremos Mikrot a través de ssh con un certificado. Aquí se pintó perfectamente todo: cómo crear la clave y vincularla a un nuevo usuario en la microtia.Bueno, el guión en sí:#!/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
Por si acaso, 2 segundos después del reinicio de las sesiones colgadas, actualizamos el registro, ¡para que definitivamente funcione!Desde el 4 de septiembre de 2019, el guión funcionó 273 veces, a juzgar por el registro. Puedes calcular cuánto me ahorró tiempo, y los gerentes y los nervios de sus clientes.PD. Una situación similar ocurre en todos los enrutadores que encontré junto con Asterisk. Y solo Mikrot puede resolver el problema sin afectar otros servicios. El resto de los enrutadores deben estar estúpidamente sobrecargados.