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

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

Что такое компьютерная сеть и зачем она админу

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

Если понимать основы сетей, становится легче:

• быстро находить причину недоступности сервера;
• отличать проблему приложения от проблемы сети;
• настраивать доступы и фильтрацию;
• безопасно сегментировать инфраструктуру;
• читать конфигурации Linux без ощущения, что там «магия».

Допустим, вы подняли Apache на виртуалке, но из локальной сети он не открывается. Вы проверяете, слушает ли он порт (ss -tulpn | grep 80), потом смотрите, не блокирует ли iptables, потом проверяете, правильный ли шлюз. Это и есть работа с сетью — без паники, по шагам.

Базовые термины, которые нужно знать с самого начала

Узел, хост, клиент, сервер

• Узел — любое устройство в сети.
• Хост — чаще всего устройство с сетевым адресом, которое участвует в обмене данными.
• Клиент — устройство или программа, которая запрашивает ресурс.
• Сервер — устройство или программа, которая отдаёт ресурс.

Важно: один и тот же компьютер может быть и клиентом, и сервером. Например, ноутбук открывает сайт как клиент, а в локальной сети может принимать подключения по SSH как сервер. В Linux роль сервера часто определяет запущенный демон: sshd, httpd. Хост может идентифицироваться по имени в /etc/hosts или через DNS.

IP-адрес

IP-адрес — это логический адрес устройства в сети. Без него пакетам данных некуда «идти». На практике администратору нужно понимать:

• адрес может быть IPv4 или IPv6;
• адрес бывает статическим и динамическим;
• один и тот же хост может иметь несколько адресов.

IPv4-адреса давно в дефиците, поэтому в локальных сетях повсеместно используют частные диапазоны (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12) и NAT. Администратор должен чётко различать публичный и частный адрес, иначе не настроить проброс портов или доступ извне. Динамический адрес обычно выдаётся DHCP-сервером; статический прописывается вручную — в Linux через /etc/network/interfaces или netplan.

Маска подсети

Маска подсети показывает, какая часть IP-адреса относится к сети, а какая — к самому устройству. Это один из ключевых моментов: пока вы не понимаете подсети, сложно разбираться с доступом между сегментами сети и маршрутизацией. Если у вас два сервера с IP 192.168.1.10/24 и 192.168.2.10/24, они не увидят друг друга без маршрутизатора, даже если подключены к одному коммутатору. В Linux маску можно увидеть через ip a — она отображается в CIDR-нотации (например, /24).

Шлюз по умолчанию

Шлюз по умолчанию — это устройство, через которое хост выходит в другие сети. Обычно это маршрутизатор. Если у компьютера правильный IP и маска, но неправильный шлюз, доступ в локалку может быть, а выхода наружу — нет. Частая ошибка новичков: прописывают статический IP, а про шлюз забывают. В Linux маршрут по умолчанию смотрят командой ip r (строка default via …).

DNS

DNS переводит понятные человеку имена, например имя сайта, в IP-адреса. Для администратора DNS — это не «дополнительная служба», а один из самых частых источников жалоб: сайт открывается по IP, но не открывается по имени; почта не доставляется; домен есть, а запись не обновилась. Записи бывают разных типов: A, AAAA, CNAME, MX, TXT. Проверять их удобно утилитой dig — она показывает не только ответ, но и сервер, TTL, секцию authority. После смены записи проблема часто в кеше: на клиенте его можно сбросить через sudo systemd-resolve --flush-caches (на systemd), а также проверить, какой DNS-сервер фактически используется (cat /etc/resolv.conf).

Как устроена передача данных: от простого к полезному

Сеть работает не «целиком», а слоями. Такая модель помогает понимать, где именно искать проблему.

Модель TCP/IP простыми словами

Чаще всего в практике системного администратора встречается стек TCP/IP. Он помогает разложить сетевой обмен на несколько уровней:

• прикладной уровень — программы и сервисы (HTTP, SSH, DNS);
• транспортный уровень — доставка между приложениями (TCP, UDP);
• сетевой уровень — адресация и маршрутизация (IP);
• уровень доступа к сети — физическая передача данных (Ethernet, Wi‑Fi).

Польза от такой модели практическая: если не работает сайт, можно понять, это проблема DNS (прикладной), TCP-соединения (транспортный), маршрута (сетевой) или канала связи (канальный). Например, при отказе SSH-соединения сначала проверяем, слушает ли sshd порт 22 (ss -tulpn | grep :22), затем пингуем хост, затем смотрим фаервол.

Что такое пакет

Данные в сети передаются не целиком, а кусками — пакетами. Пакет содержит:

• служебную информацию;
• адрес отправителя;
• адрес получателя;
• сами данные.

Представьте письмо в конверте: сам текст — это полезная нагрузка, а адреса и отметки — служебная часть. Именно так сеть понимает, куда доставлять информацию. В Linux посмотреть заголовки пакетов можно с помощью tcpdump -i eth0 -n port 80 — вы увидите MAC-адреса, IP, порты и флаги. Это особенно полезно, когда нужно понять, доходит ли трафик до сервера и что с ним происходит.

TCP и UDP: в чём разница и зачем это админу

TCP

TCP — протокол, который старается доставить данные надёжно и в правильном порядке. Он нужен там, где важна целостность:

• веб-сайты;
• почта;
• удалённое управление (SSH);
• файловые передачи (FTP, SCP).

Плюс TCP — надёжность, достигаемая трёхсторонним рукопожатием (SYN, SYN-ACK, ACK) и подтверждениями. Минус — больше служебных операций и потенциально меньшая скорость по сравнению с более простыми схемами передачи. На практике администратор часто сталкивается с тем, что фаервол блокирует SYN-пакеты, и соединение «зависает». В iptables для разрешения входящих соединений нужно явно разрешить NEW-пакеты и не забыть про ESTABLISHED.

UDP

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

• потоковое видео;
• голосовая связь (VoIP);
• некоторые сервисные протоколы (DNS, NTP, SNMP);
• игры и телеметрия.

Для администратора полезно запомнить главное: если нужен контроль и подтверждения — чаще TCP; если нужна минимальная задержка — часто UDP. UDP-трафик сложнее фильтровать с учётом состояния, поэтому на фаерволах часто просто открывают нужные порты. Если DNS-запросы не проходят, проверьте, не заблокирован ли UDP-порт 53.

OSI и TCP/IP: почему их всё ещё спрашивают на собеседованиях

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

Зачем знать модель уровней

Когда кто-то говорит: «сеть не работает», надо задавать правильные вопросы:

• виден ли кабель или Wi‑Fi (физический/канальный);
• есть ли IP-адрес (сетевой);
• отвечает ли шлюз (сетевой);
• работает ли DNS (прикладной);
• доступен ли сервис на нужном порту (транспортный/прикладной).

По сути, это и есть движение снизу вверх по уровням сети. Я всегда начинаю с проверки, горит ли линк на сетевой карте (ethtool eth0), затем смотрю IP и маску, пингую шлюз, проверяю DNS и только потом — порт сервиса. Такой подход экономит часы и убирает гадание.

Главные сетевые устройства и их роль

Коммутатор обычно работает на канальном уровне (L2) и оперирует MAC-адресами, а маршрутизатор — на сетевом (L3) и принимает решения на основе IP. Это одно из самых частых мест путаницы у новичков. Современные управляемые коммутаторы могут иметь функции L3, но базовая логика остаётся: внутри одной подсети трафик идёт через коммутатор, между подсетями — через маршрутизатор. Если серверы в одной VLAN не видят друг друга, проблема, скорее всего, в коммутаторе или настройках VLAN; если не выходят в интернет — проверяем шлюз и маршрутизатор.

Порты: как сервисы уживаются на одном IP

Порт — это номер, который помогает понять, какой именно сервис должен принять соединение. Один IP может обслуживать десятки и сотни служб, и именно порт отличает веб-сервер от SSH, базы данных и почтового сервиса. Порты с 0 по 1023 считаются привилегированными: чтобы запустить на них сервис, нужны права root.

Примеры:

• 22 — SSH;
• 80 — HTTP;
• 443 — HTTPS;
• 53 — DNS;
• 25 — SMTP.

Для админа это критично: если сервис «не отвечает», нужно проверить не только сам сервер, но и порт, на котором он слушает, а также правила фаервола. Как узнать, что висит на порту? ss -tulpn | grep :80 покажет процесс и PID. Если веб-сервер не стартует, возможно, порт уже занят другим приложением. Фаерволы (iptables, ufw) оперируют именно портами для разрешения или запрета трафика, поэтому всегда проверяйте, не блокируется ли нужный порт.

Адресация и подсети: что нужно уметь на практике

Что такое подсеть

Подсеть — это логический кусок сети. Она помогает разделять устройства по отделам, ролям или уровням доступа. Например:

• отдельная подсеть для серверов;
• отдельная для рабочих станций;
• отдельная для гостевого Wi‑Fi;
• отдельная для камер и IoT.

Это важно не только для порядка, но и для безопасности. Если все устройства в одной плоской сети, ограничивать доступ гораздо сложнее. Маска подсети определяет её размер: /24 (255.255.255.0) даёт 254 доступных адреса для хостов (2^(32-24) — 2, так как адрес сети и broadcast-адрес заняты).

Зачем делить сеть

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

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

Типовые проблемы новичка и как их отличать

1. «Интернет не работает»

Проверять нужно по цепочке, не пропуская шаги:

• есть ли физическое подключение — ip link показывает состояние интерфейса (UP/DOWN);
• получил ли хост IP — ip a; если адреса нет, возможно, не работает DHCP или неверно задан статический IP;
• правильные ли шлюз и маска — ip r; шлюз должен быть доступен (пинг до него);
• отвечает ли DNS — dig example.com или nslookup; если нет, временно пропишите 8.8.8.8 в /etc/resolv.conf;
• доступен ли внешний адрес — ping 8.8.8.8; если пинг до 8.8.8.8 есть, а сайты не открываются, проблема точно в DNS;
• не блокирует ли трафик фаервол — iptables -L -n (или ufw status).

2. «По IP открывается, по имени — нет»

Чаще всего это DNS:

• неверная запись на сервере — проверьте через dig @8.8.8.8 example.com;
• не тот сервер DNS используется — смотрите /etc/resolv.conf;
• кеш на клиенте — очистите кеш резолвера (sudo systemd-resolve --flush-caches) или перезапустите сетевую службу;
• задержка обновления записей — TTL ещё не истёк, подождите или временно используйте другой DNS.

3. «Сайт не открывается, а сервер жив»

Проверяйте:

• слушает ли сервис нужный порт — ss -tulpn | grep -E ':(80|443)';
• пропускает ли его фаервол — iptables -L -n -v или ufw status verbose; часто блокируется входящий трафик на порт;
• есть ли маршрут до хоста — traceroute или mtr;
• не упал ли веб-сервер — проверьте статус systemd: systemctl status apache2 или nginx;
• корректен ли TLS/SSL для HTTPS — openssl s_client -connect site:443 покажет сертификат и возможные ошибки.

4. «В локалке всё работает, наружу — нет»

Обычно проблема в:

• шлюзе — проверьте, правильный ли адрес шлюза и доступен ли он;
• маршрутизации — возможно, отсутствует маршрут по умолчанию или он ведёт не туда;
• NAT — если используется частный IP, на маршрутизаторе должен быть настроен NAT (проверьте iptables -t nat -L);
• правилах фильтрации — фаервол на шлюзе может блокировать исходящий трафик;
• настройках провайдера — иногда проблема выше, но сначала исключите свои.

Как новичку изучать сети без хаоса

Пошаговый маршрут обучения

1. Разобраться с IP-адресами, масками и шлюзом — сразу настройте статический IP на виртуальной машине с Linux.
2. Понять разницу между коммутатором и маршрутизатором — соберите простую схему в эмуляторе (например, GNS3 или Cisco Packet Tracer).
3. Освоить DNS и порты — поднимите свой DNS-сервер (тот же dnsmasq) и посмотрите, как резолвятся имена.
4. Изучить TCP и UDP — с помощью tcpdump пронаблюдайте рукопожатие TCP и отличие UDP-датаграмм.
5. Понять основы маршрутизации — добавьте второй интерфейс виртуалке и настройте простейший роутинг.
6. Научиться читать сетевые параметры в Linux — ip a, ip r, ss, iptables должны стать привычными.
7. Освоить базовую диагностику — методично проходите по чек-листу при любой проблеме.

Минимальный набор команд для практики

На Linux системному администратору особенно полезно уметь:

• ip a — посмотреть адреса интерфейсов и их состояние;
• ip r — увидеть таблицу маршрутизации, особенно маршрут по умолчанию;
• ping — проверить достижимость (но учтите, что ICMP может блокироваться, тогда используйте tcptraceroute);
• traceroute (или mtr) — посмотреть путь пакета и задержки на каждом хопе;
• ss -tulpn — проверить открытые порты и слушающие процессы;
• dig или nslookup — проверить DNS, понять, какой сервер отвечает и какие записи возвращаются;
• tcpdump — посмотреть сетевой трафик в реальном времени (требует root).

Не нужно заучивать их все сразу. Сначала важно понять, какой вопрос задаёт команда, и применять её в типовых сценариях.

Чек-лист для проверки сети на рабочем месте

1. Устройство включено и сетевой интерфейс активен — ip link показывает состояние UP.
2. Получен IP-адрес — ip a выводит корректный адрес (не 169.254.x.x, если DHCP не сработал).
3. Маска подсети корректна — соответствует схеме адресации.
4. Шлюз по умолчанию задан правильно — ip r содержит default via … и шлюз пингуется.
5. DNS-сервер отвечает — dig example.com возвращает ответ без таймаута.
6. Нужный порт открыт — ss -tulpn показывает, что сервис слушает на ожидаемом порту.
7. Фаервол не блокирует соединение — временно отключите фаервол для теста или проверьте правила.
8. Маршрут до узла существует — traceroute доходит до цели без звёздочек на всех хопах (если не блокируется ICMP).
9. Сервис действительно запущен — systemctl status показывает active.
10. Нет проблем на стороне провайдера или вышестоящего оборудования — проверьте, доступны ли внешние ресурсы с другого устройства в той же сети.

Практический совет: как думать как админ

Сетевая диагностика не начинается с догадок. Она начинается с проверки уровней:

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

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

Частые ошибки начинающих

• Путают коммутатор и маршрутизатор — коммутатор не знает про IP, он работает с MAC-адресами; маршрутизатор принимает решение на основе IP.
• Думают, что если IP есть, значит всё должно работать — нет, нужны ещё шлюз и DNS, иначе выход в другие сети невозможен.
• Ищут проблему в приложении, когда не работает DNS — перезагружают веб-сервер, хотя достаточно поправить /etc/resolv.conf.
• Не проверяют шлюз по умолчанию — прописали статический IP, а про шлюз забыли; интернета нет, хотя локальная сеть работает.
• Смотрят только на кабель и забывают про фаервол — iptables может молча дропать пакеты; всегда проверяйте правила или временно отключайте фаервол для диагностики.
• Не понимают разницу между портом и IP-адресом — IP-адрес идентифицирует хост, порт — конкретный сервис на этом хосте; без порта непонятно, к какому приложению обращаться.
• Игнорируют подсети и пытаются строить сеть как одну большую плоскую зону — это приводит к широковещательному шторму, хаосу в безопасности и сложностям при масштабировании.

Вывод

Основы компьютерных сетей для системного администратора — это не теория ради экзамена, а рабочий инструмент. Если вы понимаете IP, маску, шлюз, DNS, порты, TCP/UDP и роль сетевых устройств, вы уже можете решать большую часть типовых проблем в инфраструктуре. Дальше всё упирается в практику: проверять соединения по шагам, не пропускать уровни и всегда отделять проблему сети от проблемы сервиса. Как только эти принципы войдут в привычку, вы перестанете бояться фразы «всё упало» и начнёте методично чинить.

FAQ

Что нужно выучить в первую очередь?

Сначала IP-адреса, маску подсети, шлюз, DNS и порты. Это база, без которой диагностика будет поверхностной. Сразу пробуйте настраивать сеть в Linux: задайте статический IP, пропишите DNS, проверьте связность.

Нужно ли будущему админу знать OSI?

Да, хотя бы на уровне понимания. Эта модель помогает разложить проблему по слоям и быстрее искать причину сбоя. Не обязательно заучивать все семь уровней наизусть, но уметь пройтись от физики до приложения — must have.

Чем коммутатор отличается от маршрутизатора?

Коммутатор соединяет устройства внутри одной сети на канальном уровне (L2), оперируя MAC-адресами. Маршрутизатор соединяет разные сети и выбирает путь трафика на сетевом уровне (L3) на основе IP-адресов. Современные L3-коммутаторы умеют маршрутизировать, но базовая идея та же: внутри подсети — коммутация, между подсетями — маршрутизация.

Почему DNS так важен?

Потому что люди работают с именами, а сеть — с IP-адресами. Если DNS не работает, сервис может быть доступен по IP, но недоступен по имени. А поскольку большинство сервисов завязаны на имена (веб, почта, обновления), сбой DNS парализует работу даже при идеально работающей физике и маршрутизации.

Что важнее для старта: теория или практика?

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