По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Существует множество различных решений для управления Asterisk, основой которых, является FreePBX. К ним относятся - Elastix, PBX in a Flash (PIAF), Trixbox, AsteriskNOW и FreePBX Distro. Однако, с момента первого релиза FreePBX многое изменилось и большинство перечисленных проектов по-просту перестали существовать. Trixbox перестал поддерживать открытое ПО и переориентировался на коммерческую редакцию Trixbox Pro. Elastix и PIAF вообще дружно сменили свой движок с Asterisk на 3CX и для этих продуктов обновлений также больше нет. Кроме того, есть компании, которые до сих пор используют старые не поддерживаемые версии FreePBX и ежедневно испытывают трудности с их работой, а также те, кто установил FreePBX вручную на не поддерживаемые операционные системы. Единственный продукт, который до сих пор обновляется и поддерживается разработчиком - это сам проект FreePBX и FreePBX Distro. Принимая это во внимание, разработчики FreePBX создали решение, которое позволяет сделать миграцию любой системы на базе FreePBX, (начиная с версии 2.9 до и включая версию 14) на свеженькую FreePBX Distro на базе ОС SNG 7, со всеми настройками и конфигурацией! Итак, можно мигрировать с: Elastix; PBX in A Flash; AsteriskNOW; вручную установленного FreePBX (в том числе установленного на не поддерживаемой ОС); FreePBX Distro При этом система, с которой производится миграция не требует остановки эксплуатации или перезагрузки, так как инструмент всего лишь считывает конфигурацию с системы "донора" на свежую систему FreePBX Distro. Как это работает: Вам нужно будет установить свежую версию свежую версию FreePBX Distro , на которую будет происходить миграция и активировать её; Запустить на новом сервере с FreePBX Distro скрипт конвертации командой: curl -s https://convert.freepbx.org | bash Этой командой сервер запросит место (слот) в очереди на конвертацию. Когда слот будет успешно занят сгенерируется ключ, вида 2beb181b-14ed-4f56-a86b-f6e564ba6c43; После этого, нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ; Конвертер извлечёт необходимые данные с донора и загрузит их на новый сервер. Этот процесс не окажет никого влияния на донора, не внесёт на нем никаких изменений и не потребует выключения; Скрипт также будет пробовать стянуть с донора всякие кастомные данные, такие как пользовательские голосовые файлы и данные провиженинга; Все транки на новом сервере будут выключены, чтобы избежать конфликта с зарегистрированными линиями к провайдеру на старом сервере. О том, как установить FreePBX читайте в нашей статье Какие данные будут перенесены на новый сервер: Внутренние номера (Extensions); Маршруты (Inbound/Outbound Routes); Линии к провайдеру (Trunks); Музыка на ожидании (MoH); Голосовые меню (IVR); Группы вызова (Ring Groups); Очереди (Queues); Любые другие настройки, являющиеся стандартной частью FreePBX; Звуковые файлы, включая: загруженную пользователем музыку на ожидании (MoH), записи голосовой почты и приветствия для голосовой почты, а также системные записи (System Recordings) Какие данные не будут перенесены на новый сервер: История звонков, то есть Call Data Report (CDR) и таблица Call Event Log (CEL); Вы можете самостоятельно перенести эти данные на новый сервер, экспортируя их с помощью 'mysqldump' или аналогичной утилиты. Эти данные могут быть очень тяжёлыми, поэтому пользователь сам должен позаботиться об их переносе. Настройки факса; Эта часть претерпела огромные изменения с момента первого релиза FreePBX, поэтому придется самостоятельно перенастроить почты пользователей, которым нужен функционал факса. Кастомные изменения конфигурационных файлов; То есть всё, что было изменено в файлах вида *_custom.conf, например /etc/asterisk/extensions_custom.conf. Если у вас есть такие настройки, то переносить их на новый сервер нужно будет вручную. Настройки не FreePBXовых модулей; Ну например Elastix Call Center Module, Queue Metrics и остальные модули, которые не являются стандартными для FreePBX. В общем и целом, звучит неплохо, правда? Мы можем безболезненно перенести большинство необходимых данных с неподдерживаемой системы и продолжить работу на новой, получая все актуальные обновления. Процесс миграции не представляется чем-то сверх сложным, так что давайте попробуем? Процесс миграции Итак, первое с чего нужно начать - это подготовка нового сервера с FreePBX Distro. Важно устанавливать именно 64-битную версию, поскольку 32-битная больше не поддерживается. О том как установить FreePBX Distro подробно читайте в нашей статье. Как только FreePBX Distro будет установлен, его необходимо активировать. Активация требуется для того чтобы сгенерировать криптографический ключ для защиты ваших данных для передачи на сервер конвертации https://convert.freepbx.org. Данные передаются в зашифрованном виде, чтобы исключить возможность их утечки в случае атаки типа Man-in-the-Middle. Затем необходимо настроить NAT. FreePBX Distro имеет свой встроенный модуль Firewall, который автоматически настраивает параметры NAT и Firewall через специальный помощник при первом запуске FreePBX. О том как настраивать Firewall читайте в нашей статье. После того как сервер с чистым FreePBX Distro настроен, необходимо зарезервировать слот для конвертации. Это делается с помощью специального скрипта: curl -s https://convert.freepbx.org | bash. Когда Вам предложат ввести reservation ID, просто нажмите 'Enter'. По окончанию процесса резервации слота, будет сгенерирован уникальный код конвертации вида: 2beb181b-14ed-4f56-a86b-f6e564ba6c43. Его потом нужно будет ввести на доноре. После этого, новый сервер будет ожидать ответа от донора. Не останавливайте скрипт, нужно чтобы на экране была надпись Waiting for Donor…. Теперь нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ; Возвращаемся на сервер-донор (Elastix, PIAF и так) с которого мы хотим мигрировать и запускаем тот же самый скрипт: curl -s https://convert.freepbx.org | bash Когда вас попросят ввести ID, введите то что было сгенерировано при запуске скрипта на новом FreePBX Distro. Это запускает процедуру экспорта всех данных и настроек с сервера донора и создание сжатого, криптографически защищённого архива с этими данными для отправки на новый сервер. В зависимости от того, насколько давно был развёрнут старый сервер, существует возможность неудачной обработки команды скрипта, поскольку сервер может не поддерживать обработку TLS сертификатов. Если после запуска скрипта ничего не происходит, попробуйте запустить команду с отключением верификации TLS сертификата: curl --insecure https://convert.freepbx.org | bash Как только процесс завершится, новый сервер будет иметь все настройки и данные, которые были на сервере доноре. Вы получаете полностью рабочий сервер со свежей версией FreePBX Distro, которая будет получать актуальные обновления софта и безопасности со всеми настройками, которые были на старом сервере!
img
Друг, сегодня покажем простой способ интеграции Е1 – шлюза производства российской компании Eltex модели SMG-1016M и IP – АТС Asterisk. От слов к делу. /p> Настройка со стороны Eltex Начнем с настройки шлюза. Мы настроим SIP – транк в сторону IP – АТС Asterisk, а так же маршрутизацию: при наборе номера 4951234567 (вызовы, которые приходят к нам из PRI, потока) мы будем отправлять вызов в сторону Asterisk. Заходим в интерфейс администратора: Идем в раздел Маршрутизация → Интерфейсы SIP: Для добавления нового транка нажмите на соответствующий значок: Делаем настройки во вкладке Настройка интерфейса SIP: Название - дайте имя для транка; Имя хоста / IP-адрес - укажите IP – адрес Asterisk; Порт назначения SIP сигнализации - укажите порт, на котором слушает chan_sip модуль Asterisk; Переходим в секцию Настройка кодеков/RTP и отметим два кодека – G.711A и G.711U: Сохраняем настройки и переходим к маршрутизации. Для этого, переходим в раздел План нумерации → План #0: Нажимаем на уже знакомый значок «+», который создаст новую сущность: Название - дайте имя для сущности; Транковая группа - выбираем созданные транк; Сохраняем сущность. Далее, находим ее в списке плана нумерации и переходим в ее параметры. В самом низу нажимаем привычный значок «+» и добавляя маску для звонков: Готово. На данном этапе все звонки из E1 потока (DID 4951234567) будут отправляться по SIP в сторону Asterisk. Переходим к настройке Asterisk. Настройка со стороны Asterisk Все настройки выполним через графический интерфейс FreePBX. Итак, первое, что необходимо сделать – создать SIP – транк в сторону Eltex. Переходим в раздел Connectivity → Trunks. Нажимаем Add Trunk. Даем имя транку в поле Trunk Name. Во вкладке sip Settings в секции Outgoing добавляем следующие данные: host=ip_адрес_Eltex type=friend qualify=yes disallow=all allow=ulaw,alaw nat=no Готово. Теперь вы можете настроить входящую и исходящую маршрутизацию согласно требований вашей задачи. Если вы хотите сделать исходящие звонки в город через Eltex шлюз (с уходом через E1 (PRI) линию), то сделайте на транке (от Asterisk) опцию Outbound CallerID, на базе которой создавайте диалплан на шлюзе Eltex (в примере, когда мы создавали сущность с номером 4951234567, мы указали типа Called. В указанном случае тип нужно сделать Calling). В качестве назначения используйте Е1 транковую группу.
img
Теперь мы можем продолжить поиск и устранение неисправностей. В большинстве случаев вы ожидаете увидеть определенную сеть в таблице маршрутизации, но ее там нет. Далее рассмотрим несколько сценариев неправильной (или полностью не рабочей) работы EIGRP и как исправить наиболее распространенные ошибки. Ниже перечислены часто встречающиеся ошибки: Первую часть статьи про траблшутинг EIGRP можно почитать здесь. Кто-то настроил distribute-list, чтобы информация о маршрутах фильтровалась. Было настроено автосуммирование или кто-то настроил суммирование вручную Split-horizon блокирует объявление маршрутной информации. Перераспределение было настроено, но информация из EIGRP не используется. Перераспределение было настроено, но никакие внешние маршруты EIGRP не отображаются. Case #1 Давайте начнем с простой топологии. OFF1 и OFF2 работают под управлением EIGRP, и каждый маршрутизатор имеет интерфейс обратной связи. Вот конфигурация обоих маршрутизаторов: OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary OFF1(config-router)#network 1.1.1.0 0.0.0.255 OFF1(config-router)#network 192.168.12.0 0.0.0.255 OFF2(config)#router eigrp 12 OFF2(config-router)#no auto-summary OFF2(config-router)#network 2.2.2.0 0.0.0.255 OFF2(config-router)#network 192.168.12.0 0.0.0.255 Все работает нормально, пока через пару недель один из пользователей не пожаловался на то, что ему не удалось подключиться к сети 2.2.2.0 / 24 из-за OFF1. Посмотрите на таблицу маршрутизации на OFF1, и вот что вы видите: По какой-то причине нет сети 2.2.2.0 / 24 в таблице маршрутизации. Видно, что на OFF1 не настроен distribute lists. OFF2 содержит сеть 1.1.1.0 / 24 в своей таблице маршрутизации. Давайте выполним быструю отладку, чтобы увидеть, что происходит. Отладка показывает нам, что происходит. Прежде чем вы увидите это сообщение, придется немного подождать, или вы можете сбросить соседство EIGRP, чтобы ускорить процесс. Как видите, в сети 2.2.2.0 / 24 отказано из-за distribute list. Другой быстрый способ проверить это - использовать команду show ip protocol. В этом случае использование show run могло бы быстрее обнаружить distribute-list. Вот список доступа, доставляющий нам неприятности. OFF2(config)#router eigrp 12 OFF2(config-router)#no distribute-list 1 out Удалим distribute-list. Задача решена! Извлеченный урок: если команды network верны, проверьте, есть ли у вас distribute-list, который запрещает объявлять префиксы или устанавливать их в таблицу маршрутизации. Имейте в виду, distribute-list могут быть настроены как входящие или исходящие, как список доступа. Case #2 В следующем сценарии те же 2 маршрутизатора, но разные сети в loopback. Вот конфигурация: OFF1(config)#router eigrp 12 OFF1(config-router)#network 192.168.12.0 OFF1(config-router)#network 10.0.0.0 OFF2(config)#router eigrp 12 OFF2(config-router)#network 192.168.12.0 OFF2(config-router)#network 10.0.0.0 Как вы видите - это довольно базовая конфигурация. Глядя на таблицы маршрутизации, не видно сети 10.1.1.0 / 24 или 10.2.2.0 / 24. Видна запись для сети 10.0.0.0/8, указывающую на интерфейс null0. Эта запись отображается только при настройке суммирования и используется для предотвращения циклов маршрутизации. Давайте включим отладку и посмотрим, что мы можем найти. OFF2#clear ip eigrp 12 neighbors Этой командой мы сделаем сброс соседства EIGRP, чтобы ускорить процесс. Имейте в виду, что это, вероятно, не самое лучшее, что можно сделать в производственной сети, пока вы не узнаете, что не так, но это действительно помогает ускорить процесс. Вот наш ответ. Отладка говорит нам, что сеть 10.2.2.0 / 24 не следует объявлять, а сеть 10.0.0.0 / 8 нужно объявлять (это вкратце). Это может произойти по двум причинам: Суммирование было кем-то настроено Авто-суммирование включено для EIGRP. Как вы видите, авто-суммирование включено для EIGRP. В зависимости от версии IOS авто-суммирование включено или отключено по умолчанию. OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary OFF2(config)#router eigrp 12 OFF2(config-router)#no auto-summary Отключение автоматического суммирования должно помочь. Ну что, наши сети появились в таблице маршрутизации. Извлеченный урок: если включена автоматическое суммирование EIGRP, вы можете столкнуться с нестабильными сетями. Case #3 Очередная проблема. В приведенном выше примере у нас есть 2 маршрутизатора, но разные сети. OFF1 содержит сеть 172.16.1.0 / 24 на интерфейсе обратной связи, а OFF2 содержит сеть 172.16.2.0 / 24 и 172.16.22.0 / 24 на своих интерфейсах обратной связи. Посмотрим конфигурацию EIGRP обоих маршрутизаторов: Как вы видите, что все сети объявляются. Обратите внимание, что в OFF1 включено автоматическое суммирование, а в OFF2 отключено автоматическое суммирование. Кто-то настроил суммирование на OFF2 и отправляет ее на OFF1. Суммирование создана для сети 172.16.0.0 / 16. Однако, если посмотреть на таблицу маршрутизации OFF1, она не появится. Мы видим запись для сети 172.16.0.0 / 16, но она указывает на интерфейс null0, а не на OFF2. Что здесь происходит? OFF2#clear ip eigrp 12 neighbors Давайте сделаем отладку на OFF2, чтобы увидеть, объявляется ли суммирование. Выполним команду clear ip eigrp neighbors, просто чтобы ускорить процесс. Глядя на отладку, видно, что OFF2 работает правильно. Он объявляет сводный маршрут 172.16.0.0 / 16 так, как должен. Это означает, что проблема должна быть в OFF1. Давайте проведем отладку OFF1. Мы можем видеть, что OFF1 получает сводный маршрут от OFF2, но решает не использовать его. Это хороший момент для проверки таблицы топологии EIGRP. Вы видите, что он имеет суммирование сети 172.16.0.0 / 16 от OFF2 в своей таблице топологии EIGRP, но OFF1 решает не использовать ее, потому что вход через интерфейс null0 является лучшим путем. OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary Решение состоит в том, что нам нужно избавиться от записи null0 в таблице маршрутизации. Единственный способ сделать это - отключить автоматическое суммирование. Отключение автоматического суммирования удаляет запись null0, и теперь суммирование OFF2 установлено проблема решена! Извлеченный урок: автоматическое суммирование EIGRP создает запись через интерфейс null0, которая может помешать установке суммирования, которые вы получаете от соседних маршрутизаторов. Case #4 Есть еще одна проблема с суммированием, которую сейчас и разберем. Мы используем топологию, которую вы видите выше, и ниже конфигурация EIGRP обоих маршрутизаторов. Все сети объявлены, и автоматическое суммирование отключено на обоих маршрутизаторах. Суммирование было настроено на OFF2 и должно быть объявлено к OFF1. К сожалению, ничего не видно на OFF1. Давайте проверим OFF2, чтобы посмотреть, что не так. Когда дело доходит до устранения неполадок с сетью, вашими друзьями являются не Google или Яндекс, а команды Debug и show. Странно, это единственная сеть, которую OFF2 объявляет. Одно из золотых правил маршрутизации: вы не можете объявлять то, чего у вас нет. Очевидно, OFF2 знает только о сети 192.168.12.0 / 24. Вот это ошибка! Кто-то выполнил команду отключения на интерфейсах обратной связи. OFF2(config)#interface loopback 0 OFF2(config-if)#no shutdown OFF2(config)#interface loopback 1 OFF2(config-if)#no shutdown Включим интерфейсы. Теперь мы видим, что суммирование объявляется. Теперь мы видим суммирование в таблице маршрутизации OFF1- проблема решена! Извлеченный урок: вы не можете объявлять то, чего у вас нет в таблице маршрутизации. ВАЖНО. Последняя проблема может быть показаться простой, но есть важный момент, который вы не должны забывать: для объявления итогового маршрута в таблице маршрутизации объявляемого маршрутизатора должен быть указан хотя бы один префикс, попадающий в итоговый диапазон! Case #5 Давайте посмотрим на другую топологию. На рисунке выше у нас есть концентратор Frame Relay и соответствующая топология. Каждый из OFF1 и OFF2 имеет интерфейс обратной связи, который мы будем объявлять в EIGRP. Вот соответствующая конфигурация всех маршрутизаторов: CONC(config)#router eigrp 123 CONC(config-router)#no auto-summary CONC(config-router)#network 192.168.123.0 OFF1(config-if)#router eigrp 123 OFF1(config-router)#no auto-summary OFF1(config-router)#network 192.168.123.0 OFF1(config-router)#network 2.2.2.0 0.0.0.255 OFF2(config)#router eigrp 123 OFF2(config-router)#no auto-summary OFF2(config-router)#network 192.168.123.0 OFF2(config-router)#network 3.3.3.0 0.0.0.255 Видно, что все сети объявлены. Наш концентратор-маршрутизатор видит сети из двух OFF-маршрутизаторов. К сожалению, наши маршрутизаторы не видят ничего ... Похоже, что маршрутизатор-концентратор не объявляет сети, которые он изучает с помощью OFF-маршрутизаторов. Давайте включим отладку, чтобы увидеть, что происходит. CONC#clear ip eigrp 123 neighbors Сбросим соседство EIGRP, чтобы ускорить процесс. В отладке мы видим, что наш маршрутизатор-концентратор узнает о сети 2.2.2.0 / 24 и 3.3.3.0 / 24, но объявляет только сеть 192.168.123.0 / 24 для OFF-маршрутизаторов. Разделение горизонта не позволяет размещать объявление от одного маршрутизатора на другой. CONC(config)#interface serial 0/0 CONC(config-if)#no ip split-horizon eigrp 123 Давайте отключим разделение горизонта на последовательном интерфейсе маршрутизатора-концентратора. Теперь мы видим, что маршрутизатор-концентратор объявляет все сети. OFF-маршрутизаторы теперь могут узнавать о сетях друг друга, поскольку split horizon отключено. Это хорошо, но это еще не все. Извлеченный урок: RIP и EIGRP являются протоколами маршрутизации на расстоянии и используют split horizon. Split horizon предотвращает объявление префикса вне интерфейса, на котором мы его узнали. Хотя сети отображаются в таблицах маршрутизации мы не можем пропинговать от одного OFF-маршрутизатора к другому. Это не проблема EIGRP, но она связана с Frame Relay. Мы должны это исправить. Когда OFF1 отправляет IP-пакет на OFF2, IP-пакет выглядит следующим образом: Давайте пока подумаем, как роутер, и посмотрим, что здесь происходит. Сначала нам нужно проверить, знает ли OFF1, куда отправить 3.3.3.3: Существует запись для 3.3.3.3, а IP-адрес следующего перехода - 192.168.123.1 (маршрутизатор-концентратор). Можем ли мы достичь 192.168.123.1? Нет проблем, кажется, OFF1 может пересылать пакеты, предназначенные для сети 3.3.3.0/24. Давайте перейдем к маршрутизатору CONC. У маршрутизатора-концентратора нет проблем с отправкой трафика в сеть 3.3.3.0 / 24, поэтому на данный момент мы можем сделать вывод, что проблема должна быть в маршрутизаторе OFF2. Это IP-пакет, который получает маршрутизатор OFF2, и когда он отвечает, он создает новый IP-пакет, который выглядит следующим образом: Способен ли OFF2 достигать IP-адрес 192.168.123.2 Давайте узнаем! Теперь мы знаем проблему ... OFF2 не может достичь IP-адреса 192.168.123.2 Если мы посмотрим на таблицу маршрутизации OFF2, то увидим, что сеть 192.168.123.0 / 24 подключена напрямую. С точки зрения третьего уровня у нас нет никаких проблем. Пришло время перейти вниз по модели OSI и проверить уровень 2 ... или, может быть, между уровнем 2 и 3. Frame Relay использует Inverse ARP для привязки уровня 2 (DLCI) к уровню 3 (IP-адрес). Вы можете видеть, что нет сопоставления для IP-адреса 192.168.123.2. OFF2(config)#int s0/0 OFF2(config-if)#frame-relay map ip 192.168.123.2 301 Давайте frame-relay map сами. Теперь роутер OFF2 знает, как связаться с роутером OFF1 Наконец, маршрутизатор OFF1 может пропинговать интерфейс обратной связи маршрутизатора OFF2. Когда мы пытаемся пропинговать от маршрутизатора OFF2 к интерфейсу обратной связи маршрутизатора OFF1, у нас возникает та же проблема, поэтому мы также добавим туда оператор frame-relay map: OFF1(config)#int s0/0 OFF1(config-if)#frame-relay map ip 192.168.123.3 201 Теперь у нас есть extra frame-relay map на маршрутизаторе OFF1. И наш пинг проходит!
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59