По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Icinga - это бесплатное средство мониторинга с открытым исходным кодом для вашего дата-центра. Это приложение для мониторинга компьютерных систем и работы сети, которое проверяет состояние готовности вашей сети и компьютерных ресурсов, уведомляет о перебоях в работе системы, генерирует данные о производительности ваших ресурсов, а также обеспечивает высокую степень работоспособности и возможность настройки мониторинга распределённых систем со встроенной функцией кластера. Icinga была создана в 2009 году в качестве разветвления средства мониторинга Nagios. Но потом была заново переписана на С++ и стала одним из самых популярных инструментов мониторинга в интернете. Слово "Ицинга" - это Зулусское слово, означающее "оно ищет", или "оно обозревает", или "оно исследует". В этом учебном пособии мы покажем вам, как установить и настроить инструмент мониторинга Icinga 2 на сервере LTS Ubuntu 20.04. Мы установим Icinga 2 из официального репозитория, а затем настроим icingaweb2, облегченный и расширяемый веб-интерфейс для системы мониторинга icinga2. Предпосылки Для этого руководства мы установим icinga2 и icingaweb2, используя сервер Ubuntu 20.04 с 2 ГБ оперативной памяти. Но эти данные меняются в зависимости от размера вашей ИТ-инфраструктуры. Что мы будем делать? Установка Icinga2 и Nagios Monitoring Plugins; Установка и настройка базы данных MySQL; Установка и настройка модуля Icinga MySQL; Установка Apache2 и PHP-пакетов; Установка и настройка Icingaweb2; Установка Icinga2 Stack Post. Шаг 1 - Установка Icinga2 и системы мониторинга Nagios Сперва мы добавим репозиторий icinga2 для Ubuntu 20.04 и установим пакеты icinga2 и плагины мониторинга Nagios. Добавьте GPG ключ Icinga2 в вашу систему. curl https://packages.icinga.com/icinga.key | apt-key add - Теперь перейдите в директорию '/etc/apt/sources.list.d' и создайте новый репозиторий 'icinga-focal.list'. cd /etc/apt/sources.list.d/ vim icinga-focal.list Вставьте следующую конфигурацию репозитория. deb http://packages.icinga.com/ubuntu icinga-focal main deb-src http://packages.icinga.com/ubuntu icinga-focal main Нажмите сохранить и закройте. Затем обновите все доступные репозитории и установите подключаемые модули Icinga2 и Nagios Monitoring с помощью команды apt ниже. sudo apt update sudo apt install icinga2 monitoring-plugins После завершения установки запустите службу Icinga2 и добавьте сервис в автозагрузку. systemctl start icinga2 systemctl enable icinga2 После этого проверьте службу icinga2, используя приведенную ниже команду. systemctl status icinga2 Ниже приведен результат, который вы получите. В результате сервис icinga2 запущен и работает на Ubuntu 20.04 FocalFossa. Шаг 2 - Установка и настройка базы данных MySQL На этом этапе мы установим последнюю версию сервера MySQL на нашем Ubuntu 20.04 и установим пароль по умолчанию для пользователя MySQL с root правами. Установите MySQL сервер с помощью команды apt, приведенной ниже. sudo apt install mysql-server mysql-client После этого запустите службу MySQL и добавьте её в автозагрузку. systemctl start mysql systemctl enable mysql И сервис MySQL готов и запущен. Далее мы зададим пароль для root - пользователя MySQL с помощью командной строки 'mysql_secure_installation', которые предоставлены MySQL-пакетами. Запустите команду 'mysql_secure_installation', которая представлена ниже. mysql_secure_installation Теперь вам будет предложено настроить новый пароль для пользователя root, введите надежный пароль, а затем введите "Y" для прочих конфигураций. Press y|Y for Yes, any other key for No: Please set the password for root here. New password: Re-enter new password: Remove anonymous users? (Press y|Y for Yes, any other key for No) : Y Disallow root login remotely? (Press y|Y for Yes, any other key for No) : Y Remove test database and access to it? (Press y|Y for Yes, any other key for No) : Y Reload privilege tables now? (Press y|Y for Yes, any other key for No) : Y В результате завершена установка сервера MySQL и сконфигурирован корневой пароль по умолчанию. Шаг 3 - Установка и настройка модуля Icinga MySQL После установки сервера MySQL мы установим модуль icinga2 для поддержки MySQL под названием 'icinga2-ido-mysql'. Установка 'icinga2-ido-mysql' возможна с помощью команды apt, приведенной ниже. sudo apt install icinga2-ido-mysql Теперь вам будет предложено включить функцию icinga2 ido-mysql, выберите "Да", чтобы продолжить. Сконфигурируйте 'icinga2-ido-mysql'с помощью команды dbconfig, затем выберите "Yes" для продолжения. Введите свой пароль для 'icinga2-ido-mysql'. Повторите пароль для 'icinga2-ido-mysql'. В результате установка пакета 'icinga2-ido-mysql' была завершена, и был создан новый пользователь MySQL 'icinga2'. Затем, чтобы Icinga работала с новой версией MySQL, мы настроим MySQL пользователя 'icinga2' с аутентификацией по встроенному паролю MySQL. Войдите в командную строку MySQL, используя нижеприведенную команду. mysql -u root -p Теперь измените аутентификацию пользователя 'icinga2@localhost' с помощью собственного плагина аутентификации MySQL, используя следующий запрос. ALTER USER icinga2@localhost IDENTIFIED WITH mysql_native_password BY 'aqwe123@#$'; flush privileges; Введите 'exit', чтобы выйти из командной строки MySQL, а пользователь MySQL 'icinga2' теперь будет использовать родной плагин аутентификации. Далее, включите функцию 'ido-mysql' и проверьте все включенные плагины, используя следующую команду. icinga2 feature enable ido-mysql icinga2 feature list Функция 'ido-mysql' будет включена, чтобы применить новую конфигурацию, перезапустите службу icinga2. systemctl restart icinga2 Таким образом, установка и настройка 'icinga2-ido-mysql' была завершена. Шаг 4 - Установка Apache2 и PHP-пакетов На этом шаге, мы установим пакеты Apache и PHP для icingaweb2 и мы будем использовать PHP 7.3, который доступен в репозитории PPA, потому что на данный момент icingaweb2 еще не поддерживается в новой версии PHP 7.4. Сначала установите пакет 'python3-software-properties' и добавьте репозиторий PHP PPA, используя следующую команду. sudo apt install python3-software-properties sudo add-apt-repository ppa:ondrej/php Далее установите Apache и PHP пакеты с помощью команды apt, описанной ниже. sudo apt install apache2 php7.3 php7.3-common php7.3-gd php7.3-ldap php7.3-intl php7.3-curl libapache2-mod-php7.3 php7.3-mysql php7.3-pgsql php7.3-xml После того, как вся установка будет завершена, отредактируйте конфигурацию 'php.ini' с помощью vim-редактора. vim /etc/php/7.3/apache2/php.ini Снимите комментарий с опции 'date.timezone' и введите свой часовой пояс. date.timezone = Asia/Singapore Раскомментируйте конфигурацию 'cgi.fix_pathinfo' и измените значение на '0'. cgi.fix_pathinfo=0 Сохраните и закройте. Далее перезапустите службу Apache2 и добавьте ее в автозагрузку. systemctl restart apache2 systemctl enable apache2 Служба Apache2 запущена и работает, проверьте её, используя следующую команду. systemctl status apache2 Ниже приведен результат, который вы получите. В результате была завершена установка Apache и PHP пакетов для icingaweb2. Шаг 5 - Установка и настройка Icingaweb2 После установки Apache и PHP-пакетов мы установим пакет icingaweb2 и создадим новую базу данных MySQL для icingaweb2. Начните установку пакетов icingaweb2 и icingacli с помощью команды apt. sudo apt install icingaweb2 icingacli После завершения установки сгенерируйте токен icingaweb2 для установки с помощью приведенной ниже команды. icingacli setup token create Ниже приведен результат, который вы получите. The newly generated setup token is: 9b871ead0a60c94f Теперь скопируйте код токена в надёжное место, он будет использован для установки icingaweb2. Далее войдите в командную строку MySQL, используя нижеприведенную команду mysql. mysql -u root -p Теперь создайте новую базу данных и пользователя, используя следующие запросы. create database icingaweb2; create user icingaweb2@localhost identified with mysql_native_password by "icingaweb2pass"; grant all privileges on icingaweb2.* to icingaweb2@localhost with grant option; flush privileges; Введите 'exit', чтобы выйти из командной строки MySQL. В результате этого установка icingaweb2 завершена и создана новая база данных icingaweb2. Шаг 6 - Установка Icinga2 и Icinga Stack Post Откройте веб-браузер и введите IP-адрес сервера, как показано ниже. Замените IP-адрес на IP-адрес своего сервера. http://IP_адрес/icingaweb2/setup Вставьте код токена установки в поле и нажмите кнопку 'Далее'. Теперь вам нужно выбрать модуль Icinga для установки, оставить модуль 'Monitoring' и нажать 'Далее'. После этого Icinga проверит состояние среды для его установки. Убедитесь, что все необходимые модули находятся в зеленом состоянии, за исключением 'Модулей PostgreSQL', затем нажмите 'Далее'. Теперь вам нужно выбрать Аутентификацию для доступа к icingaweb2, выбрать 'Database ' (База данных) и нажать 'Next ' (Далее). Введите все данные базы данных для 'icingaweb2' и нажмите 'Validate Configuration' (Проверить конфигурацию) для тестирования. После того, как все прошло успешно, нажмите кнопку 'Next ' (Далее). Теперь для аутентификации Backend Authentication выберите 'icingaweb2' и нажмите 'Next ' (Далее). Введите логин и пароль администратора для icingaweb2 и нажмите 'Далее' еще раз. В разделе Application Configuration (Конфигурация приложения) оставьте всё по умолчанию и нажмите 'Далее'. Подтвердите все настройки и нажмите "Далее". И вы получите страницу приветствия на icingaweb2. Снова нажмите "Далее", чтобы настроить backend мониторинга. Установите имя Backend как 'icinga2' с типом 'IDO', затем нажмите 'Далее'. Теперь вам нужно настроить MySQL IDO backend ресурс для приложения icinga2. Введите данные базы данных для icinga2 и нажмите кнопку 'Validate Configuration'. После успешного завершения нажмите кнопку 'Далее'. Для 'Command Transport' выберите 'Local Command File' и оставьте его по умолчанию. Затем нажмите 'Далее'. Для службы Monitoring Security оставьте всё по умолчанию и нажмите 'Далее'. Подтвердите все настройки и нажмите кнопку 'Готово'. Теперь установка Icinga 2 и Icinga web 2 завершена, нажмите кнопку 'Login to Icinga Web 2', и вы будете перенаправлены на страницу входа. Введите пользователя, которого вы настроили в самом начале и нажмите кнопку "Войти". И, наконец, установка и настройка icinga2 и icingaweb2 на сервере Ubuntu 20.04 успешно завершена.
img
Почитайте предыдущую статью из цикла про установление и прекращение соединения в TCP. UDP предоставляет приложениям сервис для обмена сообщениями. В отличие от TCP, UDP не требует установления соединения и не обеспечивает надежности, работы с окнами, переупорядочивания полученных данных и сегментации больших фрагментов данных на нужный размер для передачи. Однако UDP предоставляет некоторые функции TCP, такие как передача данных и мультиплексирование с использованием номеров портов, и делает это с меньшим объемом служебных данных и меньшими затратами на обработку, чем TCP. Передача данных UDP отличается от передачи данных TCP тем, что не выполняется переупорядочевание или восстановление. Приложения, использующие UDP, толерантны к потерянным данным, или у них есть какой-то прикладной механизм для восстановления потерянных данных. Например, VoIP использует UDP, потому что, если голосовой пакет потерян, к тому времени, когда потеря может быть замечена и пакет будет повторно передан, произойдет слишком большая задержка, и голос будет неразборчивым. Кроме того, запросы DNS используют UDP, потому что пользователь будет повторять операцию, если разрешение DNS не удается. В качестве другого примера, сетевая файловая система (NFS), приложение удаленной файловой системы, выполняет восстановление с помощью кода уровня приложения, поэтому функции UDP приемлемы для NFS. На рисунке 10 показан формат заголовка UDP. Самое главное, обратите внимание, что заголовок включает поля порта источника и назначения для той же цели, что и TCP. Однако UDP имеет только 8 байтов по сравнению с 20-байтовым заголовком TCP, показанным на рисунке 1-1. UDP требует более короткого заголовка, чем TCP, просто потому, что у UDP меньше работы. Приложения TCP / IP Вся цель построения корпоративной сети или подключения небольшой домашней или офисной сети к Интернету состоит в использовании таких приложений, как просмотр веб-страниц, обмен текстовыми сообщениями, электронная почта, загрузка файлов, голос и видео. В этом подразделе исследуется одно конкретное приложение - просмотр веб-страниц с использованием протокола передачи гипертекста (HTTP). Всемирная паутина (WWW) состоит из всех подключенных к Интернету веб-серверов в мире, а также всех подключенных к Интернету хостов с веб-браузерами. Веб-серверы, которые состоят из программного обеспечения веб-сервера, запущенного на компьютере, хранят информацию (в виде веб-страниц), которая может быть полезна для разных людей. Веб-браузер, представляющий собой программное обеспечение, установленное на компьютере конечного пользователя, предоставляет средства для подключения к веб-серверу и отображения веб-страниц, хранящихся на веб-сервере. Хотя большинство людей используют термин "веб-браузер" или просто "браузер", веб-браузеры также называются веб-клиентами, потому что они получают услугу с веб-сервера. Чтобы этот процесс работал, необходимо выполнить несколько определенных функций прикладного уровня. Пользователь должен каким-то образом идентифицировать сервер, конкретную веб-страницу и протокол, используемый для получения данных с сервера. Клиент должен найти IP-адрес сервера на основе имени сервера, обычно используя DNS. Клиент должен запросить веб-страницу, которая на самом деле состоит из нескольких отдельных файлов, а сервер должен отправить файлы в веб-браузер. Наконец, для приложений электронной коммерции (электронной коммерции) передача данных, особенно конфиденциальных финансовых данных, должна быть безопасной. В следующих подразделах рассматривается каждая из этих функций. Унифицированные идентификаторы ресурсов Чтобы браузер отображал веб-страницу, он должен идентифицировать сервер, на котором находится эта веб-страница, а также другую информацию, которая идентифицирует конкретную веб-страницу. Большинство веб-серверов имеют множество веб-страниц. Например, если вы используете веб-браузер для просмотра www.cisco.com и щелкаете по этой веб-странице, вы увидите другую веб-страницу. Щелкните еще раз, и вы увидите другую веб-страницу. В каждом случае щелчок идентифицирует IP-адрес сервера, а также конкретную веб-страницу, при этом детали в основном скрыты от вас. (Эти интерактивные элементы на веб-странице, которые, в свою очередь, переводят вас на другую веб-страницу, называются ссылками.) Пользователь браузера может идентифицировать веб-страницу, когда вы щелкаете что-либо на веб-странице или когда вы вводите унифицированный идентификатор ресурса (URI) в адресную область браузера. Оба варианта - щелчок по ссылке и ввод URI - относятся к URI, потому что, когда вы щелкаете ссылку на веб-странице, эта ссылка фактически ссылается на URI. Большинство браузеров поддерживают какой-либо способ просмотра скрытого URI, на который ссылается ссылка. В некоторых браузерах наведите указатель мыши на ссылку, щелкните правой кнопкой мыши и выберите "Свойства". Во всплывающем окне должен отображаться URI, на который будет направлен браузер, если вы нажмете эту ссылку. В просторечии многие люди используют термины веб-адрес или аналогичные связанные термины Universal Resource Locator (или Uniform Resource Locator [URL]) вместо URI, но URI действительно является правильным формальным термином. Фактически, URL-адрес используется чаще, чем URI, уже много лет. Однако IETF (группа, определяющая TCP / IP) вместе с консорциумом W3C (W3.org, консорциум, разрабатывающий веб-стандарты) предприняли согласованные усилия по стандартизации использования URI в качестве общего термина. С практической точки зрения, URI, используемые для подключения к веб-серверу, включают три ключевых компонента, как показано на рисунке 11. На рисунке показаны формальные имена полей URI. Что еще более важно для понимания, обратите внимание, что текст перед :// определяет протокол, используемый для подключения к серверу, текст между // и / идентифицирует сервер по имени, а текст после / идентифицирует веб-страницу. В этом случае используется протокол передачи гипертекста (HTTP), имя хоста - www.certskills.com, а имя веб-страницы - blog. Поиск веб-сервера с помощью DNS Хост может использовать DNS для обнаружения IP-адреса, соответствующего определенному имени хоста. В URI обычно указывается имя сервера - имя, которое можно использовать для динамического изучения IP-адреса, используемого этим же сервером. Веб-браузер не может отправить IP-пакет на имя назначения, но он может отправить пакет на IP-адрес назначения. Итак, прежде чем браузер сможет отправить пакет на веб-сервер, браузеру обычно необходимо преобразовать имя внутри URI в соответствующий IP-адрес этого имени. Чтобы собрать воедино несколько концепций, на рисунке 12 показан процесс DNS, инициированный веб-браузером, а также некоторая другая связанная информация. С базовой точки зрения пользователь вводит URI (в данном случае http://www.exempel.com/go/learningnetwork), преобразует имя www.exempel.com в правильный IP-адрес и начинает отправлять пакеты на веб сервер. Шаги, показанные на рисунке, следующие: Пользователь вводит URI http://www.exempel.com/go/learningnetwork в адресную область браузера. Клиент отправляет DNS-запрос на DNS-сервер. Обычно клиент узнает IP-адрес DNS-сервера через DHCP. Обратите внимание, что запрос DNS использует заголовок UDP с портом назначения 53-го известного порта DNS (см. таблицу 2 ранее в этой лекции, где приведен список популярных хорошо известных портов). DNS-сервер отправляет ответ, в котором IP-адрес 198.133.219.25 указан как IP-адрес www.exemple.com. Также обратите внимание, что ответ показывает IP-адрес назначения 64.100.1.1, IP-адрес клиента. Он также показывает заголовок UDP с портом источника 53; исходный порт - 53, потому что данные получены или отправлены DNS-сервером. Клиент начинает процесс установления нового TCP-соединения с веб-сервером. Обратите внимание, что IP-адрес назначения - это только что изученный IP-адрес веб-сервера. Пакет включает заголовок TCP, потому что HTTP использует TCP. Также обратите внимание, что TCP-порт назначения - 80, хорошо известный порт для HTTP. Наконец, отображается бит SYN, как напоминание о том, что процесс установления TCP-соединения начинается с сегмента TCP с включенным битом SYN (двоичная 1). Пример на рисунке 12 показывает, что происходит, когда клиентский хост не знает IP-адрес, связанный с именем хоста, но предприятие знает адрес. Однако хосты могут кэшировать результаты DNS-запросов, так что какое-то время клиенту не нужно запрашивать DNS для разрешения имени. Также DNS-сервер может кэшировать результаты предыдущих DNS-запросов; например, корпоративный DNS-сервер на рисунке 12 обычно не имеет настроенной информации об именах хостов в доменах за пределами этого предприятия, поэтому в этом примере DNS-сервер кэшировал адрес, связанный с именем хоста www.example.com. Когда локальный DNS не знает адрес, связанный с именем хоста, ему необходимо обратиться за помощью. На рисунке 13 показан пример с тем же клиентом, что и на рисунке 12. В этом случае корпоративный DNS действует как рекурсивный DNS-сервер, отправляя повторяющиеся DNS-сообщения, чтобы идентифицировать авторитетный DNS-сервер. Шаги, показанные на рисунке, следующие: Клиент отправляет DNS-запрос для www.exemple.com на известный ему DNS-сервер, который является корпоративным DNS-сервером. (Рекурсивный) корпоративный DNS-сервер еще не знает ответа, но он не отклоняет DNS-запрос клиента. Вместо этого он следует повторяющемуся (рекурсивному) процессу (показанному как шаги 2, 3 и 4), начиная с DNS-запроса, отправленного на корневой DNS-сервер. Корень также не предоставляет адрес, но он предоставляет IP-адрес другого DNS-сервера, ответственного за домен верхнего уровня .com. Рекурсивный корпоративный DNS-сервер отправляет следующий DNS-запрос DNS-серверу, полученному на предыдущем шаге, - на этот раз DNS-серверу TLD для домена .com. Этот DNS также не знает адреса, но знает DNS-сервер, который должен быть официальным DNS-сервером для домена exemple.com, поэтому он предоставляет адрес этого DNS-сервера. Корпоративный DNS отправляет другой DNS-запрос DNS-серверу, адрес которого был получен на предыдущем шаге, снова запрашивая разрешение имени www.exeple.com. Этот DNS-сервер, официальный сервер exemple.com, предоставляет адрес. Корпоративный DNS-сервер возвращает DNS-ответ клиенту, предоставляя IP-адрес, запрошенный на шаге 1. Передача файлов по HTTP После того, как веб-клиент (браузер) создал TCP-соединение с веб-сервером, клиент может начать запрашивать веб-страницу с сервера. Чаще всего для передачи веб-страницы используется протокол HTTP. Протокол прикладного уровня HTTP, определенный в RFC 7230, определяет, как файлы могут передаваться между двумя компьютерами. HTTP был специально создан для передачи файлов между веб-серверами и веб-клиентами. HTTP определяет несколько команд и ответов, из которых наиболее часто используется запрос HTTP GET. Чтобы получить файл с веб-сервера, клиент отправляет на сервер HTTP-запрос GET с указанием имени файла. Если сервер решает отправить файл, он отправляет ответ HTTP GET с кодом возврата 200 (что означает ОК) вместе с содержимым файла. Для HTTP-запросов существует множество кодов возврата. Например, если на сервере нет запрошенного файла, он выдает код возврата 404, что означает "файл не найден". Большинство веб-браузеров не показывают конкретные числовые коды возврата HTTP, вместо этого отображая ответ, такой как "страница не найдена", в ответ на получение кода возврата 404. Веб-страницы обычно состоят из нескольких файлов, называемых объектами. Большинство веб-страниц содержат текст, а также несколько графических изображений, анимированную рекламу и, возможно, видео и звук. Каждый из этих компонентов хранится как отдельный объект (файл) на веб-сервере. Чтобы получить их все, веб-браузер получает первый файл. Этот файл может (и обычно делает) включать ссылки на другие URI, поэтому браузер затем также запрашивает другие объекты. На рисунке 14 показана общая идея, когда браузер получает первый файл, а затем два других. В этом случае, после того, как веб-браузер получает первый файл - тот, который в URI называется "/go/ccna", браузер читает и интерпретирует этот файл. Помимо частей веб-страницы, файл ссылается на два других файла, поэтому браузер выдает два дополнительных запроса HTTP GET. Обратите внимание, что, даже если это не показано на рисунке, все эти команды проходят через одно (или, возможно, несколько) TCP-соединение между клиентом и сервером. Это означает, что TCP обеспечит исправление ошибок, гарантируя доставку данных. Как принимающий хост определяет правильное принимающее приложение Эта лекция завершается обсуждением процесса, с помощью которого хост при получении любого сообщения по любой сети может решить, какая из множества своих прикладных программ должна обрабатывать полученные данные. В качестве примера рассмотрим хост A, показанный слева на рисунке 15. На хосте открыто три разных окна веб-браузера, каждое из которых использует уникальный TCP-порт. На хосте A также открыт почтовый клиент и окно чата, оба из которых используют TCP. И электронная почта, и чат-приложения используют уникальный номер TCP-порта на хосте A, как показано на рисунке. В этой части лекции показано несколько примеров того, как протоколы транспортного уровня используют поле номера порта назначения в заголовке TCP или UDP для идентификации принимающего приложения. Например, если значение TCP-порта назначения на рисунке 15 равно 49124, хост A будет знать, что данные предназначены для первого из трех окон веб-браузера. Прежде чем принимающий хост сможет проверить заголовок TCP или UDP и найти поле порта назначения, он должен сначала обработать внешние заголовки в сообщении. Если входящее сообщение представляет собой кадр Ethernet, который инкапсулирует пакет IPv4, заголовки выглядят так, как показано на рисунке 16. Принимающему узлу необходимо просмотреть несколько полей, по одному на заголовок, чтобы идентифицировать следующий заголовок или поле в полученном сообщении. Например, хост A использует сетевой адаптер Ethernet для подключения к сети, поэтому полученное сообщение представляет собой кадр Ethernet. Поле типа Ethernet определяет тип заголовка, который следует за заголовком Ethernet - в данном случае со значением шестнадцатеричного значения 0800, заголовком IPv4. Заголовок IPv4 имеет аналогичное поле, называемое полем протокола IP. Поле протокола IPv4 имеет стандартный список значений, которые идентифицируют следующий заголовок, с десятичным числом 6, используемым для TCP, и десятичным числом 17, используемым для UDP. В этом случае значение 6 определяет заголовок TCP, следующий за заголовком IPv4. Как только принимающий хост понимает, что заголовок TCP существует, он может обработать поле порта назначения, чтобы определить, какой процесс локального приложения должен получить данные. Теперь вас ждет материал про списки управления доступом IPv4
img
Сегодня, в этой статье, вы узнаете, как формируются соседства BGP внутри автономной системы, между автономными системами и даже между маршрутизаторами, которые не связаны напрямую. Кроме того, мы рассмотрим аутентификацию BGP. Предыдущие статьи цикла про BGP: Основы протокола BGP Построение маршрута протоколом BGP Видео: Основы BGP за 7 минут BGP-пиринг Учитывая, что BGP является протоколом маршрутизации AS-to-AS, вполне логично, что внешний BGP (т.е. eBGP) является ключевым компонентом в его операциях. Самое первое, что нам нужно учитывать при работе с eBGP, - это то, что стандарты построены таким образом, что требуется прямое подключение. Это требование конечно можно обойти, но этот момент необходимо рассмотреть. Поскольку предполагается прямое соединение, протокол BGP выполняет две вещи: Он будет проверять значение времени жизни (TTL), и что значение time-to-live установлено в 1. Это означает прямую связь между одноранговыми узлами EBGP. Осуществляется проверка, что два устройства находятся в одной подсети. Еще один важный момент рассмотрения пирингов eBGP - это TCP-порты, которые будут использоваться. Это особенно важно для конфигураций брандмауэров, которые защищают автономные системы. Первый спикер BGP, который инициирует изменения состояния, приходящие по мере формирования соседства, будет получать трафик из случайного TCP-порта, а конечным портом будет TCP-порт 179. Отвечающий спикер BGP будет получать трафик с TCP-порта 179, а порт назначения будет случайным портом. Брандмауэры должны быть перенастроены с учетом изменений в коммуникации. На основе этих изменений спикер BGP инициирует сеанс, и это, вносит изменения для будущего сеанса. Некоторые администраторы даже создают механизмы для обеспечения того, чтобы сформированные пиринги были получены из известного направления. А как насчет IPv6? Ну, как было сказано ранее в предыдущей статье, BGP очень гибок и работает с IPv6, поскольку протокол был изначально спроектирован с учетом IPv6. Вы можете формировать пиринги eBGP (и iBGP) с использованием IPv6- адресации, даже если вы используются префиксы IPv4 для информации о достижимости сетевого уровня. Чтобы сформировать в нашей сети пиринг eBGP, необходимо выполнить следующие действия: Запустите процесс маршрутизации для BGP и укажите локальный AS (router bgp local_as_number). Предоставить удаленному спикеру eBGP IP- адрес и удаленному AS номер (neighbor ip-_of_neighbor remote-as remote_as_number). Пример 1 демонстрирует конфигурацию и проверку EBGP пиринга между маршрутизаторами TPA1 и ATL. Пример 1: Настройка пиринга eBGP ATL#conf t Enter configuration commands, one per line. End with CNTL/Z. ATL(config)#router bgp 220 ATL(config-router)#neighbor 30.30.30.1 remote-as 110 ATL(config-router)#end ATL# TPAl#conf t Enter configuration commands, one per line. End with CNTL/Z. TPA1(config)router bgp 110 TPA1(config-router)#neighbor 30.30.30.2 remote-as 220 TPA1(config-router)#end TPA1# TPAl#show ip bgp summary BGP router identifier 30.30.30.1, local AS number 110 BGP table version is 4, main routing table version 4 1 network entries using 120 bytes of memory 1 path entries using 52 bytes of memory 1/1 BGP path/bestpath attribute entries using 124 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 320 total bytes of memory BGP activity 2/1 prefixes, 2/1 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 30.30.30.2 4 220 413 414 4 0 0 06:12:46 1 TPA1# Примечание: чтобы облегчить понимание BGP, вы можете включить функцию debug ip bgp, при настройке пиринга. Это позволит увидеть переходные состояния в соседстве. Кроме того, чтобы получить больше информации о соседствах, вы можете использовать команду show ip bgp neighbors. Создание eBGP пиринга, на основе IPv6, выполняется также очень просто, как и на основе IPv4. Единственное изменение заключается в том, что мы заменяем адресацию в IPv4 на IPv6 и активируем соседство. Семейства адресов в маршрутизаторах Cisco для BGP позволяют запускать множество различных схем информирования о достижимости сетевого уровня (NLRI) в рамках одного и того же общего процесса BGP. Пример 2 демонстрирует подход к пирингу IPv6. Пример 2: конфигурация пиринга EBGP с использованием IPv6 ATL#conf t Enter configuration commands, one per line. End with CNTL/Z. ATL(config)#router bgp 220 ATL(config-router)#neighbor 2201:1212:1212::2 remote-as 110 ATL(config-router-af)#neighbor 2201:1212:1212::2 activate ATL(config-router-af)#end ATL# iBGP-пиринг Если вы внимательно посмотрите на топологию, вы можете заметить, что что-то выглядит необычно. Видно, что есть iBGP-пиринг. Почему существует пиринг iBGP, созданный между TPA1 и TPA2? Это выглядит совершенно неуместно. В данном случае, как говорится, внешность может быть обманчива. Главное, что вы должны усвоить относительно BGP, является тот факт, что существует нечто, называемое правилом разделения горизонта (Split Horizon Rule) iBGP. Это правило гласит, что ни один спикер iBGP не может принять обновление и затем отправить это же обновление другому узлу iBGP. Так же в требовании говориться, о полном объединении наших спикеров iBGP для обеспечения полной осведомленности о префиксах. Еще одним важным аспектом, связанным с iBGP, является избыточность. Мы хотим установить несколько физических связей между устройствами, но что произойдет, если связь, используемая для BGP, прервется? Как мы автоматически переключимся к пирингу, используя альтернативное подключение? Простой способ решить эту проблему заключается в реализации loopback-адресов и использовании этих адресов для однорангового соединения. Это то, что мы часто делаем с нашими пирингами BGP, и это может потребовать, дополнительной настройки при использовании подключения к провайдеру. Например, в Cisco мы должны специально указать, что источником пиринга является loopback IP- адрес. Примечание: еще одним важным аспектом при пиринге между петлевыми адресами в iBGP является то, что loopback-адреса фактически доступны между спикерами BGP. Именно здесь очень удобно использовать протокол внутреннего шлюза (IGP), такой как OSPF или EIGRP. Пример 3 показывает конфигурацию пиринга iBGP между устройствами TPA и TPA1. Обратите внимание, что мы используем петлевой подход в том случае, если мы хотим добавить избыточные связи между устройствами в будущем. Пример 3: Настройка пиринга iBGP TPA#conf t Enter configuration commands, one per line. End with CNTL/Z. TPA(config)router bgp 110 TPA(config-router)#neighbor 8.8.8.8 remote-as 110 TPA(config-router)#neighbor 8.8.8.8 update-source loopbackO TPA(config-router)#end TPA# TPAl#conf t Enter configuration commands, one per line. End with CNTL/Z. TPA1(config)#router bgp 110 TPA1(config-router)#neighbor 5.5.5.5 remote-as 110 TPA1(config-router)#neighbor 5.5.5.5 update-source loopbackO TPA1(config-router)#end TPA1# eBGP Multihop В разделе eBGP-пиринг этой статьи, обсуждалось, что ваши соседи будут связаны напрямую. В разделе iBGP мы обсуждали преимущество пиринга между loopback для избыточности. Теперь пришло время ответить на вопрос: Что делать, если ваши спикеры eBGP не подключены напрямую? На самом деле, если мы хотим пиринговать между loopback с eBGP, чтобы воспользоваться потенциальной избыточностью. Как сделать это, поскольку интерфейсы loopback не связаны напрямую друг с другом? BGP решает эту проблему с помощью опции eBGP multihop. С помощью настройки eBGP multihop вы указываете максимальное количество допустимых прыжков. Это пропускает проверку BGP для TTL на значение равное 1, рассмотренное ранее в этой статье. Но как насчет требования прямого подключения? BGP отключает эту проверку в фоновом режиме автоматически, при использовании функции eBGP multihop. Пример 4 демонстрирует настройку eBGP multihop между TPA1 и ATL. Здесь нужен multihop, потому что мы настраиваем пиринг между loopback устройств. Пример 4: eBGP Multihop ATL#conf t Enter configuration commands, one per line. End with CNTL/Z. ATL(config)#router bgp 220 ATL(config-router)#neighbor 8.8.8.8 remote-as 110 ATL(config-router)#neighbor 8.8.8.8 update-source loopbackO ATL(config-router)#neighbor 8.8.8.8 ebgp-multihop 2 ATL(config-router)#end ATL# TPAl#conf t Enter configuration commands, one per line. End with CNTL/Z. TPA1(config)router bgp 110 TPA1(config-router)#neighbor 7.7.7.7 remote-as 220 TPA1(config-router)#neighbor 7.7.7.7 update-source loopbackO TPA1(config-router)#neighbor 7.7.7.7 ebgp-multihop 2 TPA1(config-router)#end TPA1# BGP аутентификация Большинство организаций сегодня добавляют аутентификацию в свои настройки BGP, чтобы защитить их от различного рода атак. По общему признанию, аутентификацию немного сложнее настроить на BGP, чем с на других протоколах маршрутизации, поскольку конфигурация — пирингов- это ручной процесс, который должен выполнен на обоих устройствах. Даже с учетом вышесказанного, аутентификация устройств (eBGP или даже iBGP) - отличная идея. В Cisco настройка аутентификации осуществляется просто. Необходимо задать пароль (т.е. общий секрет) на каждое устройство, настроенное для пиринга. Обязательно усвойте, что этот пароль будет отображаться в открытом виде (по умолчанию) внутри вашей сети. Можно использовать команду service password-encryption для выполнения по крайней мере простого шифрования тех незашифрованных текстовых паролей, которые появляются в конфигурации маршрутизатора. Аутентификация с шифрованием Message Digest 5 (MD5) – это результат простого задания пароля на устройствах. Пример 5 отображает аутентификацию, добавленную в конфигурации для TPA1 и ATL. Пример 5. Настройка аутентификации для BGP-пиринга ATL#conf t Enter configuration commands, one per line. End with CNTL/Z. ATL(config)#router bgp 220 ATL(config-router)#neighbor 8.8.8.8 remote-as 110 ATL(config-router)#neighbor 8.8.8.8 update-source loopbackO ATL(config-router)#neighbor 8.8.8.8 ebgp-multihop 2 ATL(config-router)#neighbor 8.8.8.8 password MySuperSecret121 ATL(config-router)#end ATL# TPAl#conf t Enter configuration commands, one per line. End with CNTL/Z. TPA1(config)router bgp 110 TPA1(config-router)#neighbor 7.7.7.7 remote-as 220 TPA1(config-router)#neighbor 7.7.7.7 update-source loopbackO TPA1(config-router)#neighbor 7.7.7.7 ebgp-multihop 2 ATL(config-router)#neighbor 7.7.7.7 password MySuperSecret121 TPA1(config-router)#end TPA1#
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59