asterisk.ru

Здравствуйте уважаемые коллеги.

Столкнулся с задачкой, решить которую сходу не понимаю как.

Есть у меня заказчик.

Сначала все было просто:
- астериск внутри сети
- сеть состоит из кучки филиалов соединенных по VPN
- два внешних канала (основной/запасной) заходящих на микротик
Для работы внешних абонентов (road warriors) настроил localnet/externhost, на микротике пробросил порты, отключил от греха подальше ALG - все работает, все хорошо.

Потом задача усложнилась.
Затянули SIP-транк от оператора который для его подачи притащил свой канал связи и дал серый адрес.
Воткнули его тоже в микротик, настроили NAT, роутинги, пробросы, отключили localnet/externhost, включили ALG на микротике - опять все работает, все хорошо.

Приходит следующая вводная - надо шифровать разговоры внешних пользователей с офисом.
Ок, не вопрос, включили SRTP - опять все работает.
Тут СБ заказчика и говорит - а у вас ключи шифрования в начале сессии в незашифрованном виде идут, непорядок.
Ладно, врубаем и настраиваем TLS.... и получаем облом.
Внутри сети и присоединившись по VPN связь работает - а напрямую никак, голоса нет...
Причина в принципе понятна и прозрачна, как обойти не ясно.
Поскольку сигнализация тоже идет в шифрованом виде SIP ALG на микротике подслушать и модифицировать ничего не может - в результате клиент пытается слать из внешнего мира пакеты на внутренний адрес астериска...

Решение в принципе очевидно - вырубить SIP ALG, включить опять localnet/externhost, все начинает работать... кроме SIP-транка от внешнего оператора...

На этом месте как-то мысли застопорились...
Как запасной вариант продумываю поднять OpenVPN а уже поверх него телефонию пускать... но как-то это неспортивно.
Решил обратится за помощью клуба, может пнете в сторону идеи?

Все гораздо хуже.
Внешние клиенты (road warriors) - руководящий состав с яблокофонами.
Я как-то даже сходу и не придумаю софтфона под эту платформу, который:
- нормально работает с TLS
- шлет через него SIP MESSAGE
- умеет игнорировать адреса внутри зашифрованного SDP и слать пакеты на Source IP

P.S. Я пока следующие варианты в голове кручу:
- попросить оператора подать транк через общий инет, чтобы свести все к одному внешнему адресу и вернутся к localnet/externhost
- вынести астериск на реальный адрес
- разделить функции VPN и телефонии на клиенте. Т.е. OpenVPN/IPSec/еще кто-то отдельно подымается а уж телефония/сообщения поверх идут

Вывести сервер на реальный public IP
bindaddr=0.0.0.0 или серый ИП адрес интерфейса провайдера,в последнем случае соорудить NAT внутри сервера - транслировать этот серый адрес на реальный ИП адрес сервера.
для провайдерского пира отдельно прописать роутинг типа
route add net 10.10.5.0/28 gw 10.10.10.33

Бесплатный софтфон нормально работает с TLS & SRTP - Linphone, частично - Zoiper
Платный - Bria, Join

Ага, спасибо за детализацию идеи, я предыдущее свое сообщение подправил на предмет рассматриваемых вариантов - вариант начинающийся со слов "вынести астериск на реальный айпишник" у меня есть.
А за идею с натом серого и реального - спасибо, буду учитывать вдруг что.

P.S. Еще мысль - поднять еще одну виртуалку с астериском на нестандартных портах на всякий случай, "сделать" на ней две сетевушки, одну в сеть в сторону основного астериска а на вторую подать канал от оператора с транком.

Голосую за отдельный сервак на атоме или виртуалку для серого прова.)))
Можно, конечно, и просто sip proxy для него сварганить.
Зло это серые сетки.

Синхронно думаем и пишем
Как раз закончил править предыдущее сообщение на тему отдельного астериска на виртуалке (там и основной на виртуалке в отказоустойчивом облаке крутится)

Искать платного SIP клиента, который может работать через VPN. Тогда необходимость SRTP и TLS отпадет (при желании будет работать внутри VPN)

Стабильность VPN поверх сотовой сети при ограничениях ios наложенное на jitter и ретрансмитты поразит наповал)
Еще многие сети блокируют VPN, достаточно побывать в Китае например.

Задача решена способом, который не был перечислен ранее.

В настройках астериска были активированы externhost/localnet.
На микротике включен SIP ALG (в его настройках убрана галочка разрешающая Direct Media).
Айпишники оператора дающего SIP-транк по своему каналы с серыми адресами были прописаны в localnet.
Что получилось в результате:
- TLS клиенты приходят через портмапинг, им возвращается правильный внешний айпишник который SIP ALG не видит (ибо зашифровано) а астериск выдает его в соответствии с externhost
- когда астериск посылает пакет к оператору то у него в SDP внутренний адрес астериска (поскольку оператора в localnet прописали). Этот пакет ловит SIP ALG микротика и подменяет на соответствующий внешний айпишник интерфейса смотрящего в сторону оператора.
В результате все работает.

В качестве самого простого клиента беспроблемно работающего с SRTP/TLS под IOS был взят PortGO (под андроид и виндовс тоже версии есть, когда занимался настройкой/отладкой системы именно PortGO под вин применял для проверки)

Но в процессе этого решения всплыла еще одна проблемка.
У клиента два канала в интернет от разных провайдеров.
И работают они не в режиме основной/запасной а одновременно - активный/активный.
Т.е. есть некоторое доменное имя на которое зарегистрировано два айпишника и которое по очереди резолвится то в один то в другой айпишник.
На микротике соответственно соединение приходящее на один айпишник попадает в свою таблицу маршрутизации, а приходящие на другой - во вторую.
Ну и попросили меня настроить астериск так, чтобы он со всей этой красотой работал.
Если бы не TLS то я бы вырубил externhost/localnet и предоставил бы микротику все это разгребать.
Но есть TLS...

В результате задача:
- есть первый внешний адрес a.a.a.a от одного провайдера
- есть второй внешний адрес b.b.b.b от второго провайдера
- с обоих этих адресов настроен проброс портов SIP/TLS/RTP на астериск внутри сети с адресом 192.168.10.10
Как заставить астериск отвечать правильным айпишником в SDP в зависимости от того на какой адрес пришел внешний клиент?
Без TLS это все разруливает Микротик своим SIP ALG.

Вспоминается реклама плавленных сырков Hochland - "Нет сынок, это фантастика!"

SIP ALG - дело тёмное. IMHO в случае Multi-Home систем самое то - переезд на public в виртуалку дата-центра.