Port forwarding HTTP/HTTPS from WAN2 to VLAN
-
@ptz-m
Ну , так посмотрите на нужных интерфейсах с помощью tcpdump , какой обмен пакетами происходит , и все ли верно ?
Получает ли Аsterisk пакет SIP Register , и что и куда он на него отвечает
Я бы лично начал бы с изучения трафика на интерфейсе , на котором висит Asterisk .
Те , Ваша задача состоит в том , чтобы определить , нет ли проблем передачи нужного трафика ( и изучение самого трафика ) в момент установления соединения ( на всех интерфейсах , которые участвуют в этом процессе )
-
В общем ситуация с SIP похожа на лабиринт Минотавра для пакетов UDP, поэтому плюнул, сижу через мобильную сеть.
Сейчас интересно другое, уже несколько раз pfSense вис наглухо. Сегодня zabbix успел выдать "Too many processes on pfsense", а в логах постоянно висит "Service 19009-tcp: server exit with 0 running servers" и такое:
Nov 29 09:31:55 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:31:55 kernel config_aqm Unable to configure flowset, flowset busy!
Nov 29 09:31:55 php-fpm 9500 /rc.filter_configure_sync: Not installing NAT reflection rules for a port range > 500
Nov 29 09:31:55 php-fpm 9500 /rc.filter_configure_sync: Not installing NAT reflection rules for a port range > 500
Nov 29 09:31:55 xinetd 29375 Starting reconfiguration
Nov 29 09:31:55 xinetd 29375 Swapping defaults
Nov 29 09:31:55 xinetd 29375 readjusting service 19000-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19000-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19001-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19001-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19002-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19002-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19003-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19003-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19004-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19004-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19005-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19006-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19007-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19008-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19009-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19010-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19011-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19012-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19013-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19014-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19015-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19016-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19017-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19018-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19019-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19020-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19021-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19022-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19023-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19024-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19025-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19026-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19027-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19028-tcp
Nov 29 09:31:55 xinetd 29375 Reconfigured: new=0 old=34 dropped=0 (services)
Nov 29 09:31:56 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:31:57 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:31:58 xinetd 29375 Deactivating service 19012-tcp due to excessive incoming connections. Restarting in 10 seconds.
Nov 29 09:31:59 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:32:00 sshguard 70811 Exiting on signal.
Nov 29 09:32:00 sshguard 71823 Now monitoring attacks.
Nov 29 09:32:01 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:32:01 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:32:02 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:32:04 xinetd 29375 Activating service 19009-tcp
Nov 29 09:32:06 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
нашёл смежную тему [Resolved]"Service 19050-tcp: server exit with 0 running servers" = ??
10 месяцев назад, как раз и трогали NAT reflection и NAT+proxy mode, что бы пропихнуть трафик в обратку.
Обновления никакие не ставил последний месяц. IPSec так и не использую, только OpenVPN по сертификатам.
Идеи? -
@ptz-m
Да все, что угодно может быть. Гадалки в отпуске.
Нес-ко раз настриваил прохождение voip на пф по оф. доке - проблем не было.
Зы. У тебя там и шейпер включен? -
Подниму тему, хотя наверное немного и то. Надеюсь поправят.
Итак, ситуация на вложенном изображении
В 1-ом случае "внешний" SIP-телефон почему-то проброшен на IAX порт, хотя он работает по портам SIP. Такое видел один раз, но не факт, что не проскакивает в принципе.
Ниже указанные правила в экране. Как видим Asterix (это уже не старая коробка, как раньше, а последняя версия на FreePBX на новом Ubuntu) с IP ....0.151 мы отправляем на WAN1 в MiltiWAN, поскольку перепрыгивания между WAN оператором телефонии расцениваются как DDOS-атака и нас банили. Аналогично IAX туннель в других офисах настроен на наш WAN1.
Во 2-ом и 3-ем случае мы видим задвоение. В результате IAX туннель висит наглухо и пока не убьёшь одно из соединений - не восстанавливается.
Вот так всё работает стабильно. Ничего ручками не маршрутизируем или перебрасываем.
Такая ситуация тянется не первый год на PfSense. Раньше мы не понимали, почему только в нашем офисе такие затупы канала и грешили на АТС. В результате чего просто перегружали её. После замены АТС, стало понятно, что дело именно в PfSense!
Соответственно вопрос - почему так происходит с пробросом портов? Что-то не так зеркалится? Как можно поправить?
UPD Ситуация получило развитие. В разделе "Состояния" порты 4569 на наши транки ВООБЩЕ перестали показываться с определённого времени. Вот буквально на той недели было, а со вчера нет. За то мы видим странную запись 192.XXX.XXX.1:4569 -> 192.XXX.XXX.61:80 со статусом FIN_WAIT_2:FIN_WAIT_2 Этот тем страннее, что по данному IP стоит вообще другой сервер и он ТОЧНО на 4569 НЕ ХОДИТ!!! Но ходит по портам 45690 и 45692 и т.д.
-
This post is deleted!
