DevOps
Модуль 1: Networking Basics


Модуль 1: Networking Basics
Понимание сетевого стека критично для эксплуатации распределенных систем. Большинство инцидентов «сервис недоступен» имеют корневую причину в сетевой связности (DNS, Firewall, Routing). часть серьёзных инцидентов — это не упало, а торчит наружу. Классический пример: открытый Elasticsearch/Redis без аутентификации, из которого утекают персональные данные. Поэтому networking для DevOps — это ещё и контроль поверхности атаки: какие порты реально доступны снаружи и зачем.
Необходимый инструментарий
  • Утилиты: curl, telnet (или nc), dig (пакет dnsutils или bind-utils), tcpdump, traceroute, ipcalc.
Опционально (но очень полезно):
  • ss (обычно есть в Linux), ip (iproute2), mtr, openssl.
Часть 1. Стек протоколов (TCP/IP)
1.1 IP Addressing & Subnets
CIDR (Classless Inter-Domain Routing): Как понять, находятся ли IP в одной сети? Нужна маска.

  • 192.168.1.10/24 -> Маска 255.255.255.0. Диапазон: 192.168.1.1 - 192.168.1.254.
  • localhost (127.0.0.1) - Loopback интерфейс. Трафик не покидает пределы хоста.
Практика: Посмотреть свои IP.
ip addr show
# или
ifconfig
Практика: быстро прикинуть подсеть.
ipcalc 192.168.1.10/24
ipcalc 10.0.2.15/16
1.2 TCP vs UDP: Наглядная разница
TCP (Web, Mail, SSH): Надежность. Handshake (SYN -> SYN-ACK -> ACK). Соединение устанавливается до передачи данных.

  • Проверка:
  • nc -vz google.com 80 - увидите "succeeded", это завершился хендшейк.
  • Если telnet установлен: telnet google.com 80.

UDP (DNS, Video, Voice): Скорость. Нет соединения. Просто шлем пакеты. Если потерялись - не страшно.
  • Проверка: nc -u -z 8.8.8.8 53 - сканирование UDP порта.

Где это встречается в observability:
  • UDP часто используется в StatsD/DogStatsD для метрик (минимальная задержка, допускается потеря части пакетов).
  • Prometheus в классическом режиме не использует UDP для сбора: он скрейпит /metrics по HTTP (TCP).
Часть 2. Маршрутизация и порты (то, что ломается в проде)
1.3 Маршруты и default gateway
Если пинг до 8.8.8.8 не идёт - часто проблема не в DNS, а в маршруте.
Посмотреть маршруты:
ip route
Обычно вы увидите:
  • default via 192.168.1.1 dev eth0 - куда уходит всё «в интернет».
  • маршруты в локальные подсети.
macOS: netstat -rn | head.
1.4 Порты и состояния TCP (SYN-SENT, ESTAB, TIME_WAIT)
Уметь читать ss - это как уметь читать логи.
  • Что слушает порты:
ss -lntp
  • Активные соединения:
ss -ant
Типовые симптомы:
  • Много TIME_WAIT - частые короткие коннекты (или неправильный keep-alive).
  • Много SYN-SENT - клиент не получает SYN-ACK (firewall/маршрут/порт закрыт).
  • Connection refused - хост доступен, но приложение не слушает порт.
  • timeout - пакеты «где-то» дропаются (firewall/ACL/security group).
1.5 Firewall: быстро проверить «дропает ли он»
На Linux чаще всего встречаются nftables/iptables, поверх них - ufw.

  • UFW (Ubuntu):
sudo ufw status verbose
  • nftables:
sudo nft list ruleset | head -n 50
Важно: на облаках «файрвол» часто в двух местах — на хосте и на уровне сети (Security Groups / NACL). В модуле это не разбираем глубоко, но держите в голове.
Часть 3. Ключевые протоколы Web
1.3 DNS (Domain Name System)
"Телефонная книга" интернета. Типы записей:
  • A: Домен -> IPv4.
  • AAAA: Домен -> IPv6.
  • CNAME: Домен -> Другой Домен (Алиас).
  • MX: Почтовый сервер.
Диагностика с dig:
dig google.com +short
# Вывод: список IP адресов (142.250.x.x)

dig google.com NS
# Вывод: какие Name Servers отвечают за зону google.com
Полезные приёмы:

  • Посмотреть, какой DNS используется локально:
cat /etc/resolv.conf
На системах с systemd-resolved резолв может идти через локальный stub 127.0.0.53.
  • Проверить резолв «по цепочке»:
dig google.com +trace
1.4 HTTP & TLS
Основа взаимодействия микросервисов. Структура запроса: METHOD PATH VERSION + Headers.

  • Детальный разбор с curl:
curl -v https://google.com
Вывод покажет:
  1. * Trying 142.250... (TCP Handshake)
  2. * TLSv1.3, TLS handshake (Шифрование)
  3. > GET / HTTP/2 (Отправка запроса)
  4. < HTTP/2 200 (Код ответа)
  5. < content-type: text/html (Заголовки ответа)

TLS дебаг (когда странные ошибки сертификатов):
openssl s_client -connect google.com:443 -servername google.com </dev/null | head -n 40
Это полезно, когда нужно увидеть цепочку сертификатов и SNI.

Проверка конкретного IP (обход DNS):
curl -v --resolve example.com:443:93.184.216.34 https://example.com/
Troubleshooting Guide: Network Issues
1. Connectivity Check (L3/L4)
Сервис недоступен. Где проблема?

  1. Пинг (L3):
ping -c 4 8.8.8.8
  • Если таймаут — возможно, нет маршрута (ip route) или дропает Firewall.

2. Порты (L4): Слушает ли порт удаленный сервер?
nc -zv 192.168.1.50 8080
# Connection refused - сервер доступен, но порт закрыт (приложение упало).
# Connection timed out - сервер недоступен или пакеты дропает Firewall.
Слушаю ли я порт локально?
ss -tunlp | grep 8080
3. Путь пакета: Где обрывается связь? На шлюзе провайдера или внутри дата-центра?
traceroute google.com
# или (более современный вариант)
mtr google.com
1.5 Когда нужен tcpdump (и как не утонуть)
tcpdump нужен, когда «всё выглядит правильно», но пакеты не приходят/не уходят.

  • Поймать DNS-запросы:
sudo tcpdump -ni any port 53
  • Поймать TCP рукопожатие до порта 443:
sudo tcpdump -ni any tcp port 443 and '(tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'
  • Сохранить в файл для Wireshark:
sudo tcpdump -ni any -w capture.pcap port 443
2. DNS Issues
«Не могу найти хост». Проверка резолва через конкретный сервер (например, через Google DNS vs локальный):
dig @8.8.8.8 my-service.internal
dig @127.0.0.53 my-service.internal
Итоговая задача: «Netcat Chat»
Понимание сокетов «на пальцах». Нужны два терминала (или две виртуалки).

Задача:
1. Server side (Терминал 1): Открыть порт 9000 и слушать входящие соединения.
nc -l -p 9000
2. Client side (Терминал 2): Подключиться к серверу.
nc 127.0.0.1 9000  # (замените IP, если разные машины)
3. Напишите что-нибудь в Терминале 2, нажмите Enter. Текст появится в Терминале 1.
4. Закройте сервер (Ctrl+C). Клиент должен получить EOF и тоже закрыться.

Бонус: Попробуйте передать файл. Server: nc-l -p 9000 > received_file.txt Client: nc127.0.0.1 9000 < full_file.txt
Дополнительная практика: «Диагностика 502/таймаута за 5 минут»
Смоделируйте ситуацию: «сервис недоступен».

  1. Поднимите простой HTTP-сервер локально:
python3 -m http.server 8080
2. Проверьте доступность:
curl -v http://127.0.0.1:8080
3. Проверьте, что порт реально слушается:
ss -lntp | grep 8080
4. Сломайте сценарий:
  • остановите сервер (Ctrl+C) и посмотрите Connection refused;
  • попробуйте обратиться по несуществующему имени хоста и поймайте DNS-проблему.
Цель: научиться быстро отличать «не слушает порт» от «DNS не резолвит» и от «пакеты дропаются».