Кластер межсетевых экранов это

Обновлено: 01.07.2024

Возможности межсетевого экрана в Proxmox VE обеспечивают исключительное средство усиления безопасности в пределах виртуальной среды. Межсетевой экран строится на основе твердо установившейся технологии сетевой фильтрации ( netfilter ) на основе Linux. Сетевая фильтрация основывается на инфраструктуре фильтрации пакетов, в которой сетевые пакеты данных допускаются или отвергаются на основании множества установленных правил. Все правила определяются в табличных структурах в iptables .

Свойством межсетевого экрана в Proxmox также является отслеживание состояния в брандмауэре. Межсетевой экран с отслеживанием состояния не только фильтрует пакеты, но также постоянно поддерживает отслеживание состояние активных соединений, таких как протоколы TCP или UDP. Он также известен возможностью динамической фильтрации пакетов, которая проверяет соответствие правилам брандмауэра в характере активных соединений, обеспечивая лучшую защиту, чем простая фильтрация пакетов.

Межсетевой экран Proxmox работает распределенным образом, причем основные настройки расположены в файловой системе кластера Proxmox, в то время как правила в iptables хранятся индивидуально в узлах Proxmox. Это обеспечивает изоляцию между виртуальными машинами, тем самым предоставляя большую пропускную способность чем в случае с централизованными параметрами межсетевого экрана.

Межсетевой экран Proxmox может быть настроен как посредством графического интерфейса Proxmox, так и через интерфейс командной строки. Графический интерфейс Proxmox предоставляет очень простую, дружественную пользователю среду для управления настройками брандмауэра.

Отметим, что хотя межсетевой экран Proxmox и обеспечивает исключительную защиту, вы должны иметь физический межсетевой экран для всей сети. Такой брандмауэр также называется межсетевым экраном контура ( edge firewall ), поскольку он располагается в основной входной точке интернета. Интернет- соединение не должно напрямую соединяться с узлами Proxmox. Виртуальный межсетевой экран не должен применяться в качестве замены физического межсетевого экрана.

В Proxmox мы можем установить межсетевой экран для всего уровня кластера, для уровней определенных узлов, а также для каждой виртуальной машины. Меню межсетевого экрана доступно для центра данных, узла, а также для зависимых от виртуальных машин закладок меню. Зарегистрируйтесь в графическом интерфейсе Proxmox, затем выберите в левой колонке навигации элемент, например, Datacenter , узел Proxmox или виртуальную машину, для отображения меню с закладками. Следующий экранный снимок показывает меню Firewall для Datacenter :

Для настройки межсетевого экрана в интерфейсе командной строки существуют некоторые файлы настроек подлежащие редактированию. Вот местоположения для файлов настроек межсетевого экрана для установок брандмауэра центра данных, узла и виртуальных машин:

Практически нет информации о том, как и какой архитектурный подход выбрать при проектировании и внедрении межсетевых экранов для обеспечения всесторонней безопасности. Данная статья является попыткой заполнить этот пробел.

ведущий эксперт группы компаний Angara

Аннотация

На просторах Интернета можно найти много статей со спорами об отличиях решений NGFW и UTM, описывающих возможности, преимущества, производительность и настройки того или иного межсетевого экрана и сравнивающих разные межсетевые экраны между собой. Но практически нет информации о том, как и какой архитектурный подход выбрать при проектировании и внедрении межсетевых экранов для обеспечения всесторонней безопасности. Данная статья является попыткой заполнить этот пробел.

Архитектурные подходы будут приведены в терминах и определениях оборудования Palo Alto Networks, но в целом будут применимы и при использовании межсетевых экранов других производителей. На момент написания статьи NGFW Palo Alto признаны одними из лучших в мире по данным отчетов Gartner Magic Quadrant for Network Firewalls от 17 сентября 2019 г. и NSS LABS Next Generation Firewall Comparative Report: Security от 17 июля 2019 г.

Будут рассмотрены различные варианты обеспечения информационной безопасности как в крупных, так и в небольших организациях с использованием межсетевых экранов:

- на границе сети Интернет;

- в ядре центра обработки данных, локальной сети и выделенного сегмента управления инфраструктуры ИТ;

- на границе зон ответственности и в качестве решения IDS;

- для обеспечения микросегментации в программно-определяемых сетях;

- как решение защиты облачных сред, в виде облачного сервиса и в качестве решения SD-WAN.

Постараемся каждый выбор архитектурного решения обосновать конкретными причинами, с указанием основных «за» и «против», привести примеры из реальной жизни и показать лучшие практики использования.

Все используемые схемы приведены с точки зрения сетевого уровня (L3), т.е. коммутация оборудования (L2 и L1) остается за рамками статьи. Каждая из рекомендуемых архитектур обеспечения информационной безопасности учитывает основные критерии качественного проектирования: масштабируемость (Scalability), удобство в управлении (Manageability) и доступность (Availability).

Классика не стареет

Для защиты сети корпоративной от угроз сети Интернет используют два подхода. Для крупных и средних организаций рекомендуемым является использование следующей схемы: два ISP – своя eBGP AS и PI подсеть адресов – пара граничных роутеров – кластер межсетевых экранов в режиме Active / Passive – сегменты корпоративной сети LAN, DMZ и другие.

Данный подход позволяет:

- разделить зону ответственности между каналообразующим оборудованием и оборудованием обеспечения безопасности;

- обеспечить маршрутизацию с сетью Интернет средствами высокопроизводительных маршрутизаторов, при необходимости поддерживающих Full view BGP;

- отфильтровать неиспользуемые порты и протоколы (SSH, Telnet, RDP, SNMP и т.д.) на самой крайней точке сети;

- применить лучшие практики в части ограничений в соответствии с RFC 3330, 6890, 2827, 5737 и 1918, что позволит заблокировать нелегитимный трафик до попадания на межсетевой экран.

Для небольших организаций более предпочтительным будет использование следующей схемы: два ISP – кластер межсетевых экранов в режиме Active / Passive – сегменты корпоративной сети LAN и DMZ.

Данный подход позволяет:

- распределить нагрузку на каналы связи между провайдерами, опубликовав разные сервисы на разных интерфейсах и используя функционал PBF либо ECMP;

- использовать разделение граничных интерфейсов на зоны безопасности в зависимости от типа трафика.

На самом межсетевом экране при любом из данных подходов должны быть задействованы все возможные средства обеспечения всесторонней безопасности:

- Threat Prevention – Antivirus, Vulnerability protection (anti-malware, IPS) и Anti-spyware (command-and-control, DNS security);

- Application-identification и User-identification;

- SSL/TLS decryption совместно с URL filtering, File blocking и Credential Phishing Prevention.

Также должна использоваться модель Zero Trust Security, и должно быть включено логирование. Хорошей практикой будет обновлять Antivirus раз в сутки, а остальные модули Threat Prevention – не реже двух раз в неделю. Рекомендуется по максимуму задействовать возможности Application-identification средств межсетевого экрана при написании правил безопасности, минимизируя этим использование в правилах TCP/UDP-портов и разрешив приложениям взаимодействовать только по их стандартным протоколам, а также User-identification, предоставляя доступ к определенным ресурсам только конкретным пользователям. User-identification поддерживает интеграцию с популярными пользовательскими репозиториями (Microsoft Exchange Server, Novell eDirectory, Microsoft AD) и серверами удаленного доступа (Citrix XenApp, Microsoft Terminal Services), а также XML API для интеграции со сторонними пользовательскими репозиториями (прокси, беспроводное оборудование и т.д.).

Для возможности расшифровки web-сервисов Google потребуется заблокировать приложение QUIC. В части File blocking необходимо, как минимум, запретить скачивать исполняемые файлы всем пользователям, кроме сотрудников департамента информационных технологий.

Защита от фишинга учетных данных (Credential Phishing Prevention) работает путем сканирования представленных на веб-сайтах имен пользователей и паролей и сравнения этих представлений с действительными корпоративными учетными данными. Необходимо выбрать, для каких веб-сайтов вы хотите разрешить или заблокировать отправку корпоративных учетных данных, в зависимости от категории URL-адреса веб-сайта.

Хотя использование модели Zero Trust Security предполагает запрет всего, кроме того, что явно разрешено, даже в этом случае правильным подходом будет сделать явные запрещающие правила для приложений торрентов и облачных хранилищ, удаленного доступа и VPN, игровых сервисов и порно, прокси, анонимайзеров и т.п. Также рекомендуется запретить обращаться к DNS в Интернете всем, кроме ваших внутренних DNS-серверов.

Логирование рекомендуется включать в конце сессии для всех разрешающих правил, кроме отдельно выделенного правила для DNS-запросов (нет смысла нагружать процессор логами DNS). В то же время функцию DNS Sinkholing для перенаправления подозрительных DNS-запросов, напротив, включить стоит. Это поможет выявлять зараженные хосты по логам трафика. Также полезным для целей отладки и мониторинга будет записывать в лог все события по последнему запрещающему правилу, если, конечно, производительности устройства хватает для этой задачи.

Для целей удаленного доступа пользователей к корпоративной сети посредством VPN рекомендуется:

- выделить различные точки терминации и пулы IP-адресов для разных типов пользователей;

- включить поддержку IPSec в настройках подключения, так как протокол SSL менее производительный;

- использовать возможности User-identification и Time-scheduling для разграничения доступа с учетом принадлежности к группам в MS Active Directory и согласованных периодов времени удаленной работы;

- настроить профилирование удаленных хостов согласно Compliance (наличие антивируса, патчей операционных систем и т.д.) и соответствующих правил безопасности.

В направлении Интернета рекомендуется запретить все версии протокола SMB и доступ из принтерных, телефонных и прочих подобных систем.

На темной стороне

В ядре центра обработки данных, локальной сети и выделенного сегмента управления инфраструктуры ИТ для обеспечения безопасного взаимодействия вычислительных ресурсов рекомендуется использовать подход, основанный на разделении серверов и пользователей по группам принадлежности к определенным подсистемам и подразделениям. В ядре центра обработки данных рекомендуемым является использование следующей схемы: роутеры зоны обмена маршрутной информации – кластер межсетевых экранов в режиме Active / Passive – виртуальные роутеры – серверные сегменты.

Данный подход позволяет:

- разделить на уровне маршрутизации потоки трафика различных серверных подсистем;

- обеспечить безопасное взаимодействие серверов различных подсистем между собой и с внешними по отношению к центру обработки данных ресурсами.

В ядре локальной сети рекомендуемым является использование следующей схемы: роутеры зоны обмена маршрутной информацией – кластер межсетевых экранов в режиме Active / Passive – виртуальные роутеры – пользовательские сегменты.

Данный подход позволяет:

- разделить на уровне маршрутизации потоки трафика различных подразделений пользователей;

- обеспечить безопасное взаимодействие подразделений пользователей между собой и с внешними по отношению к локальной сети ресурсами;

- изолировать гостевой Wi-Fi от корпоративной сети.

Важным моментом в обеспечении всесторонней безопасности также является ограничение доступа в сеть управления инфраструктурой ИТ по следующей схеме: роутеры зоны обмена маршрутной информации – кластер межсетевых экранов в режиме Active / Passive – виртуальные роутеры – сегменты управления.

Данный подход позволяет:

- разделить на уровне маршрутизации потоки трафика различных сегментов управления;

- исключить взаимодействие сегментов управления между собой;

- ограничить доступ в сегмент управления только из сетей администраторов инфраструктуры и управляющих серверов.

Межсетевой экран в ядре сети должен использовать средства обеспечения всесторонней безопасности такие, как Threat Prevention и Application-identification. Рекомендуется использовать разные политики Threat Prevention для разных сегментов сети. Также, если нет каких-либо особых приложений, хорошей практикой будет изменить правило по умолчанию для IntraZone-трафика с «Allow» на «Drop» и логировать в конце сессии.

В центре обработки данных хорошей практикой будет отключение инспекции ответа сервера (DSRI), поскольку в подавляющем большинстве случае трафик от внутренних серверов компании не содержит вредоносного кода. Да и сниженная в результате инспекции скорость передачи трафика от серверов к пользователям будет вызывать постоянный поток негативных отзывов.

В локальной сети и сети управления будет полезным для написания правил безопасности использовать возможности User-identification, разрешая и запрещая потоки трафика не по IP-адресам сетей, а по группам пользователей, полученным из MS Active Directory.

В ядре, также, как и на ее границе рекомендуется использовать подход Zero Trust Security, но, к сожалению, в реальности данный подход для потоков трафика в ядре довольно трудно претворить в жизнь. Поэтому минимальной в части правил безопасности в ядре рекомендацией, кроме явно прописанных запрещающих правил для трафика между определенными подразделениями и подсистемами, будет:

- запрет таких приложений, как smbv1 и Telnet;

- минимизация разрешений для приложений передачи файлов smbv2 и smbv3 (разрешать только в направлении файловых серверов);

- минимизация разрешений для протоколов удаленного доступа (RDP, VNC, SSH);

- минимизация разрешений для сервисов аутентификации (TACACS, RADIUS);

Разделяй и властвуй

Рассмотрим ситуацию, когда межсетевые экраны являются точкой обмена трафика между дружественными и не очень компаниями (при слияниях, поглощениях, обеспечении связности с регулирующими, вышестоящими и т.п. организациями) и одновременно выполняют функцию обеспечения выхода в Интернет. В этом случае для обеспечения всесторонней безопасности, кроме использования подхода Zero Trust Security в связке со средствами Threat Prevention и Application-identification, очень важным будет применение сегментирования межсетевого экрана на виртуальные роутеры (virtual routing and forwarding) или даже на виртуальные системы (virtual system).

В этом случае для передачи трафика между сегментами не используют маршрут по умолчанию, а с помощью статической или динамической маршрутизации разрешают взаимодействие только по конкретно определенным IP-сетям. Аналогичный подход рекомендуется использовать и в случае, когда межсетевые экраны ядра отделяют технологическую сеть производственной инфраструктуры (интернет вещей, АСУТП, КИИ и т.п.) от локальной сети предприятия.

Если же присутствует необходимость в обеспечении централизованного выхода в Интернет через межсетевой экран головного офиса в условиях, когда дочерняя структура подключена к головной посредством арендуемого сервиса MPLS или другого решения, не позволяющего передать маршрут по умолчанию, то для решения подобной задачи рекомендуется использовать возможности протокола GRE. Построение туннеля поверх арендуемого сервиса позволит анонсировать любые необходимы маршруты, в том числе и маршрут по умолчанию.

Рассмотрим, каким образом обеспечить всестороннюю безопасность при использовании современных подходов к построению распределенных сетей передачи данных: два географически распределенных дата-центра – растянутая между ними сеть L2 («по старинке» или VxLAN) – роутеры зоны обмена маршрутной информации – межсетевые экраны – граничные роутеры – офисы.

В данном случае нет единственно верного подхода, но есть список рекомендаций к архитектуре в условиях тех или иных исходных данных.

В случае если позволяет бюджет, и потоки трафика с точки зрения маршрутизации не предполагают асимметрии, в каждом из дата-центров рекомендуется установить по кластеру межсетевых экранов в режиме Active / Passive. Для обмена маршрутной информации на межсетевых экранах использовать BGP / OSPF в связке с протоколом BFD для максимально быстрого переключения маршрутизации при авариях.

Если необходимо встроить межсетевые экраны в текущую инфраструктуру без внесения изменения в маршрутизацию, хорошим вариантом будет использовать их в прозрачном режиме Virtual Wire, минусом которого является исключение межсетевых экранов из вывода команд типа «traceroute», что, в некоторых случаях, может усложнить поиск проблем. Если же асимметрия возможна, то вынужденной мерой для обеспечения передачи трафика будет добавление явных разрешающих правил в обоих направлениях (от клиента к серверу и обратно), а также отключение проверок TCP sanity (tcp asymmetric-path bypass и session tcp-reject-non-syn no).

Если же бюджета не достаточно, можно использовать по одному межсетевому экрану в дата-центрах:

- В режиме Virtual Wire Standalone Active или BGP / OSPF Standalone Active – если не смущают ограничения, указанные выше, и то, что в этом случае отсутствие синхронизации сессий между межсетевыми экранами приведет к разрыву соединений при переходе трафика между ЦОД в случае аварии.

- В режиме Virtual Wire или BGP / OSPF Active / Passive. Для этого потребуется обеспечить связность между межсетевыми экранами для High availability. Несмотря на то, что синхронизация сессий между нодами в указанном режиме имеется, Passive нода не обеспечивает связности для маршрутизации, поэтому при аварии возможны разрывы во время передачи данных таких протоколов, как FTP и SMB.

- В режиме Virtual Wire или BGP / OSPF Active / Active, что потребует не только связности между межсетевыми экранами для High availability, но и отдельного высокоскоростного канала для передачи трафика между нодами во время установки сессии и инспекции асимметричных потоков. Также необходимо глубокое понимание работы режима Active / Active межсетевого экрана.

Отдельно стоит описать возможность использования межсетевого экрана в качестве решения детектирования атак IDS out-of-band. В этом случае трафик с необходимых портов, посредством технологии SPAN или средствами пакетного брокера, перенаправляется на TAP-порты межсетевого экрана.

Это позволяет как провести проверку на угрозы безопасности при помощи средства Threat Prevention, так и показать содержимое туннелей GRE и VxLAN без необходимости внесения изменений в текущую сетевую инфраструктуру. Кроме этого, пакетный брокер в связке с межсетевым экраном позволяет решить и многие другие архитектурные проблемы всесторонней безопасности:

- Bypass Protection – межсетевые экраны могут использовать функциональность пакетного брокера для обеспечения защиты трафика в случае выхода оборудования из строя, обеспечивая резервирование «n+1»;

- Asymmetric Routing Management – пакетный брокер предоставляет эффективную возможность направлять асимметричный трафик на межсетевой экран, который этот трафик должен проинспектировать в обоих направлениях;

- Traffic Distribution – распределение трафика между несколькими межсетевыми экранами, что позволяет эффективно использовать имеющиеся мощности;

- Traffic Filtering – перенаправление только необходимого для инспекции трафика на межсетевой экран;

- Agile Deployment – добавление, удаление и обновление межсетевых экранов, а также преобразование out-of-band мониторинга в средство in-line-инспектирования «на лету», без влияния на прохождение трафика;

- Traffic Aggregation – эффективная утилизация портов межсетевого экрана посредством объединения нескольких низкоскоростных каналов в один для дальнейшей инспекции.

Заключение

В первой части статьи описаны подходы к обеспечению всесторонней безопасности с использованием межсетевых экранов:

- на границе сети Интернет;

- в ядре центра обработки данных, локальной сети и выделенного сегмента управления инфраструктуры ИТ;

- на границе зон ответственности и в качестве решения IDS.

Во второй, заключительной части статьи будут рассмотрены лучшие практики проектирования архитектуры для обеспечения информационной безопасности при помощи межсетевых экранов:

- в качестве решения по микросегментации в программно-определяемых сетях;

- при защите облачных сред, в виде облачного сервиса и в качестве решения SD-WAN.

Также будут рассмотрены критерии выбора межсетевых экранов и лучшие практики по настройке и аудиту сервисов безопасности.

Traffic Inspector Next Generation поддерживает работу в режиме отказоустойчивого кластера / кластера высокой доступности (Failover Cluster / High Availability Cluster). В данном режиме несколько хостов объединяются в кластер. В каждый момент времени, только одно устройство в кластере (мастер-устройство) обрабатывает весь трафик пользователей. Подчиненные (резервные) устройства постоянно синхронизируют свое состояние с мастер-устройством. Если мастер-устройство выходит из строя, его подменяет одно из резервных устройств, которое само становится мастером. Новый мастер способен прозрачно подхватить и продолжить обработку сетевых потоков от клиентов. В случае, если старый мастер вновь переходит в рабочее состояние, то текущий мастер возвращается в статус подчиненного резервного устройства.

Режим отказоустойчивого кластера / кластера высокой доступности обеспечивает непрерывность доступа пользователей к сети Интернет.

Функционал кластеризации реализован на базе нескольких технологий: СARP, PFSYNC, XMLRPC Sync.

CARP (Common Address Redundancy Protocol)

CARP (Common Address Redundancy Protocol) - технология и сетевой протокол, обеспечивающий возможность нескольким хостам, подключенным в один и тот же LAN-сегмент, использовать один и тот же общий виртуальный IP-адрес. CARP определяет, какое из устройств группы должно обрабатывать трафик для виртуального IP-адреса в данный момент. Если мастер-устройство не может выполнять свои функции, то ответственным за виртуальный IP-адрес становится другое устройство группы.

CARP - свободная реализацией протокола VRRP (Virtual Router Redundancy Protocol).

В процессе настройки CARP, на каждом хосте добавляется общий совместно используемый виртуальный IP-адрес. Для виртуального IP-адреса указываются специфичные для CARP-технологии параметры - VHID, advbase, advskew, пароль.

Параметр VHID (Virtual Host ID) уникально идентифицирует несколько хостов, подключенных в один и тот же LAN-сегмент. На данных машинах настраивается один и тот же VHID. Допускается значение от 1 до 255.

Для определения, какой из резервных хостов подменит мастер-устройство в случае его выхода из строя, хосты имеют настроенный параметр advskew. Меньшее значение advskew означает больший приоритет - мастер-устройство в группе имеет advskew равный 0. Параметр advskew измеряется в 1/256 секунды. Допускается значение от 0 до 254.

CARP может обеспечивать общий разделяемый виртуальный IP-адрес для группы обычных серверов. Серверы, как правило, подключены к одному LAN-сегменту. В таком случае, создается одна CARP-группа, обеспечивающая один виртуальный IP-адрес.

CARP особенно актуален в контексте межсетевых экранов / маршрутизаторов. Межсетевой экран / маршрутизатор имеет подключение как минимум к двум разным LAN-сегментам. Для таких межсетевых экранов / маршрутизаторов, как правило, создают две CARP-группы - одну с LAN-стороны и вторую с WAN-стороны. Каждая группа обеспечивает виртуальный IP-адрес, а в общей сложности, обеспечиваются два виртуальных IP-адреса.

CARP-пакеты инкапсулируются в IP-пакеты и имеют идентификатор ID 112 в заголовке IP-пакета. CARP-трафик передается в открытом нешифрованном виде.

При том, что CARP обеспечивает совместно используемый виртуальный IP-адрес, он также требует, чтобы каждый хост в CARP-группе подключался к LAN-сегменту посредством физического адаптера, которому присвоен обычный, уникальный IP-адрес.

Хост в CARP-группе отсылает Ethernet-кадры с MAC-адресом источника 00:00:5E:00:XX, где XX равен идентификатору VHID CARP-группы, на мультивещательный MAC-адрес 01:00:5e:00:00:12. На уровне IP, пакеты отсылаются с IP-адреса, присвоенного физическому адаптеру, на мультивещательный IP-адрес 224.0.0.18.

CARP может использоваться самостоятельно (в случае с обычными серверами), но если стоит задача обеспечить виртуальные IP-адреса для межсетевых экранов, то дополнительно к CARP используется протокол PFSYNC.

PFSYNC

При переключении на резервный межсетевой экран нужно обеспечить, чтобы он «знал» о всех соединениях, которые обрабатывал межсетевой экран, до этого являвшийся мастер-устройством. Данные функции берет на себя протокол PFSYNC. PFSYNC - сетевой протокол для синхронизации состояния между несколькими экземплярами межсетевого экрана Packet Filter, выполняющимися на разных хостах.

PFSYNC-пакеты инкапсулируются в IP-пакеты и имеют идентификатор ID 240 в заголовке IP-пакета. PFSYNC-трафик передается в открытом нешифрованном виде.

PFSYNC включается на определенном физическом сетевом адаптере межсетевого экрана. На канальном уровне, PFSYNC-пакеты отсылаются с MAC-адреса физического адаптера, на мультивещательный MAC-адрес 01:00:5e:00:00:f0. На уровне IP, PFSYNC-пакеты отсылаются с IP-адреса, присвоенного физическому адаптеру, на мультивещательный IP-адрес 224.0.0.240.

Протокол PFSYNC редко используется самостоятельно, чаще всего он используется в связке с протоколом CARP.

XMLRPC SYNC

XMLRPC SYNC - сетевой протокол для синхронизации настроек между несколькими экземплярами шлюза Traffic Inspector Next Generation.

В рамках работы XMLRPC, мастер-устройство связывается с резервным устройством по защищенному SSL/TLS-соединению и передает выбранные настройки.

Протокол XMLRPC SYNC редко используется самостоятельно, чаще всего он используется в связке с протоколом CARP, и возможно, PFSYNC.

Схема кластера в примере

В данной инструкции описывается настройка отказоустойчивого кластера из двух устройств TING. Каждое устройство TING представляет собой межсетевой экран / маршрутизатор. Для обеспечения функционала кластера, задействуются все три технологии CARP + PFSYNC + XMLRPC SYNC.

Схема кластера приведена ниже:

В нашем примере, LAN-интерфейсы устройств TING подключены к сети 192.168.1.0/24 (это внутренняя сеть организации). WAN-интерфейсы устройств TING подключены сети 10.1.1.0/24 (это сеть, подключенная к Интернет).

На первом устройстве кластера, физическим сетевым картам назначены следующие адреса: 192.168.1.1 (LAN-интерфейс) и 10.1.1.115 (WAN-интерфейс).

На втором устройстве кластера, физическим сетевым адаптерам назначены следующие адреса: 192.168.1.2 (LAN-интерфейс) и 10.1.1.150 (WAN-интерфейс).

В процессе настройки, устройства кластера получат возможность использовать общий виртуальный IP-адрес 192.168.1.222 на LAN-стороне и общий виртуальный IP-адрес 10.1.1.222 на WAN-стороне. Для этого будут созданы две CARP-группы с VHID 1 и 3.

Обмен PFSYNC-трафиком ведется через отдельный Ethernet-кабель, который соединяет сетевой адаптер с IP-адресом 172.16.0.1 на одном устройстве с сетевым адаптером с IP-адресом 172.16.0.2 на другом устройстве.

PFSYNC передается в открытом виде. Настоятельно рекомендуем использовать отдельный Ethernet-кабель для обмена PFSYNC-трафиком между устройствами по причинам безопасности и производительности.

Настройки физических интерфейсов и их IP-адресов

У каждого хоста в кластере должены быть собственные обычные IP-адреса.

На мастер-устройстве, в разделе Интерфейсы, настройте следующие интерфейсы / IP-адреса / маски:

В терминологии компьютерных сетей балансировка (выравнивание) нагрузки – распределение процесса выполнения заданий между несколькими серверами сети с целью оптимизации использования ресурсов и сокращения времени вычисления.

Типы серверов, которые должны быть сбалансированы:

серверные кластеры;
межсетевые экраны;
серверы инспектирования содержания (такие как AntiVirus- или AntiSpam- серверы).

Обычно системы балансировки загрузки серверов используют возможности уровня L4 (UDP/TCP). При этом контролируется доступность сервера по IP-адресу и номеру порта и принимается решение: какому из доступных серверов следует переслать запрос. Наиболее часто для выбора сервера используется карусельный алгоритм (round-robin). В этом варианте предполагается, что все запросы создают одинаковую загрузку и длительность исполнения. В более продвинутых вариантах алгоритма используется уровень занятости сервера и число активных соединений.

Раньше возможности балансировки нагрузки встраивались в саму прикладную программу или операционную систему. Современные системы балансировки нагрузки должны удовлетворять следующим требованиям:

обеспечивать управление трафиком, чтобы гарантировать доступность приложения и распределение нагрузки в условиях фермы серверов (группа серверов, соединенных сетью передачи данных и работающих как единое целое);
ускорять выполнение приложений в несколько раз;
гарантировать защиту приложений, сохранность данных и обеспечение мониторинга трафика.

Здесь важно учитывать, что доступность IP-адреса и порта еще не гарантирует доступа к приложению.

В последнее время для решения задачи балансировки нагрузки все чаще используется прикладной уровень. При этом в процессе принятия решения учитывается тип клиента, запрашиваемый URL, информация из cookie, возможности конкретного сервера и тип прикладной программы, что позволяет оптимизировать использование ресурсов системы.

Довольно существенные преимущества может предоставить система GSLB (Global Server Load Balancing), которая способна решать задачу балансировки для произвольно расположенных ферм серверов с учетом их удаленности от клиента. Эта система может поддерживать несколько разных алгоритмов распределения нагрузки и обеспечивать оптимальное обслуживание клиентов, разбросанных по всему миру. Для администраторов система дает возможность формирования гибкой политики управления ресурсами.

Одним из способов ускорения обслуживания является кэширование. В случае хорошо сконфигурированного кэша доля запросов, удовлетворяемых кэшем, может достигать 40%. При этом ускорение обслуживания может быть улучшено в 30 раз.

Еще одним методом ускорения обслуживания может служить архивация данных, так как в этом варианте понижается уровень перегрузки каналов сети.

Управление балансировкой нагрузки можно совместить с функцией прикладного межсетевого экрана (70% успешных вторжений использует уязвимости приложений) и с использованием SSL по VPN-туннелю. SSL – Secure Sockets Layer – криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером.

увеличить изображение
Рис. 4.12. Балансировка нагрузки по нескольким маршрутам

В межсетевых экранах D-Link серии NetDefend предусмотрена функция, предназначенная для балансировки сетевой нагрузки по разным маршрутам – Route Load Balancing (RLB), возможности которой обеспечивают:

балансировку трафика между интерфейсами на основе политик;
балансировку нагрузки трафика при одновременном множественном доступе в Интернет, пользуясь услугами двух и более провайдеров;
балансировку трафика, проходящего через VPN-туннели, установленные на разных физических интерфейсах.

Функция балансировки нагрузки в межсетевых экранах NetDefend активируется на основе таблицы маршрутизации путем создания объекта RLB Instance, в котором определены два параметра: таблица маршрутизации и RLB-алгоритм. С таблицей маршрутизации может быть связан только один объект Instance.

увеличить изображение
Рис. 4.13. Выбор алгоритма распределения нагрузки в межсетевых экранах NetDefend

Есть возможность выбрать один из алгоритмов распределения нагрузки между Интернет-интерфейсами:

Алгоритм Round Robin распределяет нагрузку между интерфейсами WAN1 и WAN2 последовательно (поочередно). Каждый раз, когда возникает новая исходящая сессия с интерфейса LAN, выбирается интерфейс WAN1 или WAN2 для отправки пакетов. В дальнейшем, пакеты данной сессии будут использовать ранее определенный WAN-интерфейс. TCP-сессия открывается и закрывается на одном и том же WAN-интерфейсе.
Алгоритм Destination позволит избежать проблем с некоторыми протоколами при использовании балансировки, например FTP. Данный алгоритм работает аналогично алгоритму Round Robin, за исключением того, что все данные к удаленному хосту идут через тот интерфейс, через который соединение было установлено.
Значение Spillover определяет предельное значение нагрузки для основного WAN-порта (Routing → Route Load Balancing > Algoritm Setings) . При достижении этой нагрузки за указанный период начнет использоваться второй WAN-порт (для новых сессий). Как только загрузка основного канала упадет, новые сессии будут открываться на нем.

Использование метрик маршрута с алгоритмом Round Robin

Метрика каждого маршрута по умолчанию равна нулю. При использовании взаимосвязанных алгоритмов Round Robin и Destination можно устанавливать разные значения метрик, позволяющие создать приоритет выбора маршрутов. Маршруты с минимальным значением метрики будут выбираться чаще, чем маршруты с более высоким значением.

Если в сценарии с двумя Интернет-провайдерами (часто встречается выражение "ISP-провайдер", т.е. Internet Service Provider) требуется, чтобы большая часть трафика проходила через одно из ISP-подключений, то следует активировать RLB и назначить меньшее значение метрики для маршрута основного ISP-подключения (например, 90) относительно второго (например, 100).

Если задача заключается в равномерной балансировке трафика между двумя Интернет-провайдерами, то значение метрик для обоих маршрутов следует назначать одинаковое.

Использование метрик маршрута с алгоритмом Spillover

При использовании алгоритма Spillover для каждого маршрута обязательно должна быть определена метрика. В этом случае система NetDefendOS всегда выбирает маршрут с самым низким значением метрики. Алгоритм не предназначен для работы с одинаковыми метрическими значениями маршрутов, поэтому администратору следует устанавливать различные значения метрик для всех маршрутов, к которым применяется алгоритм Spillover.

Значение метрики определяет порядок, в соответствии с которым трафик перенаправляется на другой маршрут после того, как для выбранного маршрута превышено допустимое значение передаваемого трафика.

Можно создать несколько альтернативных маршрутов с различными метрическими значениями, для каждого из которых определена пороговая величина настроек алгоритма – Spillover Setting – для каждого интерфейса. Сначала выбирается маршрут с минимальной метрикой; после того как превышен допустимый порог настроек алгоритма, будет выбран следующий маршрут.

Если на всех альтернативных маршрутах достигнуты пороговые значения Spillover Setting, то маршрут не меняется.

ВНИМАНИЕ: значение метрики на интерфейсах (маршрутах), которые используются в балансировке, должно быть установлено выше, чем для остальных интерфейсов (маршрутов). Чем ниже значение метрики на интерфейсе (маршруте), тем чаще этот интерфейс (маршрут) будет использован для установки соединения, относительно интерфейса (маршрута) с большим значением метрики. Доля использования интерфейсов (маршрутов) будет пропорциональна разнице между значениями метрик на этих интерфейсах (маршрутах).

Балансировка нагрузки сети и НА-кластеризация (резервирование устройств) межсетевых экранов NetDefend

Высокий уровень сетевой отказоустойчивости достигается за счет использования двух межсетевых экранов NetDefend: основного устройства (master) и резервного устройства (slave). Основной и резервный межсетевые экраны взаимосвязаны и составляют логический HA-кластер.

Межсетевые экраны NetDefend не поддерживают балансировку нагрузки в НА-кластеризации устройств, т.е. распределение нагрузки между ними не обеспечивается, так как одно устройство всегда является активным (active), в то время как другое находится в режиме ожидания (passive).

Читайте также: