Uma imagem 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
Uma vez ela me pegou também, e eu escrevi um roteiro.Tentei procurar receitas prontas, a maioria se resumiu a isso: recebi um ping dos endereços, liguei a depuração e vi exatamente o que foi dito na primeira frase da citação "os pacotes vão, mas as respostas não vêm". Mas por que? O ponto número 1 foi descartado como elementar. Ponto número 2 - também, porque uma conexão de teste do mesmo endereço IP, mas um host interno diferente funcionou. O ponto número 4 é absolutamente "zhost". Mas o número 3 já está mais perto. Ele simplesmente não bloqueia, mas, por algum motivo, não permite que o host troque pacotes com o Asterisk. E isso acontece em 99% dos casos após o ponto 2, quando a sessão PPPoE é interrompida. A sessão é restaurada e o acesso à Internet pela LAN também está disponível, mas as sessões UDP estão bloqueadas. Aqui está o que o Mikrotik nos diz através do qual essas sessões passam:, .
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 é o estado das sessões no modo normal quando tudo está funcionando. Na ausência de registros, se a memória me servir corretamente, não há sinalizador S - visto resposta.Tentamos reduzir as sessões paralisadas com o comando:[admin@MikroTik] > ip firewall connection remove [find where dst-address~":5060" and srcnat]
E eis que, literalmente, em um segundo troncos são restaurados, as chamadas continuam, a vida floresce com cores vivas! Então, estamos escrevendo um script!Primeiro, precisamos controlar o Mikrot com base nas informações do Asterisk. Portanto, o script será executado no cron a cada 5 minutos no host com o Asterisk, e gerenciaremos o Mikrot via ssh com um certificado. Aqui há tudo perfeitamente pintado - como criar a chave e amarrá-la a um novo usuário na microtia.Bem, o próprio script:#!/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
Apenas 2 segundos após a redefinição das sessões suspensas, atualizamos o registro - para que ele funcione definitivamente!A partir de 4 de setembro de 2019, o script funcionou 273 vezes, a julgar pelo log. Você pode calcular quanto ele me economizou tempo e os gerentes e os nervos de seus clientes.PS Uma situação semelhante ocorre em todos os roteadores que encontrei em conjunto com o Asterisk. E apenas o Mikrot pode resolver o problema sem afetar outros serviços. O restante dos roteadores precisa ser estupidamente sobrecarregado.