Самозарождение порядка

Кто сказал, что будет легко?

TODO: что-то сделать с датами. Уж очень они скачут. Просто как животное Кухельклопф скачут!

Ситуация...

Вообразим такое. Небольшая компания въезжает в новый офис. Работа кипит: кто-то двигает мебель, кто-то выбирает место поближе к окну, кто-то просто слоняется без дела, привыкая к новой обстановке. Пахнет краской, коробками, пластмассой — и переездом.

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

Системному Администратору в серверной неуютно, ему тоже хочется найти место у окна, послоняться, а ещё выпить кофе и покурить. Однако он должен как можно быстрее пустить в ход «подключение к Интернет», чтобы его коллеги, когда начнут работать, начали работать, а не страдали от отсутствия корпоративной почты, информационных ресурсов, излюбленных социальных сетей и прочего. Необходимо как-то задействовать торчащий из соединительной панели провод с надписью «интернет № 15» и торчащий из стены провод с надписью «221-б» (это номер комнаты, в которой коллеги Системного Администратора обустраивают сейчас свой нехитрый производственный уют). Спасибо предыдущим хозяевам комнаты «221-б», сетевая проводка в ней в приличном состоянии, все рабочие места объединены концентратором, один провод от которого и ведёт в серверную.

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

По тем или иным причинам Администратор принимает решение, что на сервере он установит дистрибутив «Альт Линукс Ковчег 5.0 Сервер», а на рабочих станциях — по возможности — «Альт Линукс Ковчег 5.0 Рабочая Станция». Сказано — сделано. Установка серверного дистрибутива занимает с дюжину минут, не всякий кофейник успеет закипеть. Дело спорится. После установки сервер перезагружается, и через некотрое время Системный Администратор наблюдает следующую картину:

Что дальше-то делать? Под рукой имеется совершенно новый казённый ноутбук — будущее рабочее место администратора. Очевидно, на него стоит поставить «Альт Линукс Ковчег 5.0 Рабочая Станция». И?..

Самое время читать руководство по установке!

...и её описание

Для того, чтобы решить задачу, которая очевидно проступает в нашем рассказе, её сначала нужно сформулировать. В согласии с классическими традициями, опишем, что дано, что требуется и в каких условиях решение будет считаться удовлетворительным. Упоминание об условиях не случайно. Очень многие задачи «из жизни» не имеют окончательного решения: почти всегда есть возможность улучшить то, что уже имеется, и почти всегда выбор — останавливаться ли на пути улучшения или идти дальше — упирается в наличие ресурсов: времени, квалификации, средств. Мы ограничимся тем, что опишем условия, в которых задача посчитается решённой и потеряет для нас исследовательский интерес.

Дано

• Функционирующая локальная сеть с одним концентратором, объединяющая рабочие места и серверную комнату
• Доступ в сеть Интернет из серверной комнаты в виде сетевого кабеля и инструкции по настройке сетевых параметров
• Компьютер произвольной вычислительной мощности, предназначенный на роль сервера
• Компьютер(ы) произвольной вычислительной мощности, предназначенные для рабочих станций

Требуется

• Организовать возможность полноценной работы сервера и рабочей станции (выход в Интернет, управление сервером)

Условия

• На серверный компьютер установлен дистрибутив «Альт Линукс Ковчег 5.0 Сервер», подключение к сети Интернет настроено а процессе установки таким образом, что единственный »внешнийЮ» IP-адрес приходится на серверный компьютер
• Сервер имеет два сетевых интерфейса: «нулевой» — для подключения к сети Интернет, и «первый» — для взаимодействия с локальной сетью
• На рабочую станцию установлен дистрибутив «Альт Линукс Ковчег 5.0 Рабочая Станция»
• Процесс установки ОС можно не описывать, т. к. он описан в руководстве по установке
• Доступа к серверу со стороны «внешнего» адреса на момент решения задачи нет

Решение задачи

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

Для решения нам понадобятся некоторые дополнительные данные, в первую очередь — соглашения о сетевых настройках:

• Внешний адрес, адрес DNS-сервера и адрес маршрутизатора по умолчанию сервер получает автоматически, для этого используется сетевой интерфейс breth0.

• Внутренняя подсеть выбирается произвольно, например 10.30.50.1/24, где 10.30.50.1 — адрес внутреннего сетевого интерфейса на сервере(breth), а 24 — размер сетевой маски в локальной сети. Далее мы всегда будем пользоваться адресом 10.30.50.1 в качестве адреса сервера.

• Сеть на рабочей станции ещё не настроена, но имя компьютера задано (например, автоматически)

Что уже произошло

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

«Альт Линукс Ковчег 5.0 Сервер» непосредственно после установки нуждается в начальной настройке — следует задать учётную запись суперпользователя, унифицированное имя домена и некоторую другую информацию. Руководство по установке даёт простую и однозначную картину: после перезагрузки сервер опубликует на системной консоли адрес веб-интерфейса для управления, на него следует зайти с помощью любого навигатора по адресу http://10.30.50.1:8080.

Вот только откуда зайти? По условию задачи мы должны это сделать с рабочей станции, а сеть на ней не настроена, так как не настроена автоматическое конфигурирование клиентов на сервере... замкнутый круг?

Временная настройка клиентской машины

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

Настройки рабочей станции будем менять с помощью локальной версии Центра Управления Системой (ЦУС), которая присутствует во всех дистрибутивах Пятой платформы. В дистрибутиве «Альт Линукс Ковчег 5.0 Рабочая Станция» программа доступна в меню GNOME: Система -> Параметры -> Центр управления системой:

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

Большинство операций по изменению настроек в системе требуют прав суперпользователя. Поэтому Центр управления системой (он же «acc», altlinux control center) просит весчти пароль суперпользователя:

Открывшееся окно — и есть Центр управления. Наша задача — поменять настройки сети для того, чтобы добраться до веб-интерфейса на сервере:

Как было сказано выше, временные настройки сети на клиенте должны обладать лишь одним свойством: они должны работать. В примере был взят первый попавшийся адрес, не равный адресу сервера, заполнено поле «шлюз», а поле «DNS-сервер» оставлено чистым: оно пока не понадобится.

Кстати, если теперь запустить веб-навигатор

и зайти на сервер обычным способом, (по HTTP), мы увидим большой объём документации по серверному дистрибутиву, включая руководство по установке, где описано, что делать дальше: Стоит заметить, что остальные ссылки на этой странице имеют полное право не заработать.

Настройка сервера

Ну наконец-то. Осталось только, как это сказано в руководстве по установке, запустить веб-навигатор, и зайти на сервер по адресу https://10.30.50.1:8080,

И...

Заминка с сертификатом

А это кто такой? Пограничник-книгочей? Пугает какими-то непроверенными идентификаторами... Думать некогда, у нас сервер недоустановлен. Да и какое недоверие может быть между компьютерами, воткнутыми друг в друга? По-видимому, не одни мы такие нетерпеливые. Что ж, у нас есть «веская причина»: сертификат на только что поставленном сервере просто не имел возможности стать доверенным. В третий раз призвал Абу 'Амр Му'авийа б. Аби Ахмад Салих б. 'Усман, известный под именем Джарир б. Са'ид б. Са'д б. Фихр ал-Хадрами, демона на свою главу... Ну да, да, явись уже!

Начальная настройка сервера

Уф! А вот и картинка, виденная в руководстве по установке:

Ах, какой прелестный пароль! И запоминается легко... Не забыть: breth0 — интерфейс, «смотрящий в Интернет», его нам автоматически настраивает провайдер, breth1 — интерфейс, «смотрящий в локальную сеть», его мы настроили сами.

И ещё. Домен, про который нас спрашивают, не имеет прямого отношения к службе доменных имён DNS. Как рассказывает «Справка», доступная в полновесном Центре управления (всё равно, клиентской ли машины, сервера или при установке), «домен» — это пространство имён для регистрации пользователей. Поэтому рекомендуется вместо значения localdomain по умолчанию вписать что-нибудь уникальное для вашего сервера.

Теперь мы видим уже стандартную процедуру регистрации администратора системы. Введём учётные данные суперпользователя; протокол HTTPS позаботится о шифровании:

Какой же он был, этот легко запоминающийся пароль...

Кстати, на серверной консоли можно нажать Enter, и картинка поменяется на более привычную:

Автоматическая настройка сетевых установок в локальной сети

Вот он, Центр управления сервером:

Дело за малым. Первое: организовать автоматическую настройку сети на рабочих станциях. На сервере для этого надо настроить службу DHCP: Шлюзом по умолчанию устанавливается наш сервер, диапазон раздаваемых адресов вполне произволен. Хорошо бы, чтобы в этот диапазон не входил текущий временный адрес той рабочей станции, с которой мы всё это настраиваем (не ровён час сервер его тут же кому-нибудь выдаст). Однако это требование не обязательно: достаточно после старта DHCP тут же перенастроить сеть на рабочей станции.

Настройка межсетевого экрана в режиме трансляции адресов

Второе дело: организовать доступ в Интернет. Для этого достаточно перевести сервер в режим «шлюза», что означает включение в межсетевом экране («брандмауэре»)

трансляции сетевых адресов (это и есть режим «шлюз»): Осталось только применить эти настройки и сетью можно пользоваться.

Финальная настройка клиентской машины

Не забудем только перенастроить сеть и на самой рабочей станции администратора:

Готово. В подтверждение того, что настройки DHCP приняты к сведению, специальная программа (Network Manager applet) оповестит нас о подключении к сети:

На всякий случай можно убедиться, что работает DNS и доступ в Интернет, введя в адресную строку навигатора доменное имя какого-нибудь сайта:

Если воспроизвести эти настройки (попросту — включить настройку по DHCP) на любом другом абоненте локальной сети, доступ в Интернет будет работать и там.

Системный Администратор наконец расслабляется, и, нащупывая в кармане зажигалку и пачку сигарет, отправляется на поиски кофейника...

Объяснение

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

А ларчик просто не открывался

Ни то, ни другое. Просто руководство по установке решает принципиально другу задачу: описать установку ПО на сервере, и только её. В нашем же случае речь зашла о настройке работоспособной локальной сети, что поднимает задачу определения сетевых серверных настроек. Кроме того, дополнительное требование «вакуума на площадке» приводит к необходимости настраивать рабочее место параллельно серверу. Наконец, здоровая человеческая предусмотрительность, требующая, чтобы учётные данные (пароль суперпользователя!) передавались по сети только по защищённому соединению, нашла на не менее здоровую человеческую предупредительность, которая поставила под сомнение сам факт защищённости этого соединения.

Но обо всём по порядку.

Приборная доска анфас и в профиль

Управление Linux-системой, в конечном итоге, есть просто редактирование конфигурационных файлов и уведомление соответствующих служб о том, что файлы изменились. Не более — и не менее. Опытные администраторы знают синтаксис и название наиболее часто редактируемых конфигурационных файлов, а про остальные знают, где посмотреть документацию. Неопытным на освоение этой премудрости требуется изрядное время, года два-три. НО даже самый опытный администратор в состоянии совершить ошибку, редактируя по заранее намеченной схеме несколько конфигурационных файлов подряд.

Между тем, он вовсе не обязан выполнять все сложные действия вручную. У каждого опытного имеется некоторый багаж «скриптов» — небольших (или больших) собственноручно написанных командных сценариев, решающих ту или иную часто встречавшуюся на профессиональном пути администратора задачу. Получается, что опытному и неопытному осталось сделать пару шагов навстречу друг другу, да призвать на подмогу программиста, и выйдет некий инструмент, конфигуратор, объединяющий опыт решения частных, но частых задач и быстроту освоения этого опыта.

В дистрибутивах Пятой Платформы конфигуратор, называемый «Центром управления системой», имеет трёхуровневую структуру. Первый уровень — это интерфейс, способ общения с пользователем. Интерфейс может быть каким угодно, чаще всего используется специальная программа или веб-интерфейс. В интерфейсе в простой форме представлены инструменты решения тех или иных рабочих задач. Эти инструменты могут быть весьма простыми, для решения простых задач, а могут сводиться к прямому редактированию конфигурационных файлов. Оптимум, как всегда, где-то посередине. Второй уровень — это логика, программная часть, позволяющая преобразовать данные, полученные из интерфейса в некоторые унифицированные команды изменения параметров системы. Эти команды передаются третьему уровню, реализации, на котором однотипные команды преобразуются в последовательность действий, корректно редактирующих соответствующие файлы и перезапускающих службы. Уровню реализации как раз соответствует «набор скриптов» опытного администратора.

Кроме того, Центр управления делится горизонтально — на модули. Некоторой функциональности соответствуют части сразу трёх уровней: представление данных в интерфейсе, логика преобразования в команды и реализация. Такой модуль оформляется в виде отдельного пакета в дистрибутиве или хранилище, и может быть по необходимости установлен или удалён.

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

Без окон, без дверей

Традиционно принято различать в Linux тесктовые системные консоли и графическую подсистему. В дистрибутиве «Альт Линукс Ковчег 5.0 Сервер» графическая подсистема используется только на этапе установки; собственно, в состав ПО, устанавливаемого на сервер, она не входит. Таким образом после установки серверной части мы получаем компьютер, работа с которым возможна только посредством текстовой консоли — либо через веб-интерфейс, если настроена сеть. Учитывая особенность серверного оборудования нещадно шуметь и находиться в труднодоступной серверной комнате (не говоря уже об удалённых площадках), такой минимализм вполне оправдан.

Специфика Пятой Платформы требует, чтобы был выбран именно второй вариант — через сеть — оттого администратора склоняют к подобному выбору чуть ли не силой: до тех пор, пока первоначальная настройка сервера не завершена, командная строка недоступна.

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

Кто проверяет проверяльщика?

Вторая загвоздка возникает при попытке впервые воспользоваться веб-навигатором на уже настроенной рабочей станции. Вместо того, чтобы послушно показывать нам интерфейс Центра управления сервером, навигатор изображает полицейского в форме, пугает подменой сайтов и недвусмысленно предлагает уносить ноги. Опытные пользователи давно уже привыкли к подобным — довольно частым — угрозам, и не обращают на них внимания согласно правилу «нас пугают — нам не страшно». В данном случае всё и в самом деле не страшно, однако не мешало бы разобраться.

Сам протокол HTTP, посредством которого навигатор обменивается данными с сервером, вполне текстовый; искушённые администраторы способны получить текст страницы с сервера вообще безо всякого навигатора, вводя HTTP-запросы вручную с помощью команды непосредственного подключения к порту (например, netcat). Что более важно, вся информация передаётся в нём в открытую, без шифрования. Строго говоря, даже если шифровать передаваемые данные с помощью информации, передаваемой в том же соединении, перехватить и расшифровать эти данные будет не сложнее, чем перехватить нешифрованые. Поэтому — если уж скрывать содержимое передаваемых данных, например, имя пользователя и пароль, от посторонних глаз — следует заранее позаботиться о том, чтобы как минимум не клиентской имелась какая-то информация о сервере, с помощью которой данные получилось бы зашифровать так, что только на сервере их было возможно расшифровать.

Самый распространённый способ добиться этого — использовать так называемое асимметричное шифрование. Суть метода в том, что в нём используется два пароля, и то, что зашифровано одним, может быть расшифровано только другим. Один из них, называемый закрытым ключом, хранится на сервере и никогда никому не передаётся, другой же, называемый открытым ключом, напротив распространяется как можно шире, передаётся пользователям, публикуется и т. п. Зашифровав сообщение с помощью своего закрытого ключа, отправитель даёт возможность любому обладателю открытого ключа (т. е. просто любому) расшифровать и прочесть это сообщение, будучи полностью уверенным, что оно не поддельное, ибо зашифровал его обладатель закрытого ключа и никто иной. Такой алгоритм называется «электронной подписью». Если же зашифровать сообщение открытым ключом получателя, то его сможет прочесть только этот получатель, обладатель закрытого ключа, а злоумышленник, перехвативший сообщение, не сможет.

Этого как раз и требуется достичь! Используемый протокол-надстройка Secure Socket Layser (SSL) организует на обоих концах потока данных TCP шифрующие-дешифрующие «фильтры», а программа знай себе шлёт в этом потоке свои данные. Затруднения только два. Первое: поскольку шифрование не поднимается на прикладной уровень, необходимо как-то различать шифрованные и нешифрованные потоки данных на уровне транспортном. Это легко устранить, договорившись, что для использования SSL приложение подключается к серверу по другому порту, например, научить навигатор вместо 80-го порта заходить на 443-й. С точки зрения навигатора это вообще воспринимается как новый сетевой протокол (https: вместо http:).

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

Если принимать на веру подлинность полученного открытого ключа, злоумышленник, технически способный перехватить пересылаемые данные и подменить их своими, может запросто расшифровать эти данные так, что и отправитель, и получатель этого не заметят. Традиционный (и единственный сравнительно простой) способ называется атакой «man-in-the-middle» («человек посередине»). Суть её очень проста: вместо того, чтобы позволить получателю переслать ключ, а отправителю — шифровать им данные, злоумышленник ретранслирует поток данных через свой компьютер, попутно их расшифровывая. Более подробно: открытый ключ получателя злоумышленник вообще не показывает отправителю, а отсылает ему свой открытый ключ. Отправитель, думая, что разговаривает непосредственно с получателем, шифрует этим ключом свои данные, злоумышленник их перехватывает, расшифровывает (атака прошла успешно!), затем шифрует ключом получателя и отправляет ему, чтобы не вызывать подозрений.

Если не рассматривать передачу ключа альтернативными способами (например, можно приехать к администратору сайта, и лично у него переписать этот ключ), есть два способа избежать обмана, когда открытый ключ передаётся в рамках того же, ещё не доверенного, соединения. Первый состоит в том, чтобы, получив ключ, проверить его аутентичность (опять-таки с помощью альтернативного канала передачи данных). В этом помогает так называемый «отпечаток пальца» (fingerprint) — некоторое число, которому однозначно соответствует открытый ключ. Это число достаточно велико, и алгоритм его получения достаточно сложен, так что у злоумышленника нет разумной возможности изготовить свой ключ с таким же отпечатком. При этом отпечаток намного меньше самого ключа, и человек в состоянии самостоятельно сличить два отпечатка: тот, что сгенерирован из полученного ключа, и тот, что опубликован на сайте, или в службе DNS или получен иным способом. Предполагается, что злоумышленник не готов тратить столько ресурсов, чтобы получать контроль над всеми видами передачи данных.

Другой способ — воспользоваться электронной подписью. Если на компьютере отправителя имеется некоторый проверенный открытый ключ, получатель может попросить хозяина этого ключа подписать ключ получателя перед пересылкой. Тогда отправитель увидит, что пришедшая информация подписана доверенным лицом, и, стало быть, после того, как её подписали, не менялась. В действительности это род бизнеса: договариваться с производителями дистрибутивов ОС и ПО, использующего SSL, о том, чтобы включать в них свои открытые ключи, а затем брать деньги за подписывание этими ключами (точнее, их закрытыми парами). К сожалению, относительная дороговизна подобной процедуры приводит к тому, что администраторы серверов часто используют т. н. «самоподписанные» сертификаты, проверить аутентичность ключей в которых этим способом невозможно.

Теперь картинка с полицейским становится более понятной. Для доступа к серверу по защищённому протоколу требуется получить от него свежезаведённый открытый ключ (в терминах SSL — «серитфикат»), который разумеется, никто не успел подписать. Хуже того. В сертификате, помимо собственно ключа, хранится разнообразная информация о том, кому он принадлежит — в частности, доменное имя сайта. Но к моменту, когда нам необходимо подключиться к веб-интерфейсу на сервере, служба DNS на нём может и не работать, поэтому в примере используется IP-адрес. Обо всём этом (о недоверенности передаваемого сертификата и о несоответствии доменного имени) и сообщает навигатор. Для того, чтобы история впоследствии не повторилась, сертификат надо запасти на будущее (это называется «подтвердить исключение безопасности».

Всех выпускать, никого не впускать

Теперь пару слов о «настройке сети для класса». Собственно, ничего таинственного в них нет, нам необходимо воспользоваться двумя службами сервера: службой автоматизации клиентских настроек DHCP (Dynamic Host Configuring Protocol) и межсетевым экраном с маршрутизацией.

Сначала о маршрутизации. Вообще говоря, свойство быть маршрутизатором — принимать чужие пакеты и перенаправлять их через другой сетевой интерфейс — ядру Linux присуще, однако его следует включать специальной настройкой ядра sysctl (net.ipv4.ip_forward; в дистрибутивах Пятой Платформы можно также выставить эту настройку в единицу в файле /etc/net/sysctl.conf). В сервере она включена по умолчанию, но задачу «настройки сети для класса» это может решить только в случае, когда всем компьютерам раздаются настоящие IP-адреса. Точнее говоря, когда эти адреса обрабатываются не нашим сервером, а где-то дальше, сервер же попросту маршрутизирует пакеты от абонентов своей локальной сети. В нашем случае это не так: диапазон адресов в локальной сети был выбран вполне произвольно, следовательно, нам и отвечать за то, чтобы в дальнейшем своём путешествии по сети Интернет эти пакеты были признаны годными.

Просто так пакеты из настраиваемой локальной сети годными признаны не будут: они принадлежат одному из так называемых «внутренних» диапазонов адресов, именно: 10.0.0.0/8. Пакеты с такими адресами в глобальной сети недопустимы, задача сервера — преобразовать их во что-либо пригодное. Например, воспользоваться умением межсетевого экрана Linux — IPTables — осуществлять преобразование сетевых адресов (NAT, Network Address Translation). Суть метода в том, что при пересылке пакетов «в большую сеть» адрес отправителя в них подменяется на адрес сервера (этот адрес, очевидно, работоспособный). Если предполагается обмен данными, то каждый сеанс обмена запоминается межсетевым экраном (например, для TCP-соединения запоминается адрес и порт настоящего отправителя, адрес и порт получателя, а также порт отправителя, выданный сервером в результате преобразования) и, проанализировав входящий трафик, сервер принимает решение об обратном преобразовании.

Команда iptables-save на сервере покажет, что преобразование адресов происходит в правиле таблицы nat подсистемы IPTables -A POSTROUTING -o breth0 -j MASQUERADE. Правило означает буквально, что после того, как принято решение о маршрутизации пакета (пакет предназначен куда-то вовне, и передаётся через сетевой интерфейс breth0), содержимое пакета обрабатывается специальной цепочкой-действием MASQUERADE. В отличие от цепочки-действия NAT, преобразующий адрес в некоторый заранее заданный, MASQUERADE сначала получает адрес соответствующего сетевого интерфейса, и преобразует именно в него. Это потребляет чуть больше ресурсов, чем NAT, зато правильно работает в ситуации, когда этот адрес настраивается динамически (как в нашем примере).

В Центре управления системой всё это включается, когда в соответствующей настройке межсетевого экрана («брандмауэра») переключатель «режим работы» выставляется из положения «роутер» (маршрутизатора) в положение «шлюз». Следует отметить, что маршрутизатору в чистом виде всё равно, из какого сетевого интерфейса в какой перекладывать несвои пакеты, а вот преобразование адресов необходимо только на выходе в глобальную сеть (и обратное — на входе оттуда).

Сервер не может самостоятельно определить, где глобальная сеть, а где какая-то другая. С его точки зрения существует два вида интерфейсов: внешние и внутренние. За внутренним интерфейсом лежит администрируемая локальная сеть, за внешним — «внешний мир». В режиме «шлюз» сервер будет преобразовывать адреса при выходе пакета через любой внешний интерфейс. Кроме того, межсетевой экран запретит любые входящие соединения (и приём других пакетов) через внешние интерфейсы, кроме тех, что отмечены на соответствующей странице Центра управления.

Последнее, о чём стоит упомянуть — это служба динамической настройки абонентов сети DHCP (Dynamic Host Configuring Protocol). Суть этой службы проста: абонент локальной сети может не иметь собственных настроек, а обращаться за ними к серверу; причём обращение это происходит до настройки сетевого уровня, без знания IP-адресов. Вкратце это происходит в четыре приёма: сначала клиент рассылает широковещательный запрос вида «а кто тут может мне настройки выдать» по локальной сети, и все имеющиеся в ней DHCP-серверы отвечают широковещательным же предложением «я могу дать такие настройки»; после чего клиент выбирает, чьи настройки ему больше по нраву (обычно — первые попавшиеся), и посылает ещё один широковещательный запрос: «мне такой-то сервер настройки обещал», и наконец получает ответ «вот твои настройки».

С помощью DHCP можно раздавать IP-адреса, настройки маршрутизации и адреса DNS-серверов, доменные имена, а также десятки других параметров. Кроме того, клиент может попросить выдать ему определённый адрес или имя, и, если они не заняты, получить именно их. Стоит также понимать, что адреса выдаются, вообще говоря, первые попавшиеся свободные и временно, так что без дополнительных действий адрес одного и того же компьютера может быть в разные дни разный.

Адреса, выдающиеся абонентам локальной сети, служба DHCP берёт из заданного диапазона. В примере их 91 — от 10.30.50.10 до 10.30.50.100. Предполагается, что адреса каких-то ещё серверов, если они появятся, будут заканчиваться на однозначное число, а компьютеров во внутренней сети всё равно не будет больше, даже если учитывать ноутбуки и КПК сотрудников. В принципе, достаточно, чтобы в сети не было более 91 одновременно включённого компьютера, так как новым абонентам сети адреса выдаются по принципу «самй давно не используемый». Маршрутизатором и DNS-сервером для наших рабочих мест также будет серверная машина (причём информация про DNS берётся прямо из настроек самого сервера).

Клиентские машины (с любой операционной системой) теперь можно смело переводить на «автоматическую настройку сети».

Задача решена.

CategoryP5