Lobster

У нас на виртуалках стоит, на 2008Р2 сервере, ESXi 6.5, для 60 и 100 пользователей (2 штуки в двух филиалах) полет нормальный (ну.. на сколько это возможно для Forefront TMG).

Да, у нас, благо, как то не очень парятся по поводу всяких блокировок, поэтому периодически только добавляем ИП-адреса всяких банков для БУХов на полный доступ, так как у них всякие ТЛСы разнопортые и ТМГ обычно все это блочит, поэтому добавляем полный доступ по ИП определенным компам. Ideko и Usergate тестировал. Ideko как то мало тестил и не помню, что мне там не понравилось, а в USergate на тот момент не работал КЭШ,при заполнении его, сколько бы не выделил, отваливался интернет, пока не почистишь КЭШ... ну и тех.поддержка как то вяло на это отреагировала... хотя БАГ серьезный. + цена у нее... ну, на мой взгляд, не очень гуманная. Я бы, может, на нее и перешел бы (с условием что КЭШ-баг пофиксили), но таких денег мне точно не выделят.....

Ну.... так же как и лет 7 назад. Справляется. Мозги делает иногда, конечно, но справляется. Хотя ограничения для нынешнего интернета у нее уже слабоваты. По сигнатурам не блочит, категории устарели, в HTTPS не может. Когда повсеместно внедрится SNI она станет полностью бесполезной.... Но, так как особо альтернатив нету - пока сидим на ней и не рыпаемся. (года 2 назад тестировал 5 систем на ее замену, лучшим оказался Forinet... но фортинета сейчас нет.....)

Разобрался.... Надо было на TMG добавить разрешающее правило DHCP запрос от VPN-клиентов в сторону локалхоста и DHCP ответ от локалхоста в сторону VPN-клиентов и релэй начал пересылать пакеты.

Всем привет. Уже около недели бьюсь по поводу вопроса назначения статического маршрута (121 опция) VPN клиентам от DHCP сервера через DHCP-relay на RRAS сервере с TMG - никак он не хочет пересылать пакеты на DHCP сервер.... На DHCP сервере создан пул адресов для локалки, туда прописана 121 опция, эту опцию локальные клиенты DHCP сервера в сети получают и в маршруты записывают. VPN клиентам адреса назначаются из этого же пула - это работает уже долгое время, сейчас понадобилось этим клиентам выдавать 121ю опцию с маршрутом и вот тут затык, эта опция ну ни в какую не передается VPN клиентам. В интернете видел статьи/форумы с обсуждением этого и понял, что это работает, но нигде так и не нашел пошаговой инструкции как это сделать на DHCP(1 сервер) + RRAS/TMG(2й сервер) -> DHCP 121 опция клиенту. Я понимаю как это работает внутри и как состыковать логически... (тем более что в RRAS DHCP relay особо настроек то и нету) - но оно не работает. При старте RRAS сервиса на TMG на DHCP сервере вижу от него DHCP запросы на аренду RAS адресов через WireShark, там он запрашивает/получает 121 и 249 на RAS адреса, но клиентам не отдает. При подключении клиента по VPN на DHCP сервер никакие запросы DHCP не приходят (по логике TMG должен переслать DHCPInform от клиента к DHCP серверу), в WireShark пусто.... Кто-то настраивал такую схему, как делали?

Проблема возобновилась после ребута роутера =( Теперь уже никакие прошивки не заставляют заработать эту схему =(.... Видимо баг был в том, что оно как то случайно заработало... =( Но, нашел другой выход: Раньше астериск выходил в инет с НАТом как и все внутренние хоста через interface overload ip nat inside source route-map RM_ISP1_NAT interface GigabitEthernet0/0/1.100 overload У нас были в резерве парочка запасных белых ИПа. Выпустил Астериск в инет через отдельный ИП через nat pool и все заработало тут же. 1. Сделал access list с нужными ИПшниками для выпуска через "спец.нат". 2. Этим же аксес-листом исключил эти ИПшники из основного НАТа. 3. Создал nat pool с единственным внешним ИПшником (одним из резервных) 4. И создал нат правило на основе этого аксес-листа. Прошивка та же 16.09.8. ЗЫ: пока не перезагружался =)

Вот это, честно не подскажу. Настраивалось еще давно, не мной, а тем, кто нам полностью Астериск настраивал (сторонняя компания) я тогда в VoIP еще меньше разбирался. А дальше мы просто настройки транка копировали для других линий и просто меняли логин и пароль, я даже не задумывался над этой строчкой. Ну и придерживаюсь мнения: "не трогай то что хорошо работает". ЗЫ: пробовал тестовый транк без этой строчки, на мой взгляд, в работе ничего не менялось. Да, про цисковский CUBE я знаю, но такую схему не рассматривали, так как это, в общем то, костыли. И астер делал свою работу хорошо и сейчас делает. Этой бы темы, собственно и не было бы, если бы не БАГ в прошивке циско. ЗЫ: у нас был SIP транк между астером и циской, когда были FXO линии и в циско входили несколько медях. А пока я разбирался с этой циско, "relay" сервером для наших нерабочих каналов был другой астериск, который пока еще стоит за 2951 и у него проблем с РТП нету, а с этим астериском он связан по IAX2. Пришлось чутка поковыряться чтобы входящая и исходящая связь с одного астериска (которому нужны "не рабочие" каналы) уходила/приходила через IAX2 на рабочий астер. Т.е. сделал, как бы RTP proxy, костыль конечно, тоже... но как временная схема на время решения проблемы с 4351 нам подошло. Щас уже вернул все как было: один астериск обрабатывает свои каналы, другой свои.

Иииии... баг прошивки подтвердился. Перезагрузка на прошивку 16.09.8 решила проблему! Потоки проходят! Проблема решена!

Докопался я в итоге до истины..... Дело в портах. РТП сервер шлет медиа-поток не на тот порт. Проблема, видимо, в циско.. и ее не корректном инспектировании на этой прошивке. На 28/2951 IOS смотрит внутрь пакета SIP INVITE и видит там исходящий порт астериска, допустим, 10333 и открывает у себя в НАТ этот же порт на медиапоток: получается нат трансляция ext_global: global_ip:10333, local_ip asterisk_ip:10333 и медиасервер шля поток на внешний порт попадает на астер по открытой "один-к-одному по портам" НАТ трансляции. (10333, напоминаю, указан внутри СИП Инвайта) На 4300 IOS XE инспекция так не отрабатывает (в этом, походу и есть баг) она не открывает НАТ на том порту, который указан в СИП Инвайт, а открывает свой порт (ну.. первый свободный, наверно), например 6084 и получается НАТ трансляция ext_global: global_ip: 6084, local_ip asterisk_ip:10333... Теперь о медиасерверах. Те линии, которые у нас не работают, висят на одном медиасервере и этот медиа сервере берет порт на отправку из пакета SIP INvite, получается он отправляет поток на порт 10333, соответственно на IOS он попадает в открытую НАТ-дырку и доходит до Астера, а на IOS XE открыт порт, которого нет в SIP Invite, и медиапоток, отправленный на 10333 бьется в стену... так как IOS XE открыла дырку на порту 6084... Вопрос - как же работают те линии, которые все таки работают?! - очень просто, там медиасервер настроен чуть умнее: он просто шлет 2 потока на порт, с которого пришло соединение 6084 от циски и на тот порт, который указан в SIP Invite 10333 и один из потоков, соответственно проходит через нат, который отправлен на внешний порт циски, который она открыла в нат при установлении соединения... Ну, как то так.... может сумбурно, но только сейчас сам до конца допер... Решение - либо пофиксить циску (возможно поможет другая прошивка, ведь на 28/2951 на IOS нормально работает), либо просить поставщика подправить конфиг оборудования (что в моем случае не реально, упертые как бараны, у них все хорошо), чтобы сервере слал 2 потока на оба порта. ЗЫ: как циско справится с тем, если будет конфликт портов, если в SIP Invite будет указан тот порт, который уже занят НАТ трансляцией на циске - тут не знаю как будет, не сталкивался, скорее всего надо будет перезвонить чтобы забиндились другие порты.

Да, согласен, это можно сделать. Это я вижу только 2 ИП адреса, но как утверждает поставщик они могут динамически меняться, а это периодические проблемы из-за ACL, потому как надо будет вносить новые адреса. На астериске уже давно так настроено и в СИП сигнализации от нас идут правильные данные. Но я тоже недалеко не профессионал в астериск и VoIP, может что то и можно сделать. На следующей неделе будет помощь от сторонней компании - профессионалов в астериск.. Посмотрим, может у них что то получится. Хотя у меня закрадываются подозрения что это БАГ в циско. Залил новую прошивку, была 16.06.5, залил 16.09.8 - вечером перезагружусь на новую - посмотрим что будет, может пофиксится.

Нет, голосовые сервера другие - это 100%. Об этом говорит поставщик да и я вижу в SIP сигнализации. При чем для 2 рабочих линий - один RTP IP, для 2х нерабочих другой RTP IP. Еще интересно то, что циска нат сессии открывает.... и правильно открывает. Что для рабочих линий, что для не рабочих. Это видно по команде ip nat translations - там именно то, что в SIP пакетах. Единственное в SIP пакете порт возврата ко мне указан UDP порт астериска, а не внешний порт циски, т.е. inside local, а не inside global. Но такое поведение одинаково как для рабочих каналов, так и не для рабочих. В общем не понятно где теряются эти датаграммы... но на ЛАН интерфейс циски они не выходят... ЗЫ: SIP ALG отключил (весь свой рабочий опыт без него работал, тут включил уже от безысходности) и вернул конфиг к тому, что в первом посте.

Ну так ограничение и стоит на порт 5060 только с ИП оператора... RTP не ограничишь, так как идти может с любого ИП. Ну.. постоянно открытые порты в сторону Астериск тоже не есть хорошо и тут ACLем уже не ограничишь, так как RTP может идти откуда угодно. Я тоже к этому склоняюсь... Но поставщик все равно с этим сделать ничего не может.. Поправить конфигурацию своего оборудования, чтобы оно включало эту запись в датаграмму Вот это не понял. Вы тоже придерживаетесь того, что SIP ALG нужно, все таки, отключать?

@SUrov_IBM "inspect match protocol sip" - появилось во время экспериментов, когда этой строки не было проблема была полностью та же, т.е. после добавления этой строки ничего не изменилось. Сейчас много читаю по этой теме, но до PRACK еще не дошел, может что то и с ним. Только большой разницы в SIP сигнализации между рабочими каналами и не рабочими я, к сожалению, не вижу. Единственная зацепка - это в рабочем канале есть запись Record-route на голосовой сервер, а в нерабочем канале эта запись отсутствует... Но поставщик связи сказал, что это не влияет и изменить это они не могут.... Во-первых - это постоянные дырки из внешнего мира в сторону астериска. А во вторых диапазоном НАТ не сделаешь, только для каждого порта отдельная строчка, а так как у нас открыто на астериске 500 портов.... то это 500 строк - очень не красивая портянка получается... Вчера вечером немного подкорректировал конфиг, добавил инспектирование SIP на вход и включил ALG, но ничего не изменилось... (Благо хоть рабочие каналы не отвалились) Теперь конфиг выглядит так: class-map type inspect match-all CLASS-WAN-TO-LAN-VOIP match access-group name VOIP-PASS class-map type inspect match-any CLASS-LAN-TO-WAN match protocol http match protocol https match protocol dns match protocol icmp match protocol smtp match protocol pop3 match protocol ftp match protocol ssh match protocol sip match protocol tcp match protocol udp class-map type inspect match-all CLASS-WAN-TO-LAN match access-group name ACL-WAN-TO-LAN ---Добавлено--- class-map type inspect match-all CLASS-WAN-TO-LAN-INSPECT-SIP match protocol sip ---Добавлено--- ! policy-map type inspect PMAP-LAN-TO-WAN class type inspect CLASS-LAN-TO-WAN inspect class class-default drop policy-map type inspect PMAP-WAN-TO-LAN ---Добавлено--- class type inspect CLASS-WAN-TO-LAN-INSPECT-SIP inspect ---Добавлено--- class type inspect CLASS-WAN-TO-LAN-VOIP pass class type inspect CLASS-WAN-TO-LAN inspect class class-default drop ! zone security WAN zone security LAN zone-pair security LAN-TO-WAN source LAN destination WAN service-policy type inspect PMAP-LAN-TO-WAN zone-pair security WAN-TO-LAN source WAN destination LAN service-policy type inspect PMAP-WAN-TO-LAN ---Убрано--- no ip nat service sip udp port 5060 ---Убрано--- ip nat inside source static udp int_ip 5060 ext_Ip 5060 extendable ip access-list extended VOIP-PASS permit udp any host int_ip range 10000 10500 permit tcp host voip_prov_ip host int_ip eq 5060 permit udp host voip_prov_ip host int_ip eq 5060 Но... в работе РТП ничего не изменилось.. Все так же 2 канала работают, 2 нет.... Идей больше нет... =(

Всем привет. Нужна помощь в решении проблем Asterisk+Cisco (4351) one-way RTP. Проблема появилась после замены Cisco 2851 на Cisco 4351. Есть 4 транка от поставщика услуг, до замены все 4 транка работали исправно. Настройки у всех идентичные (кроме логин/пароль), проходят все транки через идентичное оборудование в интернет. После замены Cisco на 2х транках перестал ходить голос во внутрь... На обоих Cisco отключен SIP ALG настроен НАТ на порт 5060 и разрешен пропуск пакетов UDP во внутрь... Но на 4351 не работает входящая на 2х транках, на 2851 работает. Т.е. ничего не меняя просто меняем железку с 2851 на 4351 - не работает, меняем обратно - работает. Разница на роутерах только в том, что на одном Firewall CBAC, на другом ZBF. Если пробросить пачку UDP портов через НАТ в сторону астериск, то голос начинает ходить. Но такая "портянка" пробросов в конфиге - это не красиво, да и не правильно... Конфиг старой cisco 2851 IOS: no ip nat service sip udp port 5060 ip nat inside source static udp int_ip 5060 ext_ip 5060 ip access-list extended WAN_to_LAN permit udp host voip_prov_ip host ext_ip eq 5060 permit udp any host ext_ip range 10000 10500 Конфиг новой cisco 4351 IOS XE: class-map type inspect match-all CLASS-WAN-TO-LAN-VOIP match access-group name VOIP-PASS class-map type inspect match-any CLASS-LAN-TO-WAN match protocol http match protocol https match protocol dns match protocol icmp match protocol smtp match protocol pop3 match protocol ftp match protocol ssh match protocol sip match protocol tcp match protocol udp class-map type inspect match-all CLASS-WAN-TO-LAN match access-group name ACL-WAN-TO-LAN ! policy-map type inspect PMAP-LAN-TO-WAN class type inspect CLASS-LAN-TO-WAN inspect class class-default drop policy-map type inspect PMAP-WAN-TO-LAN class type inspect CLASS-WAN-TO-LAN-VOIP pass class type inspect CLASS-WAN-TO-LAN inspect class class-default drop ! zone security WAN zone security LAN zone-pair security LAN-TO-WAN source LAN destination WAN service-policy type inspect PMAP-LAN-TO-WAN zone-pair security WAN-TO-LAN source WAN destination LAN service-policy type inspect PMAP-WAN-TO-LAN no ip nat service sip udp port 5060 ip nat inside source static udp int_ip 5060 ext_Ip 5060 extendable ip access-list extended VOIP-PASS permit udp any host int_ip range 10000 10500 permit tcp host voip_prov_ip host int_ip eq 5060 permit udp host voip_prov_ip host int_ip eq 5060 Настройка всех VOIP-транков на астерикс: username=user type=peer trunkstyle=voip secret=**** registersip=no registeriax=no qualify=yes promiscredir=yes port=5060 host=sip.prov.com hassip=yes hasiax=no hasexten=no fromuser=user disallow=all allow=alaw&ulaw