Сетевые протоколы и адресация

Что такое Сетевые протоколы и адресация

Адресация — то, как узел отвечает на вопрос «кому передать данные». Единого адреса не существует: на каждом уровне свой идентификатор, и все они работают одновременно, вложенные друг в друга.

Ethernet   MAC-адрес     52:54:00:ab:cd:ef   какому устройству в сегменте
   ↓
IP         IP-адрес      93.184.216.34       какому узлу в сети
   ↓
TCP        порт          443                 какому приложению на узле
   ↓
HTTP       URI           /api/v1/users       какому ресурсу в приложении

Разделение не избыточно: MAC не уходит дальше первого маршрутизатора, IP не знает про приложения, порт бессмысленен без IP. Открывая страницу, вы задействуете все четыре — и каждый протокол отвечает ровно за свой слой.

Кто во что превращает

Адреса разных уровней связывают отдельные протоколы, и именно они ломаются чаще всего:

Отсюда практический вывод: «сайт не открывается» — это отказ на одном из этих переходов, и диагностика состоит в том, чтобы найти, на каком.

Адресация в облаке

В облаке у сервера почти всегда два адреса, и это сбивает с толку тех, кто привык к железу.

• Приватный IP — из диапазона вашей VPC, например 10.0.1.15. Выдаётся автоматически, живёт вместе с инстансом и умирает вместе с ним. Внутри сети сервисы общаются именно по нему.
• Публичный IP — белый адрес, доступный из интернета. Его не видно внутри гостевой ОС: ip addr покажет только приватный, а публичный навешивается платформой снаружи через NAT «один к одному».

Именно поэтому команда ip addr на облачном инстансе и сервис вроде ifconfig.me показывают разные адреса — оба ответа верные, просто про разные вещи.

EIP

EIP (Elastic IP) — публичный адрес, который принадлежит не инстансу, а вашему аккаунту. Обычный публичный IP выдаётся при запуске и теряется при остановке; EIP вы резервируете за собой и назначаете на любой сервер, а при необходимости — переносите.

Разница решает вполне конкретные задачи:

Зачем это на практике:

• Переключение при аварии. Сломался сервер — переносите EIP на резервный. Адрес не меняется, DNS править не нужно, кеш резолверов не мешает. Это быстрее смены A-записи, у которой есть TTL.
• Белые списки у партнёров. Согласовать IP с банком или внешним API — недели. Пересоздавать сервер после этого с новым адресом нельзя.
• Репутация для почты. PTR-запись и история адреса в спам-листах привязаны к конкретному IP — терять его при каждом деплое недопустимо.
• Разделение жизненных циклов. Сервер — расходник, адрес — постоянная величина: можно пересобрать инстанс с нуля, оставив точку входа прежней.

В разных облаках это называется по-разному — Elastic IP, floating IP, плавающий адрес, — но идея одинакова: белый адрес как самостоятельный ресурс.

Что помнить при проектировании

• Диапазоны не должны пересекаться. Если VPC и офисная сеть обе используют 192.168.1.0/24, соединить их через VPN не выйдет — маршрутизатор не поймёт, куда слать пакет. Планируйте CIDR заранее.
• Внутри — по именам, не по адресам. Приватный IP меняется при пересоздании инстанса; FQDN или имя сервиса — нет.
• Публичный адрес — не всем. Базам и внутренним сервисам он не нужен: выход в интернет им даёт NAT-шлюз, а входящих соединений быть не должно.
• Метаданные лежат на 169.254.169.254 — служебный link-local адрес, по которому инстанс узнаёт о себе: имя, ключи, cloud-init-конфиг.

Связанные термины

• IP-адрес — основной идентификатор узла
• Маска подсети и CIDR — как режут адресное пространство
• NAT — связывает приватные и публичные адреса
• VPC — где живёт облачная адресация
• DNS — верхний уровень адресации, имена
• Сетевые протоколы — правила поверх адресов