По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! В одной из прошлых статей мы писали об организации офисной IP-DECT телефонной сети на базе решения Grandstream DP715. Так вот на днях к нам приехал его “старший брат” - Grandstream DP750 с трубками DP720. Поэтому сейчас будет небольшой анпакинг. Потом мы настроим базу и трубки, а также зарегистрируем их на IP-АТС Asterisk 13.
/p>
$dbName_ecom = "to-www_ecom";
$GoodID = "3437215979";
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение ");
mysql_select_db($dbName_ecom) or die(mysql_error());
$query_ecom = "SELECT `model`, `itemimage1`, `price`, `discount`, `url`, `preview115`, `vendor`, `vendorCode` FROM `items` WHERE itemid = '$GoodID';";
$res_ecom=mysql_query($query_ecom) or die(mysql_error());
$row_ecom = mysql_fetch_array($res_ecom);
echo 'Кстати, купить '.$row_ecom['vendor'].' '.$row_ecom['vendorCode'].' можно в нашем магазине Merion Shop по ссылке ниже. С настройкой поможем 🔧
Купить '.$row_ecom['model'].''.number_format(intval($row_ecom['price']) * (1 - (intval($row_ecom['discount'])) / 100), 0, ',', ' ').' ₽';
$dbName = "to-www_02";
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение ");
mysql_select_db($dbName) or die(mysql_error());
Обзор
База DP750 и трубки DP720 поставляются в фирменной коробке от производителя. В отличие от DP715, база DP750 больше не является ещё и зарядным стаканом для трубок.
В комплект поставки базы DP750 входит:
Сама база DP750;
Зарядное устройство на 5В;
Ethernet – кабель;
Руководство по быстрой установке;
Лицензионное соглашение
На крышке базы DP750 расположены:
Индикатор питания;
Индикатор доступности сети;
Индикатор регистрации SIP-аккаунта;
Индикатор занятости линии. Мигает, если занята хотя бы одна линия;
Индикатор радио-сигнала. Мигает, если база готова принимать регистрацию трубки
Мы, как назло, забыли сфотографировать базу включённой, чтобы продемонстрировать индикацию :(
На боковой панели располагаются:
Разъём для подключения блока питания;
Кнопка сброса к заводским настройкам;
Физический интерфейс для Fast Ethernet;
И физическая кнопка для ввода базы в режим поиска трубки. Запомните её, в процессе регистрации трубок на базе она нам очень понадобится и не раз :) Используется также для “пинга” зарегистрированных трубок.
В комплект поставки трубок DP720 входит:
Сама трубка DP720;
2 батарейки типа ААА (аккумуляторы);
Задняя крышка отсека для батареек и зажим для крепления на поясе;
Зарядный стакан;
Блок питания на 5В;
Руководство
Вот так это выглядит в собранном состоянии:
Настройка
Итак, перейдём к настройке. Сначала выясним IP-адрес базы, который она по умолчанию получит по DHCP. Для этого берём одну трубку, нажимаем на кнопку слева от центральной, далее Settings → Registration начнётся поиск базы. После этого на базе зажимаем на 15 секунд ту самую кнопку для ввода базы в режим поиска, пока индикатор радио сигнала не начнёт мигать. Через некоторое время трубка зарегистрируется на базе. У неё пока может не быть SIP-аккаунта, а база пока может не знать об IP-АТС.
Теперь мы можем узнать IP-адрес базы. Берём трубку, далее Status и стрелочками листаем до IP-адреса. После чего вбиваем его в адресную строку браузера:
Логин и пароль по умолчанию admin/admin
Первое, на что обращаешь внимание – это полностью переработанный дизайн web-интерфейса по сравнению с DP715.
На вкладке STATUS пока может быть пусто.
Настроим SIP-профиль для нашей базы, т.е укажем как найти IP-АТС. Для этого заходим во вкладку PROFILE → General Settings и в поле SIP Server указываем адрес нашей IP-АТС и порт, на который она принимает регистрации.
На данном этапе, рекомендуем позаботиться о том, чтобы на Вашей IP-АТС уже был заведён внутренний номер для трубок, которые Вы хотите зарегистрировать. Как создать внутренний номер на FreePBX 13, можно почитать в нашей статье.
Если внутренние номера готовы, то переходим на вкладку DECT, далее SIP Account Settings и заполняем в соответствии с настройками внутреннего номера, который мы завели на IP-АТС. В нашем случае, это номер 124 – User1. На забываем нажимать Save and Apply
Теперь берём трубку и вводим её в режим регистрации - нажимаем на кнопку слева от центральной, далее Settings → Registration начнётся поиск базы. Подходим к базе и зажимаем кнопку для ввода в режим регистрации. Напомним, зажимать нужно в течение 15 секунд, пока индикатор не начнёт мигать. Через какое-то время, трубка зарегистрируется на базе и вы увидите имя внутреннего номера на дисплее. Если регистрируется подряд несколько трубок, то может потребоваться перезагрузить базу.
Проверить, что трубка успешно зарегистрировалась, теперь можно на вкладке STATUS
В данной статье будет рассмотрен модуль Asterisk CLI – Command Line Interface, другими словами – консоль Asterisk. Данный инструмент является многоцелевым и может выполнять следующие функции:
Получение информации о системных компонентах Asterisk
Настройка системной конфигурации
Просмотр логов, ошибок и предупреждений в реальном времени
Генерация звонков в целях проведения тестов
Просмотр расширенной документации – для API, приложений, функций, настройки модулей и так далее.
Далее рассмотрим процесс вызова консоли – есть несколько путей.
Через веб-интерфейс FreePBX
Для этого необходимо открыть веб-интерфейс Вашей АТС и далее пройти по следующему пути: Admin –> Asterisk CLI
После этого откроется страница, на которой можно вводить команды.
По SSH
С помощью удаленного доступа – по SSHTelnet с использованием терминала (к примеру, PuTTy). При таком типе подключения необходимо будет ввести логин и пароль, и затем ввести команду:
[root@localhost ~]#asterisk -rvvvv
Примечание: Количество букв «v» означает уровень логирования в CLI. Т.е чем больше букв – тем больше информации будет «сыпаться» на экран.
Как только был получен доступ, возможно будет вывести следующую информацию:
Телефонные звонки
Регистрацию абонентов
Уведомления о появлении новых абонентов
Запросить перезагрузку системных компонентов (экстеншенов, транков и т.д)
Все команды имеют следующий синтаксис:
module name -> action type -> parameters (Название модуля –> Тип действия -> Параметры)
К примеру – команда sip show peers, которая выведет список зарегистрированных chan_sip абонентов.
Если же ваша АТС работает некорректно – к примеру, Asterisk не стартует вообще, стоит попробовать вызвать консоль с другим набором настроек, которые позволят начать специфическую отладку приложений – логирование порядка загрузки, соединения с базой данной, количества попыток регистрации и прочее.
Кроме того, есть возможность запускать команды CLI без непосредственного ввода команд, описанных выше. Для этого необходимо напрямую обратиться к модулю Asterisk:
[root@localhost ~]#asterisk -rx 'reload now'
К примеру, данная команда перезагрузит весь модуль Asterisk.
Самые нужные команды
Ниже будут приведены описания некоторых часто используемых команд:
localhost*CLI>DIALPLAN SHOW \ вывод вашего диалплана (правила маршрутизации вызовов)
localhost*CLI>CORE SHOW TRANSLATION \ вывод таблицы с методами транскодирования кодеков
localhost*CLI>SIP SET DEBUG PEER PHONE_EXT \ запуск отладки определенного экстеншена (с указанием номера экстеншена)
localhost*CLI>SIP SET DEBUG IP PEER_IP \ запуск отладки определенного абонента по его сетевому адресу
localhost*CLI>SIP SET DEBUG OFF \ отключение режима отладки
localhost*CLI>RELOAD \ перезагрузка модуля Asterisk, не всей АТС целиком. Может использоваться после внесения измерений
localhost*CLI>RESTART NOW \ перезагрузка всей системы в целом, может понадобиться если команды reload недостаточно или в целях регулярной плановой перезагрузки.
Главная команда, которую нужно усвоить – help, она выводит все прочие команды. Очень удобный внутренний инструмент.
Public Key Infrastructure (PKI) - это набор различных технологий, которые используются для обеспечения аутентификации источника, целостности данных и конфиденциальности для пользователя в сети. PKI использует преимущества асимметричного шифрования и использует пары открытого и закрытого ключей для шифрования данных.
В PKI открытый ключ обычно связан с цифровой подписью, чтобы добавить доверие и проверить сведения о владельце сертификата. Ниже приведен ключевой жизненный цикл в PKI:
Генерация ключа: Этот процесс определяет шифр и размер ключа.
Генерация сертификата: Этот процесс создает цифровой сертификат и назначает его человеку или устройству.
Распространение: Процесс распространения отвечает за безопасное распространение ключа пользователю или устройству.
Хранение: Этот процесс отвечает за безопасное хранение ключа, чтобы предотвратить любой несанкционированный доступ к нему.
Отзыв: Сертификат или ключ могут быть отозваны, если они скомпрометированы субъектом угрозы.
Срок действия: Каждый сертификат имеет срок службы.
Каждый день мы посещаем различные веб-сайты, такие как социальные сети, стрим, новости, спорт, блоги и другие платформы. Однако задумывались ли вы когда-нибудь о проверке подлинности веб-сайтов, которые вы посещаете? Вы, наверное, думаете, что всему, что находится в Интернете, нельзя доверять. Хотя это отчасти правда, мы можем доверять только ограниченному числу веб-сайтов, например, доверять веб-сайту вашего банка. Главный вопрос заключается в том, как мы можем проверить подлинность веб-сайтов, которые мы посещаем? Именно здесь как PKI, так и цифровые сертификаты помогают установить доверие между хостом в Интернете и нашим компьютером.
Центр сертификации
PKI играет жизненно важную роль в Интернете, поскольку многим пользователям и устройствам требуется метод установления доверия в самой ненадежной сети в мире – Интернете. Понимание компонентов, которые помогают PKI обеспечить доверие, необходимую как пользователям, так и устройствам, имеет важное значение для любого специалиста по кибербезопасности.
Вы можете рассматривать PKI как набор процедур, правил, аппаратного и программного обеспечения, а также людей, которые работают вместе для управления цифровыми сертификатами. Цифровой сертификат-это официальная форма идентификации объекта, которая проверяется доверенной стороной. Эти цифровые сертификаты выдаются доверенной стороной в сети или Интернете. Они известны как Центр сертификации (Certificate Authority - CA).
В каждой стране существует государственное учреждение, которое обычно отвечает за проверку личности своих граждан и выдачу удостоверений личности, такой как паспорт.
Этот паспорт будет содержать важную информацию о владельце и сроке действия, например, дату окончания срока действия. В сети и в Интернете центр сертификации выполняет похожую роль и функции. В Интернете есть множество поставщиков, которые являются доверенными центрами сертификации, которые позволяют вам приобретать цифровой сертификат для личного использования. Примеры доверенных центров сертификации включают GoDaddy, DigiCert, Let's Encrypt, Comodo, Cloudflare и многие другие.
Важное примечание! Цифровой сертификат создается при объединении ключа и цифровой подписи. Сертификат будет содержать сведения о владельце сертификата, например, об организации.
ЦС выдаст объекту цифровой сертификат только после того, как его личность будет проверена. После того, как ЦС создает цифровой сертификат, он сохраняется в базе данных сертификатов, которая используется для безопасного хранения всех утвержденных ЦС цифровых сертификатов.
Важное примечание! По истечении срока действия цифрового сертификата он возвращается в ЦС, который затем помещается в список отзыва сертификатов (Certificate Revocation List - CRL), который поддерживается ЦС.
Цифровой сертификат форматируется с использованием стандарта X.509, который содержит следующие сведения:
Номер версии
Серийный номер
Идентификатор алгоритма подписи
Название эмитента
Срок годности
Не раньше, чем
Не после
Имя субъекта
Информация об открытом ключе субъекта
Алгоритм открытого ключа
Открытый ключ субъекта
Уникальный идентификатор эмитента (необязательно)
Уникальный идентификатор субъекта (необязательно)
Расширения (необязательно)
Алгоритм подписи сертификата
Подпись сертификата
Регистрирующий орган (RA)
Следующий рисунок - это цифровой сертификат, который используется для проверки веб-сайта Cisco:
Как показано на предыдущем рисунке, видно, что CA - это HydrantID SSH ICA G2, который выдает сертификат на www.cisco.com на срок действия с 20 сентября 2019 года по 20 сентября 2021 года.
Как показано на следующем рисунке, цифровой сертификат содержит дополнительную информацию, которая хранится с использованием стандарта X.509:
Далее давайте рассмотрим, как создается цифровая подпись и ее роль в PKI.
Цифровая подпись
При совершении деловых операций на документах требуется подпись, чтобы гарантировать, что сделка санкционирована соответствующим лицом. Такая же концепция требуется в сети, так что цифровая подпись отправляется вместе с сообщением на конечный хост. Затем узел назначения может использовать цифровую подпись для проверки подлинности сообщения.
При использовании PKI используются следующие алгоритмы для создания и проверки цифровых подписей:
DSA
RSA
Elliptic Curve Digital Signature Algorithm (ECDSA)
Чтобы создать цифровую подпись, между Алисой (отправителем) и Сергеем Алексеевичем (получателем) происходит следующий процесс:
1) Алиса будет использовать алгоритм хеширования для создания хэша (дайджеста) сообщения:
2) Затем Алиса будет использовать свой закрытый ключ для шифрования хэша (дайджеста) сообщения:
Цифровая подпись используется в качестве доказательства того, что Алиса подписала сообщение.
Чтобы лучше понять, как используются цифровые подписи в реальной жизни, давайте представим, что в сети есть два пользователя. Алиса хочет отправить Сергею Алексеевичу сообщение. Алиса может использовать цифровую подпись с сообщением, чтобы заверить Сергея Алексеевича в том, что сообщение исходило именно от нее. Это шаги, которые Алиса будет использовать для обеспечения подлинности, целостности и неотрицания:
Алиса создаст пару открытых и закрытых ключей для шифрования данных.
Алиса даст Сергею Алексеевичу только открытый ключ. Таким образом, закрытый ключ хранится у Алисы.
Алиса создаст сообщение для Сергея Алексеевича и создаст хэш (дайджест) сообщения.
Затем Алиса будет использовать закрытый ключ для шифрования хэша (дайджеста) сообщения для создания цифровой подписи.
Алиса отправит сообщение и цифровую подпись Сергею Алексеевичу.
Сергей Алексеевич будет использовать открытый ключ Алисы для расшифровки цифровой подписи, чтобы получить хэш сообщения.
Сергей Алексеевич также сгенерирует хэш сообщения и сравнит его с хэшем, полученным из цифровой подписи Алисы. Как только два значения хэша (дайджеста) совпадают, это просто означает, что сообщение подписано и отправлено Алисой.
Цифровые подписи используются не только для проверки подлинности сообщений. Они также используются в следующих случаях:
Цифровые подписи для цифровых сертификатов: это позволяет отправителю вставить цифровую подпись в цифровой сертификат.
Цифровые подписи для подписи кода: это позволяет разработчику приложения вставить свою цифровую подпись в исходник приложения, чтобы помочь пользователям проверить подлинность программного обеспечения или приложения.
На следующем рисунке показан пример приложения, содержащего цифровой сертификат:
На следующем рисунке показана дополнительная проверка цифровой подписи подписавшего:
Система доверия PKI
Ранее мы узнали, что организация может получить цифровой сертификат от доверенного центра сертификации в Интернете. Однако во многих крупных организациях вы обычно найдете корневой ЦС и множество промежуточных ЦС. Корневой ЦС отвечает за создание первичного цифрового сертификата, который затем делегируется каждому подчиненному ЦС или промежуточному ЦС. Промежуточный ЦС будет использовать цифровой сертификат корневого сервера для создания новых цифровых сертификатов для конечных устройств, таких как внутренние серверы.
На следующем рисунке показана иерархия корневого и промежуточного ЦС:
Использование этого типа иерархической структуры снимает нагрузку с корневого центра сертификации по управлению всеми цифровыми сертификатами в организации. Некоторые из этих обязанностей делегированы промежуточным серверам ЦС в сети. Представьте, что в вашем головном офисе вы развернули корневой ЦС, а в каждом удаленном филиале развернули промежуточные ЦС. Следовательно, каждый промежуточный ЦС отвечает за управление сертификатами своего собственного домена или филиала. Это также снижает риски взлома корневого ЦС злоумышленником, так что в случае взлома промежуточного ЦС корневой ЦС может быть отключен от сети, не затрагивая другие конечные устройства или промежуточные ЦС.
В небольших сетях можно развернуть один корневой ЦС для предоставления цифровых сертификатов каждому конечному устройству, как показано на следующем рисунке:
Как показано на предыдущем рисунке, одним ЦС легко управлять. Однако по мере роста сети наличие единственного центра сертификации в сети не позволит легко масштабироваться, поэтому необходимо использовать иерархическую структуру с корневым центром сертификации и промежуточными (подчиненными) центрами сертификации.