От IP-адресов и DNS до маршрутизации, безопасности и отладки. Фундамент, на котором держатся Linux, облако и Kubernetes, и без которого в три часа ночи приходится гадать вместо того, чтобы чинить.
Есть старая шутка инженеров: что бы ни сломалось, в итоге виноват DNS. Шутка живуча, потому что в ней много правды: огромная доля проблем в проде — это на самом деле проблемы сети, просто переодетые в «приложение тормозит» или «сервис не отвечает». А чинить сеть, не понимая, как она устроена, всё равно что искать утечку в темноте на ощупь.
Хорошая новость в том, что сетевые основы меняются медленно. Выучите их один раз — и это знание будет работать на вас и в Linux, и в AWS, и в Kubernetes, какой бы инструмент ни вошёл в моду. Давайте пройдём путь от азов до продвинутого, по дороге отвечая на главный вопрос: зачем это лично вам как инженеру.
Что такое сеть и как на неё смотреть
Сеть — это набор устройств, которые умеют обмениваться данными. Данные ходят не сплошным потоком, а кусочками — пакетами. Каждый пакет несёт адрес отправителя, адрес получателя и часть полезной нагрузки.
Чтобы не держать в голове всё сразу, сеть удобно представлять слоями. Практичнее всего модель TCP/IP из четырёх слоёв:
· Канальный — как соседние устройства общаются в пределах одной физической сети (MAC-адреса, Ethernet, Wi-Fi).
· Сетевой (IP) — как пакет находит дорогу между сетями по IP-адресам.
· Транспортный (TCP/UDP) — как организован поток между приложениями: с гарантией доставки или без.
· Прикладной — то, чем вы пользуетесь напрямую: HTTP, DNS, SSH.
Зачем это DevOps-инженеру: когда что-то не работает, эта лестница превращается в чек-лист. Вы идёте снизу вверх и отсекаете слои по очереди, вместо того чтобы паниковать сразу обо всём.
IP-адреса: кто есть кто в сети
IPv4-адрес выглядит как четыре числа от 0 до 255: например, 10.0.4.17. Адресов IPv4 на всех не хватило, поэтому существуют приватные диапазоны для внутренних сетей, которые не маршрутизируются в интернет напрямую:
· 10.0.0.0/8
· 172.16.0.0/12
· 192.168.0.0/16
Именно из этих диапазонов нарезаются адреса в облачных сетях и домашних роутерах. Параллельно существует IPv6 с гигантским запасом адресов (вида 2001:db8::1); в облаке вы будете встречать его всё чаще.
Зачем это знать: когда вы видите у сервиса адрес 10.x.x.x, вы сразу понимаете, что это внутренний адрес, и его нельзя достучаться снаружи без отдельной настройки. Половина вопросов «почему не подключается» — про это.
Подсети и CIDR: как делят адресное пространство
Дальше начинается то, что отпугивает новичков, а зря — это просто. Запись вроде 10.0.4.0/24 означает: первые 24 бита — это «адрес сети», а остальные 8 бит — адреса машин внутри неё. Восемь бит дают 256 адресов (из них пара служебных), то есть в подсети /24 помещается около 254 хостов.
Простое правило на пальцах: чем больше число после слеша, тем меньше подсеть. /24 — это 256 адресов, /16 — уже больше 65 тысяч, /32 — ровно один адрес.
Зачем это DevOps-инженеру: вы постоянно будете нарезать подсети в облачных сетях, задавать диапазоны для подов в Kubernetes и описывать правила доступа в терминах CIDR (например, «разрешить трафик только из 10.0.0.0/16»). Не уметь читать CIDR — значит не понимать собственную инфраструктуру.
Порты и протоколы: TCP против UDP
IP-адрес приводит пакет к нужной машине, а порт — к нужному приложению на ней. На одном сервере веб-сервис слушает порт 443, база — 5432, и они не мешают друг другу.
Два главных транспортных протокола:
· TCP — с установлением соединения и гарантией доставки. Перед обменом стороны проводят «рукопожатие», пакеты приходят по порядку и подтверждаются. Это HTTP, SSH, базы данных — всё, где важна целостность.
· UDP — без соединения и без гарантий, зато быстрый и лёгкий. Это DNS, видеозвонки, стриминг — там, где лучше потерять кусочек, чем ждать.
Полезно помнить частые порты: 22 (SSH), 80 (HTTP), 443 (HTTPS), 53 (DNS), 5432 (PostgreSQL), 3306 (MySQL), 6379 (Redis), 6443 (Kubernetes API). Когда сервис «не отвечает», первый трезвый вопрос — а слушает ли вообще нужный порт и открыт ли он на файрволе.
DNS: телефонная книга интернета
Люди помнят имена, а сеть работает с адресами. DNS переводит имя вроде api.example.com в IP. Упрощённо это происходит так: ваш резолвер спрашивает корневые серверы, те направляют к серверам зоны (.com), те — к авторитетному серверу домена, который и отдаёт нужный адрес. Ответ кешируется на время, заданное в TTL, чтобы не спрашивать каждый раз заново.
Базовые типы записей: A (имя на IPv4), AAAA (на IPv6), CNAME (псевдоним на другое имя), MX (почта), TXT (произвольный текст, часто для проверок), NS (серверы имён зоны).
Почему «всегда DNS»: именно из-за кеша и TTL. Вы поменяли адрес, а полмира ещё несколько часов или суток ходит по старому, потому что у них закешировался прежний ответ. Добавьте сюда опечатку в записи или забытый внутренний резолвер — и получите классический сбой, который выглядит как «приложение сломалось», хотя сломалось имя. В Kubernetes за внутренние имена сервисов отвечает CoreDNS, и его сбой кладёт обнаружение сервисов по всему кластеру.
Маршрутизация, шлюзы и NAT
Что происходит, когда пакету нужно покинуть свою подсеть? Он идёт на шлюз по умолчанию (default gateway). На каждой машине есть таблица маршрутизации, которая говорит: «в эту сеть — туда, всё остальное — на шлюз».
Отдельная важная штука — NAT (трансляция адресов). Машины с приватными адресами не видны в интернете, поэтому при выходе наружу их адрес подменяется на внешний. В облаке за это отвечает NAT-шлюз: он выпускает приватные подсети в интернет, не делая их доступными извне.
Зачем это знать: типичная облачная схема — приватные подсети с базами и бэкендами, которые ходят в интернет через NAT, и публичные подсети для того, что должно быть доступно снаружи. Понимание маршрутов отвечает на вопрос «почему мой сервис может скачать обновление, но к нему самому не подключиться».
Путь одного запроса (всё вместе)
Чтобы связать слои воедино, проследим, что происходит, когда сервис обращается к https://api.example.com:
1. DNS превращает имя в IP-адрес.
2. Маршрутизация ведёт пакеты через шлюз к нужной сети.
3. TCP-рукопожатие устанавливает соединение на порт 443.
4. TLS-рукопожатие согласует шифрование и проверяет сертификат.
5. HTTP-запрос уходит, приходит ответ.
Любая проблема живёт на одном из этих шагов. Хороший инженер не гадает, а спрашивает по порядку: имя резолвится? маршрут есть? порт открыт? TLS поднимается? ответ корректный? Это и есть та самая отладочная дисциплина.
Сетевая безопасность
Сеть — это и есть периметр, поэтому безопасность здесь не отдельная тема, а часть базовых навыков:
· Файрволы и правила доступа. В облаке это группы безопасности (на уровне инстанса, stateful, только разрешения) и сетевые ACL (на уровне подсети, stateless, есть и запреты). Принцип один: открывать минимум портов минимуму источников.
· Шифрование в пути. HTTPS/TLS по умолчанию, а не как опция. Внутренний трафик тоже стоит шифровать.
· Наименьшие привилегии в сети. Сервис должен иметь сетевой доступ только туда, куда ему действительно нужно. В Kubernetes за это отвечают сетевые политики (NetworkPolicy).
· VPN и приватный доступ к внутренним ресурсам вместо того, чтобы выставлять их в интернет.
Сеть в облаке и в Kubernetes
Здесь сходится всё, что выше, и начинается продвинутый уровень.
В облаке вы работаете с виртуальной сетью (VPC): нарезаете подсети по CIDR, разводите публичные и приватные, ставите Internet Gateway для выхода наружу и NAT для приватных подсетей, а перед сервисами вешаете балансировщики нагрузки.
В Kubernetes модель своя, и её важно понять:
· Каждый под получает собственный IP, и поды могут общаться друг с другом напрямую, без трансляции адресов.
· Поды эфемерны, их адреса меняются, поэтому поверх них существует Service — стабильный виртуальный адрес и имя, за которыми прячется набор подов.
· За назначение адресов и связность отвечает плагин CNI (Calico, Cilium, Flannel и другие).
· За внутренние имена отвечает CoreDNS, за маршрутизацию HTTP снаружи — Ingress, за сегментацию трафика — NetworkPolicy.
Без сетевых основ Kubernetes кажется магией. С ними он становится логичной надстройкой над тем, что вы уже знаете.
Инструменты отладки, которые стоит знать наизусть
Это ваш повседневный набор. Запомните не флаги, а на какой вопрос отвечает каждый инструмент:
· ping — машина вообще доступна?
· traceroute или mtr — по какому пути идёт трафик и где он застревает?
· dig или nslookup — как резолвится имя и что на самом деле отдаёт DNS?
· curl -v — что происходит на уровне HTTP и TLS, со всеми деталями?
· ss (или старый netstat) — какие порты сервис реально слушает?
· ip addr и ip route — какие адреса и маршруты у машины?
· nc или telnet host port — открыт ли конкретный порт, доходит ли соединение?
· openssl s_client — что не так с сертификатом и TLS?
· tcpdump — крайнее средство: посмотреть на сами пакеты, когда всё остальное молчит.
Методичный подход важнее знания флагов: идите по слоям. Сначала имя (DNS), потом доступность (ping/route), потом порт (nc/ss), потом приложение (curl). Тот, кто проверяет по порядку, находит причину за минуты. Тот, кто гадает, — за часы.
Сети — невидимый фундамент всего, чем занимается DevOps. Их редко замечают, пока всё работает, и судорожно вспоминают, когда падает. Но в отличие от модных инструментов это знание почти не устаревает: IP, DNS, маршрутизация и порты будут с вами и через десять лет, в каком бы облаке и оркестраторе вы ни работали.
Поэтому вложение окупается как мало что другое. Поймите, как имя превращается в адрес, как пакет находит дорогу и как проверять это по слоям, — и в следующий раз, когда «всё сломалось», вы не будете гадать. Вы спокойно пройдёте по лестнице сверху вниз и, скорее всего, обнаружите, что это снова был DNS.
Автор: Коробов Алексей
© Коробов А.Е., 2026
