В более ранней статье под названием "Защищенный удаленный доступ к данным для Domino" мы говорили об использовании преимуществ Web-сервера Apache для решения проблем корпоративного масштаба по разумной цене. В настоящей статье мы продолжим эту тему и объясним, как с помощью Web-сервера Apache можно разместить несколько Web-сайтов с поддержкой Secure Sockets Layer (SSL) на одном сервере, подсоединенном к сети при помощи одной физической сетевой карты.
Зачем может потребоваться разместить несколько SSL-сайтов на одном сервере? Может ли вообще возникнуть такая потребность у предприятия? Мы попытаемся рассмотреть эти вопросы на примере из жизни. Опытные пользователи без сомнения найдут дополнительное творческое применение этой идеи.
Анализ проблемы: два приложения, один сервер
В более раннем проекте в нашей компании отдел кадров захотел предоставить внешний доступ по Internet к Web-приложению для начисления выплат. Это приложение должно было быть доступным, по большей части, из внутренней корпоративной сети и иногда через внешний Internet. Чтобы отвечать требованиям безопасности, мы решили разместить приложение на сервере внутри корпоративной сети и построить реверсивный proxy-сервер, использующий HTTP-сервер Apache. Реверсивный proxy-сервер будет прерывать текущее и открывать другое SSL-соединение с сервером Web-приложений, на котором находится HR-приложение. Добавив модуль mod_security на Web-сервер Apache, можно превратить реверсивный proxy-сервер в шлюз приложений и обеспечить достаточную безопасность. Отдел кадров осмотрительно выбрал удобное и легко запоминающееся полное доменное имя (fully qualified domain name -- FQDN). Затем мы получили сертификаты SSL и думали, что история на этом закончилась.
Прошел год. Появилось другое корпоративное Web-приложение с требованиями, аналогичными первому HR-приложению. К нему точно также требовалась возможность доступа внешним пользователям. Число этих пользователей было очень невелико. Большая часть ресурсоемкой работы должна была выполняться внутри корпоративной сети. Мы сразу же подумали об использовании реверсивного proxy-сервера для предоставления внешнего доступа к этому новому Web-приложению.
Однако возникло несколько препятствий. Во-первых, мы беспокоились по поводу физического пространства в центре обработки данных и серьезно рассматривали возможность объединения серверов для размещения каких-либо приложений. Во-вторых, мы должны были обосновать затраты на приобретение дополнительных реверсивных proxy-серверов. Сочетание двух этих проблем вынудило нас задуматься, как можно использовать существующий реверсивный proxy-сервер для удовлетворения нужд нового Web-приложения. Единственной проблемой было то, что это приложение должно было иметь доменное имя (FQDN), отличное от установленного для существующего приложения отдела кадров.
Мы рассмотрели несколько идей, чтобы использовать существующие реверсивные proxy-серверы для второго Web-приложения. Первой мыслью было поменять имя домена для старого и нового приложений на нечто общее, вроде rp.company.com, и разделить приложения по контекстным путям. Однако, существующие пользователи сильно возражали против возможной смены имени. Им бы пришлось сообщать новое имя всей компании и менять все печатные материалы, чтобы там присутствовал обновленный URL. Цена переименования была бы огромной, даже если проигнорировать возможный шквал обращений в службу технической поддержки пользователей, столкнувшихся с проблемой доступа к сайту. К тому же, обе группы пользователей предпочитали оставить свои собственные FQDN, аргументируя это тем, что они более запоминающееся, чем предложенный общий URL, и что свои приложения они собирались, кроме всего прочего, использовать для усиления бренда.
Была выдвинута другая идея: почему бы не зарегистрировать новое DNS-имя, которое указывало бы на уже существующий сервер? Это предложение было сразу же отвергнуто. В приложениях SSL каждый SSL-сертификат должен соответствовать запрошенному пользователем URL, в противном случае будет выдано предупреждающее сообщение о несоответствии запрошенного URL и доменного имени, указанного в SSL-сертификате. В период расцвета всплывающих окон с рекламой и всяческих вредоносных программ всех работников компании натренировали прекращать взаимодействие с Web, если выскакивали окна с предупреждениями. В соответствии с требованиями корпоративных стандартов архитектуры было запрещено в производимых Web-приложениях использовать технологию всплывающих окон для отображения предупреждающих сообщений.
Следующим предложением было разместить второй SSL-сайт на другом порту того же самого сервера, где запущен первый. Но и оно потерпело поражение -- пользователю сложно запоминать кроме URL еще и номера портов. В случае, если пользователь указывает URL без номера порта назначения, он будет перенаправлен на приложение отдела кадров. А это повлечет за собой множество проблем.
Решение: IP-алиасинг
Решение, на которое мы в конце концов наткнулись, было IP-алиасинг. Самым хитрым в поиске данного решения оказалось дать правильное название. Когда мы впервые встретились с этой концепцией, мы слышали такие понятия, как виртуальный интерфейс и виртуальный IP . Было очень сложно найти хоть что-то об этих концепциях, пока мы не поняли, что на самом деле ищем информацию об IP-алиасинге, а по этой теме литературы много. Иногда IP-алиасинг еще называют сетевым виртуальным алиасингом или логическими интерфейсами.
Использование IP-алиасинга в Linux
|
Концепция, которая стоит за понятием IP-алиасинг, проста: можно настроить несколько IP-адресов на одном сетевом интерфейсе. Это позволит запустить несколько Web-серверов на одном физическом сервере и одном сетевом интерфейсе. Настроить IP-алиас довольно просто. Нужно сконфигурировать сетевой интерфейс системы для прослушивания дополнительного IP-адреса. В Linux™ можно добавить IP-аслиасинг с помощью стандартных средств конфигурирования сети, например, ifconfig и route или через графический интерфейс администратора.
Обычно каждой сетевой карте при настройке присваивается некоторое числовое значение, характеризующее физический номер устройства. Чтобы добавить дополнительный IP-адрес к уже настроенной сетевой карте, нужно настроить интерфейс с этим же физическим номером, но добавить некоторый логический номер устройства. Например, если существующий IP-адрес был настроен для сетевой карты с физическим номером eth0, то можно создать IP-алиас, добавив к нему логический номер :1, как это показано в Листинге 1. Добавить дополнительные IP-адреса можно, просто увеличивая логический номер интерфейса. (Обратите внимание, что все вышеописанные действия необходимо выполнять, зарегистрировавшись в системе, как пользователь root.)
Листинг 1. Добавление дополнительного IP-адреса к существующему сетевому интерфейсу
ifconfig eth0:1 192.168.0.2 netmask 255.255.255.0 |
Ядро Linux в системе, которую вы настраиваете, должно поддерживать IP-алиасинг, только тогда вы сможете пользоваться этой технологией. Если поддержки нет, то возможно потребуется пересобрать ядро. Чтобы узнать, поддерживает ядро IP-алиасинг или нет, посмотрите, есть ли в системе файлы /proc/net/alias*.
Настроив новый IP-адрес, установите маршруты для нового интерфейса, как показано в Листинге 2.
Листинг 2. Добавление маршрутов для нового IP-адреса
route add -host 192.168.0.2 dev eth0:1 |
После создания нового IP-адреса вам также потребуется дать ему собственное имя в файле /etc/hosts file, как показано в Листинге 3.
Листинг 3. Добавление имени для нового IP-адреса
192.168.0.1 primaryserver 192.168.0.2 secondaryserver |
IP-алиасинг в системах Solaris
Для настройки IP-алиаса в системе Solaris™ вам потребуется немного другой набор команд. Настройте сетевой интерфейс, как показано в Листинге 4. Необходимо зарегистрироваться в системе пользователем root.
Листинг 4. Добавление виртуального IP на Solaris
ifconfig eth0:1 plumb ifconfig eth0:1 192.168.0.2 netmask 255.255.255.0 ifconfig eth0:1 up |
Для того чтобы виртуальный IP сохранился после перезагрузки, можно добавить IP-адрес или имя хоста из /etc/hosts в файл the /etc/hostname.eth0:1.
И на Linux, и на Solaris вы можете создать несколько виртуальных интерфейсов к IP-адресам из разных подсетей на одной физической карте ethernet. Но, скорее всего, вы захотите этого избежать, иначе может получиться узкое место между двумя подсетями, и тогда может пострадать эффективность работы всех сетевых устройств на этих двух подсетях.
Настройка нескольких SSL-сайтов по IP-адресу
После настройки второго IP-адреса можете наконец добавить дополнительные SSL-сайты, записав IP-адрес в конфигурационный файл Web-сервера Apache, как показано в Листинге 5.
Свершилось! Вы только что построили несколько Web-сайтов с поддержкой SSL на одном сервере и одной физической сетевой карте.
Листинг 5. Конфигурация для двух Web-сайтов с поддержкой SSL
<IfModule mod_ssl.c> Listen 443 <VirtualHost 192.168.0.1:443> DocumentRoot "/Web site1/docs" ServerName Web site1.company.com:443 SSLEngine on SSLCertificateFile ssl/site1.crt SSLCertificateKeyFile ssl/site1.key </VirtualHost> <VirtualHost 192.168.0.2:443> DocumentRoot "/Web site2/docs" ServerName Web site2.company.com:443 SSLEngine on SSLCertificateFile ssl/site2.crt SSLCertificateKeyFile ssl/site2.key </VirtualHost> </IfModule> |
Другие возможные применения нескольких SSL-сайтов
Т.к. трафик на нашем Web-сервере Apache не очень большой, возможно, мы могли бы использовать этот реверсивный proxy-сервер для других внутренних серверов с такими же низкими запросами по трафику.
С появлением более мощных серверов и сетевых карт с большей пропускной способностью вы также сможете использовать этот метод для размещения нескольких виртуальных SSL-сайтов. Вы можете выступить в роли ISP, который поддерживает SSL-сайты заказчиков, потребности которых в пропускной способности и объеме трафика невелики, но которым необходима возможность осуществлять безопасные торговые транзакции на основе SSL. С помощью IP-алиасинга вы можете разместить Web-сайт с поддержкой SSL на одном IP-адресе и предложить другие сервисы, такие как Web-сервисы, на другом. В качестве других возможностей можно рассмотреть установку основной и резервной систем, работающих в бесперебойном режиме, для которых требуется дублирование, как системы QA и/или DR. Теперь, когда вы понимаете основополагающую концепцию IP-алиасинга, у вас есть обширное поле деятельности.