LINUX.ORG.RU
Форум — Admin  

Sip через nat

 ,


0

2

Приветствую.

Имеем:
Головной офис
Avaya (адрес 10.10.6.1/20)
Шлюз (Ubuntu 16.04 адрес 10.10.0.1/20, extip 123.123.123.123, vpn ip 172.20.20.1/252)

Второй офис.
Шлюз (Ubuntu 14.04 адрес 192.168.60.1/20, extip 321.321.321.321, vpn ip 172.20.20.2/252)
Sip клиенты (телефоны) адреса 192.168.60.100-200

Маршруты и правила настроены. Форвардинг разрешен. Клиент ходят через маскарадинг. Клиенты из одного офиса видят клиентов другого офиса. То есть пакеты в обе стороны ходят без проблем.

Пытаюсь подключить телефон из второго офиса к авае. Регистрация проходит. Звонок тоже. Но вот голоса не слышно. Причем не слышно между номерами из разных офисов. Звонки внутри головного офиса и внутри второго офиса (телефоны тоже подключены к авае) проходят, слышимость отличная. А вот телефоны между офисами не слышат.

Пробовал загружать и выгружать модули nf_nat_h323 nf_conntrack_h323 ip_conntrack_sip ip_nat_sip на обоих шлюзах. Безрезультатно. Ни один из абонентов не слышит другого.

Причем раньше вместо шлюза стояла циска (головной офис) + микротик второй офис. Предыдущие админы настроили и все работало. Но по некоторым причинам пришлось менять циску и микротик на Linux сервер. Связи с админами нету.
Уже много читал, что h323 плохо дружит с NAT. Но раньше ведь работало. Знаю что туннель раньше был ipip. Такой же туннель настроил и сейчас (хотя параллельно включен и openvpn, так что можно в любой момент сменить тип туннеля, но проблема не в этом)

По tcpdump видно, что сами клиенты видят и посылают друг другу пакеты. И пакеты ходят.

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

★★
← Jenkins: перехват сообщений commit'ов
pptpd error reading packet →

Кстати вариант с Астериском на шлюзе или иное подобное решение не катит, так как есть еще один офис, который скоро подключать, и там только микротик. Ставить там что-то другое не представляется возможным. офис удаленный, микротик настроенный туда отправлен уже (настроенный в плане туннеля). Опять таки, с этими микротиками все работало раньше.

as_lan ★★
() автор топика

Так у тебя там нат или все-таки тонель. Если тонель, то нат не нужен. Поснифай трафик во время разговора между офисами и посмотри, что за адреса в сообщениях подставляются

Usuychik
()
Ответ на: комментарий от Usuychik

Итак что говорит tcpdump. Сперва с головного сервера

tcpdump eth0 (локальный интерфейс)

16:47:23.740386 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.760345 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.780346 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.800367 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.820356 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.840389 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.860357 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.880334 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.900395 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.920352 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.940353 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.960364 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:23.980332 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.000360 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.020355 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.040378 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.060298 IP 10.10.3.5.5062 > 192.168.60.100.10236: UDP, length 172

tcpdump -i tun90 (ipip интерфейс)
16:47:24.220393 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.240412 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.260831 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.280372 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.300311 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.320371 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.340393 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.360370 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.380376 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.400453 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.420396 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.440419 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.460435 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.480350 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.500423 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.534171 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:24.542462 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172


Второй сервер
tcpdump -i eth0
16:47:25.162163 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.182176 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.202166 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.222192 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.242233 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.262177 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.283579 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.302201 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.322232 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.344437 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.362205 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.382179 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.402541 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.422185 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.442165 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.462192 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:25.482203 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172


tcpdump -i tun90
16:47:18.995105 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.001765 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.015990 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.021857 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.035616 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.041853 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.055658 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.062160 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.075347 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.081798 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.095330 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.101884 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.115306 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.121821 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.135282 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.141969 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.155587 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.162314 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.175469 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36
16:47:19.181826 IP 172.20.20.1.5062 > 192.168.60.100.10236: UDP, length 172
16:47:19.195473 IP 10.10.3.5 > 192.168.60.100: ICMP 10.10.3.5 udp port 5062 unreachable, length 36


Понятно что ругается о недоступности порта 5062, но какое еще правило нужно чтоб заработало?

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

А от куда у тебя порт 5062? И у тебя фаервол стоит между Аваей и телефонами? И еще я просил посмотреть адреса внутри сип-пакетов, а не в заголовке IP-пакета

Usuychik
()

Так у тебя sip или h323? Вообще встречал такое на ISA, она просто sip-rtp не пускала от слова вообще. На убунте все должно быть ок, чини VPN.

Кстати, у тебя там порт 5062 показан в дампе - это для чего порт? Сигнализация вместо 5060? Проверь короче

Ну и если честно - очень много слов в одну кучу. Там все-таки Nat, VPN или что?

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

Простите. Неправильно выразился. Nat конечно нет. Просто по глупости назвал натом, так как клиенты обоих сетей сидят за шлюзами.

Порт 5062 сам нигде не устанавливал. Сигнализация как и обычно идет по 5060. А вот как только абонент отвечает (поднимает трубку), то трафик идет именно на этот порт. НА аваю еще не заходил, не ковырял. Руководствовался тем, что раньше оно работало, единственное что изменилось - тип и устройства, образующие впн канал.

as_lan ★★
() автор топика
Ответ на: комментарий от Usuychik

Адреса внутри сип пакетов обязательно посмотрю. Спасибо.

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

трафик идет именно на этот порт

статический rtp-порт? оригинально. в целом если у тебя через шлюз все прошло, то с vpn проблем быть не должно. самый простой вариант проверить - взять tcpdump, снять трафик вызова, запихать в wireshark и использовать встроенный анализатор телефонных разговоров.

дальше если там все пучком - снять трафик со свитча возле аппарата через mirror, аналогично проверить вызов.

если и там все пучком - косяк в аппарате, возможно у них есть фаервол (видел пару раз, типа «разрешить вызовы только из подсети X)

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

То ли лыжи не едут, то ли я...
Одним словом заработало. Из подгруженных модулей nf_nat_sip и nf_conntrack_sip. Может быть какой-то глюк аваи. Потому как ни маршруты ни правила я не трогал. Заработало и на ipip туннеле и на openvpn. Всем спасибо.

P.S. У лора какая то особенная аура, как только устаешь биться о проблему и тут постишь ее, так сразу же она решается.

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

У лора какая то особенная аура, как только устаешь биться о проблему и тут постишь ее, так сразу же она решается.

Rubber duck debugging

Но с маршрутами советую все-таки разобраться, равно как и с портами. Там что-то нездоровое

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Jenkins: перехват сообщений commit'ов
Admin
pptpd error reading packet →