По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Метрические веса TOS K1 K2 K3 K4 K5, выданные командой в режиме конфигурации маршрутизатора EIGRP, может быть использована для установки K-значений, используемых EIGRP в своем расчете. Параметр TOS был предназначен для использования маркировки качества обслуживания (где TOS обозначает тип служебного байта в заголовке IPv4). Однако параметр TOS должен быть равен 0. На самом деле, если вы введете число в диапазоне 1 - 8 и вернетесь назад, чтобы изучить свою текущую конфигурацию, вы обнаружите, что Cisco IOS изменила это значение на 0. Пять оставшихся параметров в команде metric weights - это пять K-значений, каждое из которых может быть задано числом в диапазоне от 0 до 255.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Часть 2. Про соседство и метрики EIGRP
Следующие статьи из цикла:
Часть 3. Конвергенция EIGRP – настройка таймеров
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Например, представьте, что в нашем проекте мы обеспокоены тем, что нагрузка на наши линии может быть высокой в разы, и мы хотим, чтобы EIGRP учитывал уровень насыщения линии при расчете наилучшего пути. Изучая полную формулу расчета метрики EIGRP, мы замечаем, что наличие ненулевого значения для K2 приведет к тому, что EIGRP будет учитывать нагрузку. Поэтому мы решили установить K2 равным 1, в дополнение к K1 и K3, которые уже установлены в 1 по умолчанию. Значения К4 и К5 сохранится на уровне 0. В приведенном ниже примере показано, как можно настроить такой набор K-значений.
OFF1#conf term
Enter configuration commands, one per line. End with CNTL/Z .
OFF1(config)#router eigrp 1
OFF1(config-router)#metric weights 0 1 1 1 0 0
OFF1(config-router)#end
Первый 0 в команде metric weights 0 1 1 1 0 0, показанной в приведенном выше примере, задает значение TOS равное 0. Следующие пять чисел задают наши пять K-значений: K1 = 1, K2 = 1, K3 = 1, K4 = 0, K5 = 0. Этот набор K-значений теперь будет учитывать не только пропускную способность и задержку, но и нагрузку при выполнении расчета метрики. Однако есть проблема. Обратите внимание на сообщения консоли, появляющиеся после нашей конфигурации. Оба наших соседства были разрушены, потому что маршрутизатор OFF1 теперь имеет другие K-значения, чем маршрутизаторы OFF2 и OFF3. Напомним, что соседи EIGRP должны иметь соответствующие K-значения, а это означает, что при изменении K-значений на одном EIGRP-спикер маршрутизаторе, вам нужен идентичный набор K-значений на каждом из его соседей EIGRP. Как только вы настроите соответствующие K-значения на этих соседях, то каждый из этих соседей должен соответствовать K-значениям. Как вы можете видеть, в большой топологии может возникнуть значительная административная нагрузка, связанная с манипуляцией K-значением.
Преемник и возможные маршруты преемников
Одна из причин, по которой EIGRP быстро восстанавливает соединения в случае сбоя маршрута, заключается в том, что EIGRP часто имеет резервный маршрут, готовый взять на себя управление, если основной маршрут уходит в down. Чтобы убедиться, что резервный маршрут не зависит от основного маршрута, EIGRP тщательно проверяет резервный маршрут, убедившись, что он соответствует условию осуществимости EIGRP. В частности, условие осуществимости гласит:
Маршрут EIGRP является возможным маршрутом-преемником, если его сообщенное расстояние (RD) от нашего соседа меньше возможного расстояния (FD) маршрута-преемника.
Например, рассмотрим топологию, показанную на следующем рисунке, и соответствующую конфигурацию, приведенную ниже. Обратите внимание, что сеть 10.1.1.8/30 (между маршрутизаторами OFF2 и OFF3) доступна из OFF1 через OFF2 или через OFF3. Если маршрутизатор OFF1 использует маршрут через OFF2, он пересекает канал связи 1 Гбит/с, чтобы достичь целевой сети. Однако маршрут через OFF3 заставляет трафик пересекать более медленное соединение со скоростью 100 Мбит/с. Поскольку EIGRP учитывает пропускную способность и задержку по умолчанию, мы видим, что предпочтительный маршрут проходит через маршрутизатор OFF2. Однако, что делать, если связь между маршрутизаторами OFF1 и OFF2 обрывается? Есть ли возможный преемственный маршрут, который может почти сразу заработать? Опять же, мы видим, что маршрутизатор OFF1 будет использовать возможный маршрут преемника через маршрутизатор OFF3. Однако, прежде чем мы убедимся в этом, мы должны подтвердить, что путь через OFF3 соответствует условию осуществимости.
Возможное условие преемника выполнено на маршрутизаторе OFF1
Просто в силу того, что маршрут через маршрутизатор OFF3 (то есть через 10.1.1.6) появляется в выходных данных команды show ip eigrp topology, выполненной на маршрутизаторе OFF1, мы делаем вывод, что путь через OFF3 действительно является возможным маршрутом-преемником. Однако давайте рассмотрим выходные данные немного более внимательно, чтобы определить, почему это возможный маршрут-преемник.
Во-первых, рассмотрим запись из выходных данных в приведенном выше примере, идентифицирующую последующий маршрут (то есть предпочтительный маршрут):
via 10.1.1.2 (3072/2816), GigabitEthernet0/1
Часть выходных данных via 10.1.1.2 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.2, который является маршрутизатором OFF2. На интерфейсе GigabitEthernet0/1 часть выходных данных указывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/1 (то есть выходной интерфейс). Теперь давайте рассмотрим эти два числа в скобках: (3072/2816). Стоимость 2816 называется зафиксированная дистанция (reported distance (RD). В некоторых литературных источниках это значение также называется advertised distance (AD). Эти термины, синонимы, относятся к метрике EIGRP, сообщенной (или объявленной) нашим соседом по EIGRP. В данном случае значение 2816 говорит нам, что метрика маршрутизатора OFF2 (то есть расстояние) до cети 10.1.1.8/30 равна 2816. Значение 3072 на выходе - это допустимое расстояние маршрутизатора OFF1 (FD). FD вычисляется путем добавления RD нашего соседа к метрике, необходимой для достижения нашего соседа. Поэтому, если мы добавим метрику EIGRP между маршрутизаторами OFF1 и OFF2 к RD маршрутизатора OFF2, мы получим FD (то есть общее расстояние), необходимое для того, чтобы OFF1 добрался до 10.1.1.8/30 через маршрутизатор OFF2. Кстати, причина, по которой маршрутизатор OFF1 определяет наилучший путь к сети 10.1.1.8/30, - это via via router OFF2 (то есть 10.1.1.2) В отличие от маршрутизатора OFF3 (то есть 10.1.1.6), потому что FD пути через OFF1 (3072) меньше, чем FD пути через OFF2 (28,416).
Далее рассмотрим запись для возможного последующего маршрута из приведенного выше примера:
via 10.1.1.6 (28416/2816), GigabitEthernet0/2
Часть выходных данных via 10.1.1.6 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.6, который является маршрутизатором OFF3. На интерфейсе GigabitEthernet0/2 часть результатов показывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/2. Эта запись имеет FD 28 416 и RD 2816. Однако прежде, чем EIGRP просто слепо сочтет этот резервный путь возможным преемником, он проверяет маршрут на соответствие условию осуществимости. В частности, процесс EIGRP на маршрутизаторе OFF1 запрашивает, является ли RD от маршрутизатора OFF3 меньше, чем FD последующего маршрута. В этом случае RD от маршрутизатора OFF3 составляет 2816, что действительно меньше, чем FD преемника 3072. Поэтому маршрут через маршрутизатор OFF3 считается возможным преемником маршрута.
Чтобы утвердить эту важную концепцию, рассмотрим топологию, показанную ниже. Процесс EIGRP на маршрутизаторе OFF1 изучил три пути для достижения сети 10.1.1.0/24. Однако далее EIGRP должен определить, какой из этих путей является маршрутом-преемником, какие (если таковые имеются) пути являются возможными маршрутами-преемниками, а какие (если таковые имеются) пути не являются ни преемником, ни возможным маршрутом-преемником. Результаты расчетов EIGRP приведены в таблице ниже.
Примеры расчетов Feasible Successor
Используя приведенную выше таблицу в качестве рассмотрения, сначала рассмотрим путь маршрутизатора OFF1 к сети 10.1.1.0/24 через маршрутизатор OFF2. С точки зрения маршрутизатора OFF2, расстояние до сети 10.1.1.0/24 - это расстояние от OFF2 до OFF5 (которое равно 5000) плюс расстояние от OFF5 до сети 10.1.1.0/24 (которое равно 1000). Это дает нам в общей сложности 6000 для расстояния от маршрутизатора OFF2 до сети 10.1.1.0/24. Это расстояние, которое маршрутизатор OFF2 сообщает маршрутизатору OFF1. Таким образом, маршрутизатор OFF1 видит RD 6000 от маршрутизатора OFF2. Маршрутизатор OFF1, затем добавляет расстояние между собой и маршрутизатором OFF2 (который равен 10 000) к RD от OFF2 (который равен 6000), чтобы определить его FD для достижения сети 10.1.1.0/24 составляет 16 000 (то есть 10 000 + 6000 = 16 000). Процесс EIGRP на маршрутизаторе OFF1 выполняет аналогичные вычисления для путей к сети 10.1.1.0/24 через маршрутизаторы OFF3 и OFF4. Ниже приведены расчеты, которые привели к значениям, приведенным в таблице.
Затем маршрутизатор OFF1 проверяет результаты этих вычислений и определяет, что кратчайшее расстояние до сети 10.1.1.0/24 проходит через маршрутизатор OFF2, поскольку путь через OFF2 имеет самый низкий FD (16 000). Этот путь, определяемый как кратчайший, считается следующим маршрутом. Затем маршрутизатор OFF1 пытается определить, соответствует ли любой из других маршрутов условию выполнимости EIGRP. В частности, маршрутизатор OFF1 проверяет, чтобы увидеть, что RD от маршрутизаторов OFF3 или OFF4 меньше, чем FD последующего маршрута. В случае OFF3 его RD в 11 000 действительно меньше, чем FD последующего маршрута (который составляет 16 000). Таким образом, путь к сети 10.1.1.0 /24 через OFF3 квалифицируется как возможный маршрут-преемник. Однако маршрут через OFF4 не подходит, потому что RD OFF4 из 18 000 больше, чем 16 000 (FD последующего маршрута). В результате путь к сети 10.1.1.0/24 через маршрутизатор OFF4 не считается возможным маршрутом-преемником.
Мы изучили K - значения, теперь почитайте про конвергенцию EIGRP и настройку таймеров
Фаервол на Микротике основан на базе принципов 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.
Сегодня хотим поговорить про модуль «Web Callback» для FreePBX 13. Модуль является платным и стоит $50. Платеж единоразовый. В сравнении с популярными сервисами обратного звонка, покупка модуля окупается в среднем за полгода. Интересно? Тогда читайте ниже: настройка и адаптация стиля под свой сайт.
Процесс настройки
Данный модуль находится в меню Applications. Он позволяет легко и просто добавить HTML “Позвоните Мне” код на ваш веб-сайт. Посетители просто вводят свой телефонный номер для соединения с нужной вам очередью или ринг-группой. Далее, этот модуль позволяет выставить префикс для поступающего номера, что позволит определить, что вызов идет именно с модуля обратного звонка. Так же можно указать правила набора номера, для определения номеров, на которые можно совершить вызов. Как только вы установите направление для вызова и подтвердите настройки модуля, вы получите HTML-код для добавления на вашу страницу.
Итак, пошаговый процесс создания кода для помещения на веб-страницу:
Нажмите на + Add Web Callback
Заполните поля:
Описание полей:
Name – Название коллбэка
CID Prepend – Префикс при определении номера, в данном случае – «CALLBACK»
Number Prepend – Префикс при наборе номера
Dial Matches – Маска, для определения номеров, которые можно набирать
Icon – Выбор иконки из предложенных
Valid Message – Сообщение, которое высвечивается при правильном наборе
Invalid Message – Сообщение, которое высвечивается при неправильном наборе
Error Message – Сообщение, которое высвечивается, если произошла какая-либо ошибка
Destination – Направление вызова, в данном случае – ринг-группа с названием “web callback”
HTML Code – Код, который появится после сохранения настроек
Нажмите Submit
Далее нужно только добавить получившийся код на сайт и пользоваться. Только надо учитывать два момента: первый – данный модуль надо купить у Shmooze и иметь публичный адрес вашей АТС/или пробрасывать порты.
Изменения стиля формы обратного звонка
После того как мы создали форму обратного звонка на сайт, нам необходимо доработать ее внешне, так как встроенные формы имеют не привлекательный дизайн. Открываем файл /etc/schmooze/wcb.html и добавляем в него следующий код:
<style type="text/css">
#frame {
background-image: url('/admin/images/webcallback.png');
background-repeat: no-repeat;
background-size: 200px;
height: 65px;
cursor: pointer;
cursor: hand;
}
#webcallbackinput {
position: relative;
left: 66px;
top: 30px;
width: 125px;
}
</style>
<div id="frame">
<input type="text" name="num" placeholder="Укажите ваш номер" id="webcallbackinput" value="">
<input type="hidden" id="dest" value="http://1.2.3.4:12345/wcb.php">
<input type="hidden" id="i" value="1">
</div>
<div id="link"></div>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script>
<script type="text/javascript">
$(document).ready(function(){
$('#frame').click(function(){
if ($('#webcallbackinput').val()) {
var valid_msg = 'Спасибо. Мы уже звоним Вам!';
var invalid_msg = 'Ошибка. Пожалуйста, укажите все параметры согласно требованию полей';
var but = $(this);
$.ajax({
url: $('#dest').val(),
type: 'post',
data: {p: $('#webcallbackinput').val(), i: $('#i').val()},
cache: false,
success: function(data, b, c) {
data = $.parseJSON(data);
switch (data.Response) {
case 'Error':
switch (data.Message) {
case 'Originate failed':
alert(invalid_msg);
break;
default:
alert(data.Message);
break;
}
break;
case 'Success':
alert(valid_msg);
break;
default:
break;
}
},
error: function(a, b, c) {
alert(invalid_msg);
}
})
}
})
});
</script>
Обратите внимание, чтобы форма работала корректно, вам необходимо указать корректное значение параметра value в поле input ниже (это значение было сгенерировано на этапе настройки в поле) и значение параметр id в поле, следующем следом за ним. В нашем примере, id=2:
<input type="hidden" id="dest" value="http://1.2.3.4:12345/wcb.php">
<input type="hidden" id="i" value="1">
В данном примере указано значение http://1.2.3.4:12345/wcb.php , где значение 1.2.3.4 – внешний IP – адрес нашего маршрутизатора, а 12345 – это проброс нестандартного порта в наш Asterisk. Рекомендуем в настройках проброшенного порта указать разрешенные сети (source address), с которых можно подключиться через этот порт. Это необходимо в целях безопасности, если ваш Web – сервер находится не в локальной сети, а например, на хостинге
Так же здесь вы можете настроить сообщения, которые будут показаны пользователю при успешном и неуспешном исходе вызова обратного звонка
var valid_msg = 'Спасибо. Мы уже звоним Вам!';
var invalid_msg = 'Ошибка. Пожалуйста, укажите все параметры согласно требованию полей ';