По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Почитайте предыдущую статью из цикла про Основы IPv4 Access Control Lists.
Когда вы думаете о месте и направлении ACL, вы, должно быть, уже думаете о том, какие пакеты вы планируете фильтровать (отбрасывать), а какие хотите пропустить. Чтобы сообщить маршрутизатору те же идеи, вы должны настроить маршрутизатор с IP ACL, который соответствует пакетам. Соответствующие пакеты относятся к тому, как настроить команды ACL для просмотра каждого пакета, перечисляя, как определить, какие пакеты следует отбросить, а какие разрешить.
Каждый IP ACL состоит из одной или нескольких команд конфигурации, каждая из которых содержит подробную информацию о значениях, которые нужно искать в заголовках пакетов. Как правило, команда ACL использует такую логику, как "найдите эти значения в заголовке пакета и, если они найдены, отвергните пакет" (вместо этого может быть разрешение пакета, а не его отбрасывание.) В частности, ACL ищет поля заголовка, которые вы уже должны хорошо знать, включая IP-адреса источника и назначения, а также номера портов TCP и UDP.
Давайте сначала рассмотрим пример с рисунка 2, в котором нам необходимо разрешить прохождение пакетов с хоста A на сервер S1, но отбросить пакеты от хоста B, идущие на тот же сервер. Все хосты теперь имеют IP-адреса, а на рисунке показан псевдокод ACL на R2. На рисунке 2 также показано расположение, выбранное для включения ACL: входящий на интерфейсе S0/0/1 R2.
На рисунке 2 показан ACL, состоящий из двух строк в прямоугольнике внизу с простой логикой сопоставления: оба оператора просто ищут совпадение с исходным IP-адресом в пакете. Когда этот параметр включен, R2 просматривает каждый входящий IP-пакет на этом интерфейсе и сравнивает каждый пакет с этими двумя командами ACL. Пакеты, отправленные хостом A (исходный IP-адрес 10.1.1.1), разрешены, а пакеты, отправленные хостом B (исходный IP-адрес 10.1.1.2), отбрасываются.
Принятие мер при возникновении совпадения. При использовании ACL IP для фильтрации пакетов можно выбрать только одно из двух действий. Команды настроек используют ключевые слова deny и allow, и они означают (соответственно) отбросить пакет или разрешить ему продолжать работу, как если бы ACL не существовал.
Здесь основное внимание уделяется использованию ACL для фильтрации пакетов, но IOS использует ACL для многих других функций. Эти функции обычно используют одну и ту же логику сопоставления. Однако в других случаях ключевые слова deny или allow подразумевают другое действие.
Типы ACL IP
Cisco IOS поддерживает ACL IP с первых дней существования маршрутизаторов Cisco. Начиная с исходных стандартных пронумерованных списков контроля доступа IP на заре IOS, которые могли задействовать логику, показанную ранее на рисунке 2, Cisco добавила множество функций ACL, включая следующие:
Стандартные нумерованные списки ACL (1–99)
Расширенные нумерованные ACL (100–199)
Дополнительные номера ACL (1300–1999 стандартные, 2000–2699 расширенные)
Именованные ACL
Улучшенное редактирование с порядковыми номерами
Здесь мы рассматриваем исключительно стандартные пронумерованные списки контроля доступа IP, а в следующей лекции рассмотрим другие три основные категории списков контроля доступа IP. Вкратце, списки управления доступом IP будут либо пронумерованы, либо именованы, так как конфигурация идентифицирует ACL с использованием номера или имени. ACL также будут стандартными или расширенными, при этом расширенные ACL будут иметь гораздо более надежные возможности для сопоставления пакетов. Рисунок 3 суммирует основные идеи, связанные с категориями списков контроля доступа IP.
Стандартные нумерованные списки ACL IPv4
Этот подраздел лекции посвящен типу фильтра Cisco (ACL), который соответствует только исходному IP-адресу пакета (стандарт), настроен для идентификации ACL с использованием чисел, а не имен (пронумерованных), и смотрит на пакеты IPv4.В этой части исследуются особенности стандартных пронумерованных списков контроля доступа IP. Во-первых, он исследует идею о том, что один ACL является списком, и какую логику использует этот список. После этого в тексте подробно рассматривается, как сопоставить поле IP-адреса источника в заголовке пакета, включая синтаксис команд. В конце этой лекции дается полный обзор команд конфигурации и проверки для реализации стандартных ACL.
Логика списка с IP ACL
Один ACL - это одновременно и единый объект, и список одной или нескольких команд конфигурации. Как единый объект, конфигурация включает весь ACL на интерфейсе в определенном направлении, как показано ранее на рисунке 1. В виде списка команд каждая команда имеет различную логику согласования, которую маршрутизатор должен применять к каждому пакету при фильтрации с использованием этого ACL.При обработке ACL маршрутизатор обрабатывает пакет по сравнению с ACL следующим образом: ACL используют логику первого совпадения. Как только пакет соответствует одной строке в ACL, роутер выполняет действие, указанное в этой строке ACL, и прекращает поиск в ACL.Чтобы понять, что это означает, рассмотрим пример, построенный на рисунке 4. На рисунке показан пример ACL 1 с тремя строками псевдокода. В этом примере ACL 1 применяется к входящему интерфейсу S0/0/1 R2 (то же расположение, что и на предыдущем рисунке 2).
Рассмотрим логику ACL первого совпадения для пакета, отправленного хостом A на сервер S1. Исходным IP-адресом будет 10.1.1.1, и он будет маршрутизирован так, чтобы входить в интерфейс S0/0/1 R2, управляя логикой ACL 1 R2. R2 сравнивает этот пакет с ACL, сопоставляя первый элемент в списке с действием разрешения. Таким образом, этот пакет должен быть пропущен, как показано на рисунке 5 слева.
Затем рассмотрим пакет, отправленный хостом B, исходный IP-адрес 10.1.1.2. Когда пакет поступает в интерфейс S0/0/1 R2, R2 сравнивает пакет с первым оператором ACL 1 и не находит соответствия (10.1.1.1 не равно 10.1.1.2). Затем R2 переходит ко второму утверждению, которое требует некоторого пояснения. Псевдокод ACL, показанный на рисунке 4, показывает 10.1.1.x, что означает сокращение того, что в последнем октете может существовать любое значение. Сравнивая только первые три октета, R2 решает, что этот последний пакет действительно имеет IP-адрес источника, который начинается с первых трех октетов 10.1.1, поэтому R2 считает, что это соответствует второму оператору. R2 выполняет указанное действие (запретить), отбрасывая пакет. R2 также останавливает обработку ACL для пакета, игнорируя третью строку в ACL.
Наконец, рассмотрим пакет, отправленный хостом C, снова на сервер S1. Пакет имеет IP-адрес источника 10.3.3.3, поэтому, когда он входит в интерфейс R2 S0/0/1 и управляет обработкой ACL на R2, R2 просматривает первую команду в ACL 1. R2 не соответствует первой команде ACL (10.1.1.1). в команде не совпадает с пакетом 10.3.3.3). R2 просматривает вторую команду, сравнивает первые три октета (10.1.1) с IP-адресом источника пакета (10.3.3) и по-прежнему не находит совпадения. Затем R2 смотрит на третью команду. В этом случае подстановочный знак означает игнорирование последних трех октетов и просто сравнение первого октета (10), чтобы пакет соответствовал. Затем R2 выполняет указанное действие (разрешение), позволяя пакету продолжить работу.
Эта последовательность обработки ACL в виде списка происходит для любого типа IOS ACL: IP, других протоколов, стандартных или расширенных, именованных или пронумерованных. Наконец, если пакет не соответствует ни одному из элементов в ACL, пакет отбрасывается. Причина в том, что каждый IP ACL имеет оператор deny all, подразумеваемый в конце ACL. Его нет в конфигурации, но если маршрутизатор продолжает поиск в списке, и до конца списка не найдено совпадение, IOS считает, что пакет соответствует записи, имеющей действие запрета.
Соответствие логики и синтаксиса команд
Стандартные нумерованные ACL для IP-адресов используют следующую команду:
access-list {1-99 | 1300-1999} {permit | deny} matching-parameters
Каждый стандартный нумерованный ACL имеет одну или несколько команд списка доступа с одинаковым номером, любым числом из диапазонов, показанных в предыдущей строке синтаксиса. IOS относится к каждой строке в ACL как к записи управления доступом (ACE), но многие сетевые администраторы просто называют их операторами ACL.Помимо номера ACL, каждая команда списка доступа также перечисляет действие (разрешить или запрещать), а также логику сопоставления. Остальная часть этой части изучает, как настроить параметры сопоставления, что для стандартных списков ACL означает, что вы можете сопоставить исходный IP-адрес или части исходного IP-адреса только с помощью так называемой обратной маски ACL.
Соответствие точному IP-адресу
Чтобы сопоставить конкретный исходный IP-адрес, весь IP-адрес, все, что вам нужно сделать, это ввести этот IP-адрес в конце команды. Например, в предыдущем примере псевдокод используется для "разрешить, если источник = 10.1.1.1". Следующая команда настраивает эту логику с правильным синтаксисом с использованием ACL номер 1:
access-list 1 permit 10.1.1.1
Сопоставить точный полный IP-адрес очень просто.В более ранних версиях IOS синтаксис включал ключевое слово host. Вместо того, чтобы просто вводить полный IP-адрес, вы сначала набираете ключевое слово host, а затем IP-адрес. Обратите внимание, что в более поздних версиях IOS, если вы используете ключевое слово host, IOS принимает команду, но затем удаляет ключевое слово.
Сопоставление адреса подсети с обратной маской
Часто бизнес-цели, которые вы хотите реализовать с помощью ACL, совпадают не с одним конкретным IP-адресом, а с целым рядом IP-адресов. Возможно, вы хотите сопоставить все IP-адреса в подсети. Возможно, вы хотите сопоставить все IP-адреса в диапазоне подсетей. Несмотря на это, вы хотите проверить наличие нескольких IP-адресов в диапазоне адресов.
IOS позволяет стандартным ACL сопоставлять диапазон адресов с помощью инструмента, называемого обратной маской. Обратите внимание, что это не маска подсети. Обратная маска (сокращенно называют маской WC) дает сетевому администратору способ сказать IOS игнорировать части адреса при проведении сравнений, по существу рассматривая эти части как подстановочные знаки, как если бы они уже совпадали.Вы можете использовать маски WC в десятичном и двоичном виде, и оба имеют свое применение. Для начала можно использовать маски WC в десятичной системе счисления, используя следующие правила:
Десятичное число 0: маршрутизатор должен сравнить этот октет как обычно.
Десятичное число 255: маршрутизатор игнорирует этот октет, считая его уже совпадающим.
Имея в виду эти два правила, рассмотрим рисунок 6, который демонстрирует эту логику с использованием трех различных, но популярных масок WC: одна, которая говорит маршрутизатору игнорировать последний октет, другая, которая говорит маршрутизатору игнорировать последние два октета, и третья, которая говорит маршрутизатору игнорировать последние три октета.
Все три примера во вставках на рисунке 6 показывают два числа, которые явно различаются. Маска WC заставляет IOS сравнивать только некоторые октеты, игнорируя другие октеты. Все три примера приводят к совпадению, поскольку каждая подстановочная маска указывает IOS игнорировать некоторые октеты. В примере слева показана маска WC 0.0.0.255, которая указывает маршрутизатору обрабатывать последний октет как подстановочный знак, по существу игнорируя этот октет для сравнения. Точно так же в среднем примере показана маска WC 0.0.255.255, которая сообщает маршрутизатору игнорировать два октета справа. В крайнем правом случае показана маска WC 0.255.255.255, указывающая маршрутизатору игнорировать последние три октета при сравнении значений.
Чтобы увидеть маску WC в действии, вспомните предыдущий пример, относящийся к рисункам 4 и 5. В ACL псевдокода на этих двух рисунках используется логика, которую можно создать с помощью маски WC. Напомним, что логика ACL псевдокода на этих двух рисунках включает следующее:
Строка 1: Сопоставить и разрешить все пакеты с адресом источника соответствующий строго 10.1.1.1.
Строка 2: Сопоставить и отклонить все пакеты с адресами источника с первыми тремя октетами 10.1.1.
Строка 3: сопоставить и разрешить все адреса с первым одиночным октетом 10.
На рисунке 7 показана обновленная версия рисунка 4, но с завершенным правильным синтаксисом, включая маски WC. В частности, обратите внимание на использование маски WC 0.0.0.255 во второй команде, указывающей R2 игнорировать последний октет числа 10.1.1.0, и маску WC 0.255.255.255 в третьей команде, указывающую R2 игнорировать последние три октеты в значении 10.0.0.0.
Наконец, обратите внимание, что при использовании маски WC свободно определенный параметр источника команды access-list должен иметь значение 0 в любых октетах, где маска WC - 255. IOS будет указывать адрес источника равным 0 для частей, которые будут игнорироваться, даже если были настроены ненулевые значения.
Теперь почитайте про wildcard в ACL: бинарные обратные маски
Прогресс не стоит на месте и постепенно, телефонные станции на базе IP вытесняют устаревшие аналоговые АТС. При миграции с аналоговой на IP – АТС, основной головной болью для бизнеса является сохранение телефонной емкости, которая была подключена к аналоговой АТС и к которой так привыкли постоянные клиенты. В данном случае на помощь приходит FXO шлюз.
Забегая вперед хочется отметить, что процесс подключения аналоговых линий всегда сложен: возникает множество проблем с корректной передачей CallerID, определением Busy Tones (сигналов занято), шумами или помехами на линии и прочими неприятностями.
Итак, если вас не отпугивает вышеперечисленные трудности, то мы с радостью спешим рассказать как настроить бюджетный VoIP шлюз D-Link DVG-7111S и подключить его к IP-АТС Asterisk. Данная статья будет полезна тем, кто имеет аналоговые телефонные линии и хочет скрестить их сетью VoIP.
Что такое FXO и FXS?
Зачастую, некоторые компании, по тем или иным причинам, не могут отказаться от использования старых аналоговых линий. Причин может быть множество, например, провайдер может отказаться переводить на протокол SIP номер, который многие годы знают все заказчики или невозможность миграции со старой мини-АТС. Именно для таких случаев необходим VoIP-шлюз, который позволит состыковать устройства разных поколений.
Разберемся с терминологией. Для соединения IP-АТС с аналоговыми линиями служат интерфейсы FXO (Foreign eXchange Office) и FXS (Foreign Exchange Station). Интерфейс FXS – это порт, с помощью которого аналоговый абонент подключается к аналоговой телефонной станции. Простейшим примером может служить телефонная розетка в стене у Вас дома. FXO – это интерфейс, в который включаются аналоговые линии. Следовательно, любая аналоговая линия имеет два конца, на одном из который интерфейс FXS (АТС), а на другом FXO (Телефон).
Другими словами, чтобы было совсем понятно:
FXS - если вам требуется подключить аналоговый телефон к IP – АТС, то воспользуйтесь FXS портом (шлюзом)
FXO - если вам требуется подключить аналоговую линию от провайдера к IP – АТС, то воспользуйтесь FXO портом (шлюзом)
Таким образом, для того чтобы скрестить сеть VoIP с аналоговой нам нужно иметь такое адаптирующее устройство, которое бы преобразовывало сигналы аналоговой телефонной линии в сигналы VoIP.
Настройка
В нашем примере мы имеем в распоряжении: аналоговую линию от провайдера услуг, IP-АТС Asterisk и шлюз D-Link DVG-7111S.
Первое, что необходимо сделать – включить шлюз в одну сеть с IP-АТС Asterisk с помощью интерфейса WAN, порт LAN подключить в локальный свич, а также подключить имеющуюся аналоговую линию в порт FXO на шлюзе. Теперь шлюз можно найти по адресу 192.168.8.254, только предварительно нужно на управляющей АРМ настроить адрес 192.168.8.1. Перед нами открывается вэб-интерфейс, через который можно управлять шлюзом. Стандартный логин admin без пароля.
Теперь необходимо сконфигурировать дополнительные сетевые настройки. Для этого переходим в раздел Setup -> Internet Setup и настраиваем новый адрес шлюза из той же сети, в которой находится Asterisk, а также адреса серверов DNS. Жмём Apply
Далее переходим на вкладку VoIP Setup и настраиваем следующие параметры:
PHONE 1 - FXS Настраивается если у вас есть отдельный аналоговый телефон. Сюда заносим его Extension, который зарегистрирован на Asterisk.
В разделе PHONE 2 - FXO настраиваются параметры имеющейся аналоговой линии в соответствии с настройками транка на Asterisk. Номер и пароль на шлюзе и на Asterisk должна совпадать.
В разделе SIP PROXY SERVER настраиваются параметры подключения к IP-Атс Asterisk. Указываем IP-адрес нашего сервера, порт (по умолчанию 5060) и время регистрации TTL. Нажимаем Apply.
Во вкладке LAN Setup выбираем режим Bridge, всё остальное оставляем без изменений.
Переходим в раздел ADVANCED -> VOIP CODECS и настраиваем нужный приоритет голосовых кодеков.
В разделе CPT/ Cadence рекомендуем выключить опцию BTC, поскольку разные провайдеры могут по-разному отдавать сигнал “Занято” это может являться причиной внезапных обрывов.
В разделе HOT LINE включаем данную функцию и вписываем номер телефонной линии. Теперь, при звонке из ТФоП, шлюз сам наберет данный номер с минимальной задержкой и вызов пойдёт через Asterisk.
На этом настройка шлюза завершена, рекомендуем провести следующий набор действий
MAINTENANCE -> Backup and Restore -> System--Save and Reboot -> Save all settings -> Reboot
Настройка FreePBX
Теперь необходимо на IP-АТС Asterisk создать соответствующий транк. В нашем случае, транк для подключения аналоговой линии от D-Link будет выглядеть так:
В разделе sip Settings -> Outgoing указываем адрес, который настраивали на шлюзе
host=192.168.1.2 //ip - адрес шлюза
port=5060
context=from-trunk
qualify=yes
type=peer
insecure=no
В разделе sip Settings -> Incoming настраиваем такие же параметры аналоговой линии, которые настраивали на шлюзе. Номер и пароль должны совпадать.
host=dynamic
username=495123456
secret=тут_ваш_пароль
context=from-trunk
qualify=yes
type=friend
insecure=no
Готово! Осталось только настроить входящую и исходящую маршрутизацию. О ее настройке можете почитать по ссылке ниже:
Настройка маршрутизации вызовов
Беспроводные решения вендора MikroTik для сегмента SOHO (Small Office, Home Office) - являются крайне универсальными, и, кроме того, они крайне гибки в плане настроек беспроводных интерфейсов в “простом” режиме.
SOHO продукты - продукты для маленького и/или домашнего офиса
Однако, присутствует также “продвинутый” режим, в котором можно произвести более качественную настройку многих фич. Во многих SOHO моделях, к примеру - RB-750 и RB-951 уже установлены приемлемые заводские настройки, но если произвести несколько изменений - качество подключения может сильно возрасти и, более того, позволить одновременное подключение большего количества пользователей.
Это может сыграть роль, если вы используете SOHO оборудование в небольшом филиале, в котором более десяти пользователей. Особенно учитывая тот факт, что все они используют смартфоны, планшеты и ноутбуки - нагрузка на сеть растет, и, если беспроводная инфраструктура настроена некорректно, все признаки плохого подключения будут видны невооруженным взглядом.
Что делать?
Следующие параметры могут сильно улучшить качество подключения:
frequency-mode=regulatory-domain country=russia
frequency=auto
channel-width=20mhz
wireless-protocol=802.11
distance=indoors
Для того чтобы применить эти настройки, просто скопируйте и вставьте команду ниже:
Данная команда предназначена для маршрутизаторов RB751/951
/interface wireless set wlan1 mode=ap-bridge wireless-protocol=802.11 frequency=auto band=2ghz-b/g/n channel-width=20mhz distance=indoors frequency-mode=regulatory-domain country="russia"
Очевидно, что первый параметр отвечает за регион - в нашем случае, это Россия. Кроме того, в настоящий момент некоторые из этих опций являются стандартными в последней версии RouterOS, однако, почему-то не всегда они установлены корректно.
Также, детальную информацию о данных настройках не всегда можно найти в документации MikroTik, но, по опыту, эти настройки действительно улучшают производительность беспроводной сети. Проверить производительность вашей сети можно проверить на вкладке “Status” информации о беспроводном интерфейсе, вам нужно поле Overall Tx CCQ (Client Connection Quality).
Ниже пример на одном из RB-951 - обратите внимание на очень высокий показатель 97%:
Однако, при установке более новых моделей RB-951 со стоковыми настройками, чаще всего был замечен показатель в районе CCQ < 60%, и это явный знак того, что есть куда двигаться в плане качества подключения.
Заключение
Мы рекомендуем мониторить CCQ в течение нескольких часов на загруженной беспроводной сети, чтобы определить средний уровень, и, затем, применить рекомендованные настройки по очереди, чтобы понять, как они влияют на показатель. Не все из этих настроек универсальны для всех инсталляций, но если вы заметите улучшение CCQ на 10-20% - пользователи обязательно это оценят.