По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! В сегодняшней статье расскажем о том, как настроить отправку статистики о пакетах, проходящих через наш роутер 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 портов.
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
Как известно, в телефонии существует два основных вида перевода (или трансфера - 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 - Количество попыток повторного дозвона