По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Router-on-a-stick (роутер на палочке) - это термин, часто используемый для описания схемы, состоящей из маршрутизатора и коммутатора, которые соединены с использованием одного канала Ethernet, настроенного как 802.1Q транк. Стандарт 802.1Q используется для тегирования трафика, для передачи информации о принадлежности к VLAN. В этой схеме на коммутаторе настроено несколько VLAN и маршрутизатор выполняет всю маршрутизацию между различными сетями или VLAN (Inter-VLAN routing).
/p>
Хотя некоторые считают, что термин «маршрутизатор на палочке» звучит немного глупо, это очень популярный термин, который широко используется в сетях, где нет коммутатора 3-го уровня.
Также такую схему иногда называют “леденец” – lollypop. Находите некоторое сходство?
Пример
Наш пример основан на сценарии, с которым вы, скорее всего, столкнетесь при работе с сетями VoIP. Поскольку реализации VoIP требуют разделения сети передачи данных и сети голоса для маршрутизации пакетов между ними, вам необходим либо коммутатор 3-го уровня, либо маршрутизатор. Эта конфигурация обеспечивает доступность и стабильность VoIP, особенно в часы пик трафика в вашей сети.
Пакеты, передающиеся между VLAN маршрутизируются через один роутер, подключенный к коммутатору, используя один физический порт, настроенный как транк на обоих концах (коммутатор и маршрутизатор).
Этот пример покажет вам, как настроить маршрутизатор и коммутатор Cisco для создания между ними 802.1Q транка и маршрутизации пакетов между вашими VLAN.
Шаг 1 – Настройка коммутатора
Первым шагом является создание необходимых двух VLAN на нашем коммутаторе Cisco и настройка их с IP-адресом. Поскольку все коммутаторы Cisco содержат VLAN1 (VLAN по умолчанию), нам нужно только создать VLAN2.
Switch# configure terminal
Switch(config)# vlan2
Switch(config-vlan)# name voice
Switch(config-vlan)# exit
Switch(config)# interface vlan1
Switch(config-if)# ip address 192.168.10.2 255.255.255.0
Switch(config-if)# exit
Switch(config)# interface vlan2
Switch(config-if)# ip address 192.168.20.2 255.255.255.0
Switch(config-if)# exit
Далее, нам нужно создать транк порт, который будет соединятся с маршрутизатором. Для этой цели мы выберем порт GigabitEthernet 0/1
Switch# configure terminal
Switch(config)# interface gigabitethernet 0/1
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# spanning-tree portfast trunk
При помощи данных команд мы определили, что транк будет использовать инкапсуляцию 802.1Q, установили порт в режим транка и включили функцию portfast trunk spanning-tree, чтобы гарантировать, что порт будет пересылать пакеты немедленно при подключении к устройству, например, маршрутизатору. Внимание: команда spanning-tree portfast trunk не должна использоваться на портах, которые подключаются к другому коммутатору, чтобы избежать петель в сети.
Шаг 2 – Настройка маршрутизатора
Мы закончили с коммутатором и можем переходить к настройке конфигурации нашего маршрутизатора, чтобы обеспечить связь с нашим коммутатором и позволить всему трафику VLAN проходить и маршрутизироваться по мере необходимости.
Создание транка на порте маршрутизатора не сильно отличается от процесса, описанного выше - хотя мы транк на одном физическом интерфейсе, мы должны создать под-интерфейс (sub-interface) для каждого VLAN.
Router# configure terminal
Router(config)# interface gigabitethernet0/1
Router(config-if)# no ip address
Router(config-if)# duplex auto
Router(config-if)# speed auto
Router(config-if)# interface gigabitethernet0/1.1
Router(config-subif)# encapsulation dot1q 1 native
Router(config-subif)# ip address 192.168.10.1 255.255.255.0
Router(config-subif)# interface gigabitethernet0/1.2
Router(config-subif)# encapsulation dot1q 2
Router(config-subif)# ip address 192.168.20.1 255.255.255.0
Чтобы сформировать транк с нашим коммутатором, необходимо создать один под-интерфейс для каждого VLAN, сконфигурированного на нашем коммутаторе. После создания под-интерфейса мы назначаем ему IP-адрес и устанавливаем тип инкапсуляции 802.1Q и указываем номер VLAN, к которому принадлежит под-интерфейс.
Например, команда encapsulation dot1q 2 определяет инкапсуляцию 802.1Q и устанавливает под-интерфейс на VLAN 2.
Параметр native который мы использовали для под-интерфейса gigabitethernet0/1.1, сообщает маршрутизатору, что нативный vlan - это VLAN 1. Это параметр по умолчанию на каждом коммутаторе Cisco и поэтому должен совпадать с маршрутизатором.
Для проверки можно использовать на роутере команду show vlans, где будут отображены созданные нами под-интерфейсы, а также при помощи команды show ip route в таблице маршрутизации мы должны увидеть наши под-интерфейсы.
Готово! Теперь при помощи роутера мы можем маршрутизировать файлы между разными VLAN.
Существует большое количество методов аутентификации клиентов беспроводных сетей при подключении. Эти методы появлялись по мере развития различных беспроводных технологий и беспроводного оборудования. Они развивались по мере выявления слабых мест в системе безопасности. В этой статье рассматриваются наиболее распространенные методы проверки подлинности.
Открытая аутентификация
Стандарт 802.11 предлагал только два варианта аутентификации клиента: open authentication и WEP.
Open authentication-предполагает открытый доступ к WLAN. Единственное требование состоит в том, чтобы клиент, прежде чем использовать 802.11, должен отправить запрос аутентификации для дальнейшего подключения к AP (точке доступа). Более никаких других учетных данных не требуется.
В каких случаях используется open authentication? На первый взгляд это не безопасно, но это не так. Любой клиент поддерживающий стандарт 802.11 без проблем может аутентифицироваться для доступа к сети. В этом, собственно, и заключается идея open authentication-проверить, что клиент является допустимым устройством стандарта 802.11, аутентифицируя беспроводное оборудование и протокол. Аутентификация личности пользователя проводится другими средствами безопасности.
Вы, вероятно, встречали WLAN с open authentication, когда посещали общественные места. В таких сетях в основном аутентификация осуществляется через веб-интерфейс. Клиент подключается к сети сразу же, но предварительно должен открыть веб-браузер, чтобы прочитать и принять условия использования и ввести основные учетные данные. С этого момента для клиента открывается доступ к сети. Большинство клиентских операционных систем выдают предупреждение о том, что ваши данные, передаваемые по сети, не будут защищены.
WEP
Как вы понимаете, open authentication не шифрует передаваемые данные от клиента к точке доступа. В стандарте 802.11 определен Wired Equivalent Privacy (WEP). Это попытка приблизить беспроводную связь к проводному соединению.
Для кодирования данных WEP использует алгоритм шифрования RC4. Данный алгоритм шифрует данные у отправителя и расшифровывает их у получателя. Алгоритм использует строку битов в качестве ключа, обычно называемого WEP- ключом. Один кадр данных-один уникальный ключ шифрования. Расшифровка данных осуществляется только при наличии ключа и у отправителя, и у получателя.
WEP- это метод безопасности с общим ключом. Один и тот же ключ должен быть как у отправителя, так и получателя. Этот ключ размещается на устройствах заранее.
WEP-ключ также может использоваться в качестве дополнительного метода аутентификации, а также инструмента шифрования. Если клиент отправляет неправильный ключ WEP, он не подключится к точке доступа. Точка доступа проверяет знание клиентом ключа WEP, посылая ему случайную фразу вызова. Клиент шифрует фразу вызова с помощью WEP и возвращает результат точке доступа (АР). АР сравнивает шифрование клиента со своим собственным, чтобы убедиться в идентичности двух ключей WEP.
Длина WEP - ключей могут быть длиной 40 или 104 бита, представленные в шестнадцатеричной форме из 10 или 26 цифр. Как правило, более длинные ключи предлагают более уникальные биты для алгоритма, что приводит к более надежному шифрованию. Это утверждение не относится к WEP. Так как WEP был определен в стандарте 802.11 в 1999 году, и соответственно сетевые беспроводные адаптеры производились с использованием шифрования, специфичного для WEP. В 2001 году были выявлены слабые места WEP, и началась работа по поиску более совершенных методов защиты беспроводной связи. К 2004 году поправка 802.11i была ратифицирована, и WEP официально устарел. Шифрование WEP и аутентификация с общим ключом WEP являются слабыми методами защиты WLAN.
802.1x/EAP
При наличии только open authentication и WEP, доступных в стандарте 802.11, требовался более безопасный метод аутентификации. Аутентификация клиента обычно включает в себя отправку запроса, получение ответа, а затем решение о предоставлении доступа. Помимо этого, возможен обмен ключами сессии или ключами шифрования в дополнение к другим параметрам, необходимым для клиентского доступа. Каждый метод аутентификации может иметь уникальные требования как уникальный способ передачи информации между клиентом и точкой доступа.
Вместо того чтобы встроить дополнительные методы аутентификации в стандарт 802.11, была выбрана более гибкая и масштабируемая структура аутентификации-разработан расширяемый протокол аутентификации (EAP). Как следует из его названия, EAP является расширяемым и не состоит из какого-либо одного метода аутентификации. Вместо этого EAP определяет набор общих функций, которые применяют фактические методы аутентификации, используемые для аутентификации пользователей.
EAP имеет еще одно интересное качество: он интегрируется со стандартом управления доступом на основе портов стандарта IEEE 802.1X. Когда порт стандарта 802.1X включен, он ограничивает доступ к сетевому носителю до тех пор, пока клиент не аутентифицируется. Это означает, что беспроводной клиент способен связываться с точкой доступа, но не сможет передавать данные в другую часть сети, пока он успешно не аутентифицируется.
Open authentication и WEP аутентификация беспроводных клиентов выполняется локально на точке доступа. В стандарте 802.1 x принцип аутентификации меняется. Клиент использует открытую аутентификацию для связи с точкой доступа, а затем фактический процесс аутентификации клиента происходит на выделенном сервере аутентификации. На рисунке 1 показана трехсторонняя схема стандарта 802.1x, состоящая из следующих объектов:
Клиент: клиентское устройство, запрашивающее доступ
Аутентификатор: сетевое устройство, обеспечивающее доступ к сети (обычно это контроллер беспроводной локальной сети [WLC])
Сервер аутентификации (AS): устройство, принимающее учетные данные пользователя или клиента и разрешающее или запрещающее доступ к сети на основе пользовательской базы данных и политик (обычно сервер RADIUS)
На рисунке клиент подключен к точке доступа через беспроводное соединение. AP представляет собой Аутентификатор. Первичное подключение происходит по стандарту open authentication 802.11. Точка доступа подключена к WLC, который, в свою очередь, подключен к серверу аутентификации (AS). Все в комплексе представляет собой аутентификацию на основе EAP.
Контроллер беспроводной локальной сети является посредником в процессе аутентификации клиента, контролируя доступ пользователей с помощью стандарта 802.1x, взаимодействуя с сервером аутентификации с помощью платформы EAP.
Далее рассмотрим некоторые вариации протокола защиты EAP
LEAP
Первые попытки устранить слабые места в протоколе WEP компания Cisco разработала собственный метод беспроводной аутентификации под названием Lightweight EAP (LEAP). Для проверки подлинности клиент должен предоставить учетные данные пользователя и пароля.
Сервер проверки подлинности и клиент обмениваются челендж сообщениями, которые затем шифруются и возвращаются. Это обеспечивает взаимную аутентификацию. Аутентификация между клиентом и AS осуществляется только при успешной расшифровке челендж сообщений.
На тот момент активно использовалось оборудование, работавшее с WEP- протоколом. Разработчики протокола LEAP пытались устранить слабые места WEP применением динамических, часто меняющихся ключей WEP. Тем не менее, метод, используемый для шифрования челендж сообщений, оказался уязвимым. Это послужило поводом признать протокол LEAP устаревшим. Существуют организации, которые все еще используют данный протокол. Не рекомендуется подключаться к таким сетям.
EAP-FAST
EAP-FAST (Flexible Authentication by Secure Tunneling) безопасный метод, разработанный компанией Cisco. Учетные данные для проверки подлинности защищаются путем передачи зашифрованных учетных данных доступа (PAC) между AS и клиентом. PAC- это форма общего секрета, который генерируется AS и используется для взаимной аутентификации. EAP-FAST- это метод состоящий из трех последовательных фаз:
Фаза 0: PAC создается или подготавливается и устанавливается на клиенте.
Фаза 1: после того, как клиент и AS аутентифицировали друг друга обсуждают туннель безопасности транспортного уровня (TLS).
Фаза 2: конечный пользователь может быть аутентифицирован через туннель TLS для дополнительной безопасности.
Обратите внимание, что в EAP-FAST происходят два отдельных процесса аутентификации-один между AS и клиентом, а другой с конечным пользователем. Они происходят вложенным образом, как внешняя аутентификация (вне туннеля TLS) и внутренняя аутентификация (внутри туннеля TLS).
Данный метод, основанный на EAP, требует наличие сервера RADIUS. Данный сервер RADIUS должен работать как сервер EAP-FAST, чтобы генерировать пакеты, по одному на пользователя.
PEAP
Аналогично EAP-FAST, защищенный метод EAP (PEAP) использует внутреннюю и внешнюю аутентификацию, однако AS предоставляет цифровой сертификат для аутентификации себя с клиентом во внешней аутентификации. Если претендент удовлетворен идентификацией AS, то они строят туннель TLS, который будет использоваться для внутренней аутентификации клиента и обмена ключами шифрования.
Цифровой сертификат AS состоит из данных в стандартном формате, идентифицирующих владельца и "подписанных" или подтвержденных третьей стороной. Третья сторона известна как центр сертификации (CA) и известна и доверяет как AS, так и заявителям. Претендент также должен обладать сертификатом CA только для того, чтобы он мог проверить тот, который он получает от AS. Сертификат также используется для передачи открытого ключа на видном месте, который может быть использован для расшифровки сообщений из AS.
Обратите внимание, что только AS имеет сертификат для PEAP. Это означает, что клиент может легко подтвердить подлинность AS. Клиент не имеет или не использует свой собственный сертификат, поэтому он должен быть аутентифицирован в туннеле TLS с помощью одного из следующих двух методов:
MSCHAPv2;
GTC (универсальная маркерная карта): аппаратное устройство, которое генерирует одноразовые пароли для пользователя или вручную сгенерированный пароль;
EAP-TLS
PEAP использует цифровой сертификат на AS в качестве надежного метода для аутентификации сервера RADIUS. Получить и установить сертификат на одном сервере несложно, но клиентам остается идентифицировать себя другими способами. Безопасность транспортного уровня EAP (EAP-TLS) усиливает защиту, требуя сертификаты на AS и на каждом клиентском устройстве.
С помощью EAP-TLS AS и клиент обмениваются сертификатами и могут аутентифицировать друг друга. После этого строится туннель TLS, чтобы можно было безопасно обмениваться материалами ключа шифрования.
EAP-TLS считается наиболее безопасным методом беспроводной аутентификации, однако при его реализации возникают сложности. Наряду с AS, каждый беспроводной клиент должен получить и установить сертификат. Установка сертификатов вручную на сотни или тысячи клиентов может оказаться непрактичной. Вместо этого вам нужно будет внедрить инфраструктуру открытых ключей (PKI), которая могла бы безопасно и эффективно предоставлять сертификаты и отзывать их, когда клиент или пользователь больше не будет иметь доступа к сети. Это обычно включает в себя создание собственного центра сертификации или построение доверительных отношений со сторонним центром сертификации, который может предоставлять сертификаты вашим клиентам.
Одной из основных составляющих IP – PBX на базе Asterisk являются SIP – транки в сторону провайдера и оконечные телефонные аппараты, или как их принято называть «пиры» (peers). Сегодня мы расскажем о способе автоматизации мониторинга состояния транков и пиров, с отправлением на почту системного администратора.
Мониторинг пиров
Итак, начнем с мониторинга состояния пиров. Для этого мы напишем небольшой bash – скрипт. Предположим, что у нас есть 3 площадки, А, B и C. АТС Asterisk находится на площадке A. Предварительно, перед началом работы, создадим 2 файлы: первый – для логов нашего скрипта, а второй, будет служебным, и будет использоваться только в рамках исполнения скрипта. Внутри каждого скрипта, мы будем писать комментарии к каждой из его строк.
Скачать скрипт мониторинга пиров вы можете по ссылке ниже:
Скачать скрипт мониторинга пиров
[root@asteriskpbx]# touch /home/admin/log_mail.txt
[root@asteriskpbx]# touch /home/admin/message.txt
Далее, создаем переменные для нашего скрипта:
#!/bin/sh
LOGSIZE=`ls -l /home/admin/log_mail.txt | awk '{ print $5 }'` //проверяем размер файла с логами
problempeers=`/usr/sbin/asterisk -rx 'sip show peers' | grep UNKNOWN` //выводим командой 'sip show peers' через консоль Asterisk, и затем, с помощью команды grep UNKNOWN фильтруем пиры, чтобы отобразить только те, состояние которых является UNKNOWN
GWB=`ping -c4 11.22.33.44 | grep 'received' | awk -F',' '{ print $2}' | awk '{ print $1}'` //по протоколу ICMP, пингуем IP – адрес шлюза на удаленной площадке четырьмя пакетами. Если все ОК, и шлюз доступен, до значение переменной будет равно 4. В противном случае, оно будет равно 0.
GWC=`ping -c4 44.33.22.11 | grep 'received' | awk -F',' '{ print $2}' | awk '{ print $1}'` //аналогичным образом пингуем шлюз на площадке C
ResultB="" //служебная переменная
ResultC="" //служебная переменная
FILENAME=/home/admin/message.txt //записываем в переменную путь к лог- файлам
LOGFILE=/home/admin/log_mail.txt
DATE="`date +%d.%m.%Y" "%H:%M:%S`" //выводим текущую дату и время в формате дд.мм.гггг чч:мм:сс
echo "$problempeers" > /home/admin/message.txt //записываем содержимое переменной problempeers в служебный файл. В этой переменной содержится результат вывода команды по статусу пиров.
FILESIZE=$(stat -c%s "$FILENAME") //проверяем размер служебного файла message.txt. Если в нем есть какая-либо информация, значит есть проблемы с пирами (имеются в статусе UNKNOWN), если он пустой, то все ОК.
На этом этапе, мы сформировали все необходимые переменные и у нас имеются все необходимые для формирования письма (если надо) на email системному администратору. Перейдем к исполнительной части скрипта:
if [ $GWB -eq 0 ]; then //если число ответов шлюза на площадке B на пинг равно 0, то запускаем процесс формирования письма
ResultB ="на площадке B НЕ ДОСТУПЕН!" //формируем часть текста. Мы ее включим в заголовок письма
else
ResultB ="" //если все таки шлюз ответил на пинг, то оставляем переменную пустой
fi
if [ $GWС -eq 0 ]; then //если число ответов шлюза на площадке С на пинг равно 0, то запускаем процесс формирования письма
ResultС="на площадке С НЕ ДОСТУПЕН!" //по аналогии. Указываем в заголовок, что роутер C недоступен
else
ResultС ="" //если все ОК, то оставляем переменную пустой
fi
if [ $FILESIZE -ne 1 ]; then //если наш служебный файл message.txt не пустой, то проверяем следующее условие
if [ $GWB -eq 0 ] || [ $GWC -eq 0 ]; then //если хотябы один из роутеров недоступен по пинг, то переходим к следующему пункту скрипта
echo "$problempeers"| mailx -s "Проблемы с SIP пирами | Роутер $ResultB $ResultC!" -r "info@merionet.ru" youremail@some.ru </home/admin/message.txt && //отправляем на почту письмо, где указываем, что у нас есть проблемы с пирами, и, если какой-то из роутеров не доступен, указываем это. В теле письма мы отправляем вывод недоступных пиров.
echo "FAIL :: $DATE :: Some problems with phones" >> "$LOGFILE" //параллельно с отправкой письма, записываем в лог файл запись, что у нас есть проблемы с пирами (в вывод так же можно добавить с какими именно)
else
echo "$problempeers"| mailx -s "Проблемы с SIP пирами | Роутеры ДОСТУПНЫ!" -r "info@merionet.ru" youremail@some.ru < /home/admin/message.txt && //если оба наших роутера доступны, то мы просто формируем письмо, в котором указываем перечень недоступных пиров.
echo "FAIL :: $DATE :: Some problems with phones" >> "$LOGFILE" //аналогично вносим запись в лог – файл.
fi
else
echo "OK :: $DATE :: all phones are OK" >> "$LOGFILE" //если служебный файл пустой, то мы вносим запись в лог – файл что все хорошо и проверка успешно прошла.
fi
if [ $LOGSIZE -ge 150000 ]; then //елси размер нашего лог – файла больше или равен 150 КБ, то мы очищаем этого (можете подкрутить эту величину, как вам угодно.)
cat /dev/null > /home/admin/log_mail.txt
fi
cat /dev/null > /home/admin/message.txt //на выходе чисти служебный файл message.txt, для последующего использования
Теперь давайте проверим, что приходит нам на почту в случае, если несколько пиров стали недоступны, но все роутеры доступны:
Мониторинг транков
Отлично, перейдем к формированию скрипта по мониторингу транков. Здесь все несколько проще, и мы просто будем сравнивать общее количество транков, и количество зарегистрированных транков:
Скачать сам скрипт можете ниже:
Скачать скрипт мониторинга транков
#!/bin/bash
ALLTRUNKSMINIMUM="`/usr/sbin/asterisk -rx "sip show registry"`" //выводим регистрации по протоколу SIP
ALLTRUNKS=`echo "$ALLTRUNKSMINIMUM" |grep "SIP registrations" |awk '{print $1}'` //численное обозначение всех имеющихся транков
REGTRUNKS=`/usr/sbin/asterisk -rx "sip show registry" |grep Registered |wc -l` //численное обозначение всех зарегистрированных транков
DATE="`date +%d.%m.%Y" "%H:%M:%S`" //формируем текущую дату, для логов
LOGFILE=/home/admin/log_mail.txt //для лог – файла, указываем тот же файл, что и для скрипта по мониторингу пиров
if [ "$REGTRUNKS" -lt "$ALLTRUNKS" ]; then //если число зарегистрированных транков меньше чем число всех транков
sleep 5 //ждем 5 секунд
echo `/usr/sbin/asterisk -rx "sip reload"` \ перезагружаем модуль SIP, в целях перерегистрации. Эта команда автоматически перерегистрирует транк на оборудовании провайдера, после чего, он, зачастую, начинает работать.
sleep 5 //ждем еще 5 секунд
VAR=`/usr/sbin/asterisk -rx "sip show registry"` //после перезагрузки SIP модуля, снова смотрим SIP –регистрации. Если данная команда не дала своих результатов, то в переменной VAR будет записаны не работающие транки. Если она помогла, то на email админу придет рабочий вывод всех зарегистрированных транков. Это весьма удобно.
echo "$VAR"| mailx -s "Мониторинг транков" -r "info@merionet.ru" youremail@some.ru // отправляем письмо на почту системного администратора, с выводом SIP регистраций после перезагрузки модуля
else
echo "OK :: $DATE :: all trunks are OK" >> "$LOGFILE" //если число зарегистрированных транков, равно общему числу, то записываем в лога файл соответствующую запись.
fi
Теперь, когда мы автоматизировали процессы мониторинга состояния на Asterisk, сделаем выполнение этих скриптов регулярным. Сохраним наши скрипты в формате .sh, можно сделать это, например, в Notepad ++. Сделаем выполнение мониторинг транков раз в 2 минуты, а выполнение мониторинга пиров раз в 10 минут. Перед загрузкой скриптов на сервер, дадим им необходимые права и, что очень важно, преобразуем скрипт в Linux формат:
[root@asteriskpbx]# dos2unix peer.sh //преобразуем скрипт для мониторинга пиров
[root@asteriskpbx]# dos2unix trunk.sh //преобразуем скрипт для мониторинга транков
[root@asteriskpbx]# chmod 777 peer.sh //дадим необходимые права обоим скриптам
[root@asteriskpbx]# chmod 777 trunk.sh
[root@asteriskpbx]# crontab -e
В открывшемся cron, задаем задачи для выполнения наших скриптов:
*/10 * * * * /bin/bash /home/peer.sh >/dev/null //исполнять файл раз в 10 минут
*/2 * * * * /bin/bash /home/trunk.sh >/dev/null //исполнять файл раз в 2 минуты
Вот и все. Теперь мы имеет достаточно простой, но порой очень нужный и эффективный мониторинг состояния транков и пиров на нашем Asterisk