По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Существует несколько факторов, которые следует учитывать при реализации решения SD-WAN. Одним из них является мониторинг сети. В этом посте мы рассмотрим некоторые проблемы SD-WAN и то, как мониторинг сети может помочь их преодолеть.
Исправление пути и аварийное переключение
Одним из преимуществ SD-WAN является исправление пути и автоматическое аварийное переключение. Эта функция доступна, когда маршрутизатор имеет несколько соединений, таких как MPLS, широкополосное соединение или LTE. В этом сценарии трафик можно направлять по разным линиям, что повышает надежность и качество. Например, если канал испытывает большие задержки или потерю пакетов, маршрутизатор может отправлять трафик через другой канал. Некоторые решения SD-WAN даже дублируют пакеты по двум каналам, увеличивая вероятность того, что трафик достигнет другого конца.
Эти изменения трафика могут оказать немедленное положительное влияние, но могут отрицательно повлиять на сквозную производительность. Например, маршрутизатор может маршрутизировать трафик через канал с более низкой скоростью, замедляя соединение. В случае дублирования пакетов общая полоса пропускания, доступная пользователям, уменьшается. В результате приложения могут работать медленнее, чем до корректирующего действия, которое заставляет пользователей жаловаться. Устранение проблем такого рода очень сложно без правильной информации.
Сквозные сетевые тесты
Сквозные сетевые тесты (end-to-end) предоставляют полезные данные для устранения проблем, подобных той, что проиллюстрирована ранее. Для наиболее важных служб и приложений, используемых в удаленном филиале, инструмент сетевого мониторинга должен собирать следующие показатели:
Задержка и потеря пакетов на удаленном сервере приложений (пинг по протоколу ICMP или TCP)
Джиттер для голосовой и видеосвязи (UDP iperf)
Количество сетевых скачков и изменений пути (traceroute / tracepath)
Пропускная способность для других сайтов WAN и для Интернета (iperf, NDT и speedtest)
Решения SD-WAN могут сообщать о некоторых из этих метрик, но они либо пассивны, либо учитывают только ограниченную часть сети. Обычно это последняя миля, где работают устройства SD-WAN.
Инструмент мониторинга сети для SD-WAN учитывает весь сквозной процесс от уровня пользователя до пункта назначения на дальнем конце. Такое решение для мониторинга опирается на активные агенты сетевого мониторинга, которые устанавливаются на периферии как в виде физического, так и виртуального устройства. Сквозные сетевые тесты выполняются непрерывно, а результаты извлекаются в режиме реального времени и сохраняются для исторического просмотра.
Мониторинг взаимодействия с конечным пользователем
Мониторинг взаимодействия с конечным пользователем является еще одним ключевым элементом решения для мониторинга SD-WAN. Существует множество способов получения опыта конечного пользователя и множество инструментов на рынке, нацеленных на это. Как правило, мониторинг взаимодействия с конечным пользователем включает в себя статистику и показатели уровня приложения, такие как:
Время разрешения DNS
Время загрузки HTTP
Средняя оценка мнения (MOS) для VoIP
Показатели производительности WiFi
Когда данные о производительности, генерируемые активным агентом мониторинга, соединяются с пассивными данными, полученными устройством SD-WAN, это дает четкое представление о производительности сети. Активные данные полезны для сбора упреждающих предупреждений и устранения неполадок при проблемах производительности в режиме реального времени. Пассивные данные используются, чтобы дать четкое представление о том, как полоса пропускания используется пользователями («ведущими участниками») и приложениями («наиболее эффективными приложениями»), и при необходимости обновлять конфигурацию сети. Сочетание этих двух технологий приводит к уменьшению времени разрешения проблем сети и приложений, повышению производительности и удовлетворенности пользователей.
Носки бывают чрезвычайно полезны. Сейчас мы расскажем, как правильно настроить их на роутере MikroTik. Итак, поговорим о SOCKS?
Предисловие
SOCKS (SOCKet Secure) – это сетевой протокол, с помощью которого можно обеспечивать прохождение TCP пакетов в обход блокирующих правил Firewall’а. Это реализуется за счёт proxy-сервера (также называют SOCKS-сервер), который контролирует подключение внутренних клиентов и их права на доступ к внешним ресурсам или же наоборот – внешних клиентов, к ресурсам внутри сети. SOCKS работает на сеансовом уровне, поэтому с помощью него можно проксировать FTP, HTTP, Telnet и другие верхнеуровневые протоколы. В то время как HTTP-прокси, как правило, позволяет проксировать только GET и POST запросы.
Установление соединения
Когда клиент хочет получить доступ к внешнему ресурсу, который блокирует Firewall, то соединение происходит следующим образом:
Клиент подключается к proxy-серверу (обычно используется TCP порт 1080);
Сервер проверяет список доступа и выясняет, есть ли у клиента права на доступ к внешним ресурсам;
Если клиент имеет такие права, то proxy-сервер пересылает пакет на внешний ресурс, к которому хочет получить доступ клиент;
Сервер создаёт сессию между клиентом и внешним ресурсом и между ними начинается обмен пакетами верхнеуровневых протоколов. После установления соединения можно передавать и UDP пакеты.
В настоящее время, MikroTik поддерживает SOCKS версии 4 при указании внешнего ресурса он понимает только IP-адрес. Версия SOCKS4a – может резолвить доменные имена внешних ресурсов. Более поздняя версия протокола – SOCKS5 включает расширенную поддержку аутентификации, подключение по UDP и IPv6.
На сегодняшний день, протокол SOCKS5 пока не поддерживается на устройствах MikroTik. Хотя пользователи очень просят разработчиков включить поддержку SOCKS5 в новые релизы RouterOS вот уже 8 лет. Поэтому при работе с SOCKS совместно с MikroTik, клиент также должен иметь 4 версию.
Необходимо очень тщательно настроить Firewall'ьные правила и список доступа SOCKS чтобы исключить нежелательный доступ извне. Как правило, скомпрометированные через уязвимости SOCKS устройства, используются для рассылки спама и фишинговых писем.
Перейдём к настройкам SOCKS-сервера на MikroTik:
Параметры настройки через WinBox
Параметры настройки SOCKS сервера в WinBox находятся в IP → Socks:
Как только вы поставите галочку напротив Enabled сервер станет активным. Далее, необходимо настроить списки доступа, для этого нажимаем на кнопку Access:
Активные SOCKS сессии, проходящие через сервер можно отслеживать на вкладке Connections
Параметры настройки через Termial
Для того, чтобы настроить SOCKS через терминал нужно также сначала настроить параметры сервера. Настройка проводится через команду ip socks set, доступы следующие параметры:
enabled - включает функционал SOCKS proxy-сервера (yes - включен, no - выключен);
port - номер порта, на котором сервер будет слушать SOCKS запросы. По умолчанию - 1080
connection-idle-timeout - время, через которое будут сброшены неактивные сессии (по умолчанию – 2 минуты (2m));
max-connections - максимальное число одновременных подключений (по умолчанию - 200)
Посмотреть текущие или настроенные параметры можно командой:
/ip socks print
Далее необходимо настроить правила, по которым будет осуществляться контроль доступа к серверу SOCKS. Для этого вводим команду /ip socks access set, доступны следующие параметры:
action - действие, которое будет предпринято при соответствии критериев данного правила:
allow - разрешить прохождение трафика по данному правилу;
deny - запретить прохождение трафика по данному правилу.
dst-address - адрес сервера назначения;
dst-port - TCP порт назначения, на котором удаленный сервер слушает SOCKS
src-address - адрес источника пакетов (клиент);
src-port - TCP порт источника
Практическое применение
Допустим злой сисадмин заблокировал наш любимый wiki.merionet.ru, выяснил адрес и забанил.
О том, как настраивать правила Firewall в MikroTik читайте здесь
Но одному нашему сотруднику обязательно нужно иметь доступ к данному ресурсу. Поэтому сисадмин открывает активирует SOCKS сервер и настраивает список доступа.
В качестве адреса клиента указывается IP адрес компьютера сотрудника, которому нужно открыть доступ (в нашем случае 192.168.11.48), в качестве порта источника – любой TCP порт от 1024 до 65535. В качестве адреса назначения – IP адрес ресурса wiki.merionet.ru и порт 80 (http).
Та же самая настройка через терминал выглядит следующим образом:
ip socks> set enabled=yes
ip socks access> add src-address=192.168.11.48 src-port=1024-65535 dst-address=212.193.249.136 dst-port=80
... action=allow
Готово, теперь дело за клиентом, который должен настроить сотрудник. Покажем настройку на примере браузера Google Chrome. Открываем Settings → Advanced → Confidentiality and Security, крутим в самый низ до пункта System и выбираем Proxy settings. В появившемся окне выбираем LAN settings → ставим галку напротив Use a proxy server for your LAN и заходим в Advanced. В появившемся окне вбиваем параметры нашего SOCKS сервера в строку Socks (в нашем случае 192.168.11.1 и порт 1080) и применяем настройки:
Теперь обновляем страничку wiki.merionet.ru и ву-а-ля, всё заработало! В окне Connections видны соединения с нашего компьютера до IP адреса wiki.merionet.ru.
Послесловие
Данная статья носит исключительно образовательный характер и не ставит своей целью научить кого-либо обходить правила Firewall. Протокол SOCKS 4 устарел, не поддерживает аутентификацию и не может резолвить доменные адреса. В целях безопасности, мы не рекомендуем использовать этот протокол вообще и в том числе – настраивать его на MikroTik.
По умолчанию – сервер SOCKS на роутерах MikroTik отключен. Если Вы обнаружили, что он активирован, то это может быть признаком того, что Ваш роутер был скомпрометирован злоумышленниками. Об этом мы подробнее расскажем в следующих статьях.
Как и любая современная АТС, Asterisk имеет свою встроенную систему хранения истории звонков - CDR (Call Detail Record). Она используется для снятия статистики, ведения отчетности, прослушивания вызовов или подсчета биллинговых показателей.
В Asterisk для этого создана база данных asteriskcdrdb, в которой существует таблица cdr. Давайте рассмотрим как пользоваться данной таблицей и ее структуру.
[root@asterisk]# mysql // подключаемся к MySQL
После успешного подключения, необходимо выбрать для работы базу данных asteriskcdrdb:
mysql> use asteriskcdrdb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
Давайте убедимся, что у нас есть таблица cdr. Выполним это, как указано ниже:
mysql> show tables;
+-------------------------+
| Tables_in_asteriskcdrdb |
+-------------------------+
| cdr |
| cel |
+-------------------------+
2 rows in set (0.00 sec)
На данном этапе мы убедились, что у нас есть база данных asteriskcdrdb, в которой находится таблица cdr. Давайте попробуем посмотреть входящие звонки из города за сегодня (дата написания статьи 18 марта 2016 года), в период с 12:00 до 12:10, т.е за 10 минут:
SELECT `dst` , `src` , `duration` , `calldate` , `recordingfile`
FROM `cdr` WHERE `calldate` >= '2016-03-18 12:00:00' AND `calldate` <= '2016-03-18 12:10:00' AND LENGTH( `src` ) >3;
+-----+-------------+----------+---------------------+----------------------------------------------------------------+
| dst | src | duration | calldate | recordingfile |
+-----+-------------+----------+---------------------+----------------------------------------------------------------+
| 113 | 84991111111 | 140 | 2016-03-18 12:00:36 | external-113-84991111111-20160318-115933-1458291573.157155.wav |
| 104 | 89162222222 | 81 | 2016-03-18 12:01:33 | external-104-89162222222-20160318-120133-1458291693.157169.wav |
+-----+-------------+----------+---------------------+----------------------------------------------------------------+
2 rows in set (0.00 sec)
В вышеуказанном примере, в SQL запросе указано LENGTH( `src` ) >3. Столбец ‘src’ – показывает номер звонящего (source - источник). Это сделано для того, чтобы исключить внутренние звонки, так как у нас используется трехзначная нумерация. Тем самым, мы получаем в результате данные, с которыми затем можем работать. Например, отправить на почту в виде отчета. Ниже рассмотрена структура таблицы cdr в базе данных asteriskcdrdb:
Столбец
Пример значения
Описание
calldate
2016-03-18 12:00:36
Дата и время звонка
clid
"Oleg Ivanov" <84991111111>
В данное поле попадает полное CallerID (CLID, CID), которое состоит из имени и номера звонящего. Это доступно только для считывания.
src
84991111111
Номер звонящего в конструкции CallerID (CNUM). Это доступно только для считывания.
dst
113
Номер назначения для звонка. Это доступно только для считывания.
dcontext
CustomContext1
Контекст для обработки. Это доступно только для считывания.
channel
SIP/0002B2356854-a34bh3ef
Канал, через который поступил звонок
dstchannel
SIP/0004F6675969-97836bb0
Канал, через который ушел исходящий звонок
lastapp
Dial, Busy, Congestion
Приложение, которое последним отработало этот вызов перед попаданием в таблицу cdr
lastdata
SIP/0004F6675969,30,tT
Аргумент, который был передан приложению, которое отработало вызов последним (lastapp)
duration
75
Количество секунд от начала (отметка start) до окончания вызова (отметка end)
billsec
67
Количество секунд от ответа (отметка answer) до окончания вызова (отметка end). Данное значение всегда меньше значения duration, и отражает длительность самого разговора, что важно для подсчета стоимости.
disposition
ANSWERED, BUSY, NO ANSWER, FAILED
Результат звонка
amaflags
OMIT, BILLING, DOCUMENTATION, Unknown
Метка Automatic Message Accounting (AMA) – автоматический учет стоимости вызова.
accountcode
23232
Идентификатор аккаунта. Данное значение пустое по умолчанию, и определяется параметрами конкретного пользователя.
uniqueid
1458291693.157169
Уникальный идентификатор звонка
userfield
-
Пользовательское поле. Здесь можно передавать что угодно, добавляя данные в этот столбец при работе с вызовом внутри контекста обработки.
did
4996491913
DID (Direct Inward Dialing). На основании DID вызова на Asterisk осуществляется его маршрутизация (это значение приходит от провайдера).
recordingfile
external-113-84991111111-20160318-115933-1458291573.157155.wav
Имя файла, содержащего запись разговора. В данном имени можно проследить путь к файлу в файловой структуре сервера.
cnum
84991111111
Номер звонящего в структуре CallerID.
cnam
Oleg Ivanov
Имя звонящего в структуре CallerID.
Теперь, когда вы понимаете принцип формирования запросов к базе данных и ее структуру, вы можете без труда формировать собственные отчеты. Например, ежедневный отчет о количестве входящих звонков за текущий день на почту. Это реализуется средствами php скрипта и добавления расписания через cron. Поговорим об этом в следующей статье