Рост UDP сессий от клиентов

[Egenius]

Тоже по манам или к Ванге обращались?

По опыту. Ребутать железо после изменения любой строки в конфиге считаю вредно. Сделал, не помогло.

"ваше сиятельство" накосячило)

Скажите как можно накосячить, если любое изменение во FreePBX не применяется если где-то допущена ошибка?
Вот прямо сейчас поднял линк от другого провайдера с другим внешним IP и FreePBX мне любезно напомнил что не плохо было бы обновить настройки и нажав по заветной кнопке "Детектировать сетевые настройки" заполнил как внешний IP так и все мои подсети /24
Применил и перегрузил asterisk.
И вот незадача. В tcpdump снова валятся пакеты NOTIFY, но в заголовке From уже новый белый IP.
Т.е. косяк конечно на лицо, но уверен что не мой, а где-то в глубине астера или freepbx.
И вот этот косяк я и пытаюсь найти и исправить при помощи уважаемых гуру.

[ded]

Шлюз к локальным сетям через ASA, в интернет через шлюз провайдера.
Могу выслать Вам таблицу маршрутизации если нужно.

Вот ваша проблема. И она не относится к Астериску или FreePBX. Вы плохи в сетях, основные понятия. Потому что даже видя эти notify не понимаете как там внутри появляется белый ИП.

Если, допустим, Астериск = 192.169.14.8
192.168.14.1 это шлюз провайдера, default gateway, а ASA - 192.168.14.100, то сервер Астериск должен знать, что пакеты к адресам 192.168.15.48 надо направлять в ASA - 192.168.14.100, а не в default gateway. Указывать на шлюзе провайдера статический маршрут к сетям 192.168.Х.Х через ASA неправильно.
Прописать статические роуты к сетям подразделений в сервере, где крутится Астериск, через ASA - 192.168.14.100.

P.S. Я не гуру.

[Egenius]

Вот ваша проблема

С маршрутами все правильно.
192.168.14.1 - интерфейс ASA и он же шлюз для локальных сетей.

Код: Выделить всё

192.168.1.0/24 via 192.168.14.1 dev eth0
192.168.10.0/24 via 192.168.14.1 dev eth0
192.168.11.0/24 via 192.168.14.1 dev eth0
192.168.14.0/23 dev eth0 proto kernel scope link src 192.168.14.8
192.168.16.0/24 via 192.168.14.1 dev eth0
192.168.20.0/24 via 192.168.14.1 dev eth0

Дефолт в мир уходит через шлюз провайдера, в данном конкретном случае через IP 85.202.10.1 и отдельный интерфейс VLAN.

Код: Выделить всё

default via 85.202.10.1 dev vlan990

Ну и в добавок настройки IP на сервере.

Код: Выделить всё

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:b5:88:b7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.14.8/23 brd 192.168.15.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:feb5:88b7/64 scope link
       valid_lft forever preferred_lft forever
7: vlan990@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:b5:88:b7 brd ff:ff:ff:ff:ff:ff
    inet 85.202.10.30/24 brd 85.202.10.255 scope global dynamic vlan990
       valid_lft 3076sec preferred_lft 3076sec
    inet6 fe80::5054:ff:feb5:88b7/64 scope link
       valid_lft forever preferred_lft forever

Указывать на шлюзе провайдера статический маршрут к сетям 192.168.Х.Х через ASA неправильно.

Я и не указывал потому что это бред.
Была бы это проблема в маршрутах то ни локальные клиенты ни клиенты из филиалов не увидели бы сервер астера, да и сервер тоже не видел бы клиентов.

Проблема в том что астер по какой-то непонятной логике подставляет свой белый IP для локальных клиентов и именно эту проблему я и пытаюсь решить.
Ощущение что параметры local_net и localnet игнорируются.

[amateur]

Посмотрите есть ли в конфигурации chan_pjsip (pjsip.conf или сопутствующих) параметр from_domain и каково его значение.

[Egenius]

from_domain есть только в настройках одного из транков и его значение - домен сип-провайдера.

Еще заметил одну вещь
Помимо заголовков From в пакетах есть заголовок Via, и в нём как раз всегда используется верный IP в зависимости от клиента.
Вот пример пакет от локальноко клиента

Код: Выделить всё

        SIP/2.0 405 Method Not Allowed
        Via: SIP/2.0/UDP 192.168.14.8:5060;rport=5060;branch=z9hG4bKPj75fe0140-2743-461e-99a3-f920e85cfb15
        To: <sip:218@192.168.14.112;rinstance=ae9e24d7b9e4cab6>;tag=355e7610
        From: <sip:218@85.202.10.30>;tag=d2d0ae17-997d-4738-8400-0700224c1b7b
        Call-ID: 617d3d39-c0b6-4c6f-a3bd-0dbb9fd4cb83
        CSeq: 36774 NOTIFY

И вот от внешнего

Код: Выделить всё

        SIP/2.0 405 Method Not Allowed
        Via: SIP/2.0/UDP 85.202.10.30:5060;rport=5060;branch=z9hG4bKPj1ff41693-6d71-4fb0-bc4f-f42c94e410ba
        To: <sip:571@78.29.45.193;rinstance=7f0e807b37b004db>;tag=65156809
        From: <sip:571@85.202.10.30>;tag=d4f12a78-84c7-4b7e-aba9-f579173aa2d7
        Call-ID: ab3f0479-fbe6-4878-9b72-7b968c62290a
        CSeq: 12814 NOTIFY

Так что думаю не имеет особого значение что в поле From указан белый IP
Меня больше смущают что пакетов с "SIP/2.0 405 Method Not Allowed" валится очень много.

[Zavr2008]

Почему не попробовать отключить chan_pjsip и всё на проверенном chan_sip не сделать?

[Egenius]

Есть пара нюансов из-за которых пока не решаюсь на это.
Правильно я понимаю что нужно просто оставить один драйвер в "Дополнительных настройках" FreePBX и все extentions автоматом переконфигурируются под SIP ?
Или нужно делать экспорт всех extension через "Bulk Handler", менять тип драйвера и импортировать csv обратно ?

[Zavr2008]

вручную у каждого экстена в настройках можно сконвертировать, насчет всех разом - не делал, не такой я спец по FreePBX)
сам chan_pjsip можно и не отключать, просто освободить.

[Egenius]

Понял. Попробую на выходных.
Ещё раз спасибо!

[ded]

Была бы это проблема в маршрутах то ни локальные клиенты ни клиенты из филиалов не увидели бы сервер астера, да и сервер тоже не видел бы клиентов.

Не до конца понимаете суть SIP.
Есть SIP сигнальные пакеты UDP, в которых IP source => destination IP, это мы видим на уровне tcpdump, Layer 3. На этом уровне клиенты филиалов видят Астериск и он их видит.

А есть Layer 7 информация внутри этих пакетов, как в заголовках электропочты: From, To, Via
На которые реагируют user agent телефонов, направляя ответы на полученный notify request на ваш внешний ИП Астериска.
А появляется он там не по непонятной причине, а по вполне объяснимой: Астериск точно должен понимать что есть внутри, а что снаружи инфраструктуры.

Три вопроса к вам:
1) Вы сделали перманентные роуты к филиалам через ASA в сервере Asterisk?

2) По-прежнему думаете, что проблема проста, чтобы обращаться в платную поддержку? То есть бесплатную помощь принимаете, но не получается, а платную помощь - нет? По принципиальным соображениям?

3) Зачем упорствовать, оставаясь на pjsip? Зачем вообще советы спрашивать, если им не следовать? Просто поговорить "Я думал там всё стабильно..." ??