Специальные IP — приватные, loopback, link-local и broadcast

Не все IP-адреса одинаковы. У 192.168.1.5 и 8.8.8.8 совершенно разная судьба: первый никогда не появится в интернете, второй — публичный DNS-сервер Google. Эти различия закреплены в RFC и поддерживаются всеми роутерами в мире.

В этом уроке разберём специальные диапазоны IPv4-адресов: приватные (10.0/8, 172.16/12, 192.168/16), loopback (127.0.0.1), link-local (169.254/16), broadcast и multicast. Знание этих диапазонов даёт DE возможность быстро ориентироваться — увидев 100.64.X.X в логах, вы сразу поймёте, что это CGNAT провайдер, а не атака.

Приватные адреса — RFC 1918

В 1996 году IANA выделила три диапазона как «приватные» — их можно использовать в локальной сети без регистрации, но они никогда не маршрутизируются в публичном интернете. Все провайдеры обязаны дропать пакеты с такими адресами на границе.

Эти диапазоны можно использовать сколько угодно раз в разных сетях. У вас дома 192.168.1.X, у соседа тоже 192.168.1.X, и это нормально — они изолированы NAT-ами провайдеров.

# Где обычно встречаете приватные:
# - Дома (192.168.X.X)
# - В офисе (10.X.X.X или 172.16-31.X.X)
# - В Docker (172.17-31.X.X)
# - В Kubernetes (10.X.X.X для pod CIDR, 172.20.X.X для services)
# - В AWS VPC (10.X.X.X по дефолту)
# - В VPN-сетях (любой из трёх)

Что бывает, если приватный IP «утечёт» в публичный интернет:

• Провайдер дропает на границе (ingress filtering, RFC 2827 / BCP 38).
• Если как-то прошёл — маршрут до него отсутствует в публичной BGP-таблице, пакет дропается на первом роутере.
• TTL истечёт за несколько хопов.

Поэтому приватные IP никогда не доходят до публичных сервисов. Логи на github.com никогда не покажут IP 192.168.X.X — они покажут публичный IP вашего NAT.

Loopback — 127.0.0.0/8

Loopback — адреса, ссылающиеся на саму машину. Стандартное обозначение — localhost -> 127.0.0.1.

Особенности:

• Любой адрес 127.X.X.X — loopback. Можно использовать 127.0.0.5, 127.10.20.30 — всё это та же машина.
• Пакеты на loopback никогда не идут в сетевую карту. Они обрабатываются в ядре прямо в TCP/IP-стеке.
• Loopback-интерфейс lo есть всегда. Он не привязан к физической сети.
• MTU на lo — 65,535 (а не 1500). Можно гонять огромные пакеты без фрагментации.

# Посмотреть loopback:
ip addr show lo
# 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
#     inet 127.0.0.1/8 scope host lo
#     inet6 ::1/128 scope host

# IPv6 эквивалент:
ping -c 1 ::1

Зачем 16 миллионов адресов на loopback? Историческая щедрость стандарта. Реально используется только 127.0.0.1. Иногда крупные сервисы биндят разные модули на разные loopback-адреса (127.0.0.1 для одного процесса, 127.0.0.2 для другого — чтобы они не мешали друг другу на одном порту).

Loopback используется для:

• Локальные сервисы. БД, кэш, message broker, локальные API. psql -h localhost подключается к 127.0.0.1:5432.
• Health checks. curl localhost:8080/health без интернета и DNS.
• Тестирование. Запустили тестовый сервер на 127.0.0.1:PORT, гоните по нему интеграционные тесты.
• IPC. Если процессы на одной машине говорят по TCP — loopback быстрее любого ethernet’а (нет железа).

Link-local — 169.254.0.0/16 (APIPA / IPv4LL)

Этот диапазон называется link-local. Когда хост не смог получить IP по DHCP — он сам присваивает себе адрес из 169.254.X.X. Это сделано для того, чтобы устройства могли хотя бы общаться внутри одной L2-сети, даже без DHCP-сервера.

Алгоритм (RFC 3927, IPv4 Link-Local):

1. DHCP-запрос failed (5-30 секунд таймаут).
2. Хост выбирает случайный IP из 169.254.0.0/16 (кроме .0, .255, 169.254.0.0/16 reserved).
3. Шлёт ARP probe: «у кого этот IP?»
4. Если никто не ответил — занимает его.
5. Если кто-то ответил — выбирает другой случайный.

Что бывает с этим IP:

• Можно общаться только внутри сегмента. Никакого роутинга.
• Никакого интернета.
• Если потом DHCP заработает — хост перейдёт на DHCP-адрес и сбросит link-local.

Когда видите 169.254.X.X в конфиге — что-то не так с DHCP. Скорее всего сервер не отвечает, или вы вообще не подключены к сети.

# Симптом:
ip addr show
# inet 169.254.X.X/16 scope link

# Это значит: DHCP не сработал, я сам себе назначил адрес для общения в сегменте

Особый случай — метаданные облаков. AWS, GCP, Azure все используют адрес 169.254.169.254 для metadata service:

# В AWS EC2-инстансе:
curl http://169.254.169.254/latest/meta-data/instance-id
# i-0abc1234def567890

# Вернёт информацию о текущей виртуалке -- её IAM роль, регион, AMI-id и т.д.
# IMPORTANT: на новых инстансах нужна авторизация (IMDSv2 token).

Этот адрес работает только внутри виртуалки. Снаружи он недоступен. Чрезвычайно полезен для скриптов, которые должны узнать «а где я работаю?».

Broadcast — 255.255.255.255 и внутри подсети

В IPv4 есть два вида broadcast:

1. Limited broadcast — 255.255.255.255. Кадр уходит на MAC-broadcast ff:ff:ff:ff:ff:ff. Доходит до всех в текущем L2-сегменте. Не проходит через роутер.

2. Directed broadcast — адрес X.X.X.255 (для /24) или Y.Y.255.255 (для /16). Это broadcast подсети. Например 192.168.1.255 — все хосты в 192.168.1.0/24. Раньше шёл через роутеры (smurf attack использовала это), сейчас обычно дропается.

Broadcast используется:

• DHCP DISCOVER. Клиент без IP шлёт broadcast (255.255.255.255), все DHCP-серверы в сегменте получают.
• ARP requests. Шлются на MAC-broadcast (но IP-уровня broadcast тут нет, см. урок про ARP).
• WoL (Wake-on-LAN). Magic packet шлётся broadcast’ом, спящая машина просыпается.
• NetBIOS / SMB discovery. Старый Windows-протокол.

Хосты могут принимать или дропать broadcast. По умолчанию принимают. Если на интерфейсе много шума — может быть проблема.

Multicast — 224.0.0.0/4

Multicast — адреса для «один отправитель — много получателей», но в отличие от broadcast, получатели явно подписываются. Диапазон: 224.0.0.0 - 239.255.255.255.

Несколько важных multicast-адресов:

Multicast активно используется в:

• Локальная discovery (mDNS на 224.0.0.251 для AirPlay, Chromecast, sharing).
• IGMP (как маршрутизаторы знают, кто подписан на какую группу).
• Маршрутизация (OSPF протокол обновлений идёт по multicast).
• Stock market data (биржи раздают котировки multicast’ом подписчикам — эффективно).
• VRRP / HSRP (active-passive HA для роутеров).

В большинстве end-user задач multicast не виден. Но если запустить tcpdump, вы увидите немало multicast’а.

# Захватить multicast-трафик:
sudo tcpdump -i any -n 'ip multicast'

# Что увидите:
# - mDNS-запросы от ваших устройств (поиск принтеров, AppleTV)
# - LLDP (если есть managed switches)
# - SSDP (UPnP discovery)

Зарезервированные диапазоны (must-know)

Кратко — что ещё «занято» в IPv4 и не годится для обычного использования:

Особенно полезно знать 100.64.0.0/10 — это CGNAT. Если видите такой IP в логах своего домашнего интернета — значит провайдер ставит вас за CGNAT (часто у мобильных операторов и кабельных провайдеров).

Также полезно знать 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — это TEST-NET, они гарантированно не используются в продакшене. В документации и примерах — используйте их, а не реальные. Например, в книгах часто 203.0.113.5 как «пример удалённого сервера».

Узнать тип адреса в Python

import ipaddress

def describe(addr):
    ip = ipaddress.ip_address(addr)
    print(f'{addr}:')
    print(f'  is_private: {ip.is_private}')
    print(f'  is_loopback: {ip.is_loopback}')
    print(f'  is_link_local: {ip.is_link_local}')
    print(f'  is_multicast: {ip.is_multicast}')
    print(f'  is_global: {ip.is_global}')

describe('192.168.1.5')
# is_private: True, is_global: False
describe('127.0.0.1')
# is_loopback: True, is_private: True
describe('169.254.5.5')
# is_link_local: True, is_private: True
describe('8.8.8.8')
# is_global: True, is_private: False
describe('100.64.5.5')
# is_private: True (хотя на CGNAT он не маршрутизируется глобально)
describe('239.255.0.1')
# is_multicast: True, is_private: True

Это полезно при валидации входных данных. Например, в Allowlist-проверке отказываем приватным IP («только публичные допускаются») или наоборот.

Попробуй сам

# 1. Посмотреть свои адреса и определить их тип:
ip addr show
# inet 127.0.0.1/8 -- loopback
# inet 192.168.1.42/24 -- приватный (в локалке)
# inet6 fe80::... -- IPv6 link-local

# 2. Узнать публичный IP:
curl ifconfig.me

# 3. Проверить, что приватный IP не маршрутизируется:
# Это вернёт No route to host (после нескольких секунд):
ping -c 1 -W 2 10.123.45.67  # случайный 10/8 -- скорее всего не в вашей сети
# Тут больше зависит от вашего конкретного окружения

# 4. Запустить локальный сервис на разных IP:
python3 -m http.server 8000 --bind 127.0.0.1
# Откроете в браузере http://127.0.0.1:8000 -- работает
# С другой машины в локалке -- НЕ работает (bind только на loopback)

# vs:
python3 -m http.server 8000 --bind 0.0.0.0
# Теперь доступен с любого интерфейса -- из локалки тоже

# 5. Тест IMDS (если на AWS EC2):
curl http://169.254.169.254/latest/meta-data/

# 6. Посмотреть на multicast-трафик в локалке:
sudo tcpdump -i any -n 'ip multicast' -c 10
# Увидите mDNS-запросы (224.0.0.251) от смартфонов, ChromeCast и т.д.

# 7. Найти приватные хосты в локалке (ARP scan):
sudo arp-scan -l  # Linux
# Покажет всех соседей в локалке с их MAC и IP