Страница 2 из 3
Re: Retransmission timeout reached on transmission
Добавлено: 18 июн 2019, 13:22
Zavr2008
со специально открытым guest, для сбора подобной статистики
У тебя специально открыто окошко для залета отовсюду, а вот у ТС похоже просто от незнания.
ДЛЯ ВСЕХ: ЕСЛИ У ВАС НАЧИНАЕТ ДОГ ПУХНУТЬ ОТ ПОДОБНОГО :
to extension '+441273004119' rejected because extension not found in context 'default'.
ЗНАЧИТ CHAN_SIP УЖЕ ДАЛ ДОБРО, АВТОРИЗАЦИЯ УСПЕШНА И ДЕЛО ЗА МАЛЫМ - ПОДОБРАТЬ ФОРМАТЫ НОМЕРОВ
Re: Retransmission timeout reached on transmission
Добавлено: 19 июн 2019, 07:55
virus_net
Ессно я открыл специально, но не в default контекст конечно. Там специальная песочница со специально составленым dialplan для всяческих сканеров. Пущай развлекаются.
Ну так логично, что chan_sip дал добро, т.к. guest разрешён и никакой авторизации в принципе не было, а не в последствии взлома.
Да и подбор формата не будет означать, что 100% состоится успешный вызов. Все зависит от того в какой контекст попал guest и что в этом контексте есть. Но вот в default контексте много чего есть туда guest точно пихать не стоит.
Re: Retransmission timeout reached on transmission
Добавлено: 19 июн 2019, 13:14
Zavr2008
Знаешь же, что 90% всех кто сейчас ставит Asterisk - ставят себе FreePBX. Книг не читают, нихрена разбираться не хотят - ляпают по какой-нить горе-инструкции на Хабре или тостере..
Их нужно приучать сразу: АВТОРИЗАЦИЮ И ACL ЛИСТЫ - ПРОПИСЫВАТЬ ДЛЯ ВСЕХ host=dynamic !!! (для тех кто заползет в эту тему. Перечитайте и запомните!!!) Не дожидайтесь пока дойдет до того, что неясно кто из Сомали будет по диалплану да еще в контексте default гулять!!
1. Отключайте международку у своего ТфОП городского оператора.
2. Прописывайте allowguest=no, alwaysauthreject=yes ВСЕГДА
3. Прописывайте у всех динамических пиров (host=dynamic) списки deny/permit! ВСЕГДА!
4. Не доверяйте лишь fail2ban, это - опрометчиво.
5. ЗАКРОЙТЕ внешним роутиком доступ к AMI FreePBX и WEBIF !!!
6. 20 раз подумайте а надо ли для всего мира выставлять 5060/UDP. Обычно это лучше делать ТОЛЬКО если умеешь.
Re: Retransmission timeout reached on transmission
Добавлено: 20 июн 2019, 08:37
virus_net
Знаю, к сожалению. IT специалисты деградируют , как и нация в целом.
Всё больше копипастеров, тех кто ищет кнопку "сделать все хорошо" и тех кто натыкал всех подряд галок в веб ифейсе, но абсолютно не втыкает, что он сделал, но ведь заработало ж, а что ещё там понаоткрывалось это не важно.
Ваши советы это хорошо, но остаётся вопрос будут ли такие люди их читать или закроют пост со словами "многА букАВ".
Но разговор то у нас был не об этом, а о том что именно в его логе указывало/подтверждало факт взлома.
Re: Retransmission timeout reached on transmission
Добавлено: 20 июн 2019, 12:56
yur4ik
Всё больше копипастеров, тех кто ищет кнопку "сделать все хорошо" и тех кто натыкал всех подряд галок в веб ифейсе, но абсолютно не втыкает, что он сделал, но ведь заработало ж, а что ещё там понаоткрывалось это не важно.
Ваши советы это хорошо, но остаётся вопрос будут ли такие люди их читать или закроют пост со словами "многА букАВ".
Оффтоп конечно , но , у таких специалистов возможны три варианта развития :
Первый , забросить всю эту "заумную тягомотину" и поменять работу на что то более приятное и не требующее работы "серого вещества" ...
Второй , таки напрячь "серое вещество" и через боль и ошибки пытаться таки достичь развития в той области где сейчас работают .
И третий , самый "вкусный" . платить деньги специалистам которые все сделают правильно и "красиво" и вот тут эти самые специалисты смогут заработать на хлеб с маслом , а иногда и с икоркой ...
Пы.сы. Как говорит мой начальник , пока существуют люди которые не знают , не умеют или все портят желанием самим что то настроить , мы с тобой без работы не останемся .....
Re: Retransmission timeout reached on transmission
Добавлено: 20 июн 2019, 21:02
Zavr2008
а о том что именно в его логе указывало/подтверждало факт взлома
Скорее мы наблюдаем лишь последствие: При нормальном ходе вещей до выполнения диалпалана не доходит дело, а конкретно до перебора паттернов в контексте.
Смотреть ранее надо, где он там пролез и когда ..
Re: Retransmission timeout reached on transmission
Добавлено: 21 июн 2019, 08:08
virus_net
Так если guest разрешён, то какая разница какой номер набирается? Правильно, никакой.
Идёт выполнение того контекста, в который и отправили guest'а
а там уже или такой exten есть в этом контексте или его там нет, о чем и сообщает лог.
Re: Retransmission timeout reached on transmission
Добавлено: 21 июн 2019, 13:56
Zavr2008
Так если guest разрешён
Это и есть самая большая ошибка новичков.
Отключать нужно.
Re: Retransmission timeout reached on transmission
Добавлено: 28 июн 2019, 17:24
testvtigercrm123
Хм, раскритиковали (обоссали), одобряю. Каюсь книжки не читал по астериску, только по статьям вникал. Но как появится свободное время сразу попробую прочитать.
to extension '+441273004119' rejected because extension not found in context 'default'.
я
guest отрубал, может
reload забыл тогда сделать
и в контексте default прописано
может там все и пусто должно быть, я точно не знаю, что скажете?
ну я так понял, это вполне обычное дело
retrans_pkt: Timeout, просто мешало логи звонка смотреть, сейчас отсекаю через grep
Код: Выделить всё
[Jun 28 17:10:59] WARNING[845]: chan_sip.c:4131 retrans_pkt: Timeout on 1136552847-1459711270-150199533 on non-critical invite transaction.
[Jun 28 17:11:00] WARNING[845]: chan_sip.c:4131 retrans_pkt: Timeout on 633067290-508861190-1801129485 on non-critical invite transaction.
[Jun 28 17:11:00] WARNING[845]: chan_sip.c:4131 retrans_pkt: Timeout on 1096647218-801447036-2053110939 on non-critical invite transaction.
[Jun 28 17:11:00] WARNING[845]: chan_sip.c:4131 retrans_pkt: Timeout on 1224425441-700468063-305588597 on non-critical invite transaction.
[Jun 28 17:11:02] WARNING[845]: chan_sip.c:4131 retrans_pkt: Timeout on 891464720-1509969613-1252150112 on non-critical invite transaction.
[Jun 28 17:11:02] WARNING[845]: chan_sip.c:4131 retrans_pkt: Timeout on 267518525-302707866-1555973672 on non-critical invite transaction.
[Jun 28 17:11:02] WARNING[845]: chan_sip.c:4131 retrans_pkt: Timeout on 250405688-2137334852-1910548020 on non-critical invite transaction.
Re: Retransmission timeout reached on transmission
Добавлено: 28 июн 2019, 17:40
ded
non-critical invite transaction.
Некритично.
Хватит спамить, хватит каяться, возьмитесь за чтение, пора.