Функциональность Keenetic DECT

[Joe]

Каким образом можно организовать круглосуточный мониторинг sip и dns траффика? Я чет пробовал захват на роутере включать надолго и вроде как он сам слетел через какое то время

[KorDen]

8 минут назад, des сказал:

А зачем оператору? Снять дополнительную плату за трафик по мобильному?

Видимо билайн решил не тратить лишние ресурсы и SIP-телефония стыкуется с остальное сетью через уже имеющийся IMS. Но не регистрироваться же на него

31 минуту назад, des сказал:

Вот получается кто-то сказал роутеру, что SIP сервер находится по адресу

Хм. В тех дампах, что сходу гуглятся, это безобразие присутствует в полях Contact для INVITE, а так же в realm и domain для ответов на REGISTER. По этим полям кинетик по идее не должен лезть на такой домен

[Joe]

Вот прям сейчас кажется удалось в дамп трафика и в диагностику записать.

Включил запись трафика, включил телефонию. Регистрация сразу поднялась, но в логах чето он там не смог найти.
Пинги с кинетика на ip.beeline.ru (212.119.246.230) ходят без проблем

Mar 27 22:25:13 ndm: Nvox::Manager: enabled SIP line "1".
Mar 27 22:25:13 ndm: Core::ConfigurationSaver: saving configuration...
Mar 27 22:25:17 ndm: Core::ConfigurationSaver: configuration saved.
Mar 27 22:25:17 kernel: usb 1-1: USB disconnect, device number 7
Mar 27 22:25:17 ndm: Nvox::Manager: DECT dongle removed.
Mar 27 22:25:18 kernel: usb 1-1: new full-speed USB device number 8 using xhci-mtk
Mar 27 22:25:18 kernel: usb 1-1: New USB device found, idVendor=0586, idProduct=3428
Mar 27 22:25:18 kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 27 22:25:18 kernel: usb 1-1: Product: Keenetic Plus DECT
Mar 27 22:25:18 kernel: usb 1-1: Manufacturer: ZyXEL
Mar 27 22:25:18 kernel: usb 1-1: SerialNumber: S155729000010
Mar 27 22:25:18 ndm: Nvox::Manager: DECT dongle added.
Mar 27 22:25:19 ndm: Nvox::Manager: handset id "1" registered.
[C] Mar 27 22:25:19 nvox: 22:25:19.550 pj_getaddrinfo  getaddrinfo(Viva-Solos) returned -2 (Name or service not known) 
[C] Mar 27 22:25:19 nvox: 22:25:19.558 pj_getaddrinfo  getaddrinfo(Viva-Solos) returned -2 (Name or service not known) 
[C] Mar 27 22:25:19 nvox: 22:25:19.564 pj_getaddrinfo  getaddrinfo(Viva-Solos) returned -2 (Name or service not known) 
Mar 27 22:25:20 nvox: Line Beeline Business: ip.beeline.ru registration successful: response 200 OK.
Mar 27 22:25:20 ndm: Nvox::Sip: line "Beeline Business": "ip.beeline.ru" registered.
 

[des]

@Joe D@r13@KorDen В дампе от 27 марта 13-36-01 в 83,175746 ответ сервера 200 OK на регистрацию 30885 REGISTER содержит поле:

Service-Route: <sip:mavodi-3-4a-14aa-16-ffffffff-1b359-x10pff-@mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org:5061;lr;mpcftk=1-115-8e3-2-400dd589>

Вот это поле говорит, что теперь к серверу нужно стучаться по новому адресу.

Кто это поле вставил в сообщение - сам сервер, какое-то устройство по дороге, или операционная система роутера - мы не знаем.

 

Изменено 27 марта, 2020 пользователем des
Добавл время дампа

[des]

@Joe D В последнем дампе то же поле появляется в 92,806402:

Service-Route: <sip:mavodi-2-4a-112b-6-ffffffff-1bae2-x10pff-@mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org:5061;lr;mpcftk=1-115-ddd-f-400e3a89>

 

[Joe]

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

Раз это возвращает сервер, какие основание считать что вообще кто то что то подменяет, а не сам сервер это и вернул?)

Session Initiation Protocol (SIP as raw text)
    SIP/2.0 200 OK\r\n
    Via: SIP/2.0/UDP 10.238.100.20:5060;received=212.46.10.18;rport=3743;branch=z9hG4bKPjWqpSDckJNFJVH0GgCQWU1YwnWgNLHKA8\r\n
    Service-Route: <sip:mavodi-2-4a-112b-6-ffffffff-1bae2-x10pff-@mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org:5061;lr;mpcftk=1-115-ddd-f-400e3a89>\r\n
    From: "Salon" <sip:SIP01H9CU00HUP@ip.beeline.ru>;tag=aUff8yKAE6yjdsrtpZQ93DGKLzPoCPxk\r\n
    To: "Salon" <sip:SIP01H9CU00HUP@ip.beeline.ru>;tag=mavodi-2-4b-99-6-ffffffc7-_52540039F215-5f85-fc34700-e69eeb-5e7e5321-1cfd4\r\n
    Call-ID: O4es40qxoqb1TCG2cL.UmgsO-JhgIoHs\r\n
    CSeq: 41325 REGISTER\r\n
    Contact:  <sip:SIP01H9CU00HUP@10.238.100.20:5060;ob>;expires=150\r\n
    P-Associated-URI: <sip:SIP01H9CU00HUP@ip.beeline.ru>\r\n
    Content-Length: 0\r\n
    \r\n

 

[des]

@Joe D Может и сервер.

Вот расширения стандарта, которое позволяет перенаправить трафик https://tools.ietf.org/html/rfc3608

[des]

@Joe D Вот в самом стандарте написано, что это небезопасно без шифрования

7. Security Considerations

It is possible for proxies between the UA and the registrar during the REGISTER transaction to modify the value of Service-Route returned by the registrar, or to insert a Service-Route even when one was not returned by the registrar. The consequence of such an attack is that future requests made by the UA using the service route might be diverted to or through a node other than would normally be visited. It is also possible for proxies on the INVITE path to execute many different attacks. It is therefore desirable to apply transitive mutual authentication using sips: or other available mechanisms in order to prevent such attacks. The "sips:" URI as defined in [3] defines a mechanism by which a UA may request transport-level message integrity and mutual authentication. Since there is no requirement for proxies to modify messages, S/MIME signed bodies may be used to provide end-to-end protection for the returned value. Systems using Service-Route SHOULD provide hop-by-hop message integrity and mutual authentication. UAs SHOULD request this support by using a "sips:" URI. Registrars returning a Service-Route MUST implement end-to-end protection using S/MIME and SHOULD use S/MIME to protect all such responses. UAs receiving Service-Route SHOULD authenticate attached S/MIME bodies if present.

https://tools.ietf.org/html/rfc3608#section-7

[Joe]

@des спасибо, почитал, но не понимаю как это в практическом смысле помогает понять почему кинетик  работает-работает, а потом бам не может зарегистрироваться.
Service route фигурирует во всех регистрациях и есть даже в самом первом дампе что я предоставил в саппорт 17 марта. Оно может по нескольку суток работать нормально, а может отвалится два раза на дню.

Если проблема на строне провайдера, её нужно сформулировать. Из выдержки я понял что сип прокси это не безопасно, нужна внутренняя аунтефикация, но связи с нашей проблемой не вижу

[KorDen]

2 минуты назад, Joe D сказал:

Service route фигурирует во всех регистрациях

Но его значение при успешных регах не блаблабла-3gpp, а вполне нормальный IP или домен же?

[des]

@Joe D Наша проблема в том, что сервер либо оборудование на пути к серверу перенаправляет SIP трафик через адрес, который либо сразу, либо в какой-то более поздний момент не ресолвится DNS сервером.

[des]

@Joe D Кстати, самого запроса к DNS серверу я тоже не вижу. Но я в этом не разбираюсь.

[KorDen]

53 минуты назад, des сказал:

В дампе от 27 марта 13-36-01 в 83,175746 ответ сервера 200 OK на регистрацию 30885 REGISTER содержит поле:

Service-Route: <sip:mavodi-3-4a-14aa-16-ffffffff-1b359-x10pff-@mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org:5061;lr;mpcftk=1-115-8e3-2-400dd589>

Вот это поле говорит, что теперь к серверу нужно стучаться по новому адресу.

Стоп. Нет. "6.1.  Procedures at the UA": "it uses the content of the Service-Route header field as a preloaded Route header field in outgoing initial requests". И всё. Service-Route - это не outbound-прокси, и тем более не редирект регистрации.

Пример описан в разделе 6.4. Клиенту UA1 возвращают в качестве Service-Route P2 и HSP, но он продолжает обращаться к P1, просто у себя в Route он МОЖЕТ подставлять присланные P2 и HSP.

[des]

@KorDen Ждем понедельника. Я в SIP плохо разбираюсь, что сейчас мог - то сделал. Там подтянется начальник, у которого много лет практического опыта с IP телефонией, посмотрит дампы, и что-то решит. Вполне может быть проблема в pjsip когда не ресолвится один из роутов.

[Joe]

@desспасибо что попытались. В любом случае одна голова хорошо а три лучше. По ходу разборов может что нибудь в голову придти.

Для себя я отметил следующий важный момент. Берем последний дамп и смотрим как происходит регистрация.

Кинетик направляет REGISTER sip:ip.beeline.ru
Ему приходит ответ Status: 401 Unauthorized, в заголовках которого появляется 

Цитата

WWW-Authenticate: Digest algorithm=MD5,realm="ims.mnc099.mcc250.3gppnetwork.org",nonce="407effa74be5a7df267457bae35b1e48",domain="sip:mos.epc.mnc099.mcc250.3gppnetwork.org",qop="auth",stale=FALSE\r\n

возможно это и есть та самая авторизация про которую написано в стандарте. Далее кинетик опять направляет REGISTER sip:ip.beeline.ru

В котором уже присутствует 
 

Цитата

[truncated]Authorization: Digest username="SIP01H8CU00HUP@ip.beeline.ru", realm="ims.mnc099.mcc250.3gppnetwork.org", nonce="407effa74be5a7df267457bae35b1e48", uri="sip:ip.beeline.ru", response="e275f083338cf837497667920998624f", algorith

и авторизация успешно проходит. и каждые 180 секунд успешно возобновляется с этой доп строкой.

Потом что то ломается и он не может авторизоваться, пока я руками не перезапущу телефонию, кинетик снова не постучится напрямую на ip.beeline.ru, получит 401 c заголовком WWW-Authenticate: и все начнет снова работать до след отвала.

 

@KorDenесли интересно - могу дамп скинуть.

Изменено 27 марта, 2020 пользователем Joe D

[Joe]

В логах самого кинетика процес первичной авторизации отражается как 

[C] Mar 27 22:25:19 nvox: 22:25:19.550 pj_getaddrinfo  getaddrinfo(Viva-Solos) returned -2 (Name or service not known) 
[C] Mar 27 22:25:19 nvox: 22:25:19.558 pj_getaddrinfo  getaddrinfo(Viva-Solos) returned -2 (Name or service not known) 
[C] Mar 27 22:25:19 nvox: 22:25:19.564 pj_getaddrinfo  getaddrinfo(Viva-Solos) returned -2 (Name or service not known) 

и потом все работает.

хз почему три раза

Изменено 27 марта, 2020 пользователем Joe D

[des]

@Joe D realm="ims.mnc099.mcc250.3gppnetwork.org" это не оно - реалмом, насколько я понимаю, может быть любая строка - это типа как называется провайдер. Оно нужно чтобы звонки для одного провайдера не путались со звонками для другого провайдера, когда одинаковый номер абонента.

У нас проблема ресолва адреса сервера, и строка в проблемном запросе тоже длиннее: getaddrinfo(mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org) returned -2 (Name or service not known).

PS Authorization в случае SIP - это сервер просит клиента прислать пароль, чтобы убедиться, что это правильный пользователь. Для безопасной смены роута сервером нужно наоборот - чтобы склиент убедился, что сообщение отправлено тем сервером, которому он доверяет. Там как-то по-другому, вроде механизмов https. Зашифрованный протокол называется SIPS, в детали я тоже не влазил.

 

[des]

@Joe D Почему он ищет Viva-Solos (хостнейм) - тоже не знаю. SIP вообще сложная штука - там одних стандартов и дополнений овердофига, и самому такое написать "с нуля" просто нереально. Мы взяли pjsip, он легко запустился и стабильно работает, но вникнуть в детали происходящего - это надо садить кого-то на год разбираться. Когда есть какая-то конкретная проблема - можно пробовать понять, что он там у себя делает, но тоже времени много уходит, и иногда в результате ничем не заканчивается, если какой-то кусок сильно завязан на остальные.

[KorDen]

@Joe D, описанное вами - это стандартная Challenge-Response аутентификации чтобы не передавать пароль в открытом виде. Там может быть что угодно, значения полей из раздела WWW-Authenticate в других местах не используются.

Если хочется поискать различия, надо смотреть финальное сообщение 200 OK в ответ на REGISTER и строчку Service-Route в нём. Наверняка там дается в одних случаях какой-нибудь обычный айпишник или домен, а в других это самое 3gppnetwork.

10 часов назад, des сказал:

SIP вообще сложная штука - там одних стандартов и дополнений овердофига

Ога, SIP и IPsec - два монстра... Сидишь себе с парой SIP-прокси и несколькими транками, всё вроде понятно, и даже домофон созванивается с видеотелефоном как-то сам по себе, только кодек одинаковый выбрать и разрешить. А как окунешься в "serious business" с outbound proxy, раздельными регистрантами-прокси, раздельными логинами-номерами-etc и кучей расширений-заголовков, так уже перестаешь понимать, что вообще происходит. Вишенка на торте - согласование этой тысячи расширений с SS7-фиксой, экстра-бонус контент - с опсосами

Изменено 28 марта, 2020 пользователем KorDen

[Joe]

@des есть какие нибудь новости?

[des]

@Joe D Отдал все логи и дампы начальнику. Он смотрит сейчас.

[des]

@Joe D Начальник предлагает прописать руками адрес для mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org, тогда не должно быть проблем с обнаружением сервера или прокси, который под ним прячется:

(config)> ip host mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org 212.119.246.230

Предлагаемый адрес 212.119.246.230 - это адрес ip.beeline.ru. Есть надежда, что пакеты через него пойдут нормально. Если нет - нужно посмотреть, какой адрес с Вашего роутера ресолвится на странице "Проверка сетевого соединения" (ping) для mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org и прописать его.

Если поможет - напишите, пожалуйста, результат.

Спасибо

[KorDen]

1 час назад, des сказал:

предлагает прописать руками адрес для mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org

...

Где в RFC говорится о том что UA должен ходить сам на указанный в Service-Route хост?!

[des]

@KorDen Если бы это воспроизводилось у меня на компьютере - я бы отдебажил и посмотрел, что там происходит.

Сейчас нужно решить реальную проблему реального человека, а не разбираться, кто кому что в RFC.

[Joe]

@@des на самом деле это не трудно, могу создать для вас отдельную сип линию - настройте её на любом девайсе и пусть висит пока не отвалится. Вряд-ли у вас будут какие то другие дампы и логи, нежели у меня)

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

@KorDen Но я как понял месседж такой - sip и rfc это сложно долго и непонятно, поэтому если с костылем заработает то фиксить ничего не нужно)

Изменено 30 марта, 2020 пользователем Joe D

[des]

@Joe DНас Билайн блокировал за доступ из другого региона. И надо не дамп, а словить это все под отладчиком на компьютере. Если оно отваливается раз в сутки случайным образом - тоже вариант так себе. Разве что - на выходные ставить.

[Joe]

В 30.03.2020 в 22:03, des сказал:

@Joe DНас Билайн блокировал за доступ из другого региона. И надо не дамп, а словить это все под отладчиком на компьютере. Если оно отваливается раз в сутки случайным образом - тоже вариант так себе. Разве что - на выходные ставить.

В домашних условиях это можно проделать?

[des]

@Joe D 1) Скорее всего, понадобится несколько попыток.

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

[des]

@KorDen@Joe D По RFC и кто кому Рабинович:

8.1.2 Sending the Request

The destination for the request is then computed. Unless there is local policy specifying otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows. If the first element in the route set indicated a strict router (resulting in forming the request as described in Section 12.2.1.1), the procedures MUST be applied to the Request-URI of the request. Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present. These procedures yield an ordered set of address, port, and transports to attempt. Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI.

https://tools.ietf.org/html/rfc3261#section-8.1.2

Базовый стандарт SIP требует, чтобы запросы клиента отсылались по адресу первого роута в сообщении, отресолвленному при помощи DNS.

Что у нас происходит:

В начале список роутов пустой - в настройках учетки они не сконфигурированы, если я правильно понимаю.

После регистрации сервер присылает Service-Route с адресом mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org, и этот адрес добавляется в список роутов в соответствии с RFC3608. После этого, в соответствии с RFC3261, клиент ОБЯЗАН отсылать следующие запросы на первый известный роут, который оказывается mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org. ОС или DNS не может найти его IP адрес, поэтому клиент не может отослать никакой запрос на сервер (иначе клиент нарушит RFC 3261 section 8.1.2).

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

Изменено 1 апреля, 2020 пользователем des
грамматика

[des]

@Joe D Начальник воспроизвел у себя на компьютере при подключении к билайну. Если выдернуть сетевой шнурок, и в этот момент пройдет запрос на регистрацию, регистрация не восстанавливается, пока не перезапустить телефонию. Разбираемся.