По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье рассмотрим сценарий с настройкой отказоустойчивости на маршрутизаторе Cisco с использованием двух интернет провайдеров.
При случае аварии у вашего интернет оператора отказоустойчивость с использованием двух провайдеров является очень хорошей идеей, более того – иногда без этого не обойтись. Однако, в таком сценарии часто необходимо использовать протокол маршрутизации BGP, который довольно нелегок в настройке и предъявляет высокие требования к оборудованию.
В большинстве случаев, вам необходимы две выделенных IPv4 подсети – но учтите, что покупка IPv4 блока является довольно дорогостоящей затеей. Однако, есть альтернативное и более бюджетное решение – если вам не нужна целая подсеть от провайдера, у вас может быть основной и запасной WAN каналы и использовать NAT для обоих линков с автоматическим фэйловером. Данный сценарий будет работать только для сетей, у которых есть исходящий трафик.
Описание сценария и настройка
В примере ниже мы продемонстрируем стандартную топологию – данное решение задачи будет работать во многих сценариях.
Вы все еще можете использовать BGP соединение для каждого провайдера, который анонсирует дефолтный маршрут, однако, как правило, провайдеры делают это за отдельную плату. В данной топологии мы будем использовать два плавающих статических маршрутах.
На топологии ниже у нас есть два WAN соединения (ISP1 – основной линк и ISP2 – запасной линк). Нам просто необходимо предоставить доступ в интернет для нашей внутренней подсети.
Все настройки в данной статье были выполнены на маршрутизаторе Cisco 891-K9 с двумя WAN портами и IOS версии c880data-universalk9-mz.153-3.M2.bin
Настройка маршрутизатора
Сначала настраиваем интерфейсы:
interface GigabitEthernet0
description Internet_ISP1_Main
ip address 10.10.10.10 255.255.255.0
no ip proxy-arp
ip nat outside //включаем NAT на первом интерфейсе
interface FastEthernet8
description Internet_ISP2_Back-up
ip address 100.100.100.100 255.255.255.0
no ip proxy-arp
ip nat outside //включаем NAT на втором интерфейсе
interface Vlan1
description Local_Area_Network
ip address 192.168.1.1 255.255.255.0
ip nat inside //весь сгенерированный трафик будет NATирован
Затем настраиваем ACL (лист контроля доступа) в соответствии с нашей внутренней подсетью:
ip access-list extended NAT_LAN
permit ip 192.168.1.0 0.0.0.255 any
Переходим к настройке маршрутных карт, которые будут выбирать какой трафик НАТировать на каждом интерфейсе:
route-map NAT_ISP1_Main permit 10
match ip address NAT_LAN //совпадение для настроенного прежде ACL с внутренней подсетью
match interface GigabitEthernet0 //совпадение для первого WAN интерфейса
!
route-map NAT_ISP2_Back-up permit 10
match ip address NAT_LAN //совпадение для настроенного прежде ACL с внутренней подсетью network
match interface FastEthernet8 //совпадение для второго WAN интерфейса
Настраиваем отслеживание и SLA для замены канала в случае аварии:
ip sla 1
icmp-echo 8.8.8.8 source-interface GigabitEthernet0 //пингуем DNS Гугла используя первый интерфейс
frequency 30 //пинги отправляются раз в 30 секунд
ip sla schedule 1 life forever start-time now //SLA респондер включен
track 1 ip sla 1 //“объект” для отслеживания создан с помощью IPSLA1
Добавляем маршруты по умолчанию:
ip route 0.0.0.0 0.0.0.0 10.10.10.1 track 1
ip route 0.0.0.0 0.0.0.0 100.100.100.1 30
Пока объект track 1 «поднят», первый маршрут будет указан в таблице маршрутизации. Если данный объект «упадет», то маршрут будет заменен на второй маршрут по умолчанию с метрикой 30.
Как заключительный шаг – включаем NAT:
ip nat inside source route-map NAT_ISP1_Main interface GigabitEthernet0 overload
ip nat inside source route-map NAT_ISP2_Back-up interface FastEthernet8 overload
Apache - популярный бесплатный opensource веб-сервер. Он является частью стека LAMP (Linux, Apache, MySQL, PHP), который обеспечивает большую часть Интернета. Мы уже рассказывали про его установку на Windows и сравнивали его с nginx, а сегодня расскажем про то как установить Apache на Linux.
А про то как установить nginx на Linux, можно прочитать в нашей статье.
Установка веб-сервера Apache на Linux
Установка Apache на CentOS и RHEL
Откройте окно терминала и обновите списки пакетов репозитория, введя следующее:
sudo yum update
Теперь вы можете установить Apache с помощью команды:
sudo yum –y install httpd
httpd - это имя службы Apache в CentOS. Опция –y автоматически отвечает да на запрос подтверждения.
Готово, Apache установлен.
Установка Apache на Ubuntu и Debian
В Ubuntu и Debian пакет и служба Apache называются apache2. Сначала также обновите инструмент управления пакетами apt.
sudo apt update
Теперь устанавливаем Apache:
sudo apt install apache2
Запуск и управление веб-сервером Apache
Apache - это сервис, работающий в фоновом режиме. В Debian и Ubuntu он автоматически запустится после установки, а в CentOS его нужно запустить вручную.
Не забывайте что в командах в CentOS нам нужно использовать httpd, а в Debian и Ubuntu apache2
Запустите службу Apache, введя следующее:
sudo systemctl start httpd
Система не возвращает вывод, если команда выполняется правильно.
Чтобы настроить автозагрузку Apache при запуске используйте команду:
sudo systemctl enable httpd
Чтобы проверить состояние службы Apache:
sudo systemctl status httpd
Чтобы перезагрузить Apache (перезагрузит файлы конфигурации, чтобы применить изменения):
sudo systemctl reload httpd
Чтобы перезапустить весь сервис Apache:
sudo systemctl restart httpd
Чтобы остановить Apache:
sudo systemctl stop httpd
Чтобы отключить Apache при запуске системы:
sudo systemctl disable httpd
Проверить веб-сервер Apache
Задача вашего программного обеспечения Apache - обслуживать веб-страницы по сети. Ваша новая установка Apache имеет тестовую страницу по умолчанию, но вы также можете создать собственную тестовую страницу.
Проверьте тестовую страницу Apache
В окне терминала найдите IP-адрес вашей системы:
hostname -I | awk '{print $1}'
Если вы знакомы с командами ip addr show или ifconfig, вы можете использовать их вместо этого. Подробно про команду ip можно прочитать тут.
Откройте веб-браузер и введите IP-адрес, отображаемый в выводе. Система должна показать тестовую страницу HTTP-сервера Apache, как показано на скриншоте ниже:
Или так, если у вас Ubuntu:
Если ваша система не имеет графического интерфейса, используйте команду curl:
curl [your_system's_IP_address]:80
Примечание. В конце: 80 обозначает порт 80, стандартный порт для интернет-трафика. Обязательно напишите соответствующий IP-адрес вместо [your_system's_IP_address].
Создать HTML-файл для тестирования
Если по какой-либо причине вам нужна или у вас уже есть пользовательская HTML-страница, которую вы хотите использовать в качестве тестовой страницы, выполните следующие действия:
В окне терминала создайте новый индекс файл HTML:
echo My Apache Web Server > /var/www/html/index.html
Отредактируйте файл по своему вкусу и сохраните его.
Теперь вы можете выполнить действия, описанные в предыдущем разделе, и если ваш сервер Apache работает правильно, если он отобразит указанную пользовательскую страницу.
Настройка фаервола для Apache
Фаервол в вашей системе блокирует трафик через разные порты. Каждый порт имеет свой номер, и разные виды трафика используют разные порты. Для вашего веб-сервера вам нужно разрешить HTTP и HTTPS трафик через порты 80 и 443.
В терминале введите следующее:
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload
Еще раз проверьте, правильно ли настроен ваш фаервол:
sudo firewall-cmd --list-all | grep services
Вы должны увидеть http и https в списке разрешенных сервисов.
Если вы пользуйтесь UFW, то можно открыть порты HTTP (80) и HTTPS (443), включив профиль Apache Full:
sudo ufw allow 'Apache Full'
Если вы используете nftables для фильтрации подключений к вашей системе, откройте необходимые порты, введя следующую команду:
nft add rule inet filter input tcp dport {80, 443} ct state new,established counter accept
Файлы и каталоги Apache
Apache управляется путем применения директив в файлах конфигурации:
/etc/httpd/conf/httpd.conf - основной файл конфигурации Apache
/etc/httpd/ - Расположение всех файлов конфигурации
/etc/httpd/conf.d/ - Все конфигурационные файлы в этом каталоге включены в основной файл настроек
/etc/httpd/conf.modules.d/ - Расположение конфигурационных файлов модуля Apache
Примечание. При внесении изменений в файлы конфигурации не забывайте всегда перезапускать службу Apache, чтобы применить новую конфигурацию.
Логи Apache расположены тут:
/var/log/httpd/ - расположение файлов логов Apache
/var/log/httpd/access_log - показывает журнал систем, которые обращались к серверу
var/log/httpd/error_log - показывает список любых ошибок, с которыми сталкивается Apache
Назначьте каталог для хранения файлов для вашего сайта. Используйте файлы конфигурации, чтобы указать каталог, который вы выбрали. Некоторые типичные места включают в себя:
/home/username/my_website
/var/www/my_website
/var/www/html/my_website
/opt/my_website
Сегментная маршрутизация (Segment Routing, SR) может или не может считаться туннельным решением, в зависимости от конкретной реализации и того, насколько строго вы хотите придерживаться определения туннелей, представленного ранее в статье "Виртуализация сетей". В этой статье будет рассмотрена основная концепция сегментной маршрутизации и две возможные схемы реализации: одна с использованием меток потока IPv6, а другая с использованием меток многопротокольной коммутации по меткам (Multiprotocol Label Switching -MPLS).
Каждому устройству в сети с поддержкой SR присваивается уникальная метка. Стек меток, описывающий путь в терминах этих уникальных меток, может быть присоединен к любому пакету, заставляя его принимать определенный указанный путь. Рисунок 5 демонстрирует это.
Каждый маршрутизатор на рисунке 5 объявляет IP-адрес в качестве идентификатора вместе с меткой, прикрепленной к этому IP-адресу. В SR метка, прикрепленная к идентификатору маршрутизатора, называется идентификатором сегмента узла (SID узла). Поскольку каждому маршрутизатору в сети присваивается уникальная метка, путь через сеть может быть описан с использованием только этих меток. Например:
Если вы хотите перенаправить трафик от A к K по пути [B, E, F, H], вы можете описать этот путь с помощью меток [101,104,105,107].
Если вы хотите перенаправить трафик от A к K по пути [B, D, G, H], вы можете описать этот путь с помощью меток [101,103,106,107].
Набор меток, используемых для описания пути, называется стеком меток. Между D и H есть две связи; как это можно описать? В SR доступно несколько опций, в том числе:
Стек меток может включать в себя только идентификаторы SID узла, описывающие путь через сеть в терминах маршрутизаторов, как показано ранее. В этом случае, если бы стек меток включал пару [103,107], D просто перенаправлял бы H в обычном режиме на основе информации локальной маршрутизации, поэтому он будет использовать любой локальный процесс, который он будет использовать для пересылки любого другого пакета, например, распределение нагрузки между двумя каналами для пересылки трафика с меткой SR.
Стек меток может включать явную метку для загрузки общего ресурса по любому доступному набору путей, доступных в этой точке сети.
H может назначить метку для каждого входящего интерфейса, а также SID узла, привязанный к его локальному идентификатору маршрутизатора. Эти метки будут объявляться так же, как SID узла, но, поскольку они описывают смежность, они называются SID смежности (adjacency). SID смежности уникален локально; он уникален для маршрутизатора, объявляющего сам SID смежности.
Третий вид SID, префиксный SID, описывает конкретный достижимый пункт назначения (префикс) в сети. SID узла может быть реализован как SID префикса, привязанный к loopback адресу на каждом маршрутизаторе в сети.
Не обязательно, чтобы весь путь описывался стеком меток. Например, стек меток [101,103] будет направлять трафик в B, затем в D, но затем позволит D использовать любой доступный путь для достижения IP-адреса назначения в K. Стек меток [105] обеспечит прохождение трафика через сеть к K будет проходить через F. Не имеет значения, как трафик достиг этой точки в сети и как он был перенаправлен после того, как достигнет F, если он проходит через F, будучи направленным к K.
Каждая метка в стеке представляет собой сегмент. Пакеты переносятся от метки к метке через каждый сегмент в сети, чтобы быть транспортированными от головной части пути к хвостовой части пути.
Маршрутизация сегментов с многопротокольной коммутацией меток
MPLS был изобретен как способ сочетать преимущества асинхронного режима передачи (ATM), который больше не используется широко, с IP-коммутацией. В первые дни сетевой инженерии наборы микросхем, используемые для коммутации пакетов, были более ограничены в своих возможностях, чем сейчас. Многие из используемых наборов микросхем были Field Programmable Gate Arrays (FPGA), а не Application-Specific Integrated Circuits (ASIC), поэтому длина поля, в котором коммутировался пакет, напрямую коррелировала со скоростью, с которой пакет мог коммутироваться. Часто было проще переработать пакет или обработать его дважды, чем включать в заголовок много сложной информации, чтобы пакет можно было обработать один раз.
Примечание: повторное использование пакетов по-прежнему часто используется во многих наборах микросхем для поддержки внутренних и внешних заголовков или даже для обработки различных частей более длинного и сложного заголовка пакета.
MPLS инкапсулирует исходный пакет в заголовок MPLS, который затем используется для коммутации пакета по сети. На рисунке 6 показан заголовок MPLS. Весь заголовок состоит из 32 бит, метка 20 бит. Устройство пересылки MPLS может выполнять три операции:
Текущая метка в заголовке MPLS может быть заменена другой меткой (SWAP).
В пакет можно вставить новую метку (PUSH).
Текущая метка может быть очищена, а метка под текущей меткой обработана (POP).
Операции PUSH и POP переносятся непосредственно в SR: операция SWAP реализована в SR как CONTINUE, что означает, что текущая метка заменяется той же меткой (т. е. заголовок с меткой 100 будет заменен меткой 100), и обработка этого текущего сегмента будет продолжена. Проще всего понять процесс обработки на примере. Рисунок 7 демонстрирует это.
На рисунке 7 каждому маршрутизатору присвоена глобально уникальная метка из глобального блока сегментной маршрутизации (Segment Routing Global Block -SRGB). Они объявляются через протокол маршрутизации или другую плоскость управления. Когда A получает пакет, предназначенный для N, он выбирает путь через сеть, используя некоторый локальный механизм. В этот момент:
Чтобы начать процесс, A выполнит PUSH серии заголовков MPLS на пакете, которые описывают путь через сеть, [101,103,104,202,105,106,109, 110]. Когда A коммутирует пакет в сторону B, он вставит первую метку в стек, так как нет необходимости отправлять свою собственную метку в заголовке. Стек меток на канале [A,B] будет равен [103,104,202,105,106,109,110].
Когда B получает пакет, он проверяет следующую метку в стеке. Обнаружив, что метка равна 103, он выполнит POP этой метки и перешлет пакет в D. В этом случае стек меток SR выбрал один из двух возможных путей с равной стоимостью через сеть, так что это пример выбора SR конкретного пути. Стек меток на канале [B, D] будет [104,202,105,106,109,110].
Когда D получает пакет, верхняя метка в стеке будет 104. D выполнит POP этой метки и отправит пакет в E. Стек меток на канале [D, E] будет [202,105,106,109,110].
Когда E получает этот пакет, верхняя метка в стеке - 202. Это селектор смежности, поэтому он выбирает конкретный интерфейс, а не конкретного соседа. E выберет правильный интерфейс, нижний из двух интерфейсов на рисунке, и POP этой метки. Верхняя метка теперь представляет собой SID узла для F, который можно удалить, поскольку пакет передается на F. E переработает пакет и также откроет эту POP. Стек меток на канале [E, F] будет [106,109,110].
Когда пакет достигает F, следующей меткой в стеке будет 106. Эта метка указывает, что пакет должен быть передан в G. F выполнит POP метки и передаст ее G. Стек меток на канале [F, G] будет [109,110].
Когда пакет достигает G, следующая метка в стеке - 109, что указывает на то, что пакет должен быть направлен к L. Поскольку G не соединен напрямую с L, он может использовать локальный, свободный от петель (обычно самый короткий) путь к L. В этом случае есть два пути с равной стоимостью к L, поэтому G выполнит POP метки 109 и переадресовывает по одному из этих двух путей к L. В сегменте [G, L] стек меток равен [110].
Предположим, что G решает отправить пакет через K. Когда K получает пакет, он будет иметь стек меток, содержащий [110], который не является ни локальной меткой, ни смежным узлом. В этом случае метка должна оставаться прежней, или сегмент должен иметь CONTINUE. Чтобы реализовать это, K поменяет текущую метку 110 на другую копию той же метки, так что K будет пересылать трафик с той же меткой. На канале [K,L] стек меток будет равен [110].
Когда L принимает пакет, единственной оставшейся меткой будет 110, что указывает на то, что пакет должен быть направлен в M. L будет выполнена POP метки 109, эффективно удалив всю инкапсуляцию MPLS, и перенаправит пакет в M.
Когда M получает пакет, он пересылает его, используя обычный IP-адрес, в конечный пункт назначения - N.
Концепция стека меток в MPLS реализована в виде серии заголовков MPLS, уложенных друг на друга. Pop метки означает удаление самой верхней метки, push метки означает добавление нового заголовка MPLS в пакет, а continue означает замену метки идентичной меткой. Когда вы работаете со стопкой меток, понятия внутреннего и внешнего часто сбивают с толку, особенно, поскольку многие люди используют идею метки и заголовка как взаимозаменяемые. Возможно, лучший способ уменьшить путаницу - использовать термин "заголовок" для обозначения всего стека меток и исходного заголовка, переносимого внутри MPLS, при этом обращаясь к меткам как к отдельным меткам в стеке. Тогда внутренний заголовок будет исходным заголовком пакета, а внешний заголовок будет стеком меток. Внутренняя метка будет следующей меткой в стеке в любой момент прохождения пакета по сети, а внешняя метка будет меткой, по которой пакет фактически переключается.
Хотя в приведенном здесь примере используются IP-пакеты внутри MPLS, протокол MPLS предназначен для передачи практически любого протокола, включая Ethernet. Таким образом, SR MPLS не ограничивается использованием для передачи одного типа трафика, но может также использоваться для передачи кадров Ethernet по сети на основе IP / MPLS. Это означает, что SR можно использовать для поддержки первого варианта использования, обсуждаемого в этой статье, - предоставления услуг Ethernet по IP-сети.
MPLS - это туннель?
Много написанных и произнесенных слов были пролиты на вопрос о том, является ли MPLS протоколом туннелирования. Здесь туннелирование определяется как действие, а не протокол; это намеренная попытка отделить идею протокола туннелирования от концепции туннелирования как действия, предпринимаемого при передаче трафика через сеть. В случае MPLS это означает, что он может быть, а может и не быть протоколом туннелирования, в зависимости от того, как он используется - как и любой другой протокол. Например, если у вас есть стек меток, помещенных поверх пакета с IP-заголовком, внешняя метка, на которую коммутируется пакет, не является (технически) туннелем. Этот внешний заголовок в сети MPLS фактически является локальным для сегмента, поэтому он либо выталкивается, либо отправляется на каждом маршрутизаторе. Это аналогично заголовку Ethernet для каждого канала. Однако внутренний заголовок переносится в пакете MPLS и, следовательно, технически туннелируется. Внутренняя метка не используется на текущем устройстве для коммутации пакета; он просто переносится как часть пакета.
Это определение не идеально. Например, в случае MPLS SWAP или SR CONTINUE, используется ли метка для коммутации пакета или нет? Кроме того, в отличие от заголовка Ethernet в пакете, заголовок MPLS фактически используется при принятии решения о пересылке. Заголовок Ethernet, напротив, просто используется для достижения следующего перехода, а затем отбрасывается. Возможно, более подходящим сравнением было бы следующее: Заголовок MPLS подобен заголовку Ethernet, который используется для достижения перехода за пределы устройства, на которое маршрутизатор в настоящее время передает.
Независимо от этих ограничений, этого определения обычно достаточно, чтобы мысленно управлять различием между туннелированием и не туннелированием в MPLS, а также в большинстве других протоколов.