Тема: NCP1000 порты
За ночь зациклился полностью...
Сорри - точно закциклился. Даже разделом промахнулся...
Подскажите правильно ли я еще соображаю:
Есть NCP1000 с одной стороны с адресом 192.168.0.227 и DPS 192.168.0.228.
С другой стороны TDA200+0410+0490 с адресами 192.168.0.97 и 192.168.0.98 для 0490.
Соединение через IPGW по Н323.
Необходимо пробросить порты и адреса между офисами через NAT. NAT до этого момента настраивать еще не приходилось. Всегда настраивал станции на готовом VPN. VPN поднять на данный момент не реально по техническим причинам со слов админа...
К адресу 192.168.0.227 относятся порты: 35300 - управление, 1718, 1719, 1720, 1721, 5004, 10000-10447
К адресу 192.168.0.228 относятся порты: 12000-12255
К плате 0410 относятся порты: 35300 - управление
К плате 0490 относятся порты: 1718, 1719, 1720, 1721, 5004
Вопрос:
1. Подскажите что я упустил или забыл?
2. Правильно ли распределены порты по адресам NCP?
3. Для NCP нужно два адреса за NAT или достаточно один, но с распределением по портам... т.е. адреса основной или DSP будут выбираться в зависимости от порта...
Спасибо.
P.S: с управлением справился. Дистанционно к станциям подключаться и программировать могу, а вот с VoIP - где то недоделал...
C TDA на NCP идет набор, потом нормальный зуммер - 2 гудка и обрыв.
C NCP на TDA после набора идет дисконнект...
Если станции включены в один свитч то работают как положено. т.е. проблема связана именно с NAT.
Не мучайся, через NAT никакими пробросами задачу не решишь. Дело в том, что при установлении соединения вся сигнализация через NAT проползает, там большинство информации содержится в заголовках пакетов, и эти заголовки NAT может как-то худо-бедно преобразовать. Но в один прекрасный момент, а именно в момент соединения информация об адресе, куда и что высылать, засовывается в информационную часть пакета, которую NAT никак преобразовать не может.
...
я это читал, но на практике сталкиваюсь впервые...
На данный момент меня больше интересуют порты и соответствие их IP адресам... Правильно ли я все описал? Если описал все правильно - то всплывает описываемая Вами проблема, если где то какой то порт забыл, то есть еще надежда на спасение...
Админ появится только после 14:00 Украинского времени. У меня доступа к сетевому оборудованию нет.
На данный момент звонки с ТДА200 на NCP проходят. Аппарат звонит, но после поднятия трубки - тишина... и через два гудка обрыв...
На данный момент звонки с ТДА200 на NCP проходят. Аппарат звонит, но после поднятия трубки - тишина... и через два гудка обрыв...
Приоритет кодеков одинаков на станциях?
Приоритет кодеков одинаков на станциях?
В этом плане все впорядке ибо станции, воткнутые в один свитч полноценно работают
Я далеко не спец по настройке нат, просто самому интересно: если нат поддерживает простое правило, не заморачиваясь с портами, весь UDP-трафик с внешнего айпишника удалённой подсети направить на внутренний адрес DSP - это же должно сработать?
нат должен поддерживать н.323… Как сказал Нач, в протоколе н.323 обратный адрес прячется в теле пакета, а не в заголовке, который подменяется натом, и получивший этот пакет адресат посылает ответ на адрес из тела, а не из заголовка - примерно так я это понимаю... Поэтому нат, не поддерживающий 323, бесполезен.
нат должен поддерживать н.323…
По сути ему все равно что передавать. Главное чтобы все содержимое пакета дошло от отправителя до получателя...
Собственно тему можно закрывать. Сегодня подвезли недостающее оборудование. Настроили VLAN. В итоге получили полный проброс сетевых адресов и портов между двумя офисами.
Только что перенастроил станции. Связь есть. Правда пока еще ее не проверял непосредственно на объекте. Пока проверяю удаленно из дому, но думаю на объекте тоже будет работать...
Тему можно закрыть...
Позвольте ещё подилетантствовать. :red:
Есть сеть 1
10.10.1.Х
MPR1 10.10.1.1
DSP1 10.10.1.2
Шлюз1 10.10.1.100
Внешний IP 1.1.1.1
Сеть 2
20.20.1.X
MPR2 20.20.1.1
DSP2 20.20.1.2
Шлюз2 20.20.1.100
Внешний IP 2.2.2.2
Правило на шлюзе 1: весь UDP от DSP 1 отправлять на 2.2.2.2
Правило на шлюзе 2: весь UDP от DSP 2 отправлять на 1.1.1.1
MPR2 получив запрос на соединение, извлекает из него внешний адрес шлюза1 1.1.1.1(нат подставил его вместо адреса MPR1 10.10.1.1). MPR2 даёт распоряжение DSP2 открыть RTP-сессию на адрес 1.1.1.1.
На шлюзе1 входящее правило: весь UDP от 2.2.2.2 отправлять внутрь на DSP1.
Даже если на каком-то этапе обратный адрес спрятан глубоко – АТС извлечёт его и попытается ответить на него, послав ответ на шлюз. Соответственно, для этого на шлюзе есть правила.
Например, если MPR2 или DSP2 отвечает на 10.10.1.1 или на 10.10.1.2 или на 1.1.1.1, шлюз пробрасывает эти пакеты на 1.1.1.1. А шлюз1 пробрасывает TCP на MPR1 а UDP на DSP1.
Не могу сообразить, в результате чего возникает затык.
Правило на шлюзе 1: весь UDP от DSP 1 отправлять на 2.2.2.2
Правило на шлюзе 2: весь UDP от DSP 2 отправлять на 1.1.1.1
Как ты собираешься это реализовывать?
Теоретически UDP и так попадёт с DSP на шлюз. Но нужны дополнительные правила:
UDP от DSP 1, направленные на 20.20.1.1 направлять на 2.2.2.2, при этом на шлюзе 2 UDP, пришедшие с 1.1.1.1 направлять на 10.10.1.1
UDP от DSP 1, направленные на 10.10.1.1 направлять на 1.1.1.1, при этом на шлюзе 1 UDP, пришедшие с 2.2.2.2 направлять на 20.20.1.1
Если вызов идёт с MPR1 на MPR2, то MPR1 куда делает свой запрос? На 20.20.1.1 или на 2.2.2.2? Если на 20.20.1.1, то для 1.1.1.1 (NAT) должно быть понятно, где находится 20.20.1.1, то есть что это спрятано за 2.2.2.2, если же на 2.2.2.2, то уже тот должен понимать, что по нужным портам нужно всё скинуть в 20.20.1.1.. Короче говоря, если делается тупой проброс портов снаружи вовнутрь, и в DN2IP-е указываешь внешние адреса, то сигнализация как раз-таки может проходить (набор номера, звонок, гудок). Но.. При установлении сессии вызывающий MPR внутри пакета даёт информацию, КУДА он хочет ПРИНИМАТЬ голосовые пакеты, то есть свой собственный IP. И в этом случае MPR1 даёт информацию MPR2 о том, что, мол, “мой адрес вовсе не 1.1.1.1, а 10.10.1.1”. Естественно, MPR2 отправляет UDP на 10.10.1.1, то есть на шлюз-1. Но для шлюза то как раз и нужно вышеописанное правило... Не проще ли VPN поднять? К тому же железки под это дело имеются весьма и весьма недорогие (прибалтийские Microtik около 70-ти $)
C VPN понятно. Но хотелось бы продолжить мысленный эксперемент.
UDP от DSP 1, направленные на 20.20.1.1 направлять на 2.2.2.2, при этом на шлюзе 2 UDP, пришедшие с 1.1.1.1 направлять на 10.10.1.1
Вот этого не понял. Почему так? По моим представлениям, UDP от DSP 1, направленные на 20.20.1.2 шлюз1 направит на 2.2.2.2, при этом на шлюзе 2 UDP, пришедшие с 1.1.1.1 направляться на DSP2 20.20.1.2
Если вызов идёт с MPR1 на MPR2, то MPR1 куда делает свой запрос?
На 2.2.2.2. А там шлюз2 делает проброс TCP (сигнализация) от 1.1.1.1 на 20.20.1.1 (MPR2).
Но.. При установлении сессии вызывающий MPR внутри пакета даёт информацию, КУДА он хочет ПРИНИМАТЬ голосовые пакеты, то есть свой собственный IP.
Опять же не понял. По моим представлениям, MPR должен указать для RTP(UDP) не собственный IP, а IP своей DSP.
И в этом случае MPR1 даёт информацию MPR2 о том, что, мол, “мой адрес вовсе не 1.1.1.1, а 10.10.1.1”.
Он даёт информацию о том, что адрес его DSP1 10.10.1.2. MPR2 открывает на этот адрес RTP-сессию, пакеты летят на шлюз2, а там, согласно правилу “всё UDP от 20.20.1.2 (DSP2) на 1.1.1.1” пакеты летят на шлюз1, на котором согласно правилу “всё UDP от 2.2.2.2 на 10.10.1.2 (DSP1)” они попадают на DSP1.
Естественно, MPR2 отправляет UDP на 10.10.1.1
UDP от DSP2 на 10.10.1.2 (DSP1)
dmsl, не угадал
при этом на шлюзе 2 UDP, пришедшие с 1.1.1.1 направляться на DSP2 20.20.1.2
Именно на 20.20.1.1
Принимают они голос вовсе не на адрес DSP. Принимают именно на тот же, что и сигнальный. А вот отправляют с айпишника DSP.
dmsl, не угадал
Да я не угадывал. Рассуждал по аналогии с авайей.
Принимают они голос вовсе не на адрес DSP. Принимают именно на тот же, что и сигнальный. А вот отправляют с айпишника DSP.
Чрезвычайно странно!
Для меня это полное откровение. Почему так?
Впрочем, для схемы это не важно. Пусть на процессор летят. Значит правило соответствующее должно быть.
Дык, я и говорю, что по сути лепишь тот же самый VPN, только без шифровки 😊
Ну может. Просто пытаюсь для себя понять, если VPNа нет и не предвидится будет ли это работать.
Тут мне подсказывают, что далеко не всякий нат умеет всё описанное.
Про DSP вроде понял. Это же просто интерфейс между TDM и IP.
Ip-телефоны без DSP работать будут,а вот IP-транки между АТС?
Если конечно внутри только IP-телефоны.
Ip-телефоны без DSP работать будут,а вот IP-транки между АТС?
Ну сам подумай, будут ли 😊 ... Я так подозреваю, что если где-то стоит некий транзитный узел, то чем чёрт не шутит? В смысле принять, разрулить и отправить дальше (если не требуется преобразование кодека). Но на “концах” то всё равно ведь надо загнать в TDM!
