DevOps
Сети для DevOps
Цели урока
- Понимать модель TCP/IP и различать TCP vs UDP по применению
- Использовать dig, curl, ss для диагностики сетевых проблем
- Настраивать DNS-записи и понимать TTL при миграциях
- Различать L4 и L7 балансировку, выбирать алгоритм под задачу
- Применять принцип default-deny при настройке firewalls
Предварительные знания
4 октября 2021. Facebook, Instagram, WhatsApp исчезли на 6 часов. Инженеры не могли войти в дата-центры - пропуска работали через ту же сеть. Причина: одна BGP-команда удалила все DNS-записи компании. 3.5 млрд пользователей offline, потери - десятки миллионов долларов. Одна сетевая ошибка. Одна строка конфига.
- **Каждый HTTP-запрос** проходит через DNS, TCP/IP, возможно load balancer и firewall. Без понимания сетей невозможно отладить ни один production-инцидент
- **Kubernetes networking** - pods, services, ingress - всё базируется на TCP/IP, DNS и L7 балансировке
- **Микросервисы** общаются по сети. Сетевые проблемы (timeout, DNS, firewall) - причина номер один инцидентов в распределённых системах
- **Security** - открытый Redis = взлом за минуты. Понимание портов и firewalls спасает компании от утечек данных
Рождение TCP/IP
В 1974 году Винт Серф и Боб Кан опубликовали статью о протоколе TCP - основе интернета. Первая сеть ARPANET использовала NCP, но TCP/IP оказался настолько удачным, что 1 января 1983 года ARPANET полностью перешла на него. Этот день называют "днём рождения интернета". Серф и Кан не думали о Netflix и Kubernetes - они думали о надёжности военной связи. Протокол пережил всех.
TCP/IP: как данные путешествуют по сети
Октябрь 2021. Инженеры Facebook не могут попасть в дата-центры: бейджи работают через ту же сеть, которая только что исчезла. 3.5 миллиарда пользователей, 6 часов тишины, причина - одна строка в конфиге BGP. Сетевая ошибка не выглядит как ошибка, пока она не обрушивает всё. HTTP-запрос проходит через **4 уровня** модели TCP/IP, и каждый - точка отказа.
**TCP vs UDP** - два транспортных протокола с принципиально разными гарантиями. TCP - это контракт: каждый пакет будет доставлен, порядок сохранён, потери переотправлены. UDP - это залп: быстрее, но без обещаний. Streaming-видео предпочитает потерять кадр, чем буферизоваться на 3 секунды.
| Характеристика | TCP | UDP |
|---|---|---|
| Гарантия доставки | Да (retransmission) | Нет |
| Порядок пакетов | Гарантирован | Не гарантирован |
| Установка соединения | 3-way handshake | Нет (connectionless) |
| Скорость | Медленнее (overhead) | Быстрее |
| Применение | HTTP, SSH, PostgreSQL, email | DNS, видео, VoIP, игры |
**3-way handshake** - установка TCP-соединения за 3 шага: SYN, SYN-ACK, ACK. Только после этого передаются данные. Это и есть latency "до первого байта" - TTFB, который DevOps видит в метриках каждый день.
**Порты** - числа 0-65535, идентифицирующие конкретное приложение. IP-адрес - адрес дома, порт - номер квартиры. 127.0.0.1:5432 - PostgreSQL принимает только локальные соединения. 0.0.0.0:5432 - принимает со всех интерфейсов.
Сервис PostgreSQL слушает на 127.0.0.1:5432. Можно ли подключиться к нему с другого сервера?
DNS: телефонная книга интернета
Люди запоминают имена (google.com), компьютеры работают с числами (142.250.74.46). **DNS** - распределённая иерархическая база данных, работающая с 1983 года. Когда Facebook упал в 2021-м, BGP-ошибка удалила DNS-записи - и весь интернет перестал «видеть» Facebook, хотя серверы физически работали.
DevOps-инженеру важно знать **типы DNS-записей** - они настраиваются при каждом деплое нового сервиса.
| Тип записи | Назначение | Пример |
|---|---|---|
| A | Домен → IPv4 адрес | api.example.com → 203.0.113.42 |
| AAAA | Домен → IPv6 адрес | api.example.com → 2001:db8::1 |
| CNAME | Алиас (домен → домен) | www.example.com → example.com |
| MX | Почтовый сервер | example.com → mail.example.com (приоритет 10) |
| TXT | Произвольный текст | SPF, DKIM, верификация домена |
| NS | Nameserver для зоны | example.com → ns1.registrar.com |
**TTL** (Time To Live) - сколько секунд DNS-запись кешируется. Высокий TTL (86400 = 24 часа) - меньше нагрузки на DNS, но медленное переключение при миграции. Низкий TTL (60 = 1 минута) - быстрое переключение, но больше запросов к серверу.
Перед миграцией сервера: снизить TTL до 60 секунд за 24-48 часов ДО переезда. При смене IP пользователи переключатся за минуту, а не за сутки. После миграции вернуть TTL обратно.
DNS-кеширование даёт неожиданные результаты. A-запись обновлена, но часть пользователей видит старый IP - TTL предыдущей записи ещё не истёк. Подождать TTL секунд, или проверить через `dig @8.8.8.8` - другой resolver не имеет кеша.
После обновления A-записи домена (TTL был 86400) прошло 2 часа, но часть пользователей видит старый IP. Почему?
Балансировка нагрузки
Один сервер справляется с 1000 RPS. Сервис вырос до 10 000 RPS. Горизонтальное масштабирование: несколько серверов за **балансировщиком нагрузки**. Именно так Netflix переживает спайки в 80 млн одновременных стримов - не один гигантский сервер, а тысячи машин за умным балансировщиком.
**L4 vs L7** - ключевое различие. L4 работает на транспортном уровне (TCP), видит только IP и порт - идеально для сырой скорости. L7 работает на прикладном уровне (HTTP), видит URL, заголовки, cookies - позволяет маршрутизировать `/api/*` на backend-кластер, а `/static/*` на CDN.
| Алгоритм | Как работает | Когда использовать |
|---|---|---|
| Round Robin | По очереди: 1→2→3→1→2→3 | Серверы одинаковой мощности, stateless-приложения |
| Least Connections | На сервер с наименьшим числом соединений | Запросы разной "тяжести" (короткие + долгие) |
| IP Hash | Hash IP клиента определяет сервер | Sticky sessions без cookies |
| Weighted Round Robin | Пропорционально весам серверов | Серверы разной мощности (2:1:1) |
| Random | Случайный сервер | Простая реализация, хорошо при большом числе серверов |
**Health checks** - балансировщик регулярно проверяет, жив ли каждый backend. Если сервер не отвечает - трафик уходит на оставшиеся. Без health checks мёртвый сервер продолжает получать запросы, и пользователи видят ошибки.
Endpoint /health - стандартная практика. Балансировщик отправляет GET /health каждые N секунд. Ответ 200 = сервер жив. Хороший health check проверяет не только "процесс запущен", но и "база доступна, Redis работает, диск не полный".
В кластере 3 backend-сервера за nginx. Один упал. Что произойдёт с запросами при настройке max_fails=3 fail_timeout=30s?
Firewalls и сетевая безопасность
Сервер доступен из интернета. Без **firewall** любой сканер найдёт PostgreSQL (5432), Redis (6379), SSH (22) и попробует подключиться. В 2017 году тысячи Redis-серверов были взломаны именно так: никакого firewall, никакого пароля - полный доступ к серверу через CONFIG SET. Firewall - фильтр, который решает, какие пакеты пропускать.
**Stateful vs Stateless.** Stateless проверяет каждый пакет изолированно - примитивно, но быстро. Stateful отслеживает соединения: если разрешили исходящий HTTP-запрос, ответные пакеты пропускаются автоматически. Все современные production-firewalls - stateful.
nftables - замена iptables в современном Linux. Синтаксис чище, производительность выше. В Ubuntu 22.04+ nftables - стандарт. iptables всё ещё работает как обёртка над nftables.
В облаке (AWS, GCP, Azure) вместо iptables - **Security Groups**: виртуальные firewalls, привязанные к инстансу. Принцип тот же: default deny, explicit allow. Terraform позволяет описать их как код.
| Порт | Сервис | Кому открывать |
|---|---|---|
| 22 | SSH | Только VPN / bastion host / офисный IP |
| 80 | HTTP | Всем (0.0.0.0/0) |
| 443 | HTTPS | Всем (0.0.0.0/0) |
| 5432 | PostgreSQL | Только backend-серверам (10.0.0.0/24) |
| 6379 | Redis/KeyDB | Только backend-серверам (НИКОГДА наружу!) |
| 3000-9000 | App servers | Только через Load Balancer |
Redis/Memcached открытый в интернет - одна из самых распространённых уязвимостей. В 2017 году тысячи Redis-серверов были взломаны из-за отсутствия firewall. Атакующие записывали SSH-ключи через Redis CONFIG SET и получали полный доступ к серверу.
Firewall обеспечивает полную защиту сервера - если порты закрыты, взломать невозможно
Firewall - лишь один слой защиты в стратегии defense-in-depth. Открытые порты (80, 443) всё ещё уязвимы для атак на приложение (SQL injection, XSS, RCE)
Firewall фильтрует трафик по IP/портам, но не анализирует содержимое HTTP-запросов. Атакующий может эксплуатировать уязвимость через разрешённый порт 443. Нужны все слои: firewall + WAF + обновления ПО + мониторинг + принцип минимальных привилегий.
На сервере открыт SSH (22), HTTP (80), HTTPS (443), PostgreSQL (5432) и Redis (6379) для всех IP (0.0.0.0/0). Что нужно исправить В ПЕРВУЮ ОЧЕРЕДЬ?
Ключевые идеи
- TCP/IP - 4 уровня: Link → Internet → Transport → Application. TCP гарантирует доставку, UDP - быстрый но без гарантий
- DNS - иерархическая система (root → TLD → authoritative). TTL определяет время кеширования. Перед миграцией снижать TTL заранее
- Load Balancing - L4 (по IP/порту, быстрый) vs L7 (по HTTP, умный). Алгоритмы: round-robin, least connections, IP hash
- Health checks - балансировщик проверяет жизнь backends через /health endpoint
- Firewall - default deny, открывать только нужное. БД и кеш - НИКОГДА наружу
- Facebook 2021: DNS и BGP - основа доступности. Одна ошибка в сетевом конфиге может положить весь сервис
Связанные темы
Сетевые знания - фундамент для контейнеризации, оркестрации и облачной инфраструктуры:
- Linux для DevOps — Сетевые утилиты (curl, ss, tcpdump, iptables) - часть Linux toolkit
- Что такое DevOps — SLI/SLO из урока 1 измеряют сетевые характеристики: latency, availability
Вопросы для размышления
- Сервис отвечает медленно. Как с помощью curl, dig и ss определить: проблема в DNS, сети или приложении?
- Почему базы данных (PostgreSQL, Redis) никогда не должны быть доступны из интернета, даже если у них сложный пароль?
- Для сервиса с 50 000 RPS - какой тип балансировки (L4 или L7) и какой алгоритм оптимальны? Почему?
Связанные уроки
- devops-01 — SLI/SLO из первого урока измеряют latency и availability
- devops-02 — Сетевые утилиты - часть Linux toolkit
- devops-04 — Контейнерные сети строятся поверх TCP/IP и DNS
- devops-06 — Kubernetes networking: pods, services, ingress
- sec-01 — Firewall rules - первый слой в defense-in-depth
- cloud-03 — CDN и GeoDNS - те же принципы DNS на глобальном уровне
- net-01-intro
- net-47-container-networking