По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Настройка RIPv2 (Routing Information Protocol v2) - крайне простой процесс и состоит из трех шагов:
включения протокола глобальной командой router rip
сменой версии протокола на вторую version 2
выбор сетей, которые протокол будет «вещать», для чего используется команда(ы) network;
Первые две команды очевидны, но последняя команда требует объяснения: с помощью network вы указываете интерфейсы, которые будут участвовать в процессе маршрутизации. Данная команда берет классовую сеть как параметр и включает RIP на соответствующих интерфейсах.
Пример настройки RIPv2
В нашей топологии у маршрутизаторов R1 и R2 есть напрямую подключенные подсети.
Нам нужно включить данные подсети в процесс динамической маршрутизации RIP. Для этого нам сначала нужно включить RIP на обоих маршрутизаторах и затем «вещать» данные сети с помощью команды network. На маршрутизаторе R1 переходим в глобальный режим конфигурации и вводим следующие команды:
router rip
verison 2
network 10.0.0.0
network 172.16.0.0
Немного пояснений – сначала мы включаем протокол динамической маршрутизации, затем меняем версию на вторую, затем используем команду network 10.0.0.0 для включения интерфейса Fa0/1 на маршрутизаторе R1. Как мы уже говорили, команда network берет классовую сеть, так что каждый интерфейс с подсетью, начинающейся на 10 будет добавлен в RIP процесс. К примеру, если на другом интерфейсе будет адрес 10.1.0.1, то он тоже будет добавлен в процесс маршрутизации. Также нам необходимо соединить два маршрутизатора в RIP, для этого добавляем еще одну команду network – с адресом 172.16.0.0
IP-адреса начинающиеся на 10, по умолчанию принадлежат к классу «А» и имеют стандартную маску подсети 255.0.0.0.
На R2 настройка выглядит похожей, только с другой подсетью – т.к к маршрутизатору R2 напрямую подключена подсеть 192.168.0.0.
router rip
verison 2
network 192.168.0.0
network 172.16.0.0
Как проверить таблицу маршрутизации?
Для проверки, необходимо ввести команду show ip route - вы должны увидеть подсеть 192.168.0.0/24 на R1 и подсеть 10.0.0.0/24 на R2 отмеченных буквой R – то есть это RIP маршрут. Также там будет видна административная дистанция и метрика для данного маршрута.
Административная дистанция – это некая степень доверия к протоколу, и у RIP данный показатель равен 120. В качестве метрики у RIP выступает число хопов между подсетями.
Фаервол на Микротике основан на базе принципов iptables в Linux позволяет фильтровать входящий и исходящий трафик по определенным правилам. В статье мы хотим рассказать про ключевые компоненты Firewall, дизайне и реализации этого инструмента. Погнали!
Общее представление
Основная идея любого фаервола это определение того, что разрешено и запрет всего остального. Так работают все современные инструменты фильтрации. При наличии фаервола, сеть можно разделить на ненадежные, полу - надежные и надежные.
Firewall Chains
Цепочки (последовательности) фаерволов сопоставляют по своим правилам входящий и исходящий с интерфейса трафик. После того, как трафик попал под определенное правило («сматчился»), вы можете совершать определенные манипуляции с ним: разрешить, блокировать, отклонить, внести в лог запись и так далее. В Mikrotik есть следующие флаги: Input, Output и Forward.
Input Chain
Input матчит входящий на интерфейсы маршрутизатора трафик. Условно говоря – это прилетающие на роутера IP - пакеты. Обычная практика – дропать пакеты, прилетающие на WAN, направленные на сканирование портов, попытки взлома и прочие. Помимо этого, многие блокируют входящий трафик изнутри локальной сети (например, допуск к Winbox или SSH должен быть только с определенного VLAN – остальные дропаются).
Всегда используйте VLAN – это базовое разграничение, которое позволит вам обеспечить современные стандарты безопасности.
Output Chain
Как можно догадаться по названию, данный инструмент направлен на фильтрацию исходящего от роутера трафика. Здесь можно блокировать запросы, исходящие непосредственно с роутера: например, DNS или ICMP запрос с роутера.
Forward Chain
Самое интересное – данный инструмент «матчит» трафик проходящий через Mikrotik с одного интерфейса на другой. Пример: пакет, отправленный с хоста внутри LAN через маршрутизатор в сторону провайдера. Пакет прилетает на внутренний интерфейс, а выходит через WAN.
Firewall Actions
Правила на фаерволе могут делать множество вещей, основные из которых: accept (принять), drop (сбросить) и отклонить (reject).
Accept
Данное правило позволяет просто «пропустить» проходящий через фаервол трафик. Никакой модификации или изменения маршрута – пакету будет позволено продолжить свой изначальный путь.
Reject
Фаервол может легко отклонить (сделать reject) пакетов, которые попадут под определенное правило. При этом, источнику такого пакета будет отправлено уведомление о соответствующей блокировке.
В данном методе есть один весомый минус: в случае, если злоумышленник попробует «сканировать» порты или совершить другой вид атаки – отправленные в его сторону REJECT сообщения лишь помогут ему в злодеяниях. Поэтому, в целях безопасности, мы рекомендуем использовать DROP.
Drop
Данное правило «дропает» пакет без отправления уведомления об этом источнику. Этот метод наиболее безопасен на этапе защиты своего Mikrotik от сканирования портов и прочих атак.
Firewall Rules
Правила Firewall определяют пакеты, которые будут обработаны на уровне фаервола, а какие будут отброшены. Каждое правило – это комбинация параметров IP – адресации (источник/получатель пакета), цепочек (chains), действий (actions), интерфейсов и прочих опций. Как мы говорили ранее – хорошо настроенный фаервол пропустит только необходимый для бизнеса трафика, дав запрет на пропуск всего остального потока трафика. Указывая набор разрешающих правил, всегда замыкайте их на конце строчкой «DENY ALL» (запретить все).
Chains
Каждое создаваемое правило назначается определенной цепочке (chain). После определения принадлежности к цепочке, пакеты проходят проверку через последовательность правил в порядке убывания (сверху вниз).
Порядок правил в фаерволе играет важную роль! Поэтому, от последовательности проверки зависит эффективность фильтрации.
Actions
Правило отрабатывает по одному из основных действий: принять (accept), отклонить (reject) и отбросить (drop). Выше мы подробнее рассказывали про каждое из указанных действий.
Адресация
Нашему правилу можно сказать, по какому критерию проводить блокировку: это может быть протокол, IP – адрес (это может быть как хост с /32 маской, так и целая подсеть с /24, например). Помимо этого, критерием могут быть физические или логические интерфейсы (eth/GRE).
Комментарии
Создавая правила комментируйте их. Это важно, как и при программировании – код без комментариев очень сложно анализировать и понимать в будущем.
Советы
Хотим так же поделиться парой полезных советов по настройке Firewall:
Разрешайте только необходимый для работы трафик - да, это сложно. Но методом проб и ошибок мы рекомендуем добиться той настройки фаервола, в рамках которой все ваши подключения будут ясны и понятны.
Подключения только с определенного пула адресов - это может быть удаленный офис, IP – адреса ЦОД или VPN адресация. Тут нужно быть особенно бдительным.
В конце правил всегда используйте «deny all» - после того, как вы выполнили первую и вторую рекомендации и весь тип трафика по протоколам, адресации, источникам (в том числе L7, например) четко определен – в конце цепочки добавьте правило запрета всего. Это будет означать, дословно: «Все, что не разрешено - запрещено».
Атакуйте свою сеть! - да, да, вы не ослышались. Конечно, без фанатизма :) Мы предлагаем периодически сканировать порты на вашем фаерволе. Например, это можно делать с помощью утилиты исследования сети Nmap.
Для пользователей, которые обладают премиальной лицензии на Cisco Unified Contact Center Express (UCCX), одной из самых крутых фич является наличие возможной интеграции и отправки запросов в базу данных. Сами запросы могут строиться на базе введенной звонящим информации, его номера – чего угодно.
Безусловно важно сделать ¬¬изначальный дизайн скриптов правильным и учитывать нагрузку. Большие и тяжелые скрипты, которые имеют много «плеч» в БД (базу данных), значительно увеличивают нагрузку на ресурсы сервера. А если БД еще и удалена от сервера CCX и имеет место сетевая задержка, то может иметь место прямое воздействие на бизнес и лояльность звонящего вам клиента.
Обзор Cisco Unified CCX Script Editor
Для создания и управления IVR скриптами в UCCX используется специальный инструмент - Cisco Unified CCX Editor. Он позволяет визуально управлять некими блоками, которые отвечают за то, или иное действие. Выглядит эта палетта следующим образом:
Давайте рассмотрим раздел Database. Здесь мы видимо 4 пункта:
DB Get - сопоставление полученных данных из БД к переменным скрипта;
DB Read - подключение к серверу и запрос;
DB Release - закрываем подключение к БД;
DB Write - если нужно внести изменения в БД, используем Write метод;
На скриншоте выше видно, что каждый скрипт начинается с события Start и заканчивается событием End. Во время звонка, по ходу выполнения скрипта, мы можем запрашивать данные из БД сколько угодно раз. Каждый запрос имеет свой отдельный список шагов, которые указаны в списке из 4х пунктов выше.
Мы рекомендуем предварительно обкатать все SQL запросы, доступ системы и прочие рабочие факторы перед выгрузкой в продуктивную среду
Например, давайте посмотрим, что скрыто внутри блока DB Read:
Взглянем на поля, которые доступны для конфигурации:
DB Resource Name - метка запроса. Своего рода метка;
Data Source Name - источник данных (DSN), указанное в административной консоли UCCX (Cisco Unified CCX Administration Database);
Timeout (in sec) - пауза выполнения запроса. Этот интервал защитит вашу систему от, например, потери связи с БД. То есть, максимум 7 секунд ожидания. Кстати, если указано как 0, то запрос не будет ограничен по времени;
Теперь из вкладки General переходим во вкладку Field Selection:
Запрос - SQL – команда (запрос), который вы ходите выполнить. Например, SELECT fld1, fld2 from tbl where fld1 = $variable - выбираем два поля из таблицы, где одно из полей равно переменной, которую, мы ранее, присвоили в скрипте (DTMF от клиента, например);
Test (кнопка) - нажмите на эту кнопку, чтобы проверить синтаксис запроса и подключение к БД;
Number of rows returned - количество вернувшихся строк запроса, в случае, если была нажата кнопка Test;
Show all fields (select table/view) - показать все поля в таблице, к которой выполняется подключение;
Отлично, разобрались. Теперь давайте взглянем на блок DB Get:
DB Resource Name - лэйбл или имя для этого запроса;
Data Source Name - имя БД (настраивается на стороне Cisco Unified CCX Administration);
Refresh Database Schema (кнопка) - кнопка, которая отвечает за подтягивание данных БД и таблицы в CCX Editor;
Переходим во вкладку Field Selection:
Table/View - данное поле показывает имя таблицы из БД, которая выбрана во вкладке General, которую мы описывали выше;
Табличное поле:
Field Name - имя поля, в выбранной БД;
Data Type - типа данных (строка/число и так далее);
Local Variable - переменная скрипта, которая будет хранить соответствующее поле;
Add/Modify (кнопки) - кнопки, которые отвечают за модификацию полей (кроме типа данных, он read only);
Полученные данные можно использовать в скрипте, например, чтобы озвучивать клиенту (TTS) его данные по номеру телефона, или по введенным цифрам (номер заказа). Кстати, аналогичную фичу мы реализовали в связке Yandex.SpeechKit и Asterisk.