Администрирование сетевых служб: DHCP, NTP и SSH

Настройка сервера DHCP для автоматического распределения IP-адресов

В современной сетевой инфраструктуре ручная настройка IP-адресов на каждом устройстве является неэффективной и чреватой ошибками практикой. Представьте офис на 200 компьютеров: если администратору придется вручную прописывать адрес, маску и шлюз на каждом из них, любое изменение структуры сети приведет к дням простоя. Решением этой проблемы является протокол DHCP (Dynamic Host Configuration Protocol).

Принцип работы DHCP

DHCP — это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры сети (маску подсети, шлюз по умолчанию, адрес DNS-сервера). Работа протокола строится по модели «клиент-сервер».

Процесс получения адреса часто называют аббревиатурой DORA, по первым буквам четырех основных этапов:

Discovery (Поиск): Клиент, подключившись к сети, отправляет широковещательный запрос по всей сети, пытаясь найти DHCP-сервер.
Offer (Предложение): Сервер получает запрос и, если у него есть свободные адреса, отправляет клиенту предложение с конкретным IP-адресом.
Request (Запрос): Клиент принимает предложение и отправляет серверу запрос на подтверждение использования этого адреса.
Acknowledge (Подтверждение): Сервер регистрирует выдачу адреса и отправляет клиенту окончательное подтверждение вместе с дополнительными настройками (время аренды, DNS и т.д.).

Установка DHCP-сервера

В качестве эталонного примера мы рассмотрим настройку ISC DHCP Server — одного из самых распространенных и стабильных решений для операционных систем семейства Linux (Debian/Ubuntu). Несмотря на появление более новых аналогов (например, Kea), ISC DHCP остается стандартом де-факто во многих корпоративных сетях.

Для установки пакета выполните команду:

sudo apt update
sudo apt install isc-dhcp-server

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

Базовая конфигурация

Основной файл конфигурации находится по пути /etc/dhcp/dhcpd.conf. Перед началом работы рекомендуется сделать резервную копию оригинального файла:

sudo cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.bak

Откройте файл для редактирования. Конфигурация состоит из глобальных параметров и объявлений подсетей.

Глобальные параметры

В начале файла обычно указываются параметры, общие для всех подсетей. Ключевыми являются параметры времени аренды (lease time).

default-lease-time 600;
max-lease-time 7200;
authoritative;

default-lease-time: Время в секундах, на которое выдается IP-адрес, если клиент не запросил иное (здесь 600 секунд = 10 минут).
max-lease-time: Максимально возможное время аренды, даже если клиент просит больше (7200 секунд = 2 часа).
authoritative: Этот параметр сообщает, что данный сервер является главным и единственным источником правды для этой сети. Если сервер видит клиента с неправильным адресом, он отправит команду DHCPNAK, заставляя клиента переполучить адрес.

Объявление подсети (Subnet)

Это самая важная часть настройки. Вы должны описать подсеть, в которой сервер будет раздавать адреса. Если сетевой интерфейс сервера имеет IP 192.168.1.10 с маской 255.255.255.0, то конфигурация подсети должна соответствовать этим параметрам.

Пример конфигурации:

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.100 192.168.1.200;
    option routers 192.168.1.1;
    option domain-name-servers 8.8.8.8, 1.1.1.1;
    option domain-name "local.lan";
}

Разберем каждую строку:

subnet ... netmask ...: Определяет сеть. Сервер будет обслуживать запросы только с интерфейсов, принадлежащих этой сети.
range: Диапазон выдаваемых адресов (пул). В данном примере клиенты будут получать адреса от .100 до .200. Адреса вне этого диапазона (например, с .1 по .99) можно использовать для статической настройки серверов и принтеров.
option routers: Шлюз по умолчанию (gateway), через который клиенты будут выходить в интернет.
option domain-name-servers: Адреса DNS-серверов, которые будут переданы клиентам.

Расчет доступных хостов

При планировании диапазона range важно понимать емкость вашей подсети. Количество доступных адресов для хостов рассчитывается по формуле:

N = 2^{h} - 2

где $N$ — количество доступных адресов для устройств, $h$ — количество бит, отведенных под хостовую часть адреса, а вычитание $2$ необходимо для исключения адреса самой сети и широковещательного адреса.

Например, для маски 255.255.255.0 (или /24) под хост отводится 8 бит ( $32 - 24 = 8$ ). $N = 2^8 - 2 = 256 - 2 = 254$ адреса. Если вы выделите в range 100 адресов, у вас останется 154 адреса для статических назначений.

Привязка к сетевому интерфейсу

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

Отредактируйте файл /etc/default/isc-dhcp-server:

INTERFACESv4="eth0"

Замените eth0 на имя вашего сетевого интерфейса (узнать его можно командой ip a).

Резервирование адресов (Static Leases)

В администрировании часто требуется, чтобы определенное устройство (например, сетевой принтер или файловый сервер) всегда получало один и тот же IP-адрес, но при этом настраивалось через DHCP. Это называется резервированием.

Для этого нужно знать MAC-адрес устройства. В файл dhcpd.conf добавляется блок host:

host office-printer {
    hardware ethernet 00:11:22:33:44:55;
    fixed-address 192.168.1.50;
}

hardware ethernet: Уникальный физический адрес (MAC) сетевой карты устройства.
fixed-address: IP-адрес, который всегда будет выдаваться этому MAC-адресу.

Важно: Назначаемый адрес (192.168.1.50) желательно выбирать вне диапазона range (.100–.200), чтобы избежать конфликтов, если пул переполнится.

Запуск и отладка

После внесения всех изменений сохраните файл и перезапустите службу:

sudo systemctl restart isc-dhcp-server

Проверьте статус службы:

sudo systemctl status isc-dhcp-server

Если служба не запустилась (статус failed), искать причину нужно в системных логах. DHCP-сервер очень чувствителен к синтаксису (например, пропущенная точка с запятой).

Посмотреть логи можно командой:

journalctl -u isc-dhcp-server -e

Или в файле системного журнала:

tail -f /var/log/syslog

Управление арендой (Lease Time)

Выбор времени аренды (default-lease-time) — это баланс между стабильностью и утилизацией адресов.

Короткая аренда (например, 1 час): Подходит для публичных Wi-Fi сетей (кафе, метро). Клиенты постоянно приходят и уходят. Если дать аренду на сутки, пул адресов быстро закончится, так как адреса будут числиться занятыми за устройствами, которых уже нет в сети.
Длинная аренда (например, 7 дней): Подходит для офисных сетей со стационарными ПК. Это снижает широковещательный трафик в сети, так как клиенты реже обновляют свои адреса.

Файл, где сервер хранит информацию о выданных арендах, обычно находится здесь: /var/lib/dhcp/dhcpd.leases. Это текстовый файл, который можно просмотреть, чтобы узнать, кому и когда были выданы адреса.

Итоги

Настройка DHCP-сервера — фундаментальный навык системного администратора. Правильно настроенная служба обеспечивает бесперебойное подключение новых устройств и упрощает управление сетью.

Автоматизация: DHCP избавляет от ручной настройки сети на клиентах, используя процесс DORA.
Конфигурация: Основные настройки (подсеть, шлюз, DNS) задаются в блоке subnet файла dhcpd.conf.
Резервирование: Для критически важных устройств используйте привязку IP к MAC-адресу через блок host.
Диагностика: При ошибках всегда проверяйте синтаксис конфига и системные логи /var/log/syslog.
Планирование: Разделяйте адресное пространство на пулы для динамической раздачи и зоны для статических адресов.

Конфигурация протокола NTP для точной синхронизации времени

В распределенных системах время — это не просто часы в углу экрана, а критически важный параметр согласованности данных. Рассинхронизация времени между серверами даже на несколько секунд может привести к невозможности анализа логов (события на разных серверах будут перепутаны во времени), сбоям в работе баз данных и отказу в авторизации (например, протокол Kerberos допускает расхождение не более 5 минут).

Для решения этой задачи используется протокол NTP (Network Time Protocol), работающий поверх UDP на порту 123. В этой статье мы разберем архитектуру протокола и настройку современной реализации NTP — демона Chrony.

Иерархия Stratum

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

Stratum 0: Это эталонные источники времени, такие как атомные часы, GPS-приемники или радиочасы. Они не подключаются к сети напрямую, а соединяются с компьютером через физические интерфейсы (RS-232, USB).
Stratum 1: Серверы, непосредственно подключенные к источнику Stratum 0. Это «первичные» серверы времени.
Stratum 2: Серверы, которые синхронизируют свое время с серверами Stratum 1. Они могут выступать источниками для других серверов.
Stratum 3–15: Последующие уровни иерархии.
Stratum 16: Означает, что устройство не синхронизировано (unsynchronized).

Обычные серверы в интернете (например, pool.ntp.org) чаще всего являются Stratum 2, что обеспечивает достаточную точность для большинства задач (до долей миллисекунды).

Алгоритм работы и расчет смещения

NTP не просто запрашивает время у сервера и устанавливает его. Протокол учитывает задержку прохождения пакета по сети (Network Latency). Для этого клиент и сервер обмениваются метками времени.

Процесс обмена состоит из четырех контрольных точек:

$t_0$ : Клиент отправляет запрос.
$t_1$ : Сервер получает запрос.
$t_2$ : Сервер отправляет ответ.
$t_3$ : Клиент получает ответ.

Чтобы вычислить, насколько часы клиента спешат или отстают от сервера (смещение или offset), используется формула:

\theta = \frac{(t_1 - t_0) + (t_2 - t_3)}{2}

Где:

$\theta$ (тета) — искомое смещение времени клиента относительно сервера.
$t_0$ — время отправки пакета клиентом (по часам клиента).
$t_1$ — время приема пакета сервером (по часам сервера).
$t_2$ — время отправки ответа сервером (по часам сервера).
$t_3$ — время приема ответа клиентом (по часам клиента).

Пример расчета: Предположим, часы клиента спешат на 5 секунд относительно сервера. Задержка сети составляет 2 секунды в одну сторону (мгновенная доставка для простоты).

Реальное время: 12:00:00. Клиент (спешит) отправляет запрос в $t_0 = 12:00:05$ .
Пакет идет 2 секунды. Сервер получает его в $t_1 = 12:00:02$ (по своим точным часам).
Сервер обрабатывает запрос мгновенно и отправляет ответ в $t_2 = 12:00:02$ .
Ответ идет 2 секунды. Клиент получает его, когда на его часах $t_3 = 12:00:09$ (реальное время 12:00:04 + 5 сек спешки).

Подставим значения в формулу:

\theta = \frac{(12:00:02 - 12:00:05) + (12:00:02 - 12:00:09)}{2} = \frac{-3 + (-7)}{2} = \frac{-10}{2} = -5

Результат $-5$ означает, что клиенту нужно сдвинуть свои часы на 5 секунд назад, чтобы синхронизироваться с сервером.

Установка и настройка Chrony

В современных дистрибутивах Linux (RHEL 8+, Ubuntu 20.04+) стандартом де-факто стал Chrony. Он быстрее синхронизирует время при нестабильном соединении и лучше работает на виртуальных машинах по сравнению с классическим демоном ntpd.

Установка в Debian/Ubuntu:

sudo apt update
sudo apt install chrony

После установки служба запускается автоматически. Основной конфигурационный файл находится по пути /etc/chrony/chrony.conf.

Настройка источников времени

Откройте файл конфигурации:

sudo nano /etc/chrony/chrony.conf

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

Пример конфигурации:

server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst

Разберем параметры:

server: Указывает конкретный сервер времени.
pool: Указывает DNS-имя, за которым скрывается множество серверов (балансировка).
iburst: Критически важная опция. Она заставляет клиент отправить пачку из 4-8 запросов с интервалом в 2 секунды при первом запуске. Это позволяет синхронизировать время за несколько секунд после загрузки, вместо ожидания нескольких минут.

Настройка NTP-сервера для локальной сети

По умолчанию Chrony работает только как клиент. Если вы хотите, чтобы этот сервер раздавал время другим устройствам в вашей локальной сети (например, в сети 192.168.1.0/24), нужно разрешить доступ.

Добавьте в конфиг строку:

allow 192.168.1.0/24

Это превращает ваш хост в локальный NTP-сервер (обычно Stratum 3, если он берет время из интернета).

После изменения конфигурации перезапустите службу:

sudo systemctl restart chrony

Диагностика и проверка

Для управления и мониторинга используется утилита chronyc.

Проверка источников

Команда chronyc sources -v показывает список серверов, с которыми происходит синхронизация.

chronyc sources -v

Пример вывода:

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp1.vniiftri.ru              1   6   377    45   +123us[ +145us] +/- 5ms
^+ ntp2.vniiftri.ru              1   6   377    44   -456us[ -430us] +/- 6ms

Ключевые обозначения:

* (звездочка): Текущий выбранный основной источник времени.
+ (плюс): Хороший кандидат, который используется для вычисления усредненного времени.
? (вопрос): Сервер недоступен.
Reach: Восьмеричное число, показывающее успешность последних 8 попыток опроса. Идеальное значение — 377 (все 8 пакетов дошли).

Детальная статистика

Команда chronyc tracking показывает общую информацию о состоянии системных часов.

chronyc tracking

Обратите внимание на поля:

Stratum: Уровень вашего сервера.
System time: Насколько системное время отличается от эталонного (например, 0.000054 seconds slow).
Last offset: Смещение, вычисленное при последнем опросе.

Системное время и аппаратные часы (RTC)

Важно различать два типа часов в Linux:

System Time: Время, которое поддерживает ядро ОС. Оно сбрасывается при перезагрузке.
RTC (Real Time Clock): Аппаратные часы на материнской плате с батарейкой. Они идут, даже когда сервер выключен.

При загрузке ядро считывает время из RTC. При выключении — записывает системное время обратно в RTC.

NTP синхронизирует только системное время. Однако Chrony умеет автоматически корректировать и RTC, чтобы при следующей перезагрузке время было максимально точным.

Для этого в конфиге должна быть опция:

rtcsync

Она включает режим, при котором ядро каждые 11 минут обновляет RTC.

Итоги

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

Иерархия: NTP использует уровни Stratum. Stratum 0 — это физические часы, Stratum 1 — серверы, подключенные к ним.
Chrony: Современная замена классическому ntpd, рекомендуемая для большинства Linux-систем.
Конфигурация: Используйте iburst для быстрой синхронизации при старте и allow для разрешения запросов от клиентов локальной сети.
Мониторинг: Утилита chronyc sources позволяет проверить доступность серверов и текущий статус синхронизации (ищите символ *).
Алгоритм: Протокол рассчитывает смещение $\theta$ , учитывая время прохождения пакета туда и обратно, что позволяет достигать высокой точности даже в сетях с задержками.

Обеспечение безопасного удаленного доступа и настройка ключей SSH

В предыдущих модулях мы настроили сетевую инфраструктуру (DHCP) и синхронизацию времени (NTP). Теперь, когда серверы подключены к сети и имеют корректное время, необходимо обеспечить безопасный способ управления ими. Стандартным инструментом для этого в мире Linux является протокол SSH (Secure Shell).

До появления SSH администраторы использовали Telnet и rlogin — протоколы, которые передавали данные, включая пароли, в открытом виде. Любой злоумышленник, подключившийся к промежуточному узлу сети с анализатором трафика (сниффером), мог перехватить учетные данные. SSH решает эту проблему, создавая зашифрованный туннель между клиентом и сервером.

Принцип работы и криптография

SSH работает на транспортном уровне (по умолчанию TCP-порт 22). Безопасность соединения обеспечивается комбинацией симметричного и асимметричного шифрования.

Асимметричное шифрование: Используется на этапе установления соединения (Handshake) для аутентификации сторон и безопасного обмена ключами сессии. Здесь участвует пара ключей: публичный (зашифровывает) и приватный (расшифровывает).
Симметричное шифрование: После согласования ключей весь дальнейший трафик шифруется одним общим «сессионным ключом». Это делается для скорости, так как симметричные алгоритмы (например, AES) работают значительно быстрее асимметричных.

Почему пароли ненадежны: математическое обоснование

Главная уязвимость классического входа по паролю — атаки методом перебора (Brute-force). Сравним стойкость 8-символьного пароля и SSH-ключа.

Количество возможных комбинаций для пароля рассчитывается по формуле:

N = A^L

Где:

$N$ — общее количество возможных комбинаций.
$A$ — размер алфавита (набор допустимых символов).
$L$ — длина пароля.

Рассмотрим сложный пароль из 8 символов, использующий латинские буквы (26 строчных + 26 заглавных) и цифры (10). Итого $A = 62$ .

N = 62^8 \approx 2{,}18 \times 10^{14}

Это около 218 триллионов комбинаций. Современные GPU-кластеры могут перебирать миллиарды хешей в секунду, что делает взлом такого пароля вопросом времени.

В то же время, стандартный ключ типа ED25519 имеет длину 256 бит. Количество вариантов ключа:

N_{key} = 2^{256} \approx 1{,}15 \times 10^{77}

Разница между $10^{14}$ и $10^{77}$ колоссальна. Подобрать приватный ключ методом перебора при текущем уровне развития вычислительной техники физически невозможно.

Установка и базовая настройка сервера

В большинстве дистрибутивов Linux пакет сервера openssh-server уже установлен. Если нет, его можно установить командой:

sudo apt update
sudo apt install openssh-server

Главный конфигурационный файл находится по пути /etc/ssh/sshd_config. Перед редактированием всегда создавайте резервную копию:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Критические параметры безопасности

Откройте файл конфигурации. Для повышения безопасности рекомендуется изменить несколько параметров:

Запрет входа под root. Администратор должен заходить под своим пользователем и повышать привилегии через sudo. Это оставляет след в логах аудита.
```
PermitRootLogin no
```
Смена порта (опционально). Смена стандартного порта 22 на нестандартный (например, 2222) не защитит от целенаправленной атаки, но избавит логи от тысяч записей автоматических ботов-сканеров.
```
Port 2222
```
Ограничение попыток входа.
```
MaxAuthTries 3
```

После изменений перезапустите службу:

sudo systemctl restart ssh

Настройка аутентификации по ключам

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

Шаг 1: Генерация ключей

На локальном компьютере выполните команду. Мы будем использовать алгоритм Ed25519, так как он быстрее и безопаснее старого RSA.

ssh-keygen -t ed25519 -C "admin@workstation"

Система предложит выбрать место сохранения (по умолчанию ~/.ssh/id_ed25519) и ввести кодовую фразу (passphrase). Кодовая фраза шифрует сам файл ключа на диске, добавляя второй фактор защиты. Если злоумышленник украдет файл ключа, он не сможет им воспользоваться без пароля.

В результате в папке ~/.ssh/ появятся два файла:

id_ed25519 — Приватный ключ. Храните его как зеницу ока. Никогда никому не передавайте.
id_ed25519.pub — Публичный ключ. Его можно и нужно передавать на серверы.

Шаг 2: Копирование ключа на сервер

Самый простой способ передать публичный ключ на сервер — утилита ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.1.10

Эта команда автоматически добавит содержимое вашего .pub файла в файл ~/.ssh/authorized_keys на удаленном сервере и выставит правильные права доступа.

Если утилиты нет (например, вы работаете из Windows PowerShell), скопировать ключ можно вручную:

cat ~/.ssh/id_ed25519.pub | ssh user@192.168.1.10 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Шаг 3: Проверка и отключение паролей

Попробуйте подключиться к серверу:

ssh user@192.168.1.10

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

Теперь необходимо отключить вход по паролю, чтобы полностью исключить возможность брутфорса. В файле /etc/ssh/sshd_config на сервере установите:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Перезапустите SSH. Теперь сервер будет отвергать любые попытки входа без наличия правильного приватного ключа.

Права доступа к файлам (Permissions)

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

Эталонные права доступа:

Объект	Права (Octal)	Описание
Папка `~/.ssh`	`700` (`drwx------`)	Доступ только владельцу
Файл `authorized_keys`	`600` (`-rw-------`)	Чтение/запись только владельцу
Приватный ключ `id_ed25519`	`600` (`-rw-------`)	Чтение/запись только владельцу
Публичный ключ `id_ed25519.pub`	`644` (`-rw-r--r--`)	Можно читать всем

Исправить права можно командами:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Упрощение работы: SSH Config

Администрируя десятки серверов, сложно запоминать IP-адреса, порты и имена пользователей. Для этого на клиенте существует файл конфигурации ~/.ssh/config.

Пример настройки:

Host web-prod
    HostName 203.0.113.10
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

Host db-local
    HostName 192.168.1.50
    User postgres

Теперь вместо длинной команды ssh -p 2222 admin@203.0.113.10 достаточно набрать:

ssh web-prod

Защита от перебора: Fail2Ban

Даже если вы отключили вход по паролям, боты могут продолжать стучаться в порт, создавая нагрузку и засоряя логи. Для борьбы с этим используется утилита Fail2Ban.

Она анализирует логи /var/log/auth.log, находит IP-адреса, совершающие подозрительные действия (многократные ошибки аутентификации), и автоматически добавляет правило в Firewall (iptables/nftables) для блокировки этого IP на заданное время.

Установка:

sudo apt install fail2ban

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

Итоги

Настройка SSH — это первый рубеж обороны любого сервера. Грамотная конфигурация делает взлом системы практически невозможным для автоматических сканеров и скрипт-кидди.

Криптография: Используйте ключи вместо паролей. Математическая стойкость ключа ( $2^{256}$ ) несоизмеримо выше стойкости пароля ( $62^8$ ).
Конфигурация: Отключите PermitRootLogin и PasswordAuthentication в файле sshd_config.
Ключи: Генерируйте ключи алгоритмом Ed25519. Приватный ключ всегда остается на клиенте, публичный копируется на сервер в authorized_keys.
Права доступа: Следите за правами chmod 700 на папку .ssh и 600 на файлы ключей. Неверные права — самая частая причина отказа в доступе.
Удобство: Используйте файл ~/.ssh/config для создания алиасов подключений.