Сетевые основы для джуниор DevOps-инженера: от OSI до iptables

Помните тот момент, когда вы только начинали путь в DevOps и пытались понять, почему приложение не отвечает? Вы проверили логи приложения, всё чисто. Вы перезапустили контейнер, ничего не изменилось. А потом кто-то старший сказал: «Попробуй пингануть с хоста» или «Где у нас открыт порт?». В этот момент становится ясно: без понимания сетей вы будете просто кнопочным нажимателем, а не инженером инфраструктуры.

Для джуниора сети - это часто самый страшный зверь. Слишком много аббревиатур, слишком много уровней. Но правда в том, что вам не нужно знать всё про BGP и MPLS, чтобы начать работу. Вам нужно понимать базовый поток данных: как запрос пользователя превращается в пакеты, летит через маршрутизаторы, попадает в ваш сервер и возвращается обратно. Давайте разберем этот процесс так, чтобы он перестал быть магией и стал понятной механикой.

Зачем DevOps-инженеру знать сеть глубже, чем обычный разработчик

Разработчик обычно работает на уровне кода. Ему важно, чтобы функция вернула JSON. Инфраструктурному же инженеру важно, чтобы этот JSON долетел до клиента за приемлемое время. Если вы не понимаете, как работает балансировка нагрузки или почему DNS может кешироваться часами, вы будете тратить часы на дебаггинг проблем, которые решаются одной командой.

Вот три типичных ситуации, где знание сетей спасает нервы:

• Доступность сервисов: Почему Nginx возвращает 502 Bad Gateway? Часто дело не в Nginx, а в том, что бэкенд-сервер недоступен по сети (таймаут соединения, закрытый порт).
• Безопасность: Как правильно настроить файрвол, чтобы открыть доступ только нужным IP, но не закрыть себе вход по SSH?
• Производительность: Почему API отвечает медленно? Может быть, проблема в задержке сети (latency) между дата-центрами, а не в медленном SQL-запросе.

Модель OSI и TCP/IP: карта местности

Все сетевые разговоры строятся на двух моделях: OSI (7 уровней) и TCP/IP (4 уровня). Для повседневной работы DevOps чаще используют терминологию TCP/IP, но концепция уровней из OSI помогает локализовать проблему.

Не учите эти уровни наизусть ради экзамена. Используйте их как чек-лист при диагностике:

Если ping проходит, но curl падает с ошибкой соединения - проблема на 4 уровне (порт закрыт или файрвол блокирует). Если curl соединяется, но возвращает ошибку 500 - проблема уже внутри вашего приложения или базы данных.

IP-адресация и подсети: не бойтесь масок

Каждое устройство в вашей инфраструктуре имеет уникальный адрес. Мы привыкли к IPv4 (формата 192.168.1.1), но мир постепенно переходит на IPv6. Для джуниора критически важно понимать разницу между публичными и приватными IP.

Приватные адреса (диапазоны 10.x.x.x, 172.16.x.x - 172.31.x.x, 192.168.x.x) не могут быть напрямую доступны из интернета. Это значит, что ваши серверы внутри кластера Kubernetes общаются по этим адресам, а наружу выходит только один балансировщик с публичным IP.

Маска подсети (например, /24) определяет размер вашей локальной сети. /24 означает, что первые 24 бита фиксированы, а последние 8 бит свободны для хостов. Это дает $2^8 = 256$ адресов, минус два служебных (сеть и broadcast). Итого 254usable адреса. Если вы видите ошибку "No space left on device" при создании новых инстансов в облаке, возможно, вы исчерпали пул IP в подсети.

Протоколы TCP и UDP: надежность против скорости

На транспортном уровне живут два главных героя: TCP и UDP.

TCP - это заказное письмо с уведомлением о вручении. Он гарантирует доставку, порядок пакетов и целостность данных. Если пакет потерялся, он будет переотправлен. Именно поэтому веб-сайты (HTTP/HTTPS), базы данных и SSH работают поверх TCP. Минус? Задержка на установку соединения (three-way handshake) и контроль потока.

UDP - это крик в толпе. Отправил и забыл. Нет гарантии доставки, нет порядка. Зато очень быстро и мало накладных расходов. Так работают видеозвонки (Zoom, Teams), игры и DNS-запросы. Если вы настраиваете мониторинг метрик через StatsD или Prometheus pushgateway, вы, скорее всего, имеете дело с UDP.

Как проверить, какой протокол использует ваше приложение? Посмотрите на порты. HTTP(S) - всегда TCP. DNS - чаще UDP (порт 53), но иногда TCP для больших ответов. Базы данных типа PostgreSQL или MySQL - строго TCP.

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

Люди запоминают имена (example.com), машины понимают числа (IP-адреса). Между ними стоит система DNS. Ошибки DNS - одна из самых частых причин «странного» поведения сервисов.

Важнейший параметр здесь - TTL (Time To Live). Это время, в течение которого другие серверы хранят запись в кеше. Если вы сменили IP-адрес сервера, а TTL был выставлен в 3600 секунд (1 час), то пользователи будут идти на старый IP еще целый час. Для продакшена лучше использовать меньшие значения (300-600 секунд), чтобы быстрее переключать трафик при авариях.

Типичные записи, с которыми вы столкнетесь:

• A record: Связывает домен с IPv4 адресом.
• AAAA record: То же самое, но для IPv6.
• CNAME: Алиас. Указывает, что www.example.com - это то же самое, что example.com. Полезно для балансировщиков нагрузки AWS ALB или Cloudflare.
• MX record: Почтовые серверы. Не трогайте их, если не настраиваете почту.

Команда dig example.com покажет вам всю цепочку разрешения имени и текущий TTL. Всегда проверяйте DNS перед тем, как грешить на код приложения.

Firewall и iptables: первый рубеж обороны

В Linux все сетевые фильтры проходят через ядро, используя механизм iptables (или более современный nftables). Даже если вы используете облачные Security Groups, на самом хосте тоже есть файрвол.

Логика iptables строится на правилах (chains). Есть три основные цепочки:

1. INPUT: Пакеты, идущие на сам сервер.
2. OUTPUT: Пакеты, исходящие с сервера.
3. FORWARD: Пакеты, проходящие сквозь сервер (если он работает как роутер).

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

Пример команды, которая запрещает весь входящий трафик, кроме SSH (порт 22) и HTTP (порт 80):

sudo iptables -P INPUT DROP
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Строка с ESTABLISHED,RELATED критически важна. Она позволяет отвечать на входящие запросы. Без неё вы откроете порт 80, но сервер не сможет отправить ответ клиенту, потому что обратный пакет будет считаться новым входящим соединением и заблокируется политикой DROP.

Полезные утилиты в арсенале DevOps

Вам не нужны сложные GUI-мониторы. В терминале есть всё необходимое. Освойте эти пять инструментов до автоматизма:

• ping: Проверяет доступность хоста по IP. Если пинг не идет, дальше можно не смотреть. Исключение: некоторые файрволы блокируют ICMP (ping), но открывают TCP. Тогда используйте telnet.
• traceroute (или mtr): Показывает маршрут пакета до цели. Поможет найти, где именно теряются пакеты или возникает высокая задержка.
• netstat или ss: Показывает активные сетевые соединения и слушающие порты. Команда ss -tulpn - ваш лучший друг при поиске занятого порта.
• tcpdump: «Wireshark в консоли». Позволяет захватывать сырые пакеты. Незаменимо, когда нужно понять, приходит ли вообще трафик на интерфейс и что именно там лежит.
• curl: Универсальный солдат. Позволяет эмулировать запросы браузера, проверять заголовки, тайминги и сертификаты SSL.

Например, чтобы измерить время ответа сервера и увидеть детали TLS-рукопожатия, выполните:

curl -v https://example.com

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

Контейнеры и сети: Docker и Kubernetes

В современном DevOps мы редко работаем с «голыми» серверами. Мы используем Docker и Kubernetes. Здесь сети становятся еще абстрактнее, но принципы те же.

В Docker есть несколько драйверов сети:

• Bridge (по умолчанию): Контейнеры получают свои внутренние IP (обычно 172.17.x.x). Они могут общаться друг с другом по именам контейнеров, если находятся в одной пользовательской bridge-сети. Чтобы достучаться снаружи, нужно пробросить порт (-p 8080:80).
• Host: Контейнер использует сетевой стек хоста. Нет изоляции, нет NAT, максимальная производительность. Удобно для простых задач, но опасно для микросервисов (конфликты портов).
• Overlay: Используется в Docker Swarm и Kubernetes для связи контейнеров на разных физических серверах. Создает виртуальную сеть поверх физической.

В Kubernetes каждый Pod получает свой IP. Сервисы (Services) создают стабильные DNS-имена и балансируют нагрузку между подами. Понимание того, как kube-proxy обрабатывает трафик (через iptables или IPVS), поможет вам диагностировать проблемы с внутренним взаимодействием микросервисов.

Частые ошибки новичков и как их избежать

Давайте соберем опыт коллег в короткий список граблей, на которые наступают почти все:

Практические шаги для закрепления материала

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

1. Поднимите локальный стенд: Запустите два контейнера Docker с простым Python-приложением. Настройте их общение через пользовательскую bridge-сеть.
2. Послушайте трафик: Выполните tcpdump -i eth0 port 80 внутри контейнера и сделайте запрос с хоста. Изучите вывод. Найдите SYN, ACK флаги.
3. Сломайте сеть: Попробуйте заблокировать порт 80 в iptables внутри контейнера. Убедитесь, что curl начинает падать. Затем раскомментируйте правило и убедитесь, что всё заработало.
4. Измерьте latency: Сравните время ответа curl -w "%{time_total}\n" http://localhost и http://google.com. Поймите разницу между локальной сетью и интернетом.

Сети - это фундамент. Если вы твердо стоите на этом фундаменте, любые новые технологии (Service Mesh, eBPF, SDN) станут понятными надстройками, а не пугающими монстрами. Не пытайтесь выучить всё сразу. Разбирайте одну проблему за раз, и со временем ваша картина мира станет полной и логичной.