Тема: TDE 200 и внутренние IP телефоны
Она работает на родном протоколе.
А как он называется?
Просто возможно будут проблемы на маршрутизаторе (где настроен IPSEC), нужно в тех. поддержку звонить узнавать нет ли проблем с этим протоколомгде настроен IPSEC однозначно будут проблемы
Почему?
-Вы эти телефоны самостоятельно запускать собираетесь?
-да
-что-то слишком много вопросов у Вас возникает....
+1. Не зная броду, лезешь в воду. Не заработает - купишь телефоны себе домой? Поставщик не возьмёт обратно, так как наверняка продаёт их без установки только с условием, что их неграмотное подключение не будет являться поводом для возврата.
-Вы эти телефоны самостоятельно запускать собираетесь?
-да
-что-то слишком много вопросов у Вас возникает....+1. Не зная броду, лезешь в воду. Не заработает - купишь телефоны себе домой? Поставщик не возьмёт обратно, так как наверняка продаёт их без установки только с условием, что их неграмотное подключение не будет являться поводом для возврата.
Да знаю.............. Но уже купил их =))) Завтра привезут...
Проще может было SIP купить, но все посоветовали именно NT-серию т.к. дешевле и функциональнее.
Собственно проблема может быть только с протоколом MGCP , т.к. IPSEC давно настроен и всё хорошо (настраивал я)
Телефоны подключить к сети тоже не сложно, настроить на них IP адреса тоже не сложно.
В чём такая сложность о которой вы говорите? я вижу сложность только в протоколе MGCP , с SIP бы проблем не было...
p.s Правда пока не знаю нужно ли их регистрировать на станции, я так понимаю что нужно, хотел кстати спросить про это))
Хоть не больше 8-ми купили?
Хоть не больше 8-ми купили?
нет, 3 всего пока...
Хоть не больше 8-ми купили?
нет, 3 всего пока...
Тогда все получится, 8 лицензий на борту есть. IPSEC это ж тунели у Вас?
Да нормально все будет...
IPSEC VPN- это как раз наилучший вариант для для построения сети АТС (выносов телефонов). Если ничего не перекрыто, то заработают Ваши телефоны без проблем, главное правильно прописать в них адреса и на АТС зарегистрировать телефоны...
-Вы эти телефоны самостоятельно запускать собираетесь?
-да
-что-то слишком много вопросов у Вас возникает....+1. Не зная броду, лезешь в воду. Не заработает - купишь телефоны себе домой? Поставщик не возьмёт обратно, так как наверняка продаёт их без установки только с условием, что их неграмотное подключение не будет являться поводом для возврата.
Да знаю.............. Но уже купил их =))) Завтра привезут...
Проще может было SIP купить, но все посоветовали именно NT-серию т.к. дешевле и функциональнее.
Собственно проблема может быть только с протоколом MGCP , т.к. IPSEC давно настроен и всё хорошо (настраивал я)
Телефоны подключить к сети тоже не сложно, настроить на них IP адреса тоже не сложно.В чём такая сложность о которой вы говорите? я вижу сложность только в протоколе MGCP , с SIP бы проблем не было...
p.s Правда пока не знаю нужно ли их регистрировать на станции, я так понимаю что нужно, хотел кстати спросить про это))
Сложность в том, что ты, похоже, не знаешь, как работает инкапсуляция и не представляешь себе принципа работы туннеля с IPSEC. Из твоих слов следует это. Либо ты очень косноязычен и не умеешь выразить свою мысль. Ибо туннелю пофигу, что за протокол в него заворачивается, и никаких портов между сетями, соединёнными туннелем, пробрасывать не надо. Если только там какой-нибудь цербер не кусает избранные протоколы.
Хоть не больше 8-ми купили?
нет, 3 всего пока...
Тогда все получится, 8 лицензий на борту есть. IPSEC это ж тунели у Вас?
Ок, спасибо. да, VPN по IPSEC
Да нормально все будет...
IPSEC VPN- это как раз наилучший вариант для для построения сети АТС (выносов телефонов). Если ничего не перекрыто, то заработают Ваши телефоны без проблем, главное правильно прописать в них адреса и на АТС зарегистрировать телефоны...
Спасибо. Вот тока как их зарегить сейчас буду читать)))
-Вы эти телефоны самостоятельно запускать собираетесь?
-да
-что-то слишком много вопросов у Вас возникает....+1. Не зная броду, лезешь в воду. Не заработает - купишь телефоны себе домой? Поставщик не возьмёт обратно, так как наверняка продаёт их без установки только с условием, что их неграмотное подключение не будет являться поводом для возврата.
Да знаю.............. Но уже купил их =))) Завтра привезут...
Проще может было SIP купить, но все посоветовали именно NT-серию т.к. дешевле и функциональнее.
Собственно проблема может быть только с протоколом MGCP , т.к. IPSEC давно настроен и всё хорошо (настраивал я)
Телефоны подключить к сети тоже не сложно, настроить на них IP адреса тоже не сложно.В чём такая сложность о которой вы говорите? я вижу сложность только в протоколе MGCP , с SIP бы проблем не было...
p.s Правда пока не знаю нужно ли их регистрировать на станции, я так понимаю что нужно, хотел кстати спросить про это))
Сложность в том, что ты, похоже, не знаешь, как работает инкапсуляция и не представляешь себе принципа работы туннеля с IPSEC. Из твоих слов следует это. Либо ты очень косноязычен и не умеешь выразить свою мысль. Ибо туннелю пофигу, что за протокол в него заворачивается, и никаких портов между сетями, соединёнными туннелем, пробрасывать не надо. Если только там какой-нибудь цербер не кусает избранные протоколы.
Ты знаешь что такое ALG? Я в самом начале говорил про SIP ALG, что это правило необходимо для работы SIP телеофонов за NAT. Поэтому и спрашивал нужно ли для работы MGCP правило с ALG маршрутизатора.
Если я поставлю SIP телефоны и просто открою все порты в тунели, то работать телефоны не будут! Не спорю что многое зависит от оборудования, но если реализовать всё на программном шлюзе, например на KERIO (где требуется детальная настройка входящего и исходящего трафика) , всё будет аналогичным образом....... На каждом оборудовании свои затыки, чаще всего открытые порты не дают верного результата, т.к. есть нюансы...
Ты знаешь что такое ALG?
Прочитал, не понял, какое отношение имеет NAT к VPN-туннелю.
Сложность в том, что ты, похоже, не знаешь, как работает инкапсуляция и не представляешь себе принципа работы туннеля с IPSEC. Из твоих слов следует это. Либо ты очень косноязычен и не умеешь выразить свою мысль. Ибо туннелю пофигу, что за протокол в него заворачивается, и никаких портов между сетями, соединёнными туннелем, пробрасывать не надо. Если только там какой-нибудь цербер не кусает избранные протоколы.
Ты знаешь что такое ALG? Я в самом начале говорил про SIP ALG, что это правило необходимо для работы SIP телеофонов за NAT. Поэтому и спрашивал нужно ли для работы MGCP правило с ALG маршрутизатора.
Если я поставлю SIP телефоны и просто открою все порты в тунели, то работать телефоны не будут! Не спорю что многое зависит от оборудования, но если реализовать всё на программном шлюзе, например на KERIO (где требуется детальная настройка входящего и исходящего трафика) , всё будет аналогичным образом....... На каждом оборудовании свои затыки, чаще всего открытые порты не дают верного результата, т.к. есть нюансы...
Как в твоём случае взаимодействуют ALG, NAT и VPN-туннелинг? Вернее - если есть VPN, то нафига NAT и ALG ты сюда приплетаешь? Или у тебя какая-то нетрадиционная организация сети, или ты не понимаешь, о чём говоришь.
И Керио-шмерио, туннель он и в Африке туннель. Если криво настроить, то там такое веселье начнётся (читал про проблемы с этаким “MAC-маскарадингом” на криво настроенном Керио, теперь пугаю им клиентов)...
Про NAT как распространённый пример. Но для работы SIP телефонов даже в туннеле без NAT думаю точно потребуется ALG, т.к. разницы нету, просто открытого 5060 не достаточно. По крайней мере на DFL.
В правилах для VPN статическая маршрутизация в обе стороны. Возможно никакого ALG не потребуется, но по моей теории если данное правило нужно для SIP телефонов при подключении к внешнему провайдеру, то возможно оно потребуется и для MGCP , даже если всё будет работать в туннели., т.к. на многом оборудовании просто отркытых портов бывает не достаточно...
Возможно ошибаюсь.. поэтому и спрашиваю...
Про NAT как распространённый пример. Но для работы SIP телефонов даже в туннеле без NAT думаю точно потребуется ALG, т.к. разницы нету, просто открытого 5060 не достаточно. По крайней мере на DFL.
В правилах для VPN статическая маршрутизация в обе стороны. Возможно никакого ALG не потребуется, но по моей теории если данное правило нужно для SIP телефонов при подключении к внешнему провайдеру, то возможно оно потребуется и для MGCP , даже если всё будет работать в туннели., т.к. на многом оборудовании просто отркытых портов бывает не достаточно...
Возможно ошибаюсь.. поэтому и спрашиваю...
Игорь, ты ошибаешься фундаментально. Тебе поучиться бы. Причём не АТС, а компьютерным сетям. Базовые понятия - OSI, маршрутизация, NAT, маскарады (трансляции адресов и портов). Курс CCNA или хотя бы первую часть ICND1 (хотя бы в той редакции, как оно сдаётся до сентября этого года). Без этого работа в твоей текущей должности - это некоторое нае...алово твоего работодателя.
PS. Возможно, я чего-то не понял из твоих речей - у меня трудности с пониманием людей, а ты всё описал очень неконкретно. Но из того, что я понял, однозначно следует, что ты сильно ошибаешься в своём понимании работы VPN вообще. Ты не понимаешь базовый принцип - инкапсуляция уровней OSI (или у циски модна нынче другая модель - “TCP/IP networking model”). Так вот, VPN “заворачивает” пакеты транспортного (transport, уровень 4 модели OSI) уровня в пакеты уровня приложения (application, уровни 5-7 модели OSI). Соответственно, пакеты TCP и UDP (для данного случая) и содержащиеся внутри них пакеты application MGCP или SIP заворачиваются вовнутрь VPN-пакетов, которые заворачиваются ещё раз в транспортный уровень, и внутри него передаются без изменений от одного конца туннеля в другой конец. На концах туннеля они разворачиваются из VPN-пакетов и приходят к адресату с обратным адресом туннельного оборудования. И обратно они туннельным оборудованием получаются, снова заворачиваются и отправляются назад. Иной случай с NAT - там заголовки транспортного уровня модифицируются - в общем случае подменяются адрес и порт. И такие модифицированные пакеты уже содержат в себе противоречие - внутри пакета на уровне приложения содержится один IP, а снаружи пакета на транспортном и сетевом уровнях содержится другой IP, который подставил туда NAT. Оборудование (SIP-телефон или MGCP-терминал, например), смотрит на тот IP, который содержится на уровне приложения, и пытается туда отправить свой ответ. А этот IP вообще принадлежит другой сети и в общем случае недоступен. Для преодоления этой бяки как раз и существуют ALG, в данном случае это будет инспектор SIP-протокола или MGCP. Этот инспектор подменит адрес также и внутри пакета - на уровне приложения. А при обратной передаче подменит снова на изначальный. Таким образом будет работать NAT traversal, или преодоление NAT, если по-русски.
PPS. Сам я CCNA так и не сдавал ещё, потому если кто заметил в путаной речи выше несообразности - огласите, плиз.
PPPS. Кстати, нашёл статейку, где это всё более красиво объясняется. Игорь, почитай
http://www.quizful.net/post/osi_tcpip_layers - основы
http://ru.wikipedia.org/wiki/Туннелирование_(компьютерные_сети) - тунеллирование
Как обычно связистам приходится устранять пробелы в образовании сисадминов 😊
P.S. При прохождении CCNA я долго ох...л от того, как элементарные вещи можно так сложно представлять. И до сих пор ржу, когда в вакансиях для админов пишут требование знание стека TCP/IP и модели OSI. Это все равно, что в вакансии связиста написать: знание закона Ома и теоремы Котельникова. Про сам стек я вообще промолчу. Такое впечатление, что его писали/создавали не технари, но садомазохисты.
Про NAT как распространённый пример. Но для работы SIP телефонов даже в туннеле без NAT думаю точно потребуется ALG, т.к. разницы нету, просто открытого 5060 не достаточно. По крайней мере на DFL.
В правилах для VPN статическая маршрутизация в обе стороны. Возможно никакого ALG не потребуется, но по моей теории если данное правило нужно для SIP телефонов при подключении к внешнему провайдеру, то возможно оно потребуется и для MGCP , даже если всё будет работать в туннели., т.к. на многом оборудовании просто отркытых портов бывает не достаточно...
Возможно ошибаюсь.. поэтому и спрашиваю...Игорь, ты ошибаешься фундаментально. Тебе поучиться бы. Причём не АТС, а компьютерным сетям. Базовые понятия - OSI, маршрутизация, NAT, маскарады (трансляции адресов и портов). Курс CCNA или хотя бы первую часть ICND1 (хотя бы в той редакции, как оно сдаётся до сентября этого года). Без этого работа в твоей текущей должности - это некоторое нае...алово твоего работодателя.
PS. Возможно, я чего-то не понял из твоих речей - у меня трудности с пониманием людей, а ты всё описал очень неконкретно. Но из того, что я понял, однозначно следует, что ты сильно ошибаешься в своём понимании работы VPN вообще. Ты не понимаешь базовый принцип - инкапсуляция уровней OSI (или у циски модна нынче другая модель - “TCP/IP networking model”). Так вот, VPN “заворачивает” пакеты транспортного (transport, уровень 4 модели OSI) уровня в пакеты уровня приложения (application, уровни 5-7 модели OSI). Соответственно, пакеты TCP и UDP (для данного случая) и содержащиеся внутри них пакеты application MGCP или SIP заворачиваются вовнутрь VPN-пакетов, которые заворачиваются ещё раз в транспортный уровень, и внутри него передаются без изменений от одного конца туннеля в другой конец. На концах туннеля они разворачиваются из VPN-пакетов и приходят к адресату с обратным адресом туннельного оборудования. И обратно они туннельным оборудованием получаются, снова заворачиваются и отправляются назад. Иной случай с NAT - там заголовки транспортного уровня модифицируются - в общем случае подменяются адрес и порт. И такие модифицированные пакеты уже содержат в себе противоречие - внутри пакета на уровне приложения содержится один IP, а снаружи пакета на транспортном и сетевом уровнях содержится другой IP, который подставил туда NAT. Оборудование (SIP-телефон или MGCP-терминал, например), смотрит на тот IP, который содержится на уровне приложения, и пытается туда отправить свой ответ. А этот IP вообще принадлежит другой сети и в общем случае недоступен. Для преодоления этой бяки как раз и существуют ALG, в данном случае это будет инспектор SIP-протокола или MGCP. Этот инспектор подменит адрес также и внутри пакета - на уровне приложения. А при обратной передаче подменит снова на изначальный. Таким образом будет работать NAT traversal, или преодоление NAT, если по-русски.PPS. Сам я CCNA так и не сдавал ещё, потому если кто заметил в путаной речи выше несообразности - огласите, плиз.
PPPS. Кстати, нашёл статейку, где это всё более красиво объясняется. Игорь, почитай
http://www.quizful.net/post/osi_tcpip_layers - основы
http://ru.wikipedia.org/wiki/Туннелирование_(компьютерные_сети) - тунеллирование
Базовые основы сетей я знаю.. Видишь видимо я ошибся, получается что ALG при VPN не нужно.
Но я же не утверждал, а спрашивал... Утверждал только в случае с NAT, и ты это подтвердил! в чём тогда ты так видишь мою ошибку???
Спасибо за ответ, буду пробовать...
