 netfilter SIP connection tracking,  thehangedman, 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? Мне не приходит в голову, как.
|
- netfilter SIP connection tracking, PavelR, 20:08 , 30-Янв-08 (1)
>Что происходит - наверное, понятно. Наверное не понятно. > 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 - использовать фиксированный порт на железке и сделать его проброс.
- netfilter SIP connection tracking, thehangedman, 00:44 , 31-Янв-08 (2)
> Если на внутреннем интерфейсе есть пакеты в обе стороны - значит
>трекинг работает. да, но вот этот пакет на внутренний интерфейс не попадает:
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 - использовать фиксированный порт на железке и сделать его проброс. Проблема в том, что и роутер, и железки, и пользователи находятся очень далеко от меня, и по уверениям этих пользователей железки настроек не имеют (видимо все прошито).
- netfilter SIP connection tracking, PavelR, 07:38 , 31-Янв-08 (3)
>Проблема в том, что и роутер, и железки, и пользователи находятся очень
>далеко от меня, и по уверениям этих пользователей железки настроек не
>имеют (видимо все прошито). 1. Интересно, что за железки - тогда можно сказать - есть ли настройки или нет
2. Куда железки цепляются - к своему или нет PBX (атс) ?
3. Без reinvite (должны быть SIP пакеты) номера портов смениться не должны. Вы показываете не полный tcpdump, а мы должны догадываться ? Или неверные параметры фильтра тцпдампа. Если нет входящих пакетов - тогда слышать не должны. Вы тут что-то путаете. Основная проблема - сторона за нат-ом не может слышать. Это проблема в нат-е.
Если локальная сторона слышит, а удаленная нет - тогда это либо удаленный нат, либо файрволл. Может быть не там ищем ? ======= PS: У меня стоит шлюз и точка доступа. Особо не смотрел, оно завелось сразу у меня, с симметричным RTP и опцией нат на астериске, абсолютно без проблем и использования STUN. в офисе во внутренней сети стоит телефон,стык на sipnet.ru. там ip_nat_sip не заработал, все вылечилось фиксированным портом и его пробросом на рутере (если это для вас возможный вариант).
Но там случай "нам не было слышно". А у Вас - "не слышно нас".
- netfilter SIP connection tracking, Andrew, 00:27 , 06-Мрт-09 (4)
Есть такая проблема. 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, как было описано выше....
|
Версия для распечатки
