The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"netfilter SIP connection tracking"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [ Отслеживать ]

"netfilter SIP connection tracking"  
Сообщение от thehangedman email(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ообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | 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 email(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]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру