forum.opennet.ru - "netfilter SIP connection tracking" (4)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"netfilter SIP connection tracking"

Форумы OpenNET: Виртуальная конференция (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"netfilter SIP connection tracking"
Сообщение от thehangedman (ok) on 30-Янв-08, 16:47
Добрый день, Есть удаленный маршрутизатор/файрволл (linux-2.6.24, iptables-1.4.0) с двумя интерфейсами, SNAT на внешнем. Через него гуляет VoIP-траффик от каких-то железных телефонов, про которые мне ничего неизвестно. Используется, видимо, протокол SIP, так как соединение устанавливается с порта 5060. Модули nf_nat_sip, nf_conntrack_sip подгружены. tcpdump: На внешнем интерфейсе: 21:09:07.541791 IP xxx.xxx.xxx.xxx.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 21:09:07.558731 IP yyy.yyy.yyy.yyy.43372 > xxx.xxx.xxx.xxx.61411: UDP, length 172 21:09:07.559589 IP xxx.xxx.xxx.xxx.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 21:09:07.577843 IP xxx.xxx.xxx.xxx.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 21:09:07.578455 IP yyy.yyy.yyy.yyy.43372 > xxx.xxx.xxx.xxx.61411: UDP, length 172 # Внимание: инкремент номеров портов! 21:09:07.597964 IP yyy.yyy.yyy.yyy.43373 > xxx.xxx.xxx.xxx.61412: UDP, length 84 21:09:07.598034 IP xxx.xxx.xxx.xxx > yyy.yyy.yyy.yyy: icmp 120: xxx.xxx.xxx.xxx udp port 61412 unreachable 21:09:07.598467 IP yyy.yyy.yyy.yyy.43372 > xxx.xxx.xxx.xxx.61411: UDP, length 172 21:09:07.598585 IP xxx.xxx.xxx.xxx.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 На внутреннем интерфейсе: 21:09:07.538751 IP yyy.yyy.yyy.yyy.43372 > 172.16.216.1.61411: UDP, length 172 21:09:07.541730 IP 172.16.216.1.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 21:09:07.558773 IP yyy.yyy.yyy.yyy.43372 > 172.16.216.1.61411: UDP, length 172 21:09:07.559529 IP 172.16.216.1.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 21:09:07.577786 IP 172.16.216.1.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 21:09:07.578493 IP yyy.yyy.yyy.yyy.43372 > 172.16.216.1.61411: UDP, length 172 21:09:07.598505 IP yyy.yyy.yyy.yyy.43372 > 172.16.216.1.61411: UDP, length 172 21:09:07.598539 IP 172.16.216.1.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 21:09:07.616726 IP 172.16.216.1.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 21:09:07.618782 IP yyy.yyy.yyy.yyy.43372 > 172.16.216.1.61411: UDP, length 172 21:09:07.636747 IP 172.16.216.1.61411 > yyy.yyy.yyy.yyy.43372: UDP, length 172 Здесь xxx.xxx.xxx.xxx - это внешний адрес роутера, 172.16.216.1 - локальный адрес локального абонента, yyy.yyy.yyy.yyy - удаленный абонент. Что происходит - наверное, понятно. Connection tracking, очевидно, не работает. Соответственно связи между абонентами нет (если быть точным, локальный абонент может слышать голос, но отправлять не может). Кто-нибудь сталкивался с подобным? Почему не работает conntrack sip (если это вообще sip)? Может быть, можно эмулировать connection tracking с помощью каких-либо фич нетфильтра вроде модуля recent? Мне не приходит в голову, как.
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

netfilter SIP connection tracking, PavelR, 20:08 , 30-Янв-08, (1)

netfilter SIP connection tracking, thehangedman, 00:44 , 31-Янв-08, (2)

netfilter SIP connection tracking, PavelR, 07:38 , 31-Янв-08, (3)

netfilter SIP connection tracking, Andrew, 00:27 , 06-Мрт-09, (4)

Сообщения по теме [Сортировка по времени | RSS]

1. "netfilter SIP connection tracking"

Сообщение от PavelR (??) on 30-Янв-08, 20:08

>Что происходит - наверное, понятно.
Наверное не понятно.
> Connection tracking, очевидно, не работает.
Если на внутреннем интерфейсе есть пакеты в обе стороны - значит трекинг работает.
> Соответственно связи
>между абонентами нет (если быть точным, локальный абонент может слышать голос,
>но отправлять не может).
21:09:07.598034 IP xxx.xxx.xxx.xxx > yyy.yyy.yyy.yyy: icmp 120: xxx.xxx.xxx.xxx udp port 61412 unreachable
Если быть точным, то судя приведенному тобой логу, то как раз наоборот, локальный абонент не может слышать.
==============
Легкие пути решения проблемы:
1 - использовать симметричный RTP без ip_nat_sip с удаленным Asterisk со включенным НАТ  для агента (если астериск)
2 - использовать фиксированный порт на железке и сделать его проброс.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "netfilter SIP connection tracking"

Сообщение от thehangedman (ok) on 31-Янв-08, 00:44

> Если на внутреннем интерфейсе есть пакеты в обе стороны - значит
>трекинг работает.
да, но вот этот пакет на внутренний интерфейс не попадает:
21:09:07.597964 IP yyy.yyy.yyy.yyy.43373 > xxx.xxx.xxx.xxx.61412: UDP, length 84
т.е. коннтрак модуль не может увязать его с предыдущим обменом пакетами
>Если быть точным, то судя приведенному тобой логу, то как раз наоборот,
>локальный абонент не может слышать.
да, это было бы логично, но как раз слышать он может. Как работает этот протокол, мне неизвестно, но похоже, что локальный абонент шлет удаленному - друг, сейчас я буду слать тебе голос с порта 61412, а удаленный абонент отвечает уже с нового порта (43373) на этот порт (61412), дескать шли сюда.. Возможно, так.
>Легкие пути решения проблемы:
>
>1 - использовать симметричный RTP без ip_nat_sip с удаленным Asterisk со включенным
>НАТ  для агента (если астериск)
>2 - использовать фиксированный порт на железке и сделать его проброс.
Проблема в том, что и роутер, и железки, и пользователи находятся очень далеко от меня, и по уверениям этих пользователей железки настроек не имеют (видимо все прошито).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "netfilter SIP connection tracking"

Сообщение от PavelR (??) on 31-Янв-08, 07:38

>Проблема в том, что и роутер, и железки, и пользователи находятся очень
>далеко от меня, и по уверениям этих пользователей железки настроек не
>имеют (видимо все прошито).
1. Интересно, что за железки - тогда можно сказать - есть ли настройки или нет
2. Куда железки цепляются - к своему или нет PBX (атс) ?
3. Без reinvite (должны быть SIP пакеты) номера портов смениться не должны. Вы показываете не полный tcpdump, а мы должны догадываться ? Или неверные параметры фильтра тцпдампа.
Если нет входящих пакетов - тогда слышать не должны. Вы тут что-то путаете.
Основная проблема - сторона за нат-ом не может слышать. Это проблема в нат-е.
Если локальная сторона слышит, а удаленная нет - тогда это либо удаленный нат, либо файрволл.  Может быть не там ищем ?
=======
PS:
У меня стоит шлюз и точка доступа. Особо не смотрел, оно завелось сразу у меня, с симметричным RTP и опцией нат на астериске, абсолютно без проблем и использования STUN.
в офисе во внутренней сети стоит телефон,стык на sipnet.ru. там ip_nat_sip не заработал, все вылечилось фиксированным портом и его пробросом на рутере (если это для вас возможный вариант).
Но там случай "нам не было слышно". А у Вас - "не слышно нас".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "netfilter SIP connection tracking"

Сообщение от Andrew (??) on 06-Мрт-09, 00:27

Есть такая проблема. 100% bug в nf_conntrack_sip. Сейчас думаю как полечить на проксях.
Если второй абонент висит в интернете и работает через SIP Proxy без rtp proxy
имеем следующую штуку.
192.168.2.24:5060 мой шлюз
555.555.184.13:5060 прокси
555.555.184.2:29444 rtp дальнего шлюза
весь протокол приводить не буду:
192.168.2.24:5060 -> 555.555.184.13:5060
INVITE....c=IN IP4 192.168.2.24..t=0 0..m=audio 16386 RTP/AVP
#--------
#----------
555.555.184.13:5060 -> 192.168.2.24:5060
SIP/2.0 183 Session Progress
.....
Content-Type: application/sdp..Content-Length: 263....v=0..o=root 277
  97 27797 IN IP4 555.555.184.2..s=session..c=IN IP4 555.555.184.2..t=0 0..m=audio 29444 RTP/AVP 18 101
#---------------------
555.555.184.13:5060 -> 192.168.2.24:5060
SIP/2.0 200 OK
.......
Content-Length: 265....v=0..o=root 27797 27798 IN IP4 555.555.184.13..s=session..c=IN IP4 555.555.184.13..t=0 0..m=audio
   29444 RTP/AVP 18 101..
------
Все гаплык. дальше шлем rtp на 555.555.184.13 вместо 555.555.184.2,
хотя dump на проксях показывает, что никто никакого reinvite не делал
и в rtp dump получаем unricheble, как было описано выше....

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "netfilter SIP connection tracking"
Сообщение от PavelR (??) on 30-Янв-08, 20:08
>Что происходит - наверное, понятно. Наверное не понятно. > Connection tracking, очевидно, не работает. Если на внутреннем интерфейсе есть пакеты в обе стороны - значит трекинг работает. > Соответственно связи >между абонентами нет (если быть точным, локальный абонент может слышать голос, >но отправлять не может). 21:09:07.598034 IP xxx.xxx.xxx.xxx > yyy.yyy.yyy.yyy: icmp 120: xxx.xxx.xxx.xxx udp port 61412 unreachable Если быть точным, то судя приведенному тобой логу, то как раз наоборот, локальный абонент не может слышать. ============== Легкие пути решения проблемы: 1 - использовать симметричный RTP без ip_nat_sip с удаленным Asterisk со включенным НАТ для агента (если астериск) 2 - использовать фиксированный порт на железке и сделать его проброс.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "netfilter SIP connection tracking"
	Сообщение от thehangedman (ok) on 31-Янв-08, 00:44
	> Если на внутреннем интерфейсе есть пакеты в обе стороны - значит >трекинг работает. да, но вот этот пакет на внутренний интерфейс не попадает: 21:09:07.597964 IP yyy.yyy.yyy.yyy.43373 > xxx.xxx.xxx.xxx.61412: UDP, length 84 т.е. коннтрак модуль не может увязать его с предыдущим обменом пакетами >Если быть точным, то судя приведенному тобой логу, то как раз наоборот, >локальный абонент не может слышать. да, это было бы логично, но как раз слышать он может. Как работает этот протокол, мне неизвестно, но похоже, что локальный абонент шлет удаленному - друг, сейчас я буду слать тебе голос с порта 61412, а удаленный абонент отвечает уже с нового порта (43373) на этот порт (61412), дескать шли сюда.. Возможно, так. >Легкие пути решения проблемы: > >1 - использовать симметричный RTP без ip_nat_sip с удаленным Asterisk со включенным >НАТ для агента (если астериск) >2 - использовать фиксированный порт на железке и сделать его проброс. Проблема в том, что и роутер, и железки, и пользователи находятся очень далеко от меня, и по уверениям этих пользователей железки настроек не имеют (видимо все прошито).
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "netfilter SIP connection tracking"
	Сообщение от PavelR (??) on 31-Янв-08, 07:38
	>Проблема в том, что и роутер, и железки, и пользователи находятся очень >далеко от меня, и по уверениям этих пользователей железки настроек не >имеют (видимо все прошито). 1. Интересно, что за железки - тогда можно сказать - есть ли настройки или нет 2. Куда железки цепляются - к своему или нет PBX (атс) ? 3. Без reinvite (должны быть SIP пакеты) номера портов смениться не должны. Вы показываете не полный tcpdump, а мы должны догадываться ? Или неверные параметры фильтра тцпдампа. Если нет входящих пакетов - тогда слышать не должны. Вы тут что-то путаете. Основная проблема - сторона за нат-ом не может слышать. Это проблема в нат-е. Если локальная сторона слышит, а удаленная нет - тогда это либо удаленный нат, либо файрволл. Может быть не там ищем ? ======= PS: У меня стоит шлюз и точка доступа. Особо не смотрел, оно завелось сразу у меня, с симметричным RTP и опцией нат на астериске, абсолютно без проблем и использования STUN. в офисе во внутренней сети стоит телефон,стык на sipnet.ru. там ip_nat_sip не заработал, все вылечилось фиксированным портом и его пробросом на рутере (если это для вас возможный вариант). Но там случай "нам не было слышно". А у Вас - "не слышно нас".
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "netfilter SIP connection tracking"
	Сообщение от Andrew (??) on 06-Мрт-09, 00:27
	Есть такая проблема. 100% bug в nf_conntrack_sip. Сейчас думаю как полечить на проксях. Если второй абонент висит в интернете и работает через SIP Proxy без rtp proxy имеем следующую штуку. 192.168.2.24:5060 мой шлюз 555.555.184.13:5060 прокси 555.555.184.2:29444 rtp дальнего шлюза весь протокол приводить не буду: 192.168.2.24:5060 -> 555.555.184.13:5060 INVITE....c=IN IP4 192.168.2.24..t=0 0..m=audio 16386 RTP/AVP #-------- #---------- 555.555.184.13:5060 -> 192.168.2.24:5060 SIP/2.0 183 Session Progress ..... Content-Type: application/sdp..Content-Length: 263....v=0..o=root 277 97 27797 IN IP4 555.555.184.2..s=session..c=IN IP4 555.555.184.2..t=0 0..m=audio 29444 RTP/AVP 18 101 #--------------------- 555.555.184.13:5060 -> 192.168.2.24:5060 SIP/2.0 200 OK ....... Content-Length: 265....v=0..o=root 27797 27798 IN IP4 555.555.184.13..s=session..c=IN IP4 555.555.184.13..t=0 0..m=audio 29444 RTP/AVP 18 101.. ------ Все гаплык. дальше шлем rtp на 555.555.184.13 вместо 555.555.184.2, хотя dump на проксях показывает, что никто никакого reinvite не делал и в rtp dump получаем unricheble, как было описано выше....
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

Архив \| Удалить	Индекс форумов \| Темы \| Пред. тема \| След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 \| 2 \| 3 \| 4 \| 5 ] [Рекомендовать для помещения в FAQ]