По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Предыдущая статья из цикла про соответствие пакетов в IP ACL.
Обратные маски, такие как значения dotted-decimal number (DDN), фактически представляют собой 32-разрядное двоичное число. Как 32-разрядное число, маска WC фактически направляет логику маршрутизатора бит за битом. Короче говоря, бит маски WC (wildcard), равный 0, означает, что сравнение должно выполняться как обычно, но двоичный 1 означает, что бит является подстановочным знаком и может быть проигнорирован при сравнении чисел.
Кстати, наш калькулятор подсетей показывает и сам считает WC (wildcard) маску.
Вы можете игнорировать двоичную маску WC. Почему? Что ж, обычно мы хотим сопоставить диапазон адресов, которые можно легко идентифицировать по номеру подсети и маске, будь то реальная подсеть или сводный маршрут, который группирует подсети вместе. Если вы можете указать диапазон адресов с помощью номера подсети и маски, вы можете найти числа для использования в вашем ACL с помощью простой десятичной математики, как описано далее.
Если вы действительно хотите знать логику двоичной маски, возьмите два номера DDN, которые ACL будет сравнивать (один из команды access-list, а другой из заголовка пакета), и преобразуйте оба в двоичный код. Затем также преобразуйте маску WC в двоичную. Сравните первые два двоичных числа бит за битом, но также игнорируйте любые биты, для которых маска WC случайно перечисляет двоичный 1, потому что это говорит вам игнорировать бит. Если все биты, которые вы проверили, равны, это совпадение!
Нахождения правильной обратной маски, соответствующей подсети
Во многих случаях ACL должен соответствовать всем хостам в определенной подсети. Чтобы соответствовать подсети с помощью ACL, вы можете использовать следующие сочетания:
Используйте номер подсети в качестве исходного значения в команде access-list.
Используйте обратную маску, полученную путем вычитания маски подсети из 255.255.255.255.
Например, для подсети 172.16.8.0 255.255.252.0 используйте номер подсети (172.16.8.0) в качестве параметра адреса, а затем выполните следующие вычисления, чтобы найти обратную маску:
Продолжая этот пример, завершенная команда для той же подсети будет следующей:
access-list 1 permit 172.16.8.0 0.0.3.255
Соответствие любому/всем адресам
В некоторых случаях вам может понадобиться одна команда ACL для сопоставления всех без исключения пакетов, которые достигают этой точки в ACL. Во-первых, вы должны знать (простой) способ сопоставить все пакеты с помощью ключевого слова any. Что еще более важно, вам нужно подумать о том, когда сопоставить все без исключения пакеты.
Во-первых, чтобы сопоставить все пакеты с помощью команды ACL, просто используйте ключевое слово any для адреса. Например, чтобы разрешить все пакеты:
access-list 1 permit any
Итак, когда и где вы должны использовать такую команду? Помните, что все ACL Cisco IP заканчиваются неявным отрицанием любой концепции в конце каждого ACL. То есть, если маршрутизатор сравнивает пакет с ACL, и пакет не соответствует ни одному из настроенных операторов, маршрутизатор отбрасывает пакет. Хотите переопределить это поведение по умолчанию? Настроить permit any в конце ACL.
Вы также можете явно настроить команду для запрета всего трафика (например, access-list 1 deny any) в конце ACL. Почему, когда та же самая логика уже находится в конце ACL? Что ж, ACL показывает счетчики списка для количества пакетов, соответствующих каждой команде в ACL, но нет счетчика для этого не явного запрета любой концепции в конце ACL. Итак, если вы хотите видеть счетчики количества пакетов, совпадающих с логикой deny any в конце ACL, настройте явное deny any.
Внедрение стандартных IP ACL
В этой лекции уже представлены все этапы настройки по частям. Далее суммируются все эти части в единую конфигурацию. Эта конфигурация основана на команде access-list, общий синтаксис которой повторяется здесь для справки:
access-list access-list-number {deny | permit} source [source-wildcard]
Этап 1. Спланируйте локацию (маршрутизатор и интерфейс) и направление (внутрь или наружу) на этом интерфейсе:
Стандартные списки ACL должны быть размещены рядом с местом назначения пакетов, чтобы они случайно не отбрасывали пакеты, которые не следует отбрасывать.
Поскольку стандартные списки ACL могут соответствовать только исходному IP-адресу пакета, идентифицируйте исходные IP-адреса пакетов по мере их прохождения в направлении, которое проверяет ACL.
Этап 2. Настройте одну или несколько команд глобальной конфигурации списка доступа для создания ACL, учитывая следующее:
Список просматривается последовательно с использованием логики первого совпадения.
Действие по умолчанию, если пакет не соответствует ни одной из команд списка доступа, - отклонить (отбросить) пакет.
Этап 3. Включите ACL на выбранном интерфейсе маршрутизатора в правильном направлении, используя подкоманду ip access-group number {in | out}.
Далее рассмотрим несколько примеров.
Стандартный нумерованный список ACL, пример 1
В первом примере показана конфигурация для тех же требований, что и на рисунках 4 и 5. Итак, требования для этого ACL следующие:
Включите входящий ACL на интерфейсе R2 S0/0/1.
Разрешить пакеты, приходящие от хоста A.
Запретить пакеты, приходящие от других хостов в подсети хоста A.
Разрешить пакеты, приходящие с любого другого адреса в сети класса A 10.0.0.0.
В исходном примере ничего не говорится о том, что делать по умолчанию, поэтому просто запретите весь другой трафик.
В примере 1 показана завершенная правильная конфигурация, начиная с процесса настройки, за которым следует вывод команды show running-config.
R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# access-list 1 permit 10.1.1.1
R2(config)# access-list 1 deny 10.1.1.0 0.0.0.255
R2(config)# access-list 1 permit 10.0.0.0 0.255.255.255
R2(config)# interface S0/0/1
R2(config-if)# ip access-group 1 in
R2(config-if)# ^Z
R2# show running-config
! Lines omitted for brevity
access-list 1 permit 10.1.1.1
access-list 1 deny 10.1.1.0 0.0.0.255
access-list 1 permit 10.0.0.0 0.255.255.255
Во-первых, обратите внимание на процесс настройки в верхней части примера. Обратите внимание, что команда access-list не изменяет командную строку из приглашения режима глобальной конфигурации, поскольку команда access-list является командой глобальной конфигурации. Затем сравните это с выводом команды show running-config: детали идентичны по сравнению с командами, которые были добавлены в режиме конфигурации. Наконец, не забудьте указать ip access-group 1 в команде под интерфейсом R2 S0/0/1, который включает логику ACL (как локацию, так и направление).
В примере 2 перечислены некоторые выходные данные маршрутизатора R2, которые показывают информацию об этом ACL. Команда show ip access-lists выводит подробную информацию только о списках ACL IPv4, а команда show access-lists перечисляет сведения о списках ACL IPv4, а также о любых других типах ACL, настроенных в настоящее время, например, списки ACL IPv6.
Вывод этих команд показывает два примечания. В первой строке вывода в этом случае указывается тип (стандарт) и номер. Если существовало более одного ACL, вы бы увидели несколько разделов вывода, по одной на каждый ACL, каждая со строкой заголовка, подобной этой. Затем эти команды перечисляют счетчики пакетов для количества пакетов, которые маршрутизатор сопоставил с каждой командой. Например, на данный момент 107 пакетов соответствуют первой строке в ACL.
Наконец, в конце примера перечислены выходные данные команды show ip interface. Эта команда перечисляет, среди многих других элементов, номер или имя любого IP ACL, включенного на интерфейсе для подкоманды интерфейса ip access-group.
Стандартный нумерованный список ACL, пример 2
Для второго примера используйте рисунок 8 и представьте, что ваш начальник в спешке дает вам некоторые требования в холле. Сначала он говорит вам, что хочет фильтровать пакеты, идущие от серверов справа к клиентам слева. Затем он говорит, что хочет, чтобы вы разрешили доступ для хостов A, B и других хостов в той же подсети к серверу S1, но запретили доступ к этому серверу хостам в подсети хоста C. Затем он сообщает вам, что, кроме того, хостам в подсети хоста A следует отказать в доступе к серверу S2, но хостам в подсети хоста C должен быть разрешен доступ к серверу S2 - и все это путем фильтрации пакетов, идущих только справа налево. Затем он говорит вам поместить входящий ACL на интерфейс F0/0 R2.
Если вы просмотрите все запросы начальника, требования могут быть сокращены до следующего:
Включите входящий ACL на интерфейсе F0/0 R2.
Разрешить пакеты от сервера S1, идущие к хостам в подсети A.
Запретить пакетам с сервера S1 идти к хостам в подсети C.
Разрешить пакетам с сервера S2 идти к хостам в подсети C.
Запретить пакетам с сервера S2 идти к хостам в подсети A.
Не было комментариев о том, что делать по умолчанию; используйте подразумеваемое отклонение всего по умолчанию.
Как оказалось, вы не можете сделать все, что просил ваш начальник, с помощью стандартного ACL. Например, рассмотрим очевидную команду для требования номер 2: access-list 2 permit 10.2.2.1. Это разрешает весь трафик с исходным IP-адресом 10.2.2.1 (сервер S1). Следующее требование просит вас фильтровать (отклонять) пакеты, полученные с того же IP-адреса! Даже если вы добавите другую команду, которая проверяет исходный IP-адрес 10.2.2.1, маршрутизатор никогда не доберется до него, потому что маршрутизаторы используют логику первого совпадения при поиске в ACL. Вы не можете проверить и IP-адрес назначения, и исходный IP-адрес, потому что стандартные ACL не могут проверить IP-адрес назначения.
Чтобы решить эту проблему, вам следует переосмыслить проблему и изменить правила. В реальной жизни вы, вероятно, вместо этого использовали бы расширенный ACL, который позволяет вам проверять как исходный, так и целевой IP-адрес.
Представьте себе, что ваш начальник позволяет вам изменять требования, чтобы попрактиковаться в другом стандартном ACL. Во-первых, вы будете использовать два исходящих ACL, оба на маршрутизаторе R1. Каждый ACL разрешает пересылку трафика с одного сервера в эту подключенную локальную сеть со следующими измененными требованиями:
Используя исходящий ACL на интерфейсе F0 / 0 маршрутизатора R1, разрешите пакеты с сервера S1 и запретите все остальные пакеты.
Используя исходящий ACL на интерфейсе F0 / 1 маршрутизатора R1, разрешите пакеты с сервера S2 и запретите все остальные пакеты.
Пример 3 показывает конфигурацию, которая удовлетворяет этим требованиям.
access-list 2 remark This ACL permits server S1 traffic to host A's subnet
access-list 2 permit 10.2.2.1
!
access-list 3 remark This ACL permits server S2 traffic to host C's subnet
access-list 3 permit 10.2.2.2
!
interface F0/0
ip access-group 2 out
!
interface F0/1
ip access-group 3 out
Как показано в примере, решение с номером ACL 2 разрешает весь трафик с сервера S1, при этом эта логика включена для пакетов, выходящих из интерфейса F0/0 маршрутизатора R1. Весь другой трафик будет отброшен из-за подразумеваемого запрета all в конце ACL. Кроме того, ACL 3 разрешает трафик от сервера S2, которому затем разрешается выходить из интерфейса F0/1 маршрутизатора R1. Также обратите внимание, что решение показывает использование параметра примечания списка доступа, который позволяет оставить текстовую документацию, которая остается в ACL.
Когда маршрутизаторы применяют ACL для фильтрации пакетов в исходящем направлении, как показано в Примере 2, маршрутизатор проверяет пакеты, которые он направляет, по списку ACL. Однако маршрутизатор не фильтрует пакеты, которые сам маршрутизатор создает с помощью исходящего ACL. Примеры таких пакетов включают сообщения протокола маршрутизации и пакеты, отправленные командами ping и traceroute на этом маршрутизаторе.
Советы по устранению неполадок и проверке
Устранение неполадок в списках ACL IPv4 требует внимания к деталям. В частности, вы должны быть готовы посмотреть адрес и обратную маску и с уверенностью предсказать адреса, соответствующие этим двум комбинированным параметрам.
Во-первых, вы можете определить, соответствует ли маршрутизатор пакетам или нет, с помощью пары инструментов. Пример 2 уже показал, что IOS хранит статистику о пакетах, соответствующих каждой строке ACL. Вдобавок, если вы добавите ключевое слово log в конец команды access-list, IOS затем выдает сообщения журнала со случайной статистикой совпадений с этой конкретной строкой ACL. И статистика, и сообщения журнала могут помочь решить, какая строка в ACL соответствует пакету.
Например, в примере 4 показана обновленная версия ACL 2 из примера 3, на этот раз с добавленным ключевым словом log. Внизу примера затем показано типичное сообщение журнала, в котором показано результирующее совпадение на основе пакета с исходным IP-адресом 10.2.2.1 (в соответствии с ACL) с адресом назначения 10.1.1.1.
R1# show running-config
! lines removed for brevity
access-list 2 remark This ACL permits server S1 traffic to host A's subnet
access-list 2 permit 10.2.2.1 log
!
interface F0/0
ip access-group 2 out
R1#
Feb 4 18:30:24.082: %SEC-6-IPACCESSLOGNP: list 2 permitted 0 10.2.2.1 -> 10.1.1.1, 1
Packet
Когда вы впервые устраняете неисправности на ACL, прежде чем вдаваться в подробности логики сопоставления, подумайте, как об интерфейсе, на котором включен ACL, так и о направлении потока пакетов. Иногда логика сопоставления идеальна, но ACL был включен на неправильном интерфейсе или в неправильном направлении, чтобы соответствовать пакетам, настроенным для ACL.
Например, на рисунке 9 повторяется тот же ACL, показанный ранее на рисунке 7. Первая строка этого ACL соответствует конкретному адресу хоста 10.1.1.1. Если этот ACL существует на маршрутизаторе R2, размещение этого ACL в качестве входящего ACL на интерфейсе S0/0/1 R2 может работать, потому что пакеты, отправленные хостом 10.1.1.1 - в левой части рисунка - могут входить в интерфейс S0/0/1 маршрутизатора R2. Однако, если R2 включает ACL 1 на своем интерфейсе F0/0 для входящих пакетов, ACL никогда не будет соответствовать пакету с исходным IP-адресом 10.1.1.1, потому что пакеты, отправленные хостом 10.1.1.1, никогда не войдут в этот интерфейс. Пакеты, отправленные 10.1.1.1, будут выходить из интерфейса R2 F0/0, но никогда не попадут в него только из-за топологии сети.
Переменные окружения (или переменные среды) - это набор пар ключ-значение, которые хранятся в вашем Linux и используются процессами для выполнения определенных операций. Они отвечают за стандартное поведение системы и приложений. При взаимодействии с вашим сервером через сеанс оболочки, есть много информации, которую ваша оболочка обрабатывает, чтобы определить ее поведение и доступы. Некоторые из этих параметров содержатся в настройках конфигурации, а другие определяются пользовательским вводом. Оболочка отслеживает все эти параметры и настройки через окружение. Окружение - это область, которую оболочка создает каждый раз при запуске сеанса, содержащего переменные, определяющие системные свойства. Например, это может быть часовой пояс в системе, пути к определенным файлам, приложения по-умолчанию, локали и многое другое. Переменные окружения также могут использоваться в программах оболочки или в подоболочках для выполнения различных операций.
В этом руководстве мы расскажем, как просматривать, устанавливать и сбрасывать переменные окружения в вашей системе.
Переменные окружения и переменные оболочки
Переменные имеют следующий формат:
KEY=value
KEY="Some other value"
KEY=value1:value2
Должны соблюдаться следующие правила:
Имена переменных чувствительны к регистру (регистрозависимы). Переменные окружения должны быть написаны большими буквами (UPPER CASE).
Несколько значений переменных разделяются двоеточием :
Вокруг символа = нет пробела
Переменные можно разделить на две категории:
Переменные окружения (Environmental Variables) - это переменные, которые определены для текущей оболочки и наследуются любыми дочерними оболочками или процессами. Переменные окружения используются для передачи информации в процессы, которые порождаются из оболочки.
Переменные оболочки (Shell Variables) - это переменные, которые содержатся исключительно в оболочке, в которой они были установлены или определены. Они часто используются для отслеживания эфемерных данных, например, текущего рабочего каталога.
Про Linux за 5 минут
В эпоху автоматизации люди все время ищут средства для эффективного выполнения задач. А почему бы и нет, каждая секунда имеет значение!
Аналогично, если вы пользуетесь Unix-подобной операционной системой, планировщик Cron очень экономит время за счет автоматизации рутинных задач. Давайте кратко разберем, как это работает, а затем изучим некоторые облачные решений для мониторинга самого Cron.
Так, что же такое Cron и с чем его едят?
Планировщик Cron - это служебная программа, которая выполняет заранее запланированные сценарии или команды на сервере. Эта команда встроена в запланированное время и дату для автоматического выполнения без выполнения вручную.
Кроме того, планировщик Cron точно реализованы для автоматизации повторяющихся задач, таких как удаление файлов за неделю, перезагрузка сервера или выполнение некоторых других функций.
Основные элементы задания Cron
Планировщик Cron работает поверх трех важными компонентов:
Сценарий - сценарий является первым составляющим Cron, которое вызывается для выполнения.
Расписание - когда запускать указанные сценарии.
Действие - это ход вывода, который происходит после окончательного выполнения.
Типы заданий Cron, требующих мониторинга
Отсутствие уведомлений о статусе заданий Cron может не иметь сиюминутных последствий, но может помешать работе системы в долгосрочной перспективе. Вот некоторые из заданий Cron, которые обычно остаются незамеченными если не использовать эффективную службу мониторинга:
Резервные копии
Обновление SSL-сертификата
Антивирусное сканирование
Динамические обновления DNS
Перезагрузка сервера
Преимущества мониторинга статуса заданий Cron
Помимо контроля за своевременным выполнение запланированных заданий Cron, службы мониторинга предоставляют следующие практические преимущества:
Планирование заданий - можно запланировать любые задания доступные через планировщик Cron прямо из панели управления сервиса;
Мгновенные оповещения - если какое-либо приложение или процесс задания занимает больше времени, чем ожидалось, то эти службы будут выдавать мгновенные оповещения.
Metric Insights - вы можете отслеживать все метрики по заданиям и оптимизировать их выполнение.
Теперь давайте рассмотрим некоторые облачные средства мониторинга Cron.
1. HealthChecks
Простота и эффективность HealthCheck делают его одним из лучших вариантов для мониторинга заданий Cron. Она предоставляет еженедельные отчеты по триггерам оповещений, сбоям в выполнении запланированных задач, сбоям резервного копирования и многом другом.
Еще одна впечатляющая вещь в HealthCheck заключается в том, что он предлагает уникальный URL для каждой задачи, для которой включен мониторинг. Вы можете легко проверять запросы на обслуживание по HTTP или отправлять сообщения по электронной почте.
Применение HealthChecks для мониторинга cron уменьшит количество автоматических сбоев. Сервис располагает удобной панелью мониторинга с интерактивным обновлением, которая предоставляет подробные сведения обо всех предупреждениях или проверках. Можно также назначить имена или теги всем проверяемым службам, что в конечном итоге поможет легко распознать их при необходимости.
Она поставляется с простой конфигурацией с параметрами "Grace Time" и "Period" для указания различных аспектов или состояния мониторинга. Он позволяет добавить подробное описание для каждого задания Cron.
Для выполнения дальнейших действий можно добавить указатели и заметки. Кроме того, можно просмотреть историю отправленных или полученных сообщений ping. Другие функции включают в себя публичные значки состояния, поддержку выражений Cron и интеграцию с Slack, Email, WebHooks, Microsoft Teams и т.д.
2. Cronitor
Cronitor поможет вам более удобно планировать задачи с помощью быстрых оповещений. Он работает с несколькими заданиями Cron, такими как запланированные события AWS, планировщик заданий Microsoft, планировщик Jenkins, Kubernetes Cron, Java Cron и многое другое.
Мониторинг контрольного сигнала позволяет получить представление о состоянии конвейеров данных, фоновых заданий, демонов, сценариев, ETL-заданий и других. Его легко можно использовать для любого языка и на любой платформе. Сервис обладает гибкими настройками политик и правил оповещения.
Cronitor также предлагает мониторинг времени безотказной работы для веб-сайта, API, S3 объектов Amazon (корзин) и т.д.
3. Cronhub
Cronhub устраняет необходимость в написании любых кодов для планирования и контроля фоновых заданий. Вам просто нужно сконцентрироваться на своих приложениях и позволить им планировать ваши задачи. Вы получаете мгновенные предупреждения о всех аспектах мониторинга, как только появится отклонение от нормы в любом из запланированных задач.
Поддерживается планирование заданий с использованием выражений Cron или временных интервалов. Для этого достаточно задать API или целевой URL-адрес, который будет выполняться в задании. Затем Cronhub отправляет HTTP-запрос на указанный API или целевой URL.
Если расписание будет прервано по какой-либо причине, Cronhub немедленно отправит предупреждения через настроенные каналы, в число которых входит SMS, Slack, Email и другие.
Помимо этого, Cronhub также помогает отслеживать информацию о запланированных заданиях, обеспечивает поддержку команды, доступ к журналу. Это в конечном итоге поможет вам найти лазейки в приложении вместе с заданиями в фоновом режиме.
4. Dead Man’s Snitch
Еще один сервис, который на русский язык переводится довольно забавно "Стукач Мертвеца" Dead Man’s Snitch завоевал рынок, во время бума служб мониторинга планировщика Cron. Он больше ориентирован на задания вроде выставления счетов или резервного копирования, которые не были выполнены в соответствии установленным графикам.
Dead Man's Snitch гарантирует, что разработчики и пользователи будут следить за работой Cron так, как они ожидали. С помощью этого сервиса можно контролировать Cron, Heroku Scheduler и другие планировщики. Для уведомления о сбоях в работе может использоваться любой HTTP клиент, например, cURL.
cURL - это фрагмент, добавляемый как суффикс к концу строки Crontab. Он предлагает запрос к Dead Man 's Snitch, чтобы проверить, выполняется ли задание или выполняется ли оно должным образом или нет. Для различных заданий, вы можете изменить Snitch URL, чтобы знать результаты мониторинга для каждого из них по отдельности.
Другой интересной особенностью является добавление к заданию функции "Полевой агент". Можно загрузить и установить его для улучшения результатов мониторинга вместе с метриками и записями данных. С его помощью можно проверить журналы ошибок заданий Cron, чтобы найти лучшее разрешение для них.
Эти функции являются идеальным сочетанием для обеспечения лучшего отслеживания фоновых заданий. Его цены начинаются всего от 5 долларов в месяц для трех "доносчиков" и неограниченных членов команды.
5. CronAlarm
CronAlarm - это универсальный концентратор, помогающий получить представление о надежности и производительности запланированных задач с минимальными сложностями.
Лучшее в CronAlarm это поддержка каждого Cron задания с возможностью доступа к URL без особых хлопот. Обо всех фоновых заданиях приложений, будь то выполняющиеся слишком быстро или медленно, либо с опережением, или с отставанием, сообщается и пользователям.
Существует несколько платформ интеграции для оповещения пользователей, включая электронную почту, Slack и webhooks. Необходимо предоставить CronAlarm информацию о расписаниях работы, таких как время запуска, продолжительность выполнения и т.д.
Он назначает определенный ключ API различным заданиям. Чтобы начать работу со службой мониторинга CronAlarm, необходимо просто добавить ключ API или вызов в начале или конце URL. Вы также можете обратиться к CronAlarm чтобы получить более функциональный API, оснащенный интегрированными функциями для более эффективного решения проблем.
6. WebGazer
Web Gazer помогает планировать задачи и выполнять мониторинг всех выбранных заданий Cron для отслеживания производительности.
В Web Gazers не посылает ложные аварийные сигналы, так как инциденты проверяются в течение нескольких секунд перед отправкой предупреждения пользователю. Кроме того, Web Gazer обеспечивает квитирующий мониторинг (heartbeat monitoring), мониторинг SSL.
Его план начинается с $19/месяц, а также доступна бесплатная версия со всем основным функционалом.
Заключение
За автоматизацией будущее.
Планирование и мониторинг заданий Cron помогают эффективно выполнять задачи. В противном случае, как бы вы узнали, что выполняются ли запланированные операции подобающим образом или нет? Но к счастью, вышеуказанные решения, в конечном итоге, помогут вам оптимизировать задачи и устранить недочёты, мешающие работе пользователя.