Блок 12

Сети в Linux

Мы уже несколько раз упоминали сетевые понятия на протяжении курса — сеть виртуальной машины в Блоке 2, файл /etc/hosts» в Блоке 7, — но никогда не раскрывали тему сетей полноценно. В этом блоке мы…

Обновлено: 23 июля 2026 · DeeNet

Введение в блок

Мы уже несколько раз упоминали сетевые понятия на протяжении курса — сеть виртуальной машины в Блоке 2, файл `/etc/hosts» в Блоке 7, — но никогда не раскрывали тему сетей полноценно. В этом блоке мы разберём базовые принципы работы компьютерных сетей простыми словами, освоим настройку сети в Ubuntu, разберёмся, как работает DHCP и DNS, и научимся пользоваться основными инструментами сетевой диагностики. Этот блок — необходимая подготовка к Блоку 13 (SSH), Блоку 14 (безопасность) и Блоку 19 (веб-сервер), где сетевые знания будут применяться постоянно.

Урок 12.1. Основы сетей: IP-адрес, маска подсети, шлюз — простыми словами

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

Теория

Представьте обычную почтовую систему в реальном мире. Чтобы отправить письмо конкретному человеку, вам нужен его точный адрес — улица, дом, квартира. Компьютерные сети работают по похожему принципу.

IP-адрес (Internet Protocol address) — это уникальный числовой «адрес» устройства в сети, по которому другие устройства могут его найти и отправить ему данные, аналогично тому, как почтовый адрес позволяет найти конкретный дом. В наиболее распространённой сегодня версии протокола, IPv4, адрес записывается в виде четырёх чисел от 0 до 255, разделённых точками, например 192.168.1.10. Каждое из этих четырёх чисел называется октетом (так как оно вписывается в 8 бит компьютерной памяти, а 2 в восьмой степени как раз и равно 256 — количеству возможных значений от 0 до 255).

Маска подсети (subnet mask) — это дополнительное число (тоже записываемое в том же четырёхоктетном формате, например 255.255.255.0), которое определяет, какая часть IP-адреса относится к «сети» (аналогично номеру улицы, общему для всех домов на ней), а какая — к конкретному «узлу» внутри этой сети (аналогично номеру конкретного дома на этой улице). Маска 255.255.255.0» означает, что первые три числа адреса (например, 192.168.1) определяют саму сеть, а последнее число (в нашем примере — 10) — это конкретное устройство внутри этой сети. Это, в свою очередь, означает, что все устройства с адресами от 192.168.1.1» до 192.168.1.254» (адреса .0» и `.255» обычно зарезервированы для специальных, служебных целей) находятся в одной, общей локальной сети и могут напрямую «видеть» и обращаться друг к другу, без необходимости выхода за пределы этой сети.

Более компактная, широко распространённая альтернативная запись маски подсети — CIDR-нотация (Classless Inter-Domain Routing), где вместо полной записи маски указывается просто число после слэша, обозначающее количество «единичных» битов в маске: например, 192.168.1.10/24» — это то же самое, что и адрес 192.168.1.10» с маской `255.255.255.0» (число 24 означает, что первые 24 из 32 битов адреса относятся к сети, что как раз соответствует первым трём октетам из четырёх).

Шлюз (gateway, часто также называемый «шлюзом по умолчанию», default gateway) — это устройство (обычно роутер), через которое устройства локальной сети отправляют данные, предназначенные для узлов за пределами этой локальной сети — например, для любого сайта в интернете. Продолжая почтовую аналогию: если письмо адресовано кому-то на той же улице, почтальон может доставить его напрямую; но если адресат находится в другом городе, письмо сначала отправляется на центральную сортировочную станцию (аналог шлюза), которая знает, как переслать его дальше, в нужном направлении, к месту назначения.

Практика

Шаг 1. Определите IP-адрес вашей виртуальной машины с помощью команды ip», которую мы подробнее разберём в следующем уроке (здесь используем лишь простейший вариант для начального знакомства): ip a» (address, «адрес» — сокращённая форма записи).

Что вы увидите: список сетевых интерфейсов вашей виртуальной машины (обычно как минимум lo» — «loopback», локальный, «петлевой» интерфейс, используемый компьютером для обращения самого к себе, и ещё один интерфейс, обычно называемый чем-то вроде enp0s3» или eth0, представляющий реальное сетевое подключение) вместе с их IP-адресами в формате CIDR-нотации, изученной в теории этого урока.

[Скриншот терминала]

Шаг 2. Найдите в выводе строку с адресом вашего основного сетевого интерфейса (не lo) и запишите в конспект полный адрес вместе с указанным после слэша числом (например, 10.0.2.15/24).

Шаг 3. Определите ваш шлюз по умолчанию с помощью команды ip route» (маршрут, тему которой подробнее затронем и в этом же блоке, и особенно в Блоке 20): ip route».

Что вы увидите: список маршрутов, среди которых должна быть строка, начинающаяся со слова `default» — это и есть указание на используемый вашей системой шлюз по умолчанию.

[Скриншот результата]

Разбор команд

Команда ip

• Назначение:** современный, комплексный инструмент для просмотра и настройки сетевых параметров в Linux, постепенно заменивший более старый набор отдельных команд (ifconfig, route и другие), с которым вы всё ещё можете столкнуться в старых руководствах или на более старых системах.
• Синтаксис:** ip [объект] [команда]
• Основные параметры:** a» или addr» (показать сетевые адреса); `route» (показать таблицу маршрутизации).
• Подробно эту команду мы продолжим разбирать в следующем уроке.

Возможные ошибки

• Ошибка:** путаница между понятием «IP-адрес устройства» и «IP-адрес сайта/сервера», особенно на начальном этапе знакомства с темой.

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

Как определить: непонимание, почему у вашего собственного компьютера есть один IP-адрес, а сайты в интернете при этом «имеют» какие-то другие, совершенно иные адреса.

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

Как избежать: запомнить, что IP-адрес — универсальное понятие, применимое к любому устройству в сети, а не какая-то характеристика, специфичная исключительно для «интернет-сайтов».

Практические задания

1. Выполните ip a» и ip route» на своей системе, запишите в конспект найденный IP-адрес и адрес шлюза по умолчанию.
2. Своими словами объясните в конспекте, чем принципиально отличаются устройства, находящиеся «в одной сети» (могут обращаться друг к другу напрямую), от устройств «в разных сетях» (требующих шлюза для взаимодействия), опираясь на понятие маски подсети.
3. Переведите маску 255.255.0.0» в CIDR-нотацию (число после слэша) самостоятельно, порассуждав, сколько октетов при такой маске относится к «сети», а сколько — к конкретному устройству внутри неё (подсказка: вспомните, что каждый полный октет 255» соответствует восьми «единичным» битам).

Проверка знаний

Вопрос 1. Что определяет маска подсети применительно к IP-адресу?

Ответ: Маска подсети определяет, какая часть IP-адреса относится к самой сети, а какая — к конкретному устройству (узлу) внутри этой сети, что, в свою очередь, определяет, какие устройства могут напрямую обращаться друг к другу без необходимости прохождения через шлюз.

Вопрос 2. Для чего нужен шлюз по умолчанию?

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

Итоги урока

Вы изучили: базовые понятия IP-адреса, маски подсети (включая CIDR-нотацию) и шлюза по умолчанию простыми словами.

Вы умеете: определять IP-адрес и шлюз своей системы с помощью базовых команд ip a» и ip route».

В следующем уроке потребуется: это базовое понимание, чтобы кратко познакомиться с версией протокола IPv6 и углубить понимание команды `ip».

Урок 12.2. IPv4 и немного об IPv6

Закрепить понимание IPv4, изученного в предыдущем уроке, и получить общее, ознакомительное представление о его более современном преемнике — IPv6.

Теория

Мы уже разобрали в предыдущем уроке принцип работы IPv4 — четырёхоктетной системы адресации, используемой в интернете с самых ранних этапов его развития. У IPv4 есть существенное практическое ограничение: общее количество возможных уникальных адресов в этой системе составляет чуть более 4 миллиардов (2 в 32-й степени, так как полный адрес состоит из 4 октетов по 8 бит каждый) — число, которое на заре развития интернета в 1980-х годах казалось практически неисчерпаемым, но с массовым распространением интернета, а затем и появлением миллиардов дополнительных подключённых устройств (смартфонов, «умных» устройств, и так далее) оказалось совершенно недостаточным для прямого, уникального адресования каждого отдельного устройства в мире.

Именно эта проблема нехватки адресов и стала основной причиной разработки IPv6 (Internet Protocol version 6) — значительно более современной версии протокола с кардинально увеличенным адресным пространством. IPv6-адрес записывается принципиально иначе, чем привычный IPv4: он состоит из восьми групп по четыре шестнадцатеричных символа (цифры от 0 до 9 и буквы от a до f), разделённых двоеточиями, например: `2001:0db8:85a3:0000:0000:8a2e:0370:7334». Общее количество возможных уникальных адресов в IPv6 астрономически велико (2 в 128-й степени) — этого пространства адресов должно с большим запасом хватить на любое мыслимое в обозримом будущем количество подключённых к сети устройств.

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

Одна практически важная деталь записи IPv6-адресов, о которой стоит упомянуть: последовательные группы, целиком состоящие из нулей, часто сокращаются с помощью двойного двоеточия ::» (может использоваться только один раз в пределах одного адреса, чтобы сокращение оставалось однозначным) — например, полный адрес 2001:0db8:0000:0000:0000:0000:0000:0001» может быть сокращённо записан как `2001:db8::1».

Практика

Шаг 1. Проверьте, назначен ли вашей виртуальной машине IPv6-адрес, используя уже знакомую нам команду ip a» из предыдущего урока, обратив внимание на строки, начинающиеся с inet6» (в отличие от строк с inet», относящихся именно к уже знакомому нам IPv4): ip a | grep inet6».

Что вы увидите: если IPv6 настроен и активен (что часто бывает даже в изолированных виртуальных сетях, по крайней мере для локального использования), вы увидите строки с адресами в характерном шестнадцатеричном формате, изученном в теории этого урока.

[Скриришот терминала]

Шаг 2. Сравните увиденный вами IPv6-адрес (если он есть) с примером из теории этого урока и попробуйте определить, есть ли в нём сокращение через `::», и если да — попытайтесь мысленно «развернуть» его обратно в полную, несокращённую форму, чтобы закрепить понимание этого принципа сокращения.

Шаг 3. Своими словами (без подглядывания) объясните в конспекте, почему возникла необходимость в разработке IPv6, опираясь на теорию этого урока о численном ограничении адресного пространства IPv4.

Разбор команд

В этом уроке мы применяем уже знакомую нам команду ip a» из предыдущего урока, дополнительно комбинируя её с уже хорошо знакомым grep» из Блока 6 для избирательного поиска именно IPv6-адресов среди прочего вывода.

Возможные ошибки

• Ошибка:** ошибочное представление, что IPv6 — это просто «более новая версия» того же самого формата IPv4, отличающаяся лишь незначительными деталями записи.

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

Как определить: попытка интерпретировать IPv6-адрес по тем же правилам, что и IPv4 (например, ожидание найти в нём именно четыре числовых группы, разделённых точками).

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

Как избежать: воспринимать IPv6 как концептуально родственный, но технически совершенно самостоятельный протокол со своим собственным, отдельным форматом записи адресов, а не просто «косметически обновлённую» версию IPv4.

Практические задания

1. Найдите в своей системе IPv6-адреса (если они есть) через команду из практики этого урока и запишите их в конспект.
2. Разверните следующий сокращённый IPv6-адрес в его полную форму: fe80::1» (подсказка: символ ::» здесь заменяет собой все недостающие до полных восьми групп нулевые группы).
3. Составьте в конспекте краткую сравнительную таблицу IPv4 и IPv6 по критериям: формат записи, общее количество возможных адресов, текущая степень распространённости на практике.

Проверка знаний

Вопрос 1. Какая основная проблема IPv4 стала причиной разработки IPv6?

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

Вопрос 2. Что означает двойное двоеточие :: в записи IPv6-адреса?

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

Итоги урока

Вы изучили: причины появления IPv6, его формат записи, принцип сокращения через ::, и текущую практическую ситуацию сосуществования IPv4 и IPv6.

Вы умеете: находить IPv6-адреса своей системы и различать форматы записи IPv4 и IPv6.

В следующем уроке потребуется: это базовое понимание IP-адресации, чтобы полноценно освоить настройку сети в Ubuntu через Netplan и команду `ip».

Урок 12.3. Настройка сети в Ubuntu: Netplan, `ip a`, `ip route`

Полноценно освоить инструмент Netplan, используемый в современных версиях Ubuntu для настройки сети, а также углублённо разобрать команду `ip», уже частично использованную в предыдущих двух уроках.

Теория

Netplan — это современная система настройки сети в Ubuntu (и некоторых других дистрибутивах на его основе), использующая конфигурационные файлы в формате YAML (YAML Ain't Markup Language — рекурсивная аббревиатура, сама себя определяющая через отрицание, в шутливой традиции, отдалённо напоминающей уже знакомую нам по уроку 1.3 рекурсивную расшифровку «GNU»; YAML — широко распространённый, удобный для человеческого восприятия формат хранения структурированных данных, использующий отступы для обозначения вложенности, вместо фигурных скобок или других подобных символов, характерных для некоторых других форматов). Конфигурационные файлы Netplan обычно располагаются в папке /etc/netplan/» (вспомните привычную нам по многим предыдущим блокам папку /etc», где хранится подавляющее большинство системных конфигураций) и имеют расширение `.yaml».

Типичный, простейший файл конфигурации Netplan для настройки сети с автоматическим получением адреса (тему которого — DHCP — подробно раскроем в следующем уроке) выглядит примерно так:

```yaml

network:

version: 2

ethernets:

enp0s3:

dhcp4: true

```

А для настройки статического, неизменного IP-адреса (без автоматического получения) — примерно так:

```yaml

network:

version: 2

ethernets:

enp0s3:

addresses: [192.168.1.100/24]

gateway4: 192.168.1.1

nameservers:

addresses: [8.8.8.8, 8.8.4.4]

```

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

После изменения файла конфигурации Netplan изменения применяются командой `sudo netplan apply», которая перечитывает конфигурацию и применяет её к реальным сетевым интерфейсам без необходимости полной перезагрузки системы.

Практика

Шаг 1. Найдите текущий файл конфигурации Netplan вашей виртуальной машины: `ls /etc/netplan/» (используя уже хорошо знакомую нам команду из Блока 5).

Что вы увидите: как минимум один файл .yaml, обычно с автоматически сгенерированным при установке именем вроде 01-network-manager-all.yaml» или 00-installer-config.yaml» (конкретное имя может отличаться в зависимости от версии Ubuntu и способа установки).

[Скриришот терминала]

Шаг 2. Просмотрите содержимое найденного файла (используя уже хорошо знакомую команду cat» из Блока 5): cat /etc/netplan/имя_найденного_файла.yaml» (подставив реальное имя файла).

Что вы увидите: конфигурацию, скорее всего, использующую именно автоматическое получение адреса (dhcp4: true), аналогичную первому примеру из теории этого урока — стандартная настройка по умолчанию для большинства виртуальных машин и типичных домашних/офисных сетей.

Шаг 3. Важное предупреждение перед следующим шагом: мы не будем реально изменять действующую сетевую конфигурацию вашей виртуальной машины в рамках этой практики, чтобы избежать риска случайной потери сетевого подключения — вместо этого создадим резервную копию (следуя уже хорошо усвоенному нами из Блока 7 и Блока 11 правилу) и лишь потренируемся в безопасном, «сухом» синтаксисе, не применяя реальных изменений: `sudo cp /etc/netplan/имя_файла.yaml /etc/netplan/имя_файла.yaml.bak» (резервная копия — на всякий случай, хотя в рамках данной осторожной практики мы и не планируем вносить реальные изменения).

Шаг 4. Углубим понимание уже знакомой нам по предыдущим урокам команды ip». Выполните ip link» (link — «связь», ещё одно представление сетевых интерфейсов, но с фокусом именно на их состоянии на физическом/канальном уровне, а не на IP-адресах): `ip link».

Что вы увидите: список сетевых интерфейсов с указанием их состояния — UP» (интерфейс активен, работает) или DOWN» (интерфейс неактивен).

[Скриришот результата]

Шаг 5. Проверьте более подробно таблицу маршрутизации (уже частично затронутую в уроке 12.1) с дополнительным параметром для более наглядного, числового представления: `ip route show».

Что вы увидите: развёрнутый список всех известных системе маршрутов, включая уже знакомую нам строку `default», указывающую на шлюз, а также отдельные строки для локальной сети, доступной напрямую (то есть без необходимости прохождения через шлюз, в соответствии с теорией маски подсети из урока 12.1).

Разбор команд

Команда ip link

• Назначение:** показывает список сетевых интерфейсов и их текущее физическое/канальное состояние (активен/неактивен).
• Синтаксис:** ip link [подкоманда]
• Основные параметры:** show» (показать список, часто используется по умолчанию, даже без явного указания); с правами sudo» также возможно изменение состояния интерфейса, например `sudo ip link set enp0s3 down» (временно отключить конкретный интерфейс) — но такие операции мы не практикуем в рамках базового ознакомительного урока из соображений осторожности, чтобы избежать случайной потери сетевого подключения к вашей виртуальной машине.

Команда netplan

• Назначение:* применяет и проверяет конфигурацию сети, заданную в файлах `/etc/netplan/.yaml».
• Синтаксис:** sudo netplan [подкоманда]
• Основные параметры:** apply» (применить текущую конфигурацию из файлов); try» (попробовать применить конфигурацию с автоматическим откатом изменений через определённое время, если пользователь явно не подтвердит, что новая конфигурация работает корректно, — крайне полезная, защитная возможность именно для сетевых настроек, где ошибка легко может привести к полной потере доступа к системе, особенно при удалённой работе, тему которой раскроем в Блоке 13).

Возможные ошибки

• Ошибка:** нарушение синтаксиса отступов YAML при редактировании файла Netplan, приводящее к ошибке при попытке применения конфигурации.

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

Как определить: команда sudo netplan apply» (или, что ещё безопаснее для предварительной проверки, sudo netplan generate», которая только проверяет синтаксис файлов, не применяя изменения) сообщает об ошибке синтаксиса с указанием конкретной проблемной строки.

Как исправить: внимательно перепроверить и выровнять отступы в проблемной части файла, сверяясь с корректным примером из теории этого урока.

Как избежать: всегда внимательно, вдумчиво редактировать файлы YAML, уделяя особое внимание последовательности и количеству пробелов в отступах, и перед реальным применением изменений (netplan apply) сначала проверять синтаксис более безопасной командой netplan generate», либо, что ещё безопаснее (особенно при работе через удалённое подключение, актуальное для Блока 13), использовать netplan try» с автоматическим откатом при неудаче.

Практические задания

1. Найдите и изучите содержимое файла конфигурации Netplan вашей системы, определив, использует ли она DHCP (автоматическое получение адреса) или статическую настройку, и запишите вывод в конспект.
2. Выполните ip link» и ip route show» и запишите в конспект, сколько сетевых интерфейсов вы обнаружили и в каком они находятся состоянии (UP/DOWN).
3. Своими словами объясните в конспекте, зачем нужна команда netplan try» и чем она безопаснее обычного netplan apply» при внесении потенциально рискованных изменений в сетевую конфигурацию.

Проверка знаний

Вопрос 1. В каком формате записываются конфигурационные файлы Netplan, и в какой системной папке они обычно располагаются?

Ответ: В формате YAML, в папке `/etc/netplan/».

Вопрос 2. Какая команда Netplan позволяет применить новую конфигурацию с автоматическим откатом изменений, если пользователь явно не подтвердит её работоспособность, и почему это особенно полезно именно для сетевых настроек?

Ответ: Команда `netplan try». Это особенно полезно для сетевых настроек, потому что ошибка в конфигурации легко может привести к полной потере сетевого подключения к системе, и автоматический откат защищает от ситуации, когда администратор случайно теряет возможность исправить собственную ошибку из-за отсутствия сетевого доступа.

Итоги урока

Вы изучили: систему настройки сети Netplan, формат YAML, и углублённо команды ip link» и ip route show».

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

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

Урок 12.4. DHCP: как компьютер автоматически получает IP-адрес

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

Теория

Мы уже несколько раз упоминали DHCP на протяжении этого блока (в частности, в примере файла Netplan из предыдущего урока, где параметр `dhcp4: true» как раз и указывает на использование этого механизма). Разберём его подробно.

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

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

1. Discover («обнаружение») — новое устройство, подключившееся к сети, рассылает широковещательный (broadcast — сообщение, адресованное сразу всем устройствам в локальной сети, а не какому-то конкретному отдельному адресату) запрос: «Есть ли в этой сети DHCP-сервер, готовый выдать мне сетевые настройки?»
2. Offer («предложение») — DHCP-сервер, получивший такой запрос, отвечает конкретным предложением: «Я готов предоставить тебе такой-то IP-адрес со следующими параметрами».
3. Request («запрос») — устройство подтверждает, что принимает именно это конкретное предложение (это существенно на случай, если в сети присутствует более одного DHCP-сервера, отправивших свои предложения одновременно).
4. Acknowledge («подтверждение») — DHCP-сервер официально подтверждает выделение указанного адреса именно этому устройству на определённый период времени, называемый сроком аренды (lease time).

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

В типичной домашней или небольшой офисной сети роль DHCP-сервера чаще всего выполняет сам домашний роутер (в контексте нашей учебной практики — виртуальный сетевой адаптер VirtualBox, работающий в уже упоминавшемся ранее в курсе, в уроке 2.7, режиме NAT, тоже, как правило, выполняет и роль DHCP-сервера для виртуальной машины). В более крупных, корпоративных сетях DHCP-сервер часто настраивается отдельно, как выделенная служба на специальном сервере.

Практика

Шаг 1. Просмотрите подробную информацию об аренде текущего IP-адреса вашей виртуальной машины через DHCP с помощью специализированного инструмента журналирования, изученного в Блоке 10 (journalctl), отфильтрованного по ключевым словам, связанным с DHCP: `journalctl | grep -i dhcp | tail -n 20» (используя уже хорошо знакомую нам из Блока 6 и Блока 10 комбинацию инструментов).

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

[Скриришот терминала]

Шаг 2. Проверьте текущее подробное состояние сетевого интерфейса с помощью более специализированного инструмента networkctl (network control, часть более широкой системы systemd-networkd, тесно связанной по духу с уже изученным нами в Блоке 10 systemctl, хотя конкретно для настройки сети в Ubuntu Desktop чаще применяется именно Netplan, изученный в предыдущем уроке, — здесь мы используем networkctl» скорее для дополнительной, ознакомительной диагностики): networkctl status» (если команда недоступна в вашей конкретной конфигурации системы — это не критично, просто зафиксируйте это наблюдение в конспекте и переходите к следующему шагу).

Шаг 3. Попробуйте вручную инициировать обновление аренды DHCP-адреса (полезная диагностическая операция при некоторых сетевых проблемах, к теме которых мы ещё вернёмся в Блоке 18) с помощью команды dhclient» (DHCP client), если она доступна в вашей системе: which dhclient» (проверка наличия, аналогично уже знакомому нам подходу из Блока 5), и, если команда найдена — sudo dhclient -r» (release, освободить текущую аренду) с последующим sudo dhclient» (запросить новую аренду заново). Если команда `dhclient» недоступна в вашей конкретной, современной конфигурации Ubuntu (что вполне вероятно, так как эта функциональность может обеспечиваться и другими, более новыми инструментами) — просто зафиксируйте это наблюдение и переходите дальше, не переживая об этом.

Разбор команд

Команда journalctl (повторное применение)

Мы уже подробно разбирали эту команду в Блоке 10 — здесь применяем уже знакомые нам навыки фильтрации к новой, сетевой предметной области.

Команда dhclient (обзорно)

• Назначение:** ручное управление процессом получения/освобождения DHCP-аренды адреса.
• Синтаксис:** sudo dhclient [опции] [интерфейс]
• Основные параметры:** `-r» (release, освободить текущую арендованную аренду адреса).

Возможные ошибки

• Ошибка:** ошибочное представление, что DHCP-адрес, однажды полученный устройством, остаётся закреплённым за ним постоянно и неизменно, аналогично статически настроенному адресу.

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

Как определить: в редких случаях (например, при длительном отключении устройства от сети, превышающем срок аренды, или при значительном увеличении числа других устройств в сети) IP-адрес устройства может неожиданно измениться при следующем подключении.

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

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

Практические задания

1. Найдите в системном журнале записи, связанные с DHCP, используя команду из шага 1 практики этого урока, и запишите в конспект найденный IP-адрес и, если удастся его найти в журнале, срок аренды.
2. Своими словами (без подглядывания) опишите четыре шага процесса DORA, изученные в теории этого урока.
3. Порассуждайте в конспекте: в каких конкретно практических ситуациях (приведите хотя бы два примера) статическая настройка IP-адреса была бы более предпочтительна, чем автоматическое получение через DHCP.

Проверка знаний

Вопрос 1. Что означает акроним DORA применительно к процессу получения адреса через DHCP?

Ответ: Discover (обнаружение DHCP-сервера устройством), Offer (предложение адреса сервером), Request (подтверждение принятия предложения устройством), Acknowledge (окончательное подтверждение выделения адреса сервером).

Вопрос 2. Что такое «срок аренды» (lease time) применительно к DHCP-адресу?

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

Итоги урока

Вы изучили: принцип работы DHCP, процесс DORA получения адреса, понятие срока аренды, и разницу между динамической и статической настройкой адреса.

Вы умеете: находить информацию о DHCP-аренде в системных журналах, осознанно выбирать между DHCP и статической настройкой для конкретной практической ситуации.

В следующем уроке потребуется: понимание IP-адресации, чтобы разобраться, как человекочитаемые доменные имена сайтов превращаются в конкретные IP-адреса — тема DNS.

Урок 12.5. DNS: как доменные имена превращаются в IP-адреса

Понять принцип работы DNS — системы, без которой было бы невозможно пользоваться привычными, удобными для запоминания именами сайтов вместо необходимости запоминать числовые IP-адреса каждого отдельного сервера.

Теория

Представьте, что вместо привычных, легко запоминаемых доменных имён (например, google.com или wikipedia.org) вам приходилось бы запоминать и вводить в браузер конкретные числовые IP-адреса каждого нужного вам сайта — крайне неудобная и практически нереализуемая для повседневного использования ситуация. Именно эту проблему решает DNS (Domain Name System, «система доменных имён») — распределённая, иерархическая система, которая переводит человекочитаемые доменные имена в соответствующие им числовые IP-адреса, необходимые для реального установления сетевого соединения (вспомните урок 12.1 — установление соединения происходит именно по IP-адресу, а не напрямую по «имени»).

Этот процесс перевода имени в адрес называется разрешением имени (name resolution). Упрощённо, при попытке обратиться, например, к example.com, происходит следующее: ваш компьютер обращается к настроенному в его сетевых параметрах (мы уже видели пример такой настройки во втором примере файла Netplan в уроке 12.3, в поле nameservers) DNS-серверу с вопросом: «Какой IP-адрес соответствует имени example.com?» DNS-сервер, в свою очередь, либо уже знает ответ (если недавно уже обрабатывал похожий запрос и сохранил результат в своём кэше — временном хранилище недавно полученных ответов, ускоряющем обработку повторных, аналогичных запросов), либо обращается дальше по иерархической цепочке других DNS-серверов, пока не будет найден окончательный, точный ответ, который затем и возвращается обратно вашему компьютеру.

Мы уже мельком сталкивались с одним из механизмов, связанных с разрешением имён, ещё в Блоке 7, когда практиковались на файле /etc/hosts. Этот файл представляет собой простейший, локальный, ручной способ разрешения имён — своего рода «личный, персональный DNS-справочник» прямо на вашем компьютере: если в `/etc/hosts» явно прописано соответствие определённого имени определённому IP-адресу, система будет использовать именно эту локальную запись, даже не обращаясь к внешнему DNS-серверу вообще. Это может быть удобно, например, для локального тестирования конкретного сайта до момента его официальной, публичной регистрации в реальной, глобальной системе DNS.

Практика

Шаг 1. Проверьте настроенные в вашей системе DNS-серверы (продолжение материала уже изученного нами Netplan из урока 12.3): `cat /etc/resolv.conf» (этот файл традиционно хранит информацию об используемых DNS-серверах, хотя в некоторых современных конфигурациях Ubuntu он может быть автоматически сгенерирован и управляться другими системными компонентами, о чём иногда явно упоминается прямо в содержимом самого файла).

Что вы увидите: строки вида `nameserver 8.8.8.8» (в качестве конкретного примера — это один из широко известных, общедоступных DNS-серверов, предоставляемых компанией Google) или похожий адрес, используемый для разрешения имён.

[Скриришот терминала]

Шаг 2. Выполните разрешение конкретного доменного имени в IP-адрес с помощью команды nslookup» (name server lookup, «поиск через сервер имён» — базовый, широко распространённый инструмент, который мы дополнительно разберём и в следующем уроке этого блока, наравне с более специализированным dig): nslookup ubuntu.com».

Что вы увидите: имя использованного DNS-сервера и полученный в результате разрешения IP-адрес (или несколько адресов — многие крупные сайты используют одновременно несколько серверов для распределения нагрузки, темы которой мы слегка коснёмся уже в контексте Блока 19).

[Скриришот результата]

Шаг 3. Вспомните материал Блока 7 и снова просмотрите содержимое файла /etc/hosts: `cat /etc/hosts».

Что вы увидите: уже знакомые нам с Блока 7 строки, определяющие соответствие имени localhost» адресу 127.0.0.1» (специальный, зарезервированный адрес, всегда указывающий «на сам этот же компьютер», к которому мы ещё вернёмся подробнее в контексте портов, в одном из следующих уроков этого блока).

Разбор команд

Команда nslookup

• Назначение:** выполняет разрешение доменного имени в IP-адрес (и, реже, обратную операцию — разрешение IP-адреса обратно в доменное имя, если это возможно).
• Синтаксис:** nslookup доменное_имя [DNS-сервер]
• Реальные примеры использования:** `nslookup wikipedia.org» — быстро проверить текущий IP-адрес указанного сайта, что может быть полезно, например, при диагностике проблем с доступом к нему.

Возможные ошибки

• Ошибка:** непонимание того, почему после изменения содержимого `/etc/hosts» некоторые изменения в разрешении имени начинают действовать сразу и без какой-либо дополнительной настройки, тогда как реальное изменение записей в глобальной, публичной системе DNS для настоящего сайта в интернете (что выходит за рамки этого курса, но полезно упомянуть концептуально) может занимать значительное время, вплоть до суток, для полного распространения по всей иерархической системе DNS.

Почему возникает: отсутствие понимания принципиальной разницы между локальным, персональным справочником (/etc/hosts, действующим немедленно и только на данном конкретном компьютере) и глобальной, распределённой, иерархической системой DNS (требующей времени на распространение изменений по множеству серверов и кэшей по всему миру).

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

Как исправить/избежать: запомнить это принципиальное различие: `/etc/hosts» — локальный, немедленно действующий, но применимый только на данном конкретном компьютере способ; настоящая, глобальная система DNS — распределённая, требующая времени на распространение изменений, но применимая для всех пользователей интернета одновременно.

Практические задания

1. Выполните `nslookup» для трёх любых знакомых вам сайтов и запишите в конспект полученные IP-адреса.
2. Найдите настроенный DNS-сервер вашей системы через `/etc/resolv.conf» и определите (можно через поиск в интернете), какой компании или организации принадлежит этот конкретный DNS-сервер.
3. Своими словами объясните в конспекте (без подглядывания), зачем нужна DNS-система, представив, как выглядела бы повседневная работа в интернете без неё, опираясь на аналогию из самого начала теории этого урока.

Проверка знаний

Вопрос 1. Что делает DNS-система, и почему без неё было бы крайне неудобно пользоваться современным интернетом?

Ответ: DNS переводит человекочитаемые доменные имена (например, example.com) в соответствующие им числовые IP-адреса, необходимые для реального установления сетевого соединения. Без неё пользователям пришлось бы запоминать и вводить числовые адреса для каждого нужного сайта, что было бы крайне неудобно и практически нереализуемо для повседневного использования.

Вопрос 2. В чём принципиальное отличие файла /etc/hosts от настоящей, глобальной системы DNS?

Ответ: `/etc/hosts» — это локальный, персональный «справочник» соответствий имён и адресов, действующий немедленно, но только на данном конкретном компьютере. Глобальная система DNS — это распределённая, иерархическая система, применимая для всех пользователей интернета одновременно, но требующая некоторого времени на распространение изменений по множеству серверов.

Итоги урока

Вы изучили: принцип работы DNS, процесс разрешения имени, роль кэша, и разницу между локальным /etc/hosts и глобальной системой DNS.

Вы умеете: выполнять разрешение доменных имён с помощью `nslookup» и находить настроенные DNS-серверы своей системы.

В следующем уроке потребуется: это понимание DNS, чтобы освоить полный набор инструментов диагностики сети, включая уже частично затронутые `nslookup».

Урок 12.6. Диагностика сети: `ping`, `traceroute`, `mtr`, `dig`, `nslookup`

Освоить полный набор инструментов диагностики сетевых проблем — навык, критически важный для эффективного администрирования, особенно в контексте будущих тем Блока 13 (SSH) и Блока 18 (troubleshooting), где сетевая диагностика будет использоваться регулярно.

Теория

Мы уже частично познакомились с `nslookup» в предыдущем уроке. Разберём остальные ключевые инструменты диагностики сети.

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

traceroute — показывает полный путь (маршрут), который проходят сетевые пакеты от вашего компьютера до указанного адреса назначения, отображая каждый промежуточный узел (router, «маршрутизатор») на этом пути вместе со временем отклика на каждом отдельном участке — крайне полезно для определения, на каком именно конкретном участке длинного сетевого пути возникает проблема (задержка или полная потеря связи), если простой `ping» лишь констатирует наличие проблемы в целом, без детализации по конкретному месту её возникновения.

mtr (My TraceRoute) — современный, значительно более удобный инструмент, объединяющий в себе функциональность и ping», и traceroute» одновременно, в виде непрерывно обновляющегося в реальном времени, интерактивного отчёта по каждому промежуточному узлу маршрута — концептуально похожий по духу на уже знакомую нам разницу между top» и htop» из Блока 10 (более простой, базовый инструмент против более удобного, наглядного и информативного).

dig (Domain Information Groper) — более продвинутая, детальная альтернатива уже знакомому нам `nslookup» для работы с DNS, предоставляющая значительно более подробную техническую информацию о результате запроса и широко используемая профессиональными системными администраторами именно благодаря этой детальности и гибкости.

Практика

Шаг 1. Проверьте базовую доступность известного, надёжного сайта с помощью ping: ping -c 4 google.com» (параметр -c 4» ограничивает количество отправляемых пакетов четырьмя, вместо непрерывной, бесконечной отправки по умолчанию, что типично для многих реализаций `ping» в Linux, в отличие, например, от поведения по умолчанию в Windows).

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

[Скриришот терминала]

Шаг 2. Проверьте маршрут до того же сайта с помощью traceroute» (если команда не установлена — установите её через уже хорошо знакомый нам APT из Блока 9: sudo apt install traceroute): traceroute google.com».

Что вы увидите: пронумерованный список промежуточных узлов маршрута, каждый со своим IP-адресом (и, если удаётся определить через DNS, доменным именем) и временем отклика.

[Скриришот результата]

Шаг 3. Установите и опробуйте mtr (аналогично уже практиковавшемуся подходу для новых команд из Блока 9): sudo apt install mtr-tiny» (обратите внимание на конкретное, чуть отличающееся название пакета — распространённая на практике деталь, когда имя пакета в APT-репозитории не полностью совпадает с именем самой команды), затем mtr google.com».

Что вы увидите: интерактивный, постоянно обновляющийся отчёт, аналогичный по духу интерфейсу top/`htop» из Блока 10, но применительно именно к маршруту сети.

Шаг 4. Выйдите из mtr нажатием клавиши `q» (аналогично уже привычному нам поведению многих интерактивных инструментов на протяжении курса).

Шаг 5. Потренируйте dig как более продвинутую альтернативу уже знакомому нам nslookup: dig ubuntu.com» (если команда не установлена — установите пакет dnsutils» через APT: sudo apt install dnsutils).

Что вы увидите: значительно более подробный, технический вывод по сравнению с nslookup, включающий явное указание времени, затраченного на запрос, использованного DNS-сервера, и подробную структуру самого ответа DNS-сервера.

[Скриришот результата]

Разбор команд

Команда ping

• Назначение:** проверка базовой доступности узла сети и измерение времени отклика.
• Синтаксис:** ping [опции] адрес_или_имя
• Основные параметры:** `-c число» (ограничить количество отправляемых пакетов указанным числом).
• Типичные ошибки:** интерпретация отсутствия ответа на ping» как безусловного, окончательного доказательства недоступности узла — в реальности некоторые серверы и сети сознательно настроены на игнорирование (блокировку) именно ping`-запросов из соображений безопасности, оставаясь при этом полностью доступными и работоспособными по другим сетевым протоколам.

Как избежать: использовать ping» как один из нескольких инструментов диагностики, но не как единственный, безусловно надёжный индикатор доступности узла — при отсутствии ответа стоит дополнительно проверить доступность конкретного нужного сервиса напрямую (например, попыткой открыть сайт в браузере), а не полагаться исключительно на результат ping».

Команда traceroute

• Назначение:** показывает полный путь пакетов от текущего компьютера до указанного адреса назначения, узел за узлом.
• Синтаксис:** `traceroute адрес_или_имя»

Команда mtr

• Назначение:** объединяет функциональность ping» и traceroute» в едином, непрерывно обновляющемся интерактивном отчёте.
• Синтаксис:** `mtr [опции] адрес_или_имя»

Команда dig

• Назначение:** детальная диагностика DNS-запросов.
• Синтаксис:** `dig [опции] доменное_имя»

Возможные ошибки

• Ошибка:** попытка диагностировать сложную сетевую проблему, используя только ping, без дальнейшего использования более детальных инструментов (traceroute/mtr), когда простой `ping» показывает лишь общий факт наличия проблемы, но не даёт достаточно информации для определения её точной причины и местоположения.

Почему возникает: `ping» — самый известный, простой и часто используемый инструмент, что создаёт соблазн ограничиться только им.

Как определить: диагностика заходит в тупик — известно лишь, что «что-то не работает», но неясно, на каком именно конкретном участке сети или по какой конкретной причине.

Как исправить: перейти к использованию traceroute или mtr для более детальной картины по каждому промежуточному узлу маршрута, а при подозрении именно на проблему с DNS — дополнительно применить dig/`nslookup» для проверки корректности разрешения имени.

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

Практические задания

1. Выполните `ping -c 4» для трёх разных сайтов и сравните полученное время отклика, предположив в конспекте возможные причины различий (например, географическая удалённость серверов).
2. Выполните traceroute» (или mtr`) для любого сайта и определите, сколько промежуточных узлов проходит сетевой пакет на пути к нему, зафиксировав это число в конспекте.
3. Сравните вывод nslookup» и dig» для одного и того же доменного имени и опишите в конспекте, какую дополнительную информацию вы обнаружили именно в более детальном выводе dig, отсутствующую в более простом выводе `nslookup».

Проверка знаний

Вопрос 1. Почему отсутствие ответа на ping не всегда означает полную недоступность узла сети?

Ответ: Некоторые серверы и сети сознательно настроены на игнорирование (блокировку) именно ping-запросов из соображений безопасности, оставаясь при этом полностью доступными и работоспособными по другим сетевым протоколам и сервисам.

Вопрос 2. В чём практическое преимущество mtr перед раздельным использованием ping и traceroute?

Ответ: `mtr» объединяет функциональность обоих инструментов в едином, непрерывно обновляющемся в реальном времени интерактивном отчёте, показывающем и маршрут (как traceroute), и статистику отклика по каждому промежуточному узлу (как ping), не требуя раздельного запуска двух отдельных команд.

Итоги урока

Вы изучили: полный набор инструментов сетевой диагностики — ping, traceroute, mtr, dig», дополняющий уже знакомый нам с предыдущего урока nslookup».

Вы умеете: проверять доступность узлов сети, анализировать маршрут прохождения пакетов, выполнять детальную диагностику DNS-запросов.

В следующем уроке потребуется: это понимание сетевой диагностики, чтобы освоить последнюю практическую тему блока — работу с портами и сетевыми соединениями.

Урок 12.7. Порты и сетевые соединения: `ss`, `netstat`

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

Теория

Мы уже знаем из предыдущих уроков, что IP-адрес идентифицирует конкретное устройство в сети. Но на одном устройстве одновременно может работать множество различных сетевых служб (например, веб-сервер, тему которого раскроем в Блоке 19, и SSH-сервер, тему которого раскроем в Блоке 13) — как система определяет, какому именно из них конкретно предназначены входящие данные, если IP-адрес устройства только один?

Именно эту задачу решает концепция порта (port) — дополнительного числового идентификатора (от 0 до 65535), который вместе с IP-адресом однозначно определяет конкретную службу на конкретном устройстве. Комбинацию «IP-адрес плюс порт» иногда называют сокетом (socket).

Некоторые номера портов зарезервированы за широко известными, стандартными службами по общепринятому соглашению — так называемые well-known ports («хорошо известные порты», от 0 до 1023): например, порт 22» традиционно используется для SSH (Блок 13), порт 80» — для обычного, незашифрованного веб-трафика (HTTP, тема Блока 19), порт `443» — для зашифрованного веб-трафика (HTTPS). Знание этих стандартных соответствий часто помогает быстро понять, какая именно служба стоит за конкретным открытым портом, даже без дополнительной документации.

Уже упоминавшийся нами в уроке 12.5 специальный адрес 127.0.0.1» (или его текстовый псевдоним localhost, из уже знакомого нам файла /etc/hosts`) — это особый, зарезервированный адрес loopback («петля», «обратная связь»), всегда указывающий на сам данный компьютер, вне зависимости от его реального внешнего IP-адреса в сети. Это удобно для организации взаимодействия между разными программами, работающими на одном и том же компьютере, без необходимости выхода в настоящую внешнюю сеть — мы столкнёмся с практическим применением этого принципа уже в Блоке 19, при настройке связки веб-сервера и базы данных.

Практика

Шаг 1. Просмотрите список всех открытых портов и активных сетевых соединений вашей системы с помощью команды ss» (socket statistics, «статистика сокетов» — современный, рекомендуемый инструмент, постепенно заменивший более старый, но всё ещё иногда встречающийся netstat, о котором скажем чуть подробнее далее): ss -tuln» (параметры -t» — TCP-соединения, -u» — UDP-соединения, о разнице которых мы кратко упомянем в разборе команд, -l» — показать только слушающие, то есть готовые принимать входящие соединения, порты, а не все текущие активные соединения, -n» — показать номера портов численно, а не пытаться преобразовать их в текстовые названия известных служб, что иногда удобнее для быстрого, однозначного анализа).

Что вы увидите: список открытых портов с указанием протокола, локального адреса и порта (например, 127.0.0.1:631», где 631» может относиться к службе печати, если она установлена по умолчанию в Ubuntu Desktop) и текущего состояния соединения.

[Скриришот терминала]

Шаг 2. Найдём в этом списке порт уже установленной в Блоке 10 службы Nginx (стандартно работающей на порту 80, как мы упоминали в теории этого урока), скомбинировав уже хорошо знакомый нам grep» из Блока 6: ss -tuln | grep :80».

Что произойдёт: если служба Nginx всё ещё установлена и работает с предыдущего блока (при необходимости запустите её снова уже знакомой нам командой sudo systemctl start nginx» из Блока 10) — вы должны увидеть строку, подтверждающую, что порт 80» действительно открыт и «слушает» входящие соединения.

[Скриришот результата]

Шаг 3. Просмотрите не только слушающие порты, но и активные, уже установленные сетевые соединения (без параметра -l», ограничивавшего вывод на предыдущих шагах именно слушающими портами): ss -tun».

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

Шаг 4. Опробуем более старый, альтернативный инструмент netstat» для сравнения (если он не установлен — установите пакет net-tools» через уже хорошо знакомый нам APT: sudo apt install net-tools): netstat -tuln» (обратите внимание на очень похожий, практически идентичный синтаксис параметров по сравнению с уже опробованным ss» — это не случайность, а сознательная преемственность синтаксиса при разработке более нового ss» как замены более старому netstat`).

Разбор команд

Команда ss

• Назначение:** современный инструмент просмотра сетевых соединений и открытых портов.
• Синтаксис:** ss [опции]
• Основные параметры:** -t» (TCP); -u» (UDP); -l» (только слушающие порты); -n» (числовой вывод портов, без попытки преобразования в текстовые названия); -p» (показать, каким именно процессом/PID открыт данный конкретный порт — требует sudo» для полной, детальной информации о процессах, принадлежащих другим пользователям, в соответствии с уже хорошо изученной нами в Блоке 8 моделью прав доступа).
• Краткое пояснение разницы TCP/UDP:** TCP (Transmission Control Protocol) — «надёжный» протокол передачи данных, гарантирующий доставку всех пакетов в правильном порядке (используется, например, для загрузки веб-страниц, где важна полная целостность получаемых данных); UDP (User Datagram Protocol) — более «быстрый», но не гарантирующий надёжной доставки протокол, используемый там, где скорость важнее абсолютной надёжности (например, для потокового видео или голосовой связи, где потеря отдельного, единичного пакета менее критична, чем задержка ради его повторной пересылки).

Команда netstat (более старая альтернатива)

• Назначение:** аналогично ss, но с использованием более старого, исторического подхода к получению этой информации, из-за чего современные системы всё чаще рекомендуют использовать именно `ss» как более быструю и эффективную альтернативу.
• Синтаксис:** netstat [опции]» (синтаксис параметров практически идентичен уже изученному ss`).

Возможные ошибки

• Ошибка:** попытка получить полную информацию о том, каким именно процессом открыт конкретный порт (параметр -p), без использования sudo, особенно применительно к процессам других пользователей или системным службам.

Почему возникает: аналогично уже неоднократно встречавшемуся в курсе принципу — детальная информация о чужих процессах защищена правами доступа, в соответствии с материалом Блока 8.

Как определить: неполная информация в выводе (например, отсутствие имени процесса там, где ожидалось его увидеть) при выполнении без `sudo».

Как исправить: добавить `sudo» перед командой для получения полной картины.

Практические задания

1. Выполните `ss -tuln» на своей системе и составьте в конспекте список всех обнаруженных открытых, слушающих портов вместе с предположением о том, какая служба каждый из них может использовать (при необходимости сверяясь со списком «хорошо известных портов» через поиск в интернете).
2. Найдите порт службы Nginx (80) с помощью комбинации ss» и grep», как в практике этого урока, а затем определите, каким конкретно процессом он используется, с помощью параметра -p» и sudo»: `sudo ss -tulnp | grep :80».
3. Своими словами объясните в конспекте (без подглядывания), зачем нужна концепция портов, если у устройства уже есть уникальный IP-адрес — опираясь на теорию этого урока о том, что на одном устройстве может одновременно работать множество разных сетевых служб.

Проверка знаний

Вопрос 1. Что такое сокет, и из каких двух компонентов он состоит?

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

Вопрос 2. Какой специальный, зарезервированный IP-адрес всегда указывает «на сам данный компьютер», вне зависимости от его реального внешнего адреса в сети, и как называется этот принцип?

Ответ: Адрес 127.0.0.1» (с текстовым псевдонимом localhost`), реализующий принцип loopback («петля», «обратная связь»).

Итоги урока

Вы изучили: концепцию портов, разницу между TCP и UDP, понятие loopback-адреса, и инструменты ss/netstat для просмотра сетевых соединений и открытых портов.

Вы умеете: находить открытые порты своей системы и определять, какой процесс их использует.

В следующем уроке потребуется: весь накопленный в этом блоке материал о сетях, чтобы получить начальное, вводное представление о теме firewall и базовой маршрутизации, к которой мы вернёмся полноценно уже в Блоке 14, посвящённом безопасности.

Урок 12.8. Firewall и базовая маршрутизация — введение

Получить общее, ознакомительное представление о концепции firewall (межсетевого экрана) и базовой маршрутизации, подготавливая почву для полноценного, практического изучения этих тем уже в Блоке 14.

Теория

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

Зачем нужен firewall, если сама служба и так может быть просто не запущена (и, соответственно, порт не будет открыт), обеспечивая тем самым естественную защиту? Firewall добавляет дополнительный, независимый уровень защиты — так называемый эшелонированный подход к безопасности (defense in depth, «эшелонированная оборона», принцип, к которому мы ещё вернёмся в Блоке 14): даже если на сервере случайно окажется запущена и открыта служба, которую администратор не собирался делать доступной извне (например, по ошибке, или как побочный эффект установки какой-то другой программы), правильно настроенный firewall всё равно заблокирует нежелательный доступ к ней, служа дополнительной, независимой «страховочной сетью» поверх остальных мер безопасности.

В Ubuntu наиболее распространённым, дружественным для пользователя инструментом настройки firewall является UFW (Uncomplicated Firewall, «несложный firewall») — мы посвятим ему отдельный, полноценный урок именно в Блоке 14, здесь лишь кратко упомянем о его существовании для общей связности материала.

Маршрутизация (routing) — это процесс определения, по какому именно пути (через какие промежуточные узлы) сетевые данные должны следовать от источника до места назначения. Мы уже частично касались этой темы в уроке 12.1 (понятие шлюза) и в уроке 12.6 (команда traceroute», наглядно показывающая реальный маршрут). Таблица маршрутизации (routing table), которую мы уже просматривали в этом блоке через ip route», — это тот самый набор правил, определяющий, куда именно должен быть направлен конкретный сетевой пакет в зависимости от его адреса назначения: отправить ли его напрямую в локальную сеть (если адрес назначения относится к той же самой сети, определяемой маской подсети, изученной в уроке 12.1), или же передать его через шлюз для дальнейшей маршрутизации за пределы локальной сети.

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

Практика

Шаг 1. Проверьте, установлен ли UFW в вашей системе (в Ubuntu он часто предустановлен по умолчанию, хотя и не обязательно активен): `sudo ufw status» (мы намеренно не активируем и подробно не настраиваем firewall в рамках этого ознакомительного урока — детальная, практическая настройка UFW станет полноценной темой отдельного урока в Блоке 14).

Что вы увидите: скорее всего, статус «inactive» («неактивен») — стандартное состояние по умолчанию сразу после установки Ubuntu, до момента осознанной, явной настройки администратором.

[Скриришот терминала]

Шаг 2. Ещё раз просмотрите уже знакомую нам с урока 12.1 и урока 12.3 таблицу маршрутизации, теперь уже с более полным пониманием происходящего: `ip route show».

Что вы увидите: как минимум две строки — одну для маршрута по умолчанию (default via ..., указывающую на шлюз) и как минимум одну для локальной сети вашей виртуальной машины, доступной напрямую, без прохождения через шлюз.

[Скриришот результата]

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

Разбор команд

В этом уроке мы не вводим принципиально новых команд, а лишь кратко, ознакомительно затрагиваем ufw status» (полноценно разберём в Блоке 14) и повторно применяем уже хорошо знакомую нам ip route show».

Возможные ошибки

• Ошибка:** ошибочное представление, что отсутствие активного firewall автоматически означает полную незащищённость системы, или, наоборот, что простое включение firewall само по себе гарантирует полную безопасность без какой-либо дополнительной настройки.

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

Как определить: сложно определить без более глубокого погружения в тему, которое нам ещё предстоит в Блоке 14.

Как исправить/избежать: воспринимать firewall как один из нескольких взаимодополняющих уровней защиты (эшелонированная оборона, упомянутая в теории), а не как единственную, самодостаточную меру безопасности — полноценное понимание комплексного подхода к безопасности мы будем последовательно выстраивать на протяжении всего Блока 14.

Практические задания

1. Проверьте статус UFW на своей системе командой из практики этого урока и запишите результат в конспект.
2. Составьте в конспекте полную, связную схему (текстом или в виде простого рисунка) прохождения сетевого пакета согласно заданию из шага 3 практики этого урока, стараясь задействовать максимальное количество понятий, изученных на протяжении всего этого блока.
3. Своими словами объясните в конспекте принцип «эшелонированной обороны» (defense in depth), приведя собственный, не связанный напрямую с компьютерами пример подобного многоуровневого подхода к безопасности из повседневной жизни (например, несколько независимых уровней защиты жилища: дверной замок, сигнализация, и так далее).

Проверка знаний

Вопрос 1. Зачем нужен firewall, если нежелательную службу можно было бы просто не запускать вообще, тем самым естественным образом закрывая соответствующий порт?

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

Вопрос 2. Что определяет таблица маршрутизации применительно к конкретному сетевому пакету?

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

Итоги урока

Вы изучили: общую концепцию firewall и принцип эшелонированной обороны, а также углубили понимание маршрутизации и таблицы маршрутов.

Вы умеете: проверять базовый статус firewall и осмысленно интерпретировать таблицу маршрутизации своей системы.

В следующем уроке (это будет уже Блок 13) потребуется: весь накопленный в этом блоке материал о сетях, IP-адресах и портах, чтобы освоить SSH — главный инструмент удалённого администрирования Linux-серверов, применяющий все изученные здесь сетевые концепции на практике.

Мини-проект блока

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

Что нужно сделать:

1. Определите и задокументируйте: IP-адрес виртуальной машины (с маской в CIDR-нотации), адрес шлюза по умолчанию, используемые DNS-серверы.
2. Проверьте и задокументируйте, использует ли система DHCP или статическую настройку, найдя и изучив соответствующий файл конфигурации Netplan.
3. Выполните ping, traceroute (или mtr) и dig для трёх разных внешних сайтов, задокументировав время отклика и количество промежуточных узлов маршрута для каждого.
4. Составьте полный список всех открытых, слушающих портов вашей системы (ss -tulnp, с sudo для полной информации о процессах), сопоставив каждый порт с соответствующей службой.
5. Проверьте базовый статус UFW.
6. Оформите всё это в виде единого, структурированного текстового отчёта в вашем конспекте, как если бы вы готовили документацию для передачи этого сервера другому администратору.

Критерий готовности: отчёт полностью заполнен на основе реальных, самостоятельно полученных данных вашей системы, а не гипотетических примеров из уроков.

Контрольные вопросы

1. Объясните своими словами понятия IP-адреса, маски подсети и шлюза, используя аналогию с почтовой системой.
2. В чём принципиальное отличие формата записи IPv6-адреса от IPv4?
3. Опишите четыре шага процесса DORA при получении адреса через DHCP.
4. Объясните, чем DNS-разрешение имени отличается от простого обращения по IP-адресу, и зачем нужна DNS-система в целом.
5. В чём разница между ping и traceroute/mtr с точки зрения объёма получаемой диагностической информации?
6. Что такое порт, и зачем он нужен, если у устройства уже есть уникальный IP-адрес?
7. Объясните принцип эшелонированной обороны на примере firewall.

Выводы по блоку

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

Список изученных тем

• IP-адрес, маска подсети, CIDR-нотация, шлюз по умолчанию.
• Основы IPv6 в сравнении с IPv4.
• Настройка сети в Ubuntu через Netplan, углублённая работа с командой `ip».
• DHCP: принцип работы, процесс DORA, срок аренды.
• DNS: разрешение имён, роль /etc/hosts, кэширование.
• Инструменты сетевой диагностики: ping, traceroute, mtr, dig, `nslookup».
• Порты, сокеты, TCP/UDP, loopback-адрес, инструменты ss/`netstat».
• Общее представление о firewall и таблице маршрутизации.

Рекомендации перед переходом

Убедитесь, что вы уверенно понимаете разницу между IP-адресом устройства и доменным именем сайта, можете объяснить, зачем нужны порты, и умеете использовать хотя бы базовый набор инструментов диагностики (ping, nslookup, ss). Этот материал станет прямой практической основой для следующего блока, посвящённого SSH — технологии, которая позволит вам впервые в этом курсе по-настоящему удалённо администрировать компьютер через сеть, а не только локально, через терминал на самой машине.