По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Docker и Kubernetes - два ведущих инструмента, используемых в индустрии облачных вычислений. В то время как Docker - это компьютерное приложение, использующее концепцию контейнеризации, а Kubernetes - это система оркестровки контейнеров.
Как правило, Docker и Kubernetes используются совместно друг с другом. Тем не менее, сравнение Kubernetes и Docker является чрезвычайно популярной темой в сообществе облачных вычислений.
Прежде чем сравнивать две наиболее важные технологии облачных вычислений, давайте сначала кратко расскажем о каждой из них.
Kubernetes
Впервые выпущенный в июне 2014 года, Kubernetes был изначально разработан Google. За дальнейшую разработку и обслуживание системы оркестровки контейнеров с открытым исходным кодом отвечает Cloud Native Computing Foundation.
Согласно официальному сайту, Kubernetes является «системой с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнеризованными приложениями».
Используя технологию контейнеризации, Kubernetes позволяет запускать контейнеры на нескольких вычислительных узлах, которые могут быть простыми серверами или виртуальными машинами. Перед использованием Kubernetes нужно перепроверить несколько вещей. Одним из них является обеспечение того, чтобы все участвующие вычислительные узлы были надежно связаны друг с другом.
Docker
Разработанная Docker, Inc., Docker была впервые выпущена в марте 2013 года. Это компьютерная программа, способная выполнять виртуализацию на уровне операционной системы, широко известную как контейнерная упаковка.
Docker можно рассматривать в двух разных сторон. С первого взгляда контейнеры Docker - это действительно легкие виртуальные машины, а со второй точки зрения Docker - это платформа для упаковки и доставки программного обеспечения.
Последний аспект в первую очередь ответственен за огромную популярность технологии контейнеризации Docker и ее широкое распространение в индустрии облачных вычислений.
Можно ли сравнивать Docker и Kubernetes?
Сравнивать Docker с Kubernetes - все равно что сравнивать Солнце с Луной. Конечно, оба небесных тела, но сравнение между ними не звучит правильно! Это потому, что, хотя оба сияют, один - звезда, а другой - естественный спутник.
Хотя Docker может работать без Kubernetes, а Kubernetes может функционировать в полной мере без Docker, использование обоих в совместной работе улучшает функциональность друг друга. Docker может быть установлен на компьютере для запуска контейнерных приложений. Подход контейнеризации означает запуск приложений в операционной системе таким образом, чтобы они были изолированы от остальной части системы. Приложение будет чувствовать, что оно имеет свою собственную выделенную ОС.
Несколько приложений могут работать в одной ОС, как если бы у каждого из них был свой экземпляр операционной системы. Каждое приложение находится внутри контейнера. Docker позволяет создавать, управлять и запускать контейнеры в одной операционной системе.
Теперь, когда у вас установлен Docker на нескольких хостах, то есть на операционных системах, вы можете воспользоваться Kubernetes. В таком случае мы называем эти хосты узлами или узлами Docker, которые могут быть серверами с открытым исходным кодом или виртуальными машинами. Прелесть использования Kubernetes с Docker заключается в том, что он помогает автоматизировать балансировку нагрузки контейнера, создание сетей, выделение ресурсов, масштабирование и безопасность на всех хостах Docker с помощью отдельной панели мониторинга или интерфейса командной строки.
Повышение масштабируемости приложений и повышение надежности инфраструктуры - две лучшие причины выбора нескольких узлов. Коллекция узлов, управляемых отдельным экземпляром Kubernetes, называется кластером Kubernetes.
Kubernetes vs Docker
Docker Swarm, про настройку которого можно прочитать тут - это платформа оркестрации контейнеров с открытым исходным кодом. Это собственный механизм кластеризации для Docker, и поэтому он использует ту же командную строку, что и Docker. Ниже приведены различные важные различия между Swarm и Kubernetes.
Развертывание приложений
Приложение развертывается в Kubernetes с использованием комбинации модулей и служб (или микросервисов). В Docker Swarm развертывание приложения происходит просто в виде микросервисов или сервисов в кластере Swarm.
Docker Swarm поставляется с Docker Compose, который помогает в установке приложения. Для идентификации нескольких контейнеров в Docker Swarm есть файлы YAML (YAML Ain’t Markup Language).
Настройка контейнера
Хотя Docker Swarm API не поддерживает все команды Docker, он предлагает почти все лучшие функциональные возможности Docker.
Итак, Docker Swarm поддерживает большинство инструментов, доступных для Docker. Однако, если Docker API не способен выполнять некоторые необходимые операции, не существует простого обходного пути для их использования в Docker Swarm.
Как и Docker Swarm, Kubernetes имеет свою собственную версию API, определения клиентов и YAML. Тем не менее, они отличаются от их коллег Docker.
Следовательно, нет возможности использовать Docker CLI или Docker Compose для определения контейнеров в Kubernetes. В случаях, когда необходимо переключить платформу, команды и определения YAML необходимо переписать.
Балансировка нагрузки
Как правило, Ingress используется для балансировки нагрузки в Kubernetes. Тем не менее, есть и другой способ, в котором модуль в Kubernetes выставляется через сервис и его можно использовать в качестве балансировщика нагрузки в кластере, к которому он принадлежит.
Docker Swarm имеет DNS-элемент, который можно использовать для распределения входящих запросов по определенному имени службы. Для балансировки нагрузки службы могут быть назначены автоматически или настроены для работы на указанных пользователем портах.
Сеть
Kubernetes использует плоскую сетевую модель. Таким образом, все модули могут взаимодействовать друг с другом. Как будет происходить взаимодействие между модулями, определяется сетевыми политиками. Обычно модель плоской сети реализована в виде наложения.
Модель плоской сети в Kubernetes требует две CIDR (Classless Inter-Domain Routing): один для сервисов, а другой - от которого модули получают IP-адрес.
В Docker Swarm узел, присоединяющийся к кластеру Swarm, отвечает за генерацию оверлейной сети для сервисов, охватывающей каждый хост в кластере, и сети мостов Docker только для хостов для контейнеров.
Docker Swarm дает пользователям возможность шифровать трафик контейнерных данных при создании оверлейной сети.
Масштабируемость
Kubernetes - это комплексная структура для распределенных систем. Поскольку он предлагает унифицированный набор API и надежные гарантии состояния кластера, Kubernetes является сложной системой. Эти способности отвечают за замедление развертывания и масштабирования контейнера.
По сравнению с Kubernetes, Docker Swarm может развертывать контейнеры на гораздо более высокой скорости. Следовательно, это позволяет быстрее реагировать на масштабирование системы в соответствии с требованиями.
Синергия между Docker и Kubernetes
Kubernetes способен работать в тандеме с любой технологией контейнеризации. RKT и Docker являются двумя наиболее популярными опциями для механизма оркестровки контейнеров с открытым исходным кодом. Однако последний предпочтительнее, чем первый.
Из-за большего предпочтения использования Docker с Kubernetes было приложено много усилий для совершенствования сотрудничества между этими двумя технологиями.
Хотя Docker имеет свой собственный механизм оркестровки контейнеров в форме Docker Swarm, склонность к использованию Kubernetes с Docker нельзя не заметить. Это видно из того факта, что Docker for Desktop поставляется с собственным дистрибутивом Kubernetes.
Следовательно, совершенно очевидно, что обе технологии, Docker и Kubernetes, объединили свои усилия и также извлекли большую пользу из этого сотрудничества.
Управление компьютерными сетями - дело непростое. В последние годы всеобщая компьютеризация вызвала огромный скачок в расширении компьютерных сетей. Это добавило работы системному администратору. Ведь если ранее были распространены небольшие сети, то добавление и настройка новых устройств, либо обновление ПО на уже находящихся требовали ручной настройки операционной системы, а то и установки на каждом из них. Это требовало времени и нервов администратора. Сейчас же, когда сети насчитывают сотни, а то и тысячи машин, ручная настройка требует либо участия многих специалистов (а это порождает проблему плохой совместимости согласно человеческому фактору, каждый админ мыслит по-своему), либо очень долгого времени, если этим будет заниматься один специалист.
Такая проблема, с учетом технического прогресса, породила решение об автоматизации. На сегодняшний день существует специализированное программное обеспечение, которое позволяет присоединиться к удаленным машинам, и в автоматическом режиме произвести настройки операционной системы для корректной работы сети. Однако, как быть, если на нужных компьютерах в рамках одной сети установлены разные операционные системы? Ведь сейчас компьютеры под Linux, FreeBSD и Windows, объединенные в одну сеть - далеко не редкость. Поэтому одним из требований к управляющей программе стала кроссплатформенность. В этом случае одним из самых эффективных решений является такая программа, как Puppet.
Puppet это один из самых нужных инструментов сетевого администратора. Это приложение создано специально для управления конфигурацией операционных систем внутри одной сети. Оно имеет клиент-серверную архитектуру, то есть администратор, находящийся за сервером, может отправлять данные конфигурации на периферийные машины, на которых установлена клиентская часть. На этих рабочих станциях система в автоматическом режиме сконфигурирует себя в соответствии с присланными с сервера настройками.
Важным моментом является кроссплатформенность. Простота настройки и управления самыми распространенными операционными системами делает Puppet одним из самых актуальных решений по управлению компьютерными сетями на сегодняшний день.
Как же работает Puppet? Разберем подробнее. Для начала, на сервер нужно установить серверную часть программы. Поскольку приложение написано на Ruby, на серверной рабочей станции обязательно должна быть установлена нужная программная среда.
Серверная часть программы создана для хранения манифестов так в программной терминологии Puppet называются файлы с настройками конфигурации. В процессе работы сервер принимает обращения с клиентских машин и автоматически отсылает им обновленные файлы конфигурирования ОС для работы в сети.
На клиентских компьютерах также должно быть установлено программное обеспечение Puppet, уже в виде клиентской части. Как правило, данные установочные пакеты включаются в саму операционную систему, что позволяет быстро развертывать компьютерную сеть, однако, в случае их отсутствия, придется скачивать необходимую сборку с сайта разработчика.
Дополнительное удобство данного решения в том, что один администратор с помощью сервера может осуществить настройку и управление сотен и тысяч машин, объединенных в сеть. Если возникнут какие-то проблемы, то отклик с мест позволит админу быстро поправить код и устранить их. Хотя в данном случае возрастают требования к внимательности админа - одна неверно написанная строка кода конфигурации может привести к неполадкам по всей сети. Хотя, если разобраться, в данном случае можно запустить работающий манифест предыдущей сборки и восстановить все достаточно оперативно.
Если Вы не раз сталкивались с большими списками доступа и/или входящими в них object-группами, то наверняка уже задавались вопросом, существует ли инструмент, позволяющий определить, пропустит ли access-лист некий заданный трафик и вообще, какие строки имеют к этому отношение.
Конечно, такие инструменты существуют и полностью или частично решают перечисленные задачи. Однако, эти инструменты как правило являются частью функционала больших "комбайнов" управления сетью, 90% функционала которых Вас не интересует.
Чтобы продолжить, необходимо скачать утилиту ACL check
Безусловно, никто не запрещает использовать регулярные выражения для поиска определённых строк списка доступа прямо в консоли сетевого устройства. Но данный метод предоставит очень поверхностный результат. Например, он не отобразит доступ хоста, попадающего в сетевую маску или порт, попадающий под диапазон. Тем более, таким образом нельзя отобразить все существующие доступы между двумя заданными узлами/сетями. Знающий сетевой администратор осведомлён о безрезультативности метода простого парсинга access-листа в таких ситуациях.
Данная небольшая утилита создана именно для этого - найти строки access-листа, разрешающие или запрещающие определённый сетевой трафик. И даже более - выявить все строки, имеющие отношение к доступам между интересующими узлами или сетями.
Идея использования проста: Вы задаёте критерий, а программа находит строки access-листа, которые ему удовлетворяют. При этом, сам критерий выглядит как строка access-листа, но без использования оператора "permit" или "deny".
Если регулярно добавлять сетевые правила в access-лист без должной проверки их существования, то списки доступа могут содержать большое количество избыточных правил. Чтобы навести порядок в таких access-листах, в данной программе реализован функционал анализа списков доступа на избыточность. Вы можете выявить ненужные строки и освободить ресурсы оборудования.
Для анализа ACL с object-группами программе необходимо указать состав object-групп. Вывод ACL будет предоставлен в развёрнутом виде.
У нас есть нужные для изучения листов доступа статьи:
Стандартные листы контроля доступа (ACL)
Расширенные листы контроля доступа (Extended ACL)
Интерфейс программы
Поле ввода access-листа
Поле ввода object-групп
Кнопка распознавания access-листа
Поле вывода access-листа в детальном виде
Однострочное поле ввода условия
Многострочный список ввода условий
Кнопка прямой проверки
Кнопка обратной проверки
Поле результата проверки
Шкала позиционирования поля детальных результатов (11) по отношению ко всему ACL
Поле просмотра детальных результатов проверки
Кнопка анализа ACL на конфликты и избыточность
Кнопка сортировки строк ACL по различным критериям
Маркер текущего активного условия в многострочном списке (6)
Шкала сокращённого обозначения результатов проверки условий многострочного списка
Переключатель типа маски для различного типа сетевого устройства
Переключатель алгоритма проверки адресов источника и назначения
Активация режима игнорирования строк ACL с ICMP протоколом в режиме частичного совпадения адресов
Меню выбора вариантов CLI команд в составе с именем ACL
Вывод object-групп, используемых в распознанном ACL
Вывод списка известных программе именованных протоколов, а также типов и кодов ICMP
Поле вывода ошибок, возникающих в процессе распознавания ACL
Основные шаги
Исходный access-list необходимо скопировать в поле 1. Если он содержит object-группы, то их состав необходимо скопировать в поле 2. ACL и object-группы можно копировать как с конфигурации устройства (“show running-config”, “show startup-config”), так и по прямым командам “show access-lists”, “show object”.
Ниже приведён пример результата команды “show running-config”, допустимого для использования в поле 1:
ip access-list extended ACL
permit icmp host 172.16.0.6 host 172.21.0.6
permit ip host 172.16.0.6 host 172.21.0.1
permit tcp host 192.168.8.15 range 1024 65534 host 192.168.66.47
permit tcp 192.168.8.0 0.0.0.255 eq 22 1521 3389 addrgroup ADMIN_BSD
permit tcp host 192.168.8.12 eq 1521 192.168.83.20 0.0.0.1
Тот же access-list по команде “show access-lists”:
Extended IP access list ACL
10 permit icmp host 172.16.0.6 host 172.21.0.6
20 permit ip host 172.16.0.6 host 172.21.0.1 (32 matches)
30 permit tcp host 192.168.8.15 range 1024 65534 host 192.168.66.47
40 permit tcp 192.168.8.0 0.0.0.255 eq 22 1521 3389 addrgroup ADMIN_BSD (1 match)
50 permit tcp host 192.168.8.12 eq 1521 192.168.83.20 0.0.0.1
Пример результата команды “show running-config”, допустимого для использования в поле 2:
object-group ip address ADMIN_BSD
host-info 10.237.92.131
host-info 10.22.145.132
host-info 10.22.145.136
host-info 10.22.145.141
Содержимое вывода команды “show object-group”:
IP address object group ADMIN_BSD
host 10.237.92.131
host 10.22.145.132
host 10.22.145.136
host 10.22.145.141
Также допустимы и другие форматы object-групп. Пример допустимого фрагмента команды “show running-config”:
object-group network Servers
host 10.15.12.5
host 10.15.5.11
host 10.15.4.2
host 10.15.7.34
object-group service Ports1
tcp-udp eq domain
tcp-udp eq 88
udp range 3268 3269
tcp gt 49151
Пример того же фрагмента команды “show object-group”:
Network object group Servers
host 10.15.12.5
host 10.15.5.11
host 10.15.4.2
host 10.15.7.34
Service object group Ports1
tcp-udp eq domain
tcp-udp eq 88
udp range 3268 3269
tcp gt 49151
После копирования ACL и object-групп необходимо нажать кнопку 3. В результате access-list будет распознан и отображён в развёрнутом виде (в случае использования object-групп) в поле 4. Если на этапе распознавания возникли ошибки, то они будут отображены в поле 22.
Если номер строки конечного access-листа дополнен ‘0’, это означает, что данная строка получена из object-группы.
Если access-лист скопирован вместе с его заголовком, то активируется кнопка 19, позволяющая использовать команды конфигурирования, содержащие имя access-листа.
После распознавания ACL необходимо в поле 5 ввести условие для поиска интересуемого нас доступа и нажать кнопку 7. Результат поиска доступа отобразится в поле 9. В случае наличия доступа более детальная информация появится в поле 11. Вызов контекстного меню “Показать результат” по правой кнопке мыши на поле 11 позволит отобразить строки ACL, удовлетворяющие условию поиска.
Проверка существования доступа между заданными узлами по определённому порту
Предположим, нас интересует существование доступа с хоста 192.168.1.2 по порту TCP 1521 на сервер 192.168.2.2 в следующем списке доступа:
ip access-list extended ACL
10 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 range 1521 1522
20 permit tcp host 192.168.1.2 any
30 permit tcp host 192.168.1.3 any eq 1521
Копируем access-лист в поле 1 и нажимаем кнопку 3. В поле 5 вводим следующее условие:
tcp host 192.168.1.2 gt 1023 host 192.168.2.2 eq 1521
Нажимаем кнопку 7 или клавишу “Enter”. В поле 9 отобразится результат:
Разрешено в строке 1: 10 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 range 1521 1522
Имеются ещё совпадения
Здесь значение “1:” является результатом сквозной нумерации всех строк конечного (распознанного) ACL, а “10” – номер строки в исходном ACL. Надпись “Имеются ещё совпадения” означает, что в ACL присутствуют и другие строки, в которых теоретически может сработать наше условие. Результаты совпадения правил можно просмотреть в поле 11. Если на этом поле вызвать контекстное меню (правой кнопкой мыши) и выбрать пункт “Показать результат”, то появится дополнительное окно с выборкой сработавших строк ACL.
Определение узлов заданной сети, к которым имеется доступ по определённому порту
Рассмотрим ситуацию, когда требуется выяснить, к каким серверам сети 192.168.2.0 /24 открыт доступ по SSH (TCP 22). Список доступа следующий:
ip access-list extended ACL
10 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 range 1521 1522
20 permit tcp any 192.168.2.0 0.0.0.3 eq 22 3389
30 permit tcp host 192.168.1.3 host 192.168.2.254
40 permit tcp host 192.168.1.10 any
Копируем access-лист в поле 1 и нажимаем кнопку 3. Ставим переключатель 17 в положение “частичное по src и dst”. Алгоритм будет учитывать строки ACL, в которых IP-адреса источника и назначения полностью или частично попадают в диапазон адресов, указанный в условии.
В поле 5 вводим следующее условие:
tcp any gt 1023 any eq 22
Нажимаем кнопку 7 или клавишу “Enter”. В поле 9 отобразится результат
Блок
Результаты совпадения правил можно просмотреть в поле 11. Если на этом поле вызвать контекстное меню (правой кнопкой мыши) и выбрать пункт “Показать результат”, то появится дополнительное окно с выборкой сработавших строк ACL. Символ “?” в этом окне означает частичное совпадение по адресам.
Определение доступов, открытых между определёнными узлами
Выясним, какие доступы открыты от узла 192.168.1.10 к узлу 192.168.2.254 в следующем ACL:
ip access-list extended ACL
10 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 range 1521 1522
20 permit tcp any 192.168.2.0 0.0.0.3 eq 22 3389
30 permit tcp host 192.168.1.3 host 192.168.2.254
40 permit tcp host 192.168.1.10 any
Копируем access-лист в поле 1 и нажимаем кнопку 3. Ставим переключатель 17 в положение “частичное по src и dst”. В поле 5 вводим следующее условие:
ip host 192.168.1.10 host 192.168.2.254
Метод состоит в том, что заданное условие рассматривается как access-лист, а каждая строка исходного ACL как отдельное условие. Другими словами, условие и ACL меняются ролями. Кнопка (8), решающая эту задачу, называется “Обратная проверка”. Нажимаем кнопку 8 или комбинацию “Ctrl-Enter”. В поле 9 отобразится результат:
Блок
Результаты совпадения правил можно просмотреть в поле 11. Если на этом поле вызвать контекстное меню (правой кнопкой мыши) и выбрать пункт “Показать результат”, то появится дополнительное окно с выборкой сработавших строк ACL. Символ “?” в этом окне означает частичное совпадение по адресам.
Важным требованием при такой проверке является необходимость установки переключателя 17 в среднее положение.
Многострочный список условий (поле 6)
Список условий (6) предназначен для ввода нескольких условий и последовательной их проверки. Для ввода каждого следующего условия (новой строки) предусмотрена комбинация “Shift-Enter”. Для проверки условия из списка необходимо установить на него курсор и нажать кнопку 7 (Enter) или 8 (Ctrl-Enter). На шкале 15 напротив строки запрошенного условия отобразится соответствующий символ результата. Он сохранится до изменения условия в этой строке списка.
Сортировка (кнопка 13)
Распознанный access-list, выведенный в развёрнутом виде в поле 4, можно упорядочить по различным критериям и их комбинации. При нажатии на кнопку сортировки (13) открывается дополнительное окно.
1-7 – Кнопки включения элементов в цепь сортировки
8 – Отображение исходных номеров строк
9 – Режим группирования результатов сортировки
Каждый следующий критерий в цепочке выбирается соответствующей кнопкой. Рассмотрим следующий список доступа:
1 permit udp 192.168.8.0 0.0.0.255 host 192.168.38.24 eq syslog
2 permit tcp 192.168.8.0 0.0.0.255 host 192.168.38.23 eq 1514
3 permit tcp 192.168.8.0 0.0.0.255 host 192.168.38.24 eq 1514
4 permit tcp 192.168.8.0 0.0.0.255 host 192.168.38.23 eq 4041
5 permit tcp 192.168.8.0 0.0.0.255 host 192.168.12.26
6 permit ip 192.168.8.0 0.0.0.255 192.168.41.0 0.0.0.255
7 permit ip 192.168.8.0 0.0.0.255 host 192.168.41.31
Чтобы упорядочить эти строки сначала по IP адресу назначения, а затем по протоколу, необходимо нажать последовательно кнопки 5 и 1:
Цифры в круглых скобках на соответствующих кнопках указывают позицию элемента в цепочке сортировки. При отключении элемента из цепочки также исключаются все элементы с номерами выше отключенного.
Анализ на конфликты и избыточность (кнопка 12)
Кнопка “Анализ” (12) становится активной после распознания access-листа. Её нажатие запускает процесс анализа строк access-листа на конфликты и избыточность. Конфликтующей является строка access-листа, которая никогда не сработает из-за вышестоящего правила противоположного значения (“deny” после “permit” или наоборот).
К примеру, загрузим следующий ACL:
10 permit icmp any any
20 permit tcp host 10.15.2.11 eq 1521 host 10.15.1.10
30 deny tcp 10.15.2.0 0.0.0.255 10.15.0.0 0.0.31.255
40 permit udp 10.15.2.0 0.0.0.255 host 10.19.9.232
50 permit udp 10.15.2.0 0.0.0.255 host 10.19.9.120 eq syslog
60 permit tcp host 10.15.2.11 eq 1521 host 10.15.7.11
Распознаем его (кнопка 3) и нажмём кнопку “Анализ” (12). Программа предупредит нас о имеющихся конфликтах:
Кнопка “Да” откроет окно с результатами анализа, включающими только конфликты:
Если нажать кнопку ‘Нет’, то откроется окно, включающее как конфликтующие, так и избыточные правила. Рассмотрим следующий access-list:
10 permit icmp any any
20 permit tcp host 192.168.1.10 host 192.168.2.20 eq 22
30 permit tcp host 192.168.1.10 host 192.168.2.20
40 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
Анализ такого ACL отобразит следующие результаты:
Здесь жирным шрифтом выделены строки, если имеются другие правила, попадающие под их действие. Остальные строки (обычный шрифт) являются производными правилами.
Установив курсор на определённой строке, удерживая нажатой клавишу “Ctrl”, получим детальную информацию в нижней части окна:
Поле результатов
Поле детализации выбранного правила
Иерархический вид детализации
В данном случае правило 2 является производным от правила 3. В свою очередь, правило 3 входит в правило 4. Визуально уровень такой вложенности можно определить по отступам строки вправо или выбрать иерархический вид (3). При иерархическом виде производные правила будут выведены ниже строк, в которые они входят. Можно выделить диапазон интересуемых строк в поле 1 и вызвать контекстное меню правой кнопкой мыши, в котором выбрать варианты удаления избыточных строк.
Следует учитывать намеренное чередование операторов “permit” и “deny” в одном ACL для его упрощения. В таких случаях следует анализировать ACL частями. Например, до и после операторов “deny”. Либо анализировать полностью, но дополнительно обращать внимание на порядок следования конфликтующих строк в ACL и не удалять такие производные строки из исходного ACL.
Опции запуска программы
Предусмотрены следующие опции запуска exe-файла:
/h, /?, /help – вызов справки параметров запуска
/l (rus) – выбор языка
/nm – включение режима “netmask”
/pm (and,or) – выбор режима совпадения адресов
/skipicmp – включение режима “игнорировать ICMP при частичном совпадении”.