Gansterito

Можно попробовать через модуль hashlimit с hashlimit-mode=srcip,srcport. Этот параметр поможет выполнить условие лимит на коннект.
Но, мне кажется, что правильней держать черные и белые списки на ipset.

Source-адрес будет выбран по умолчанию с того интерфейса, через который идет маршрут до нужного узла.
Если на интерфейсе несколько IP-адресов, то берется тот, что первый (primary).
Если в используемой программе есть возможность указать IP-адрес источника запросов, то с этого адреса и пойдут IP-пакеты.
Утилита чтобы посмотреть трафик - tcpdump (linux, freebsd), wireshark (linux, windows).

А для чего Вам это? Что-то "подвисает" или хотите периодически менять IP-адрес?
Посмотрите какие команды есть в меню "cmd". Если там стандартный unix shell, то сгодится команда reboot (или shutdown -r now). Если там все-таки меню, то полазайте в нем, поищите подходящую команду.
Автоматизация выполнения скриптов telnet в Windows возможна, например, через Windows Script Host, примеры в интернете есть.

Могу предложить два варианта:
1) Хеш-функция от переменной UniqueueID. Функция должна выдавать значение от 1 до 20 (или сколько у Вас там). Как эту функциою написать - другая задача, но тут возможны коллизии, когда один файл может повториться более одного раза.
2) Установка каждому вызову SET(GROUP()=mygroup), а затем проигрывание файла ${GROUP_COUNT(mygroup)}.wav. Это почти такой же вариант как от предыдущего комментатора, но без глобальной переменной, а через группу. Гарантирует уникальность проигрываемого одновременно файла.

Не совсем понятно что подразумевается под "разработчиком". Если это программист на С, пишущий модули или закрывающий баги в *, то это одно направление. Если это программист на Python/Perl/etc, пишущий систему, взаимодействующую с * через AMI/AGI/ARI - другое. Если это человек, пишуший кОнфиг к * ручками, оптимизирующий его работу - третье.
В любом случае, войдя в направление "телефония" придется самостоятельно расширять свой кругозор, расти. А там уже будут новые горизонты - "highload", масштабируемые решения и т.д.
Возможно, потребуются глубокие знания SIP (справочник Гольдштейна в помощь) и других телефонных протоколов - PRI, SS7 и т.д.

Не совсем понятно в какой момент (с привязкой к какому событию) необходимо передавать пакет сторонней системе.
Если важен только факт вызова (не важно отвечен или нет), то достаточно сделать как в примере выше - system на неблокирующий скрипт. Может быть, перед System поставить Ringing, чтобы КПВ уже ушел звонящему абоненту.
Если важен факт ответа (и другие параметры - длительность вызова и т.д.), то System нужно вешать на событие Hangup, которое сгенерируется после окончания разговора.
Если важен момент ответа, то нужно колдовать с флагом G команды Dial.

Заходите на S20 по SSH, там запускайте 2 экземпляра tcpdump - на внешний интерфейс в сторону оператора и на внутренний, в сторону телефонов. Примерно так: tcpdump -i eth0 -n -s0 -w /tmp/dump-eth0.pcap
Еще желательно запустить asterisk -rvvvvv для сбора данных из консоли. На всякий случай.

Далее, делаете тестовый вызов, ждете "обрыва" через 186 секунд. Прерываете tcpdump, загружаете себе на декстоп оба дампа, открываете оба уже упомянутым выше Wireshark-ом, смотрите что происходило (меню Telephony - Sip flows сильно поможет).

Вопрос "по времени" - 186 секунд многовато, чтобы не соответствовать каким-то таймингам SIP-а на прерывание разговора. Обычно 15 или 30 секунд - потерялся "ACK". А 186 - скорее где-то ошибочно выставляется длительность звонка. Может быть NAT теряет "трансляцию", но тогда прерывался бы голос (RTP), а сам вызов продолжался бы.

Можно предложить три варианта:
1) Сам роутер Zyxel актуализирует список занятых устройств (включенных, например, мимо DHCP);
2) Кто-то за пределами роутера пытается "достучаться" до ваших внутренних адресов;
3) Кто-то изнутри роутера (а там внутри Linux со всем окружением + shell) пытается найти что-либо для своего дальнейшего "проникновения" и "закрепления" на вашей сети.

За последние пару дней слышал о какой-то аномальной активности абонентов с роутерами Zyxel, однако, подтверждения этому не было. На всякий случай отключите роутер от внешней сети, посмотрите на активность. Можно сбросить к заводским настройкам, обновить прошивку до последней и, не подключая к сети, проверить наличие who has запросов. Но это уже на любителя.

Несколько Mikrotik с CAPsMAN.

А uart-usb нормально работает? Может быть драйвер встал криво?
Можно посмотреть PortMon от Sysinternals - какой процесс занимает порт.
Можно попробовать подключиться к COM9 чем-то типа гипертерминала (такая программа все еще существует?) или Putty чтобы проверить доступность порта.

Можно. Раньше были радио-конструкторы на базе Z80, где реализован "российский АОН" (который поднимал трубку и "курлыкал" в линию). Сейчас на новых ГАТС есть функция "Евро АОН" (который трубку не поднимает), но включен он не везде, и зачастую идет как доп. услуга.
Наверное, оба варианта можно реализовать на современной базе - Arduino и пр.
Мануалы и схемы - искать в журнале Радио. Теорию - в многочисленных трудах Гольдштейна.

Посмотрите tcpdump-ом на стороне Asterisk доходят ли до него SIP-пакеты REGISTER, отвечает ли Asterisk.

Подключите выделенный ноутбук проводом в локальную сеть и запустите wireshark на нем на сколько-нибудь длительный период. Возможно, в сети есть широковещательный флуд, в wireshark вы его сможете увидеть.

При 50ти внутренних клиентах целесообразно сегментировать сеть, как проводную (по этажам, офисам, отделам, etc), так и wifi (гостевой, для личных устройств, для служебного использования).

А покажите вкладку Wireless - Interfaces и еще откройте отсюда же сам wlan1

А в каком режиме идет DTMF от Asterisk в сторону GSM-шлюза?
Может быть Asterisk генерирует DTMF в соответствии с rfc2833, а звуковые тоны воспроизводит сам GSM-шлюз (как ему захочется/сможется)?

Самый правильный способ - потребовать провайдера отключить этот функционал.
Отвечая на ваш вопрос - через /tool fetch можно отправить в том числе и POST запрос с произвольными полями. Если форма статическая (без капчи, галочек и прочего) - то проблемы нет.
Другое дело - распознать перенаправление. Тут, пожалуй, придется поэкспериментировать - посмотреть как сделана переадресация на страницу кэптив портала и подогнать логику под нее.

Добавить на DLINK используемые VLAN и прописать их на портах в сторону Mikrotik-ов в режиме "tagged".
Либо все порты DLINK в сторону Mikrotik настроить в режим TRUNK (не уверен, что в DGS-1100 есть этот режим).

Выше уже написали, что нужно сегментировать сеть. Эта задача и стратегическая (будете решать после устранения проблемы) и тактическая (ограничение распространения зловреда).

Сегментировать нужно заменой коммутаторов на управляемые с функционалом vlan, acl, dhcp snooping (на перспективу), loopback detection. Закупить коммутаторов на ~ 6000 портов можно одним днем (это порядка 120 коммутаторов доступа не считая агрегацию и маршрутизатора). Выйдет все же дешевле финансовых и имиджевых потерь от простоев.

Как именно нужно сегментировать - можно определить только по месту. Может быть сразу отсечь сегменты, не занятые в оперативной деятельности компании, отправив туда 1-2 человек для зачистки антивирусом, а основные силы бросить на приведение в порядок сети. Может быть есть смысл "заблокировать всё" и открывать доступ к тем или иным ресурсам по мере возникновения проблем. Из 15 админов на месте можно оставить 5, а остальных (35) отправить разбираться у кого чего не работает. Все общение должно быть сведено к:
- Володя, это Сёмен, IP адрес 10.156.2.25, MAC-адрес заканчивается на 13-AC-F4 нужен доступ к 10.43.1.67, это рентген в кабинете 523
- Готово проверяй
- Да, есть, сделай тоже самое для XXX, YYY, ZZZ...