По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Всем привет! В сегодняшней статье расскажем о том, как настроить отправку статистики о пакетах, проходящих через наш роутер Mikrotik на коллектор для дальнейшего анализа. Все мы знаем про такой протокол как Netflow, предназначенный для учёта сетевого трафика, разработанный компанией Cisco, так вот у Mikrotik есть своя реализация данного решения, которая полностью совместима со стандартом Cisco Netflow - Mikrotik Traffic Flow. Помимо мониторинга и анализа трафика, с помощью Traffic Flow, администратор может выявлять различные проблемы, которые могут появляться в сети, а также анализировать и оптимизировать общие сетевые характеристики. Поскольку Traffic Flow полностью совместим с Cisco Netflow, то он может использоваться различными утилитами, которые разработаны для Netflow. Traffic Flow поддерживает следующие версии Netflow: version 1 - Самая первая версия формата данных Netflow. Рекомендуется использовать только если нет альтернатив version 5 - Дополнение первой версии, которой появилась возможность добавления номеров автономных систем (AS) BGP и порядковых номеров потоков version 9 - новая версия, позволяющая добавлять новые поля и типы записей благодаря шаблонному исполнению Настройка Итак, для того, чтобы начать собирать статистическую информацию о трафике, необходимо сначала включить Traffic Flow и определиться с каких интерфейсов осуществлять сбор. Делается это при помощи комбинации следующих команд: /ip traffic-flow set enabled=yes interfaces=ether1 В нашем случае, указан лишь один интерфейс ether1, однако, если вы хотите собирать статистику с нескольких интерфейсов, просто укажите их через запятую. Если со всех - интерфейсов введите interfaces=all. Вы также можете настроить количество потоков, которые могут одновременно находиться в памяти роутера командой cache-entries и указав нужное значение - (128k | 16k | 1k | 256k | 2k / 4k - по умолчанию) Командой active-flow-timeout - можно настроить максимальное время жизни потока, по умолчанию это 30 минут. Некоторые потоки, могут стать неактивными через какое-то время, то есть, в них не будет происходить обмен пакетами, этот тайм-аут настраивается командой inactive-flow-timeout. Если пакетов в потоке нет и данное время истекло, то в следующий раз traffic flow создаст новый поток, если обмен возобновится. По умолчанию это 15 секунд, но если сделать данное время слишком коротким, то это может привести к созданию большого количества отдельных поток и переполнению буфера. После того как мы включили Traffic Flow и определились с интерфейсами, с которых хотим получать информацию о потоках, необходимо настроить хост назначения, который будет получать данную информацию (в терминологии Netflow такой хост называется коллектором). Делается это при помощи следующей команды ip traffic-flow target Затем указывается IP адрес и UDP порт хоста назначения -add dst-address=(IP address) port=(UDP port). Если вы хотите использовать конкретную версию протокола, то укажите ее командой version= (1,5,9) Пример Рассмотрим пример конфигурации Traffic Flow на роутере Mikrotik Допустим мы хотим собирать статическую информацию о трафике, который проходит через интерфейс ether3 нашего роутера и отправлять её на коллектор по адресу 192.168.2.123 используя 5 версию протокола. В этом случае конфигурация может выглядеть следующим образом: Сначала включаем Traffic Flow и указываем интерфейс /ip traffic-flow set enabled=yes interfaces=ether3 Затем указываем адрес коллектора, стандартный порт и версию протокола 5: /ip traffic-flow target add dst-address=192.168.2.123 port=2055 version=5 Если Вы предпочитаете консоли утилиту WinBox, то для настройки Traffic Flow левом меню откройте пункт IP и выберите Traffic Flow, перед Вами откроется следующее окно: Необходимо включить Traffic Flow, поставив галочку напротив Enabled и выбрать желаемый интерфейс для сбора информации. После этого переходим на вкладку Targets и добавляем параметры коллектора, достаточно внести IP адрес, порт и версию. После этого нажимаем на кнопку Apply После этого наш роутер начнет отправлять информацию на коллектор. Если вы хотите указать несколько коллекторов, то это можно сделать, используя разные версии протокола и номера UDP портов.
img
PPTP (Point to Point Protocol), или, если дословно перевести, тунельный протокол типа точка-точка, является простым и быстрым решением по предоставлению удаленного доступа для пользователей. Данный протокол нативно поддерживается на операционных системах Windows XP, 7, 8, и так далее, что делает его идеальным решением для большинства офисных работников – он, к тому же, не требует установки никакого дополнительного ПО. Главное, что нужно понимать: PPTP не обладает сильным шифрованием и прочими «фишками», которые предлагают IPSEC или SSL VPN решения. Несмотря на то, что MPPE (Microsoft Point-to-Point Encryption), поддерживаемый маршрутизаторами Cisco предоставляет довольно высокую степень защищенности, все равно не должен использоваться в сценариях, когда предоставляется доступ к ценной и/или конфиденциальной информации. Как и в других решениях, предоставляющих удаленный доступ, удаленный пользователь может использовать PPTP для доступа к корпоративной сети и, по сути, он будет подключен прямо к внутренней подсети. PPTP всегда настраивается между сервером (маршрутизатором Cisco) и клиентом (рабочей станцией Windows). PPTP поддерживается маршрутизаторами Cisco, а МСЭ ASA, в свою очередь, не поддерживают терминирование туннеля на самом фаерволле. Процесс настройки клиента легко ищется в интернете, данная же статья описывает настройку маршрутизатора. Сценарий и схема сети В данной статье у нас предполагается следующий сценарий: к корпоративной сети принадлежит несколько филиалов, соединенных через VPN (к примеру, MPLS VPN, IPSEC VPN и так далее). Главный офис подключен к интернету и мы реализиуем простой и быстрый способ подключения удаленных пользователей к данной сети. Допустим, интерфейс VLAN 1 (подсеть 10.10.10.0/24) маршрутизируется в основной сети. Если мы «подключим» удаленных пользователей через PPTP туннель к данному VLAN и назначим адрес из диапазона 10.10.10.0/24, то, логично, что у них появится доступ ко всем сетевым ресурсам. В данном случае аутентификация будет реализована через локальные аккаунты на маршрутизаторе Cisco. Однако, в соответствии с рекомендациями по безопасности, мы рекомендуем использовать внешний RADIUS cервер. Оборудованием в нашем гипотетическом случае является 867VAE-K9 с образом c860vae-advsecurityk9-mz.152-4.M3.bin. PPTP всегда настраивается между сервером (маршрутизатором Cisco) и клиентом (рабочей станцией Windows). PPTP поддерживается маршрутизаторами Cisco, а МСЭ ASA, в свою очередь, не поддерживают терминирование туннеля на самом фаерволле. Настройка маршрутизатора Ниже приведен пример конфига, с комментариями почти после каждой команды. vpdn enable //Включаем VDPN (Virtual Private Dialup Network) vpdn source-ip 1.1.1.1 //адрес используемый для входящих подключений vpdn-group MerioNet //название группы accept-dialin //разрешает маршрутизатору принимать подключение protocol pptp //используемый протокол virtual-template 1 //интерфейс, используемый для доступа interface Virtual-Template1 //интерфейс используемый для клонирования !описание PPTP доступа ip unnumbered Vlan1 //использование адреса, настроенного для VLAN 1 ip virtual-reassembly in load-interval 30 peer default ip address pool PPTP-Pool //назначение сетевого адреса для клиентов в диапазоне, указанном в PPTP- no keepalive ppp encrypt mppe auto //Использование MPPE шифрования с автоматически указанной силой шифрования (40, 56 или 128 бит) ppp authentication ms-chap ms-chap-v2 //настройка разрешенных способов методов аутентификации ip local pool PPTP-Pool 10.10.10.90 10.10.10.100 //диапазон IP-адресов, которые могут получать клиенты username RemoteUserMerionet password merionet //создание локального пароля и логина для подключения. Далее, обратите внимание на настройку интерфейсов (очевидные и всем известные команды): interface GigabitEthernet1 description WAN Interface ip address 1.1.1.1 255.255.255.252 interface Vlan1 description LAN Network ip address 10.10.10.1 255.255.255.0 Далее, попробуйте подключить какой-нибудь клиент и проверьте работоспособность PPTP командами: show users show vpdn
img
Как известно, в телефонии существует два основных вида перевода (или трансфера - transfer) входящих звонков, это: Attendant Transfer/ consultative transfer - Перевод звонка, при котором оператор, получив информацию от звонящего, ставит звонок на удержание, затем инициирует второй вызов третьей стороне (абоненту, с которым хочет соединиться звонящий), уведомляет о входящем вызове и лишь после разрешения третьей стороны, соединяет с вызывающим абонентом. После этого, оператор кладет трубку и больше никак не влияет на переведенный вызов. Таким образом, оператор остается уверенным в том, что звонящий соединен с нужным абонентом. В случае, если у оператора не получается дозвониться до вызываемого абонента или он сообщает, что не может в данный момент принять звонок, оператор снимает звонящего с удержания и просит его перезвонить позднее. Blind Transfer - Даже из названия становится понятно, что данный вид перевода является “слепым”, т.е оператор переводит звонок, не уведомляя третью сторону в входящем вызове. Не трудно догадаться, что если вызываемый абонент занят или не отвечает, то вызов попросту обрывается. Согласитесь, ситуация крайне нежелательная, клиентам приходится заново набирать номер, общаться с оператором, объяснять, что разговора не состоялось и т.д. Теряется время, лояльность клиентов и интерес. В IP телефонии на базе Asterisk с данной проблемой познакомились, когда начали осуществлять миграцию с аналоговых АТС. Дело в том, что аналоговые АТС по умолчанию поддерживают так называемый Transfer Recall. Данный функционал заставляет АТС перезванивать оператору, если звонок между вызывающим и вызываемым абонентами, по каким то причинам не состоялся. Оператор, в свою очередь, просил вызывающего абонента перезвонить. Проблема с потерянными вызовами после “слепого” перевода имела место быть вплоть до Asterisk версии 1.6, когда в файл feature.conf в Attended Transfer (atxfer) не был введен дополнительный функционал atxferdropcall , со значениями yes и no atxferdropcall = yes - Звонок не будет возобновлен после неудачного перевода atxferdropcall = no – Звонок будет возобновлен после неудачного перевода По умолчанию в Asterisk данная переменная имеет значение yes. Таким образом, чтобы решить проблемы с потерянными вызовами при переводе, нужно просто изменить файл feature.conf следующим образом: [general] parkext => *700 parkpos => 701-720 context => parkedcalls parkedcalltransfers = caller transferdigittimeout => 1 xfersound = beep xferfailsound = beeperr atxfernoanswertimeout = 15 atxferdropcall = no atxferloopdelay = 10 atxfercallbackretries = 2 [featuremap] blindxfer => * atxfer => # Где, atxfernoanswertimeout - Время, которое необходимо для дозвона обратно; atxfercallbackretries - Количество попыток повторного дозвона
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59