список доверенных IP-адресов и многопользовательская VOIP в CUBE

[Garrett Hensley]

Я настроил многопользовательский режим в Cisco CUBE. Мне нужно было направить SIP-сессии на разные интерфейсы. Мой вопрос: могу ли я создать список доверенных IP-адресов для каждого пользователя или он всегда ссылается на глобальную конфигурацию голосовой службы VoIP? Я удалил все общедоступные IP-адреса из списка доверенных IP-адресов, но по-прежнему получаю звонки от облачного VoIP-провайдера. Единственный адрес, который у меня есть в списке, — это адрес моего CUCM. Похоже, что арендатор, которого я настроил для хостинга VoIP-провайдера, не учитывает список доверенных IP-адресов. Я понимаю, что это так, поскольку он является глобальным. Однако я не могу найти способ применить такой список доверенных адресов к арендатору. Гарретт

[Roger Kallberg]

Насколько я знаю, список доверенных адресов является только глобальным, но все, что явно определено на диалоговом сопряжении, также может связываться с шлюзом. Таким образом, все, что вы определили в качестве целевых адресов на диалоговых сопряжениях вашего поставщика услуг, будет автоматически считаться частью вашего списка доверенных адресов, хотя и не будет отображаться. Насколько я понимаю, не должно быть никаких проблем с определением этих IP-адресов в глобальной конфигурации. Как вы, вероятно, знаете, подключение к конкретным интерфейсам осуществляется на уровне арендатора или набора номера. Помимо этого, я бы порекомендовал использовать VRF для разделения интерфейсов, обращенных к поставщику услуг, но сохранить интерфейс, обращенный внутрь, без использования VRF. ![Response Signature]

[Garrett Hensley]

@Roger Kallberg
, я сделал именно так. Я использую VRF для внешнего интерфейса только с маршрутами к поставщику услуг. Внутренний интерфейс находится в глобальной таблице маршрутизации. Я использовал арендаторов для каждого диалогового соседа, чтобы иметь возможность привязать сеанс SIP к разным интерфейсам для каждого диалогового соседа. Спасибо за информацию. Я не знал, что наличие целевого сеанса на диалоговом пире автоматически добавляет его в список доверенных. Это вызывает вопрос: зачем разрешать что-то, для чего у вас нет диалогового пира? Я полагаю, у вас может быть входящий диалоговый пир, который не используется для исходящих вызовов? В любом случае, это не относится ко мне. Полагаю, мне нужно добавить хотя бы одну запись (возможно, мою CUCM), чтобы список был создан и проверен. Я просто хочу иметь еще один уровень безопасности. С ACL и VRF это может быть не нужно.

[Roger Kallberg]

Один из вариантов использования — если у вас есть несколько узлов CM, больше, чем обычно вы бы указали в качестве целей для исходящих диалоговых пар или других систем CM, которые напрямую связываются с шлюзом, но не обязательно имеют исходящую диалоговую пару, которая указывает на него напрямую. Второй вариант использования может быть применен в случае, если у вас есть DN, который рекламируется через GDPR (ILS) из другого кластера CM, отличного от того, в котором находится большая часть серии DID-номеров, и вы хотите разрешить этому DN совершать исходящие вызовы через этот конкретный шлюз в PSTN. При этом вызов будет использовать обычный исходящий диалоговый партнер, который отправляет вызов, например, CM A, но CM B рекламирует этот конкретный DN как находящийся в этом листьевом кластере. CM A тогда знает, что он должен маршрутизировать вызов на CM B, поскольку он более конкретен, чем диапазон DN, которые он содержит. Затем, когда DN в CM B совершает вызов, который попадает на этот шлюз, назовем его GW 1, ему необходимо иметь IP-адреса узлов CM B CPE в списке доверенных, чтобы разрешить прохождение вызова. Первый вариант использования, который довольно распространен в организациях с большими кластерами CM, возникает, когда у вас больше узлов CPE CM, чем вы обычно указываете непосредственно в вашем исходящем диале-пире. Если один из этих CM CPE будет обмениваться данными с шлюзом через SIP-транк между ним и CM, который настроен на
работу на всех узлах
, это приведет к сбою, поскольку он не входит в список доверенных. Чтобы это разрешить, необходимо явно указать эти IP-адреса в списке доверенных, чтобы они также могли связываться с шлюзом. Я бы сказал, что с ACL и VRF вы получите гораздо лучший уровень безопасности, чем просто полагаясь на список доверенных. Мое личное предпочтение в отношении диалоговых пар — разделять их по направлению использования. По моему мнению, это значительно упрощает устранение неполадок при звонках, поскольку можно увидеть направление звонка, посмотрев, какие диалоговые пары используются для входящих и исходящих звонков. С одним объединенным вариантом это не так легко обнаружить и потребуется более подробный анализ диалога SIP или других результатов отладки/отображения. ![Response Signature]

[Garrett Hensley]

Вау, как только ты думаешь, что что-то понял, сразу осознаешь, как мало ты знаешь! Раньше у меня на старом маршрутизаторе была настроена функция dial peers (он использует PRI для PSTN), так что для каждого направления и каждого плана нумерации был свой dial peer. Кроме того, в случае сбоя маршрутизатор может переключить SIP на другой маршрутизатор с другим PRI. Это стало довольно запутанным. На этот раз я пытаюсь сократить количество наборов номеров, чтобы посмотреть, как это сработает. Я использую карты шаблонов голосового класса e164, чтобы сократить количество наборов номеров и иметь по одному для каждого «участка» потенциальных вызовов... Возможно, мне это не понравится... Время покажет, ха-ха!

[Roger Kallberg]

Я бы предложил использовать информацию в заголовке VIA для сопоставления входящего направления. Это очень хороший документ о том, как работает маршрутизация вызовов в IOS.
Подробное объяснение маршрутизации вызовов Cisco IOS и IOS-XE — Cisco ![Response Signature]

[Nithin Eluvathingal]

Список доверенных IP-адресов является глобальной настройкой, а не настройкой для каждого арендатора, как вы ожидаете. Как упомянул
@Roger Kallberg
в своем ответе, когда вы добавляете IP-адрес в цель сеанса dial-peer, IOS добавляет эти IP-адреса в список доверенных адресов, поэтому вызовы обрабатываются CUBE, даже если вы удалили IP-адреса ITSP из списка доверенных адресов.
Вы можете просмотреть подробности списка доверенных адресов с помощью команды «
show ip address trusted list
», которая также отобразит IP-адреса Dial-peer. ![Response Signature]

[Garrett Hensley]

@Nithin Eluvathingal
Я попробовал использовать список доверенных IP-адресов sho, чтобы увидеть динамические записи от диалоговых одноранговых узлов. Похоже, это не работает. Кроме того, провайдер является записью DNS, использующей команду sip-server на арендаторе. Я не знаю, влияет ли это на отображение в списке доверенных IP-адресов, но трафик проходит независимо от того, что у меня есть в таблице.

[Stefan Mihajlov]

@Гаррет Хенсли На CUBE
ip address trusted list
действительно является глобальным в контексте
voice service voip
— он не ограничен арендатором. Поэтому даже после удаления публичных IP-адресов из списка многоарендаторный контекст по-прежнему будет принимать сеансы, если они соответствуют логике dial-peer. Список доверенных адресов контролирует только то, рассматривает ли платформа источник как «доверенный» для обмена сообщениями SIP, а не то, достигает ли трафик данного арендатора. Для многопользовательских конструкций обычным подходом является оставление глобального списка доверенных минимальным (обычно только CUCM или известные основные системы), а затем контроль внешних источников с помощью сопоставления dial-peer и явных ACL на уровне интерфейса. Для хостинговых провайдеров расширенный ACL на входном интерфейсе, связанном с
ip access-group
(или политикой на основе зон на платформах IOS-XE) дает вам возможность детальной настройки для каждого арендатора, поскольку конструкция SIP-арендатора не переопределяет глобальный список доверенных. Короче говоря: вы не можете создать список доверия для каждого арендатора; вам нужно будет объединить глобальный список с ACL интерфейса или зонированием, чтобы изолировать арендаторов и разрешить только ожидаемые диапазоны IP-адресов провайдера. С уважением,
Стефан Михайлов Отметьте этот пост как полезный, если он вам помог, и примите как решение, если он решил ваш вопрос.