воскресенье, 19 апреля 2009 г.

Solaris, multihomed-хосты и IPFilter

Задача конфигурирования для Solaris 10 multihomed-хоста (оконечного сервера, подключенного в две сети) неожиданно оказалась более сложной, чем описывается.

Речь идет о машине, являющейся оконечным сервером. Не роутером, не форвардером. А просто концевой машиной, включенной в две или более сети.

В теории все гладко. Гладко настолько, что в мануалах оказалось даже недостойно существенного упоминания**. Я умолчу о том, что в мануалах отсутствуют даже простенькие примеры на указанную тему и интернет практически заполнен воплями о помощи в конфигурировании подобных систем, на которые гуру хранят гордое и пренебрежительное молчание - де, задача тривиальна.
___________________________
** Мне пришлось выслушать мнение нескольких специалистов, заверявших меня, что даже (!) в Windows использование более, чем одного интерфейса приводит якобы к перебоям в функционировании обеих подключений. Что более, чем странно, так как я много лет пользуюсь именно подобным подключением рабочей станции и множества серверов без единой проблемы.

Однако, все не настолько тривиально.

Во-первых, источники в Интернете утверждают взаимоисключающие вещи. Например, чем же разделяются записи в /etc/defaultrouter. Встречались настолько уверенные заявления (Например, что IP-адреса в оном файле разделяются в Solaris 10 пробелами), что пришлось усомниться в собственном опыте и проверить на кошечках. Оказалось, что, хотя в мануалах нигде нет явного примера с несколькими шлюзами, и об этом упоминается более, чем абстрактно - верно первое встреченное в гугле утверждение, и записи в /etc/defaultrouter разделяются символами новой строки. То бишь - каждый шлюз - с новой строки.

Во-вторых, выяснилось, что статические роуты не нужны и команда route должна выводить следующее:

root @ host / # route -p show
No persistent routes are defined

В-третьих, выяснилось, что оконечная машина под Solaris действительно ответные пакеты разбрасывает по всем доступным интерфейсам, и необходимо принимать определенные меры (не обязательно multipathing), чтобы ответные пакеты уходили на тот интерфейс, с которого поступали входящие пакеты. Причем при ответах используется алгоритм round-robin, если в /etc/defaultrouter указано более одного шлюза по умолчанию.

Опуская все страдания и попытки, отмечу, что наиболее простой вариант решения последней задачи действительно оказался с использование IP Filter. Отмечу лишь, что пляски с бубном, роутингом, форвардингом, таблицами маршрутизации и командой route результатов не дали.

Вот фрагмент шаблона конфигурации IP Filter, написанный по следам указанной статьи:

# Group 650 - Ports traffic separation
# Group 650 setup
pass out all head 650
pass out quick on bge0 to nge0:Gateway_Net2_IP from host2 to any group 650
pass out quick on bge0 to nge1:
Gateway_Net2_IP from host3 to any group 650
pass out quick on nge0 to bge0:
Gateway_Net1_IP from host1 to any group 650
pass out quick on nge1 to bge0:
Gateway_Net1_IP from host1 to any group 650
pass out quick on nge0 to nge1:
Gateway_Net2_IP from host3 to any group 650
pass out quick on nge1 to nge0:
Gateway_Net2_IP from host2 to any group 650

Как следует из приведенной конфигурации, ключевым набором правил является группа 650, разделяющая ответный трафик портов по портам происхождения. Данный пример относится к серверу, имеющем три активных интерфейса - bge0, nge0 и nge1, которым назначены адреса и имена хостов host1, host2 и host3 соответственно, при этом host1 находится в одной сети, а host2 и host3 - соответственно во второй, в каждой сети по одному шлюзу.

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