H323 и NAT

[corpse]

Уважаемые форумчане, требуется ваша помощь.
Имеется Avaya IP Office и Elastix. Настроил транк между ними внутри сети через канал OOH323. Все работает голос проходит в обе стороны.
Перенесли Elastix в филиал, получается Avaya IPO и Elastix отделены друг от друга двумя шлюзами с NAT. Проброс портов привел лишь к тому, что связь устанавливается, голос ни проходит ни в одну из сторон, хотя RTP порты так же проброшены.
Почитал, что NAT-ирование для H323 подменят IP адрес лишь на транспортном уровне, в самом пакете остаются инкапсулированы IP адреса АТСки, все рекомендуют поднять VPN канал. Поднял VPN канал на машинах стоящих внутри сети (не шлюзах), в одну сторону голос пошел, поскольку появилась прямая видимость Elastix. В обратную все равно не идет, как я понимаю поскольку пакет идет с IP адреса VPN клиента, а не с того который ожидает увидеть Avaya.
Подскажите куда копать. Возможно ли настроить это таким образом, или необходимо поднимать VPN канал на самом Elastix?
Спасибо!

[Zavr2008]

Не умеете строить VPN - ставьте астеры и рядом с Аваей и в другом филиале и спокойно вяжите по IAX2 или SIP..
Также если встанет вопрос с лицензиями (под нагрузкой) Вы можете использовать и наше решение: E1 PRI/SIP шлюз Alvis.

[corpse]

ставьте астеры и рядом с Аваей

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

[amateur]

Avaya IPO и Elastix отделены друг от друга двумя шлюзами с NAT.

Поднял VPN канал на машинах стоящих внутри сети (не шлюзах)

Я не понял суть эксперимента. Почему "не на шлюзах" ?

[Zavr2008]

ТС, сам протокол H323 - лампово-транзистроный телевизор: что-то осталось от ISDN, что-то пришло от первой волны voip (RTP)..
Очень сложно его пропускать через NAT.

Гораздо проще поставить либо VPN, либо шлюзы с SIP и не иметь головняка.
Также для IPO стоит подумать и о лицензировании.

[amateur]

Вы можете использовать и наше решение: E1 PRI/SIP шлюз Alvis.

Вот оно спасение! Никто уже и не надеялся...

что-то осталось от ISDN, что-то пришло от первой волны voip (RTP)..

Воистину всё смешалось в голове обывателя, охваченного жаждой "толкнуть" своё барахло на рынке. ISDN у него теперь - это даже не "лампово-транзисторная", а "до лампово-транзисторная" технология, т.е. чистейший архаизм. Однако шлюзы ISDN(!)-SIP от Alvis при этом являются вершиной инженерной мысли. Протокол RTP - это представитель какой-то "первой волны voip". Тут, судя по всему, опять намёк на какое-то технологическое отставание. Но смотрим на шлюзы ISDN-SIP от Alvis и видим, что протокол SIP не чурается устанавливать сеансы связи с использованием того же RTP.

Очень сложно его пропускать через NAT.

Очень сложно пропускать через NAT трафик, формируемый устройствами, в которых не реализована поддержка NAT для H.323. Автор темы уже в своем понимании ушел дальше Вас - понял, что требуется VPN. Вы же продолжаете "впаривать" ему свой "металлолом", пытаясь его еще и дезинформировать...

Ну и как это выглядит?

[ded]

Огонь! Горячо!
Ш-ш-ш-ш - пена, огнетушитель ОВП - 10(з) - АВ - 01 (УгПАВ) по ГОСТ Р 51057-2001

[corpse]

Я не понял суть эксперимента. Почему "не на шлюзах" ?

Так получилось. Один из gateway простейшая Zyxel железка поддерживающая только VPN, как VPN-клиент pptp.
Вообщем перенастроил. Поднял VPN сервер на шлюзе (mpd4), второй шлюз VPN клиент. Тоннель построен на протоколе pptp (GRE).
Узлы из обоих подсетей пингуются по своим прямым IP-шникам, но проблема та же: Голос проходит лишь в одну сторону с Avaya на Asterisk.
Трафик снятый tcpdump-ом и загнанный в WireShark парсится как VOIP Calls, RTP пакеты идут в обе стороны.
Подскажите куда еще можно покопать, я что-то в замешательстве.
Сейчас на шлюзе трафик натируется для подмены адреса источника, в противном случае он приходит с IP адресом VPN-клиента.
Если настроить VPN клиента на самом Asterisk, это может решить проблему.
Буду благодаерн любой помощи. Спасибо!
P.S. Понимаю что возможно мало информации, подскажите что выложить.

[ded]

а должен приходить с IP адресом Астериска (на Авайю), и с адресом Авайи - на Астериск. Никаких промежуточных НАТов.

Сейчас на шлюзе трафик натируется для подмены адреса источника, в противном случае он приходит с IP адресом VPN-клиента.

VPN как раз предназначен, чтобы избавиться от НАТа, а у вас опять 25.
В общем случае: VPN - это роутинг, никак не трансляция адресов. Тогда и голос будет в обе стороны.

[corpse]

должен приходить с IP адресом Астериска (на Авайю), и с адресом Авайи - на Астериск

Я умом то вроде это понимаю, но трафик то приходит с адреса VPN клиента, а не с реального адреса Asterisk-а

Еще один момент: анализ трафика полученный с внутреннего интерфейса шлюза, после разбора его в WireShark-е воспроизводится. То есть голос нормально приходит в подсеть Avaya.
Если смотреть в WireShark-e RTP stream, то для SIP протокола порт источника Asterisk явялется портом назначения клиента (аппарата) и наоборот. А для H323 у меня сейчас (к сожалению когда они Avaya и * внутри одной подсети уже не могу посмотреть), порт назначения на который шлет Avaya rtp поток, совпадает с портом источника для *, но при этом порт назначения от * для Avaya уже другой. Соответственно например "Find Reverse" в WireShark не отрабатывает. Если я правильно предполагаю, Avaya просто игнорирует этот поток, поскольку не ждет его там.