Современный Linux-сервер: виртуализируем сетевые устройства

Алексей Барабанов

В серверном эксплуатационном цикле часто возникает потребность во всевозможных манипуляциях над сетевыми подключениями в режиме on-line. Переведя последние в категорию виртуальных, можно значительно упростить их обслуживание и предусмотреть многие внештатные ситуации.

Сетевые интерфейсы в серверах обычно ассоциируются с чем-то неизменным и предопределенным. Их число, топология подключения и настройки, как правило, заранее определяются в проектном задании и не меняются в процессе штатной эксплуатации. Но даже в таком идеализированном рассуждении статичность интерфейсов весьма условна. Возможен и иной взгляд на подсистему, отвечающую за сетевые интерфейсы. Безусловно, это всего лишь некий технический прием или рекомендация, и каждый из вас волен следовать ей или предпочесть консервативный вариант настроек. Более того, и не откровение, так как элементы такого подхода вы можете встретить во многих системах, например, во встроенных Linux или при создании виртуальных серверов. Рассмотрим предпосылки, идею и реализацию перевода сетевых интерфейсов в виртуальный режим. В качестве платформы будем использовать openSUSE Linux версий 10.0 и 10.1 [1]. Все несоответствия между ними я отмечу особо. Итак, начнем с перечисления возможных проблем, не решаемых в рамках традиционной настройки сети.

Исходные предпосылки

Рассмотрим «редкий» вариант, когда у сервера всего лишь один сетевой интерфейс. Что тут сложного, спрашивается, – от «рождения» и до «смерти» будет eth0. А вот и нет, как бы того не хотелось многим наивным скриптописателям, eth0 будет лишь в идеальном случае при установке системы прямо на данный системный блок. Если же, что более реально, сервер не устанавливается каждый раз с нуля, а копируется через образ системы или всего жесткого диска, то, скорее всего, даже единственный интерфейс будет иметь иное название. Eth1 и далее, в том случае, если полагаться на автоматическую систему наименования устройств, использованную в udev, что для современных систем является стандартом.

Но в серверах, как правило, более одного интерфейса. И если их названия в некоторый момент упорядочены и устраивают системного администратора и используемые им настроечные скрипты, то представим, что может произойти в случае отказа одного из интерфейсов. Например, произошел отказ в процессе старта. В старых системах, без использования udev, происходило смещение нумерации устройств или фактическая перекоммутация соединений. Интерфейсы, предназначенные для внутрисетевых соединений, могли переключиться на внешние линии. Практически это означало крах всей системы защиты. Современные скрипты, ориентированные на udev, привязывают имена сетевых интерфейсов к их физическим адресам или PCI-идентификаторам. Можно быть уверенным, что катастрофического «выворачивания» сервера внутренними интерфейсами наружу не произойдет. Но есть иная беда. Сетевая конфигурация, созданная автоматическим образом, может потерять свое сбалансированное состояние, и очередная перезагрузка может привести к новому изменению имен интерфейсов из-за отказа одной из сетевых карт. Впрочем, и при добавлении сетевой карты в систему с udev такие случаи нередки. Итогом подобного процесса может стать частичный или полный отказ стартовых сетевых скриптов, то есть изоляция сервера от сети. Для противодействия этому в системах с udev рекомендуется применять постоянные, или персистентные (от persistent – постоянный) сетевые имена. Увы, в такой схеме главное – исключить столкновение переименований. Другими словами, сетевые интерфейсы можно называть как угодно, но только не по схеме ethN, принятой по умолчанию.

Выход из строя сетевой карты непосредственно в ходе эксплуатации потребует замены физического интерфейса, то есть в процессе очередного старта произойдет добавление следующего номера в базу udev при обнаружении нового устройства, что сведется к ранее описанной проблеме привязки имен. Но можно и рассмотреть существование в серверном блоке сетевой карты, рассчитанной на горячую замену. Тут мы сталкиваемся с иной сложностью. Простое отключение интерфейса через ifdown (как вариант через ip link set) может привести к нарушению работы сетевых служб, использующих (прослушивающих) адрес данного интерфейса. Это в том благоприятном случае, если вы уверены, что созданная «на лету» аварийная схема при следующем рестарте не сломается.

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

Теперь пример из смежной области. Давайте задумаемся о том, как производится включение сетевого экрана в процессе старта сервера. Самый грамотный из мною наблюдаемых – это способ, использованный в дистрибутивах SuSE. Безусловно, в качестве серьезного решения это совершенно неприемлемо (практически бытовой вариант). Отмечу лишь одно важное качество: в этом сетевом экране выделена отдельная стадия предварительной настройки – сначала срабатывает SuSEfirefall2_init после старта boot.localnet, а потом уже SuSEfirewall2_setup после $network. Не буду обсуждать, что эти скрипты делают конкретно, меня ни один из них не устраивает, но главное – здесь продемонстрирована необходимость нулевой фазы настройки сетевого экрана, которая переводит сервер в защищенное состояние. А вот иная схема, используемая в Fedora Core и RHEL, совершенно неприемлема. Кстати, как и всякое применение iptables-save/restore. Дело в том, что, как уже указано, вовсе не обязательно сетевые интерфейсы стартуют нужным образом. Поэтому не факт, что iptables-restore создаст те правила, которые требуются из-за изменившейся схемы наименования интерфейсов. В схеме SuSE есть скрипт, который теоретически может проанализировать реальное состояние сети и адаптировать сетевой экран нужным образом. Минус только в том, что сетевой экран должен подниматься не отдельным скриптом по расписанию SysVinit, а синхронно с интерфейсом, на который он настраивается! Увы, хотя разработчики Red Hat, Inc. далеки от этой простой мысли, но и в SuSE не лучше. Не может система безопасности стартовать, во-первых, после поднятия сетевых интерфейсов (и ведь никто не нормирует данное «после») и, во-вторых, вне всякой связи с настройкой динамических сетевых интерфейсов (wifi, ppp и прочие ADSL).