Основы компьютерных сетей и Linux для создания локального сервера

Практический курс для новичков, который за 5 шагов проведёт от первого знакомства с терминалом Linux до работающего локального веб-сервера. Курс фокусируется на ключевых концепциях, которые часто спрашивают на технических собеседованиях, и включает чек-листы и конкретные команды для быстрого освоения.

1. Основы работы в терминале Linux: навигация, файлы и базовые команды

Безопасность и проверка работоспособности сервера

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

Философия безопасности: модель угроз для новичка

Прежде чем ставить замки, нужно понять, от кого и чего мы защищаемся. Для локального сервера угрозы делятся на три категории:

  • Сетевые атаки извне (даже в локальной сети!): сканирование портов, попытки подбора паролей, эксплуатация уязвимостей в ПО.
  • Ошибки конфигурации: открытые по умолчанию порты, слабые пароли, избыточные права доступа у сервисов.
  • Отказ в обслуживании (DoS): исчерпание ресурсов процессора, памяти или диска из-за сбоя или атаки.
  • Ваша задача — не построить неприступную крепость (это задача для продакшн-серверов в дата-центрах), а закрыть очевидные дыры и научиться видеть состояние системы.

    Первая линия обороны: межсетевой экран (Firewall)

    Межсетевой экран — это фильтр, который анализирует входящий и исходящий сетевой трафик и пропускает или блокирует его по заданным правилам. В Linux стандартом является UFW (Uncomplicated Firewall) — упрощенная надстройка над более сложным iptables.

    Принцип работы: «Все запрещено, кроме явно разрешенного». Представьте nightclub с охранником: без имени в списке — не войти.

    Практическая настройка UFW:

    > Важно: Если вы подключены к серверу по SSH, правило allow ssh ОБЯЗАТЕЛЬНО должно быть добавлено ДО включения UFW. Иначе вы мгновенно потеряете доступ.

    Укрепление SSH: ключи вместо паролей

    SSH (Secure Shell) — протокол для удаленного управления сервером. Атаки на SSH с подбором паролей (brute-force) — самые распространенные в мире. Решение — аутентификация по SSH-ключам.

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

    Пошаговая настройка:

  • На вашем локальном компьютере (не на сервере!) сгенерируйте пару ключей:
  • Скопируйте публичный ключ на сервер:
  • На сервере отключите аутентификацию по паролю в конфигурации SSH:
  • Теперь для входа на сервер потребуется только ваш приватный ключ и его passphrase.

    Мониторинг: глаза и уши администратора

    Вы не можете управлять тем, что не можете измерить. Базовый мониторинг — это регулярная проверка трех китов: ресурсов системы, сетевой активности и состояния сервисов.

    Ключевые команды для диагностики

    | Команда | Что показывает | Когда использовать | | :--- | :--- | :--- | | htop / top | Загрузку CPU, памяти, список процессов | Сервер «тормозит», высокая нагрузка | | df -h | Занятое место на дисках | Ошибки записи, полный диск | | free -h | Использование оперативной памяти и swap | Нехватка памяти, OOM-killer | | ss -tuln | Все открытые сетевые порты и слушающие сервисы | Проверка, что работает только нужное | | journalctl -u nginx --since "1 hour ago" | Логи конкретного сервиса за последний час | Ошибки веб-сервера | | last | Историю входов в систему | Обнаружение несанкционированного доступа |

    Проверка работоспособности веб-сервера

    После настройки Nginx или Apache (как в предыдущей статье) необходимо провести комплексную проверку:

  • Локальная проверка на сервере:
  • Проверка из локальной сети:
  • Проверка доступности портов:
  • Проверка логов в реальном времени:
  • Автоматизация и регулярные задачи

    Безопасность — это процесс, а не состояние. Два критически важных шага:

  • Обновления безопасности: Регулярно обновляйте систему и ПО.
  • Резервное копирование (бэкапы): Самая важная защита от человеческой ошибки и атак-шифровальщиков. Простой сценарий — копирование конфигурационных файлов:
  • Чек-лист для проверки безопасности вашего сервера

  • [ ] Межсетевой экран (UFW) включен, разрешены только порты 22 (SSH), 80 (HTTP), 443 (HTTPS)
  • [ ] Аутентификация по SSH-ключам включена, парольная аутентификация отключена
  • [ ] Установлены последние обновления безопасности (apt upgrade)
  • [ ] Проверены открытые порты командой ss -tuln — нет ничего лишнего
  • [ ] Настроено регулярное резервное копирование критичных данных
  • [ ] Проверены логи на наличие ошибок и подозрительных активностей
  • [ ] Веб-сервер отвечает на HTTP-запросы и отдает корректные заголовки
  • После прохождения этого чек-листа ваш сервер из «игрушечного» превращается в учебный стенд, максимально приближенный к реальным условиям. Вы не просто знаете команды — вы понимаете, почему каждая настройка существует и какую угрозу она нивелирует. Именно это понимание и ценится на техническом собеседовании выше, чем заучивание команд наизусть.

    2. Базовые концепции компьютерных сетей: IP, порты и протоколы

    Базовые концепции компьютерных сетей: IP, порты и протоколы

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

    IP-адрес: почтовый индекс для компьютеров

    IP-адрес (Internet Protocol Address) — это уникальный числовой идентификатор устройства в сети. Работает как почтовый адрес: чтобы доставить письмо, почте нужен конкретный адрес дома, а не просто имя получателя. Без IP-адреса компьютер в сети невидим — к нему невозможно обратиться, и он сам не может никуда отправить данные.

    Существует две версии IP-адресации:

    IPv4 — классический формат, состоящий из четырёх чисел от 0 до 255, разделённых точками. Пример: 192.168.1.10. Каждое число занимает 8 бит (1 байт), итого 32 бита. Это даёт примерно 4,3 миллиарда уникальных адресов — звучит много, но интернет-провайдеры и компании давно исчерпали свободный пул.

    IPv6 — новый формат, записываемый как восемь групп шестнадцатеричных чисел через двоеточие. Пример: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Обеспечивает уникальных адресов — достаточно, чтобы присвоить IP каждому атому на поверхности Земли. Для локального сервера и собеседования вам достаточно уверенно работать с IPv4.

    Два типа адресов: публичный и приватный

    Публичный IP — адрес, видимый из интернета. Его выдаёт провайдер, и он уникален в глобальной сети. Именно по нему внешние пользователи обращаются к вашему серверу, если он доступен извне.

    Приватный IP — адрес внутри локальной сети, невидимый из интернета. Диапазоны приватных адресов зарезервированы стандартом RFC 1918:

    | Диапазон | Маска | Типичное использование | | :--- | :--- | :--- | | 10.0.0.010.255.255.255 | /8 | Крупные корпоративные сети | | 172.16.0.0172.31.255.255 | /12 | Средние сети | | 192.168.0.0192.168.255.255 | /16 | Домашние роутеры, малые сети |

    Когда ваш ноутбук подключается к домашнему Wi-Fi, роутер выдаёт ему адрес вроде 192.168.1.105. Это приватный адрес — он работает только внутри вашей квартиры. Для выхода в интернет роутер выполняет NAT (Network Address Translation) — подменяет приватный адрес на публичный при отправке запросов и возвращает ответы обратно на нужное устройство.

    Маска подсети: границы территории

    Маска подсети (Subnet Mask) определяет, какая часть IP-адреса обозначает сеть, а какая — конкретное устройство внутри неё. Представьте жилой комплекс: первые цифры адреса — это номер комплекса (сеть), последние — номер квартиры (хост).

    Маска записывается как четыре числа или как число после косой черты (CIDR-нотация). Например:

  • 192.168.1.10/24 — маска 255.255.255.0. Первые 24 бита — сеть, последние 8 — хост. В такой подсети может быть до 254 устройств (256 минус адрес сети и широковещательный адрес).
  • 10.0.0.5/8 — маска 255.0.0.0. Первые 8 бит — сеть, остальные 24 — хост. Потенциально более 16 миллионов устройств.
  • Для локального сервера в домашней или офисной сети вы почти всегда работаете с /24 — это стандарт для небольших сетей.

    Порт: номер комнаты на этаже

    Если IP-адрес — это адрес здания, то порт — это номер комнаты в этом здании. Компьютер может одновременно запускать десятки сервисов: веб-сервер, SSH-сервер, базу данных, почтовый сервер. Каждый из них слушает свой порт, и сетевые запросы направляются именно тому сервису, который их ждёт.

    Порт — это число от 0 до 65535. Диапазоны делятся на три категории:

  • 0–1023 — системные (привилегированные) порты. Закреплены за стандартными сервисами: 80 — HTTP, 443 — HTTPS, 22 — SSH, 53 — DNS. Для запуска сервиса на таком порту нужны права суперпользователя.
  • 1024–49151 — зарегистрированные порты. Назначаются конкретному ПО: 3306 — MySQL, 5432 — PostgreSQL, 8080 — часто используется для альтернативного веб-сервера.
  • 49152–65535 — динамические (эфемерные) порты. Операционная система автоматически назначает их клиентским приложениям при исходящих подключениях.
  • На собеседовании часто спрашивают: «Какой порт использует Apache по умолчанию?» — 80 для HTTP и 443 для HTTPS. «Какой порт у SSH?» — 22. Эти знания должны быть на уровне рефлекса.

    Протоколы: языки общения

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

    Модель OSI и TCP/IP

    Теоретически сетевое взаимодействие описывается моделью OSI из семи уровней: от физического (кабели, сигналы) до прикладного (браузер, почтовый клиент). На практике используется упрощённая модель TCP/IP из четырёх уровней. На собеседовании могут спросить про обе — важно понимать, что OSI это теоретическая модель, а TCP/IP это то, что реально работает.

    Для вашей задачи важны два протокола транспортного уровня:

    TCP (Transmission Control Protocol) — протокол с установлением соединения и гарантией доставки. Перед передачей данных устройства «договариваются» через тройное рукопожатие (three-way handshake): SYN → SYN-ACK → ACK. Если пакет потерян, TCP запросит повторную отправку. Используется для всего, где важна точность: веб-страницы, файлы, электронная почта, SSH.

    UDP (User Datagram Protocol) — протокол без установления соединения. Данные отправляются сразу, без гарантий доставки и порядка. Быстрее, но ненадёжнее. Используется для DNS-запросов, видеозвонков, онлайн-игр — везде, где скорость важнее идеальной точности.

    > Представьте разницу так: TCP — это заказное письмо с уведомлением о вручении. UDP — это открытка, брошенная в почтовый ящик: может дойти, может нет, но отправляется мгновенно.

    DNS: телефонная книга интернета

    DNS (Domain Name System) — система, которая преобразует доменные имена в IP-адреса. Когда вы вводите google.com, DNS-сервер возвращает IP-адрес вроде 142.250.74.46, и браузер подключается уже к нему.

    Без DNS вам пришлось бы запоминать IP-адреса всех сайтов. DNS работает на порту 53 и использует преимущественно UDP.

    Как всё работает вместе: запрос веб-страницы

    Когда вы вводите http://192.168.1.100 в браузере, происходит следующее:

  • Браузер создаёт TCP-соединение с хостом 192.168.1.100 на порту 80 (стандарт для HTTP).
  • По установленному соединению отправляется HTTP-запрос — текстовое сообщение вида GET / HTTP/1.1.
  • Веб-сервер на 192.168.1.100 получает запрос на порту 80, обрабатывает его и отправляет обратно HTTP-ответ с содержимым страницы.
  • Браузер отображает полученную HTML-страницу.
  • Каждый элемент — IP (куда обращаемся), порт (какому сервису), протокол TCP (как гарантируем доставку) и HTTP (какой формат запроса) — работает как шестерёнки в одном механизме.

    Диагностические команды

    Для проверки сетевых параметров в Linux используются несколько инструментов:

    Команда ss заменила устаревшую netstat и показывает все слушающие (LISTEN) TCP и UDP сокеты. Флаг -p покажет, какой именно процесс держит порт — критически полезно при отладке.

    Чек-лист базовых сетевых концепций

  • [ ] Могу объяснить разницу между публичным и приватным IP-адресом
  • [ ] Знаю зарезервированные диапазоны приватных адресов (10.x, 172.16–31.x, 192.168.x)
  • [ ] Понимаю, что маска подсети /24 означает 255.255.255.0 и ~254 хоста
  • [ ] Знаю стандартные порты: 22 (SSH), 80 (HTTP), 443 (HTTPS), 53 (DNS)
  • [ ] Могу объяснить разницу между TCP и UDP на бытовом примере
  • [ ] Понимаю, зачем нужен DNS и на каком порту он работает
  • [ ] Умею использовать ip addr, ping, ss -tuln для диагностики
  • 3. Настройка сетевых интерфейсов и IP-адресации в Linux

    Настройка сетевых интерфейсов и IP-адресации в Linux

    Вы знаете, что такое IP-адрес и порт, но как заставить Linux использовать конкретный адрес? Большинство проблем с локальным сервером — не в сложном ПО, а в неправильно назначенном IP: сервер работает, но к нему невозможно подключиться, потому что он сидит на адресе 127.0.0.1 вместо адреса локальной сети. В этой статье мы разберём, как Linux видит сеть, как назначать адреса и как убедиться, что ваш сервер действительно доступен другим машинам.

    Сетевые интерфейсы: точки входа в сеть

    Сетевой интерфейс — это абстракция, через которую операционная система взаимодействует с сетью. Каждый интерфейс — это либо реальное сетевое оборудование (Ethernet-карта, Wi-Fi-адаптер), либо виртуальное устройство.

    Стандартные интерфейсы в Linux:

  • lo (loopback) — виртуальный интерфейс, всегда имеет адрес 127.0.0.1. Используется для связи программы с самой собой на том же хосте. Когда вы делаете curl http://localhost, запрос идёт именно через lo.
  • eth0 (или enp0s3, ens33) — проводное Ethernet-соединение. Нумерация зависит от дистрибутива и способа именования.
  • wlan0 (или wlp2s0) — беспроводное Wi-Fi-соединение.
  • > Именование интерфейсов изменилось в последних версиях systemd: вместо простых eth0 используются предdictable names вроде enp0s3 (Ethernet, PCI bus 0, slot 3). На собеседовании могут спросить об этом — это не баг, а осознанное решение для предотвращения конфликтов имён при добавлении нового оборудования.

    Просмотр интерфейсов

    Вывод ip addr show содержит критически важную информацию:

    Здесь enp0s3 — имя интерфейса, 192.168.1.105/24 — IP-адрес с маской подсети, brd 192.168.1.255 — широковещательный адрес. Флаг UP означает, что интерфейс активен.

    Способы назначения IP-адреса

    В Linux существует два принципиально разных подхода к назначению адресов:

    DHCP: автоматическое назначение

    DHCP (Dynamic Host Configuration Protocol) — протокол автоматической настройки сетевых параметров. Когда компьютер подключается к сети, DHCP-клиент отправляет широковещательный запрос, а DHCP-сервер (обычно на роутере) отвечает, выдавая IP-адрес, маску подсети, адрес шлюза и DNS-серверы.

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

    Статический IP: фиксированный адрес

    Статический IP-адрес — адрес, назначенный вручную и не меняющийся со временем. Для сервера это обязательное условие: клиенты должны знать, куда обращаться.

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

    Настройка статического IP в Ubuntu (Netplan)

    Начиная с Ubuntu 18.04, сетевые настройки управляются через Netplan — систему, которая генерирует конфигурацию для сетевых демонов (NetworkManager или systemd-networkd).

    Конфигурационные файлы Netplan находятся в /etc/netplan/. Обычно там лежит один файл с расширением .yaml.

    Пошаговая настройка

  • Определите текущие сетевые параметры:
  • Откройте конфигурационный файл:
  • Запишите конфигурацию со статическим адресом:
  • Разберём каждую строку: - dhcp4: no — отключаем автоматическое получение адреса по DHCP. - addresses — статический IP с маской подсети. Выберите адрес в диапазоне вашей локальной сети, который не занят другим устройством. - routesvia — адрес шлюза (роутера), через который идёт трафик в другие сети и интернет. - nameservers — DNS-серверы. 8.8.8.8 — Google DNS, 1.1.1.1 — Cloudflare DNS.

  • Примените настройки:
  • > Важно: команда netplan try применяет настройки временно. Если вы потеряете доступ, через 120 секунд настройки автоматически откатятся. Это спасение, если вы ошиблись в адресе. Всегда используйте try перед apply.

  • Проверьте результат:
  • Настройка статического IP в CentOS/RHEL (nmcli)

    В дистрибутивах на базе Red Hat сетью управляет NetworkManager. Настройка через командную строку:

    Маршрутизация: как пакеты находят путь

    Маршрут — правило, определяющее, через какой интерфейс и на какой шлюз отправить пакет в зависимости от адреса назначения. Таблица маршрутизации — это набор таких правил.

    Типичный вывод:

    Первая строка: «всё, что не подпадает под другие правила, отправляй через шлюз 192.168.1.1». Вторая строка: «устройства в подсети 192.168.1.0/24 доступны напрямую через интерфейс enp0s3».

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

    Проверка доступности: кто видит ваш сервер

    После настройки статического IP нужно убедиться, что сервер доступен из локальной сети:

    Если ping проходит, но подключение к порту нет — проблема не в сети, а в firewall или в том, что сервис не запущен. Это разделение диагностики критически важно: сначала проверяете связность (ping), потом доступность порта (nc/ss), потом работу сервиса (curl/journalctl).

    Имена хостов и файл hosts

    IP-адрес 192.168.1.100 запомнить сложно. Файл /etc/hosts позволяет назначить имя локальному адресу без DNS-сервера:

    Добавьте строку:

    Теперь на любом компьютере в сети (с аналогичной записью в hosts) можно обращаться к серверу по имени: ping myserver.local, http://myserver.local. Для локальной разработки это удобнее, чем помнить цифры.

    Чек-лист настройки сетевых интерфейсов

  • [ ] Знаю имя своего сетевого интерфейса (ip a)
  • [ ] Могу объяснить разницу между DHCP и статическим IP
  • [ ] Настроил статический IP через Netplan (Ubuntu) или nmcli (CentOS)
  • [ ] Указал корректный шлюз и DNS-серверы
  • [ ] Проверил связность с шлюзом (ping 192.168.1.1) и интернетом (ping 8.8.8.8)
  • [ ] Проверил доступность сервера с другого компьютера в сети
  • [ ] Настроил запись в /etc/hosts для удобного обращения по имени
  • 4. Установка и конфигурация веб-сервера (Apache/Nginx)

    Установка и конфигурация веб-сервера (Apache/Nginx)

    Сеть настроена, адрес назначен, но сервер — это не просто компьютер с IP-адресом. Это программа, которая слушает порт, принимает HTTP-запросы и отдаёт ответы: HTML-страницы, файлы, API-ответы. Без веб-сервера ваш компьютер — это дом без двери: адрес есть, но зайти невозможно. На собеседовании выбор между Apache и Nginx и умение объяснить, почему вы выбрали конкретный вариант, часто становится тем самым вопросом, который отделяет «читал» от «делал».

    Apache vs Nginx: два подхода к одной задаче

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

    Apache HTTP Server — старейший и наиболее гибкий веб-сервер. Работает по модели процесс-на-запрос: каждый входящий запрос обрабатывается отдельным процессом или потоком. Главная сила Apache — .htaccess файлы, позволяющие настраивать поведение сервера на уровне отдельных директорий без перезагрузки. Это удобно для хостингов, где множество сайтов с разными настройками работают на одном сервере.

    Nginx (Engine-X) — создавался как ответ на проблему C10K (одновременное обслуживание 10 000 соединений). Использует асинхронную событийно-ориентированную модель: один рабочий процесс обрабатывает тысячи соединений неблокирующим способом. Nginx потребляет меньше памяти, быстрее отдаёт статический контент и эффективнее работает как обратный прокси-сервер.

    | Критерий | Apache | Nginx | | :--- | :--- | :--- | | Модель обработки | процесс/поток на соединение | событийная, неблокирующая | | Статический контент | Хорошо | Отлично | | Динамический контент | Встроенные модули (mod_php) | Через внешний процесс (PHP-FPM) | | Конфигурация | .htaccess + основной конфиг | Только основной конфиг | | Потребление памяти | Выше при большой нагрузке | Ниже | | Обратный прокси | Через модули | Встроенная, нативная функция |

    > Для локального сервера и обучения разница не критична. Но если на собеседовании спросят «почему Nginx?», правильный ответ: «Потому что он эффективнее работает с большим числом одновременных соединений и лучше подходит как reverse proxy перед приложениями». Если спросят «почему Apache?» — «Потому что гибкая конфигурация через .htaccess и встроенная поддержка динамических языков».

    Установка Nginx

    После установки Nginx автоматически запускается и начинает слушать порт 80. Откройте браузер и перейдите по адресу http://ip_вашего_сервера — вы увидите приветственную страницу Nginx.

    Базовые команды управления

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

    Структура конфигурации Nginx

    Конфигурационные файлы Nginx расположены в /etc/nginx/. Ключевые файлы и директории:

    Паттерн sites-available / sites-enabled работает так: вы создаёте конфигурацию в sites-available, а затем создаёте символическую ссылку в sites-enabled, чтобы активировать её. Чтобы отключить сайт, достаточно удалить ссылку — конфигурация сохраняется, но сервер её не использует.

    Настройка первого виртуального хоста

    Виртуальный хост — механизм, позволяющий одному серверу Nginx обслуживать несколько сайтов, различая их по имени домена или порту. Представьте один reception desk в здании, который направляет посетителей в нужный офис по имени компании.

    Шаг 1: Создайте директорию для сайта

    Шаг 2: Создайте тестовую страницу

    Шаг 3: Создайте конфигурацию виртуального хоста

    Разберём директивы:

  • listen 80 — сервер слушает порт 80 (HTTP).
  • server_name — обрабатывает запросы с заголовком Host: mysite.local.
  • root — директория с файлами сайта.
  • index — файл, отдаваемый по умолчанию при запросе директории.
  • location / — обработка запросов к корню и вложенным путям. try_files сначала ищет файл, затем директорию, иначе возвращает 404.
  • access_log и error_log — пути к логам. При отладке это первое место, куда нужно смотреть.
  • Шаг 4: Активируйте сайт

    Шаг 5: Настройте DNS-разрешение

    Добавьте запись в /etc/hosts на клиентской машине (или на сервере для локальной проверки):

    Проверьте: http://mysite.local в браузере должен показать вашу тестовую страницу.

    Установка Apache (альтернатива)

    Если вы выбрали Apache:

    Конфигурация Apache устроена иначе — основной файл /etc/apache2/apache2.conf, виртуальные хосты в /etc/apache2/sites-available/, а .htaccess файлы позволяют переопределять настройки прямо в директориях сайта.

    Команда a2ensite (Apache 2 Enable Site) делает то же, что ручное создание символической ссылки в Nginx — включает виртуальный хост.

    Обслуживание статических и динамических файлов

    Nginx и Apache отлично отдают статический контент: HTML, CSS, JavaScript, изображения. Но что если нужна динамика — например, страница, генерируемая на Python или PHP?

    Статический контент — файлы, которые отдаются как есть, без обработки сервером. Nginx делает это исключительно эффективно.

    Динамический контент — ответы, генерируемые программным кодом при каждом запросе. Для этого используется связка веб-сервера с интерпретатором:

  • PHP: Nginx → PHP-FPM (FastCGI Process Manager). Nginx передаёт запросы к .php файлам процессу PHP-FPM, который выполняет код и возвращает результат.
  • Python: Nginx → Gunicorn/uWSGI. Nginx выступает как reverse proxy перед WSGI-сервером.
  • Node.js: Nginx → Node.js приложение. Аналогично, Nginx проксирует запросы.
  • Для локального сервера и подготовки к собеседованию достаточно понимать принцип: веб-сервер принимает запрос, определяет, статический это файл или динамический, и либо отдаёт файл напрямую, либо передаёт обработку внешнему процессу.

    Логирование: ваши глаза

    Логи — это первое, что нужно проверить при любой проблеме. Nginx пишет два типа логов:

  • access.log — каждый запрос: IP клиента, время, HTTP-метод, URL, код ответа, размер ответа.
  • error.log — ошибки: проблемы с конфигурацией, отказы в доступе, сбои бэкенда.
  • При любой неожиданной ошибке 502 (Bad Gateway), 403 (Forbidden) или 404 (Not Found) первым делом открывайте логи — они почти всегда содержат точное описание причины.

    Чек-лист установки и настройки веб-сервера

  • [ ] Могу объяснить разницу между Apache и Nginx (архитектура, сильные стороны)
  • [ ] Установил веб-сервер и проверил его работу (systemctl status, браузер)
  • [ ] Создал директорию для сайта с корректными правами доступа
  • [ ] Настроил виртуальный хост с указанием server_name, root, index
  • [ ] Проверил конфигурацию на ошибки (nginx -t или apachectl configtest)
  • [ ] Активировал сайт и перезагрузил конфигурацию
  • [ ] Проверил доступность сайта через браузер и curl
  • [ ] Знаю расположение логов и умею их читать
  • 5. Безопасность и проверка работоспособности сервера

    Безопасность и проверка работоспособности сервера

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

    Философия безопасности: модель угроз для новичка

    Прежде чем ставить замки, нужно понять, от кого и чего мы защищаемся. Для локального сервера угрозы делятся на три категории:

  • Сетевые атаки извне (даже в локальной сети!): сканирование портов, попытки подбора паролей, эксплуатация уязвимостей в ПО.
  • Ошибки конфигурации: открытые по умолчанию порты, слабые пароли, избыточные права доступа у сервисов.
  • Отказ в обслуживании (DoS): исчерпание ресурсов процессора, памяти или диска из-за сбоя или атаки.
  • Ваша задача — не построить неприступную крепость (это задача для продакшн-серверов в дата-центрах), а закрыть очевидные дыры и научиться видеть состояние системы.

    Первая линия обороны: межсетевой экран (Firewall)

    Межсетевой экран — это фильтр, который анализирует входящий и исходящий сетевой трафик и пропускает или блокирует его по заданным правилам. В Linux стандартом является UFW (Uncomplicated Firewall) — упрощённая надстройка над более сложным iptables.

    Принцип работы: «Всё запрещено, кроме явно разрешённого». Представьте nightclub с охранником: без имени в списке — не войти.

    Практическая настройка UFW:

    > Важно: Если вы подключены к серверу по SSH, правило allow ssh ОБЯЗАТЕЛЬНО должно быть добавлено ДО включения UFW. Иначе вы мгновенно потеряете доступ.

    Укрепление SSH: ключи вместо паролей

    SSH (Secure Shell) — протокол для удалённого управления сервером. Атаки на SSH с подбором паролей (brute-force) — самые распространённые в мире. Решение — аутентификация по SSH-ключам.

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

    Пошаговая настройка:

  • На вашем локальном компьютере (не на сервере!) сгенерируйте пару ключей:
  • Скопируйте публичный ключ на сервер:
  • На сервере отключите аутентификацию по паролю в конфигурации SSH:
  • Теперь для входа на сервер потребуется только ваш приватный ключ и его passphrase.

    Мониторинг: глаза и уши администратора

    Вы не можете управлять тем, что не можете измерить. Базовый мониторинг — это регулярная проверка трёх китов: ресурсов системы, сетевой активности и состояния сервисов.

    Ключевые команды для диагностики

    | Команда | Что показывает | Когда использовать | | :--- | :--- | :--- | | htop / top | Загрузку CPU, памяти, список процессов | Сервер «тормозит», высокая нагрузка | | df -h | Занятое место на дисках | Ошибки записи, полный диск | | free -h | Использование оперативной памяти и swap | Нехватка памяти, OOM-killer | | ss -tuln | Все открытые сетевые порты и слушающие сервисы | Проверка, что работает только нужное | | journalctl -u nginx --since "1 hour ago" | Логи конкретного сервиса за последний час | Ошибки веб-сервера | | last | Историю входов в систему | Обнаружение несанкционированного доступа |

    Проверка работоспособности веб-сервера

    После настройки Nginx или Apache необходимо провести комплексную проверку:

  • Локальная проверка на сервере:
  • Проверка из локальной сети:
  • Проверка доступности портов:
  • Проверка логов в реальном времени:
  • Автоматизация и регулярные задачи

    Безопасность — это процесс, а не состояние. Два критически важных шага:

  • Обновления безопасности: Регулярно обновляйте систему и ПО.
  • Резервное копирование (бэкапы): Самая важная защита от человеческой ошибки и атак-шифровальщиков. Простой сценарий — копирование конфигурационных файлов:
  • Чек-лист для проверки безопасности вашего сервера

  • [ ] Межсетевой экран (UFW) включён, разрешены только порты 22 (SSH), 80 (HTTP), 443 (HTTPS)
  • [ ] Аутентификация по SSH-ключам включена, парольная аутентификация отключена
  • [ ] Установлены последние обновления безопасности (apt upgrade)
  • [ ] Проверены открытые порты командой ss -tuln — нет ничего лишнего
  • [ ] Настроено регулярное резервное копирование критичных данных
  • [ ] Проверены логи на наличие ошибок и подозрительных активностей
  • [ ] Веб-сервер отвечает на HTTP-запросы и отдаёт корректные заголовки
  • После прохождения этого чек-листа ваш сервер из «игрушечного» превращается в учебный стенд, максимально приближённый к реальным условиям. Вы не просто знаете команды — вы понимаете, почему каждая настройка существует и какую угрозу она нивелирует. Именно это понимание и ценится на техническом собеседовании выше, чем заучивание команд наизусть.