IPv4 (Internet Protocol version 4) — четвёртая версия протокола IP, на которой до сих пор работает большая часть интернета. IPv4-адрес — это 32-битное число, обычно записываемое в виде четырёх десятичных чисел через точку: 192.168.1.1.

Структура IPv4-адреса

192  .  168  .  1  .  1
 ^       ^      ^    ^
 |       |      |    Хост (номер устройства)
 |       |      Подсеть
 |       Сеть
 Класс сети

Каждое число — это один байт (0–255). Итого: 4 байта × 8 бит = 32 бита = ~4.3 млрд возможных адресов.

Маски подсети и CIDR-нотация

CIDR	Маска	Хостов	Пример
/8	255.0.0.0	16 777 214	10.0.0.0/8
/16	255.255.0.0	65 534	172.16.0.0/16
/24	255.255.255.0	254	192.168.1.0/24
/28	255.255.255.240	14	192.168.1.16/28
/30	255.255.255.252	2	10.0.0.0/30 (P2P)
/32	255.255.255.255	1	Один хост

Приватные (RFC 1918) диапазоны

Эти адреса не маршрутизируются в интернете — только в локальных сетях:

Диапазон	CIDR	Назначение
10.0.0.0 – 10.255.255.255	/8	Корпоративные сети
172.16.0.0 – 172.31.255.255	/12	Средние организации
192.168.0.0 – 192.168.255.255	/16	Домашние сети, офисы
127.0.0.0 – 127.255.255.255	/8	Loopback (127.0.0.1)

Проверка своего IPv4-адреса

# На Linux — внешний IP
curl ifconfig.me

# Локальный IP интерфейсов
ip addr show
# или
ifconfig

Почему заканчиваются IPv4-адреса

32 бита = 4 294 967 296 адресов. Из них ~600 миллионов зарезервированы (приватные, мультикаст, loopback). IANA исчерпала пул свободных /8 блоков ещё в 2011 году. Региональные реестры (RIPE, ARIN) заканчивают запасы с 2019–2023 годов.

💡 Для VPS: Публичный IPv4 — дефицитный ресурс, который уже стоит денег (~$1–5/мес за дополнительный IP). Именно поэтому провайдеры переходят на IPv6 и используют NAT для VPS.

⚠️ NAT и проблемы: Многие хостинги выдают VPS с адресом за NAT — у вас «публичный» IP, но он shared. Это ограничивает возможности: почтовый сервер, VPN, некоторые API не работают за NAT. Уточняйте у провайдера тип IP.

Разбор типичных ошибок адресации

Сервер получил IP, но недоступен извне, хотя интерфейс "up" — частая причина: адрес назначен в чужой подсети, не совпадающей с сетью шлюза, и пакеты не могут выйти дальше локального сегмента.

ip addr show eth0
    inet 192.168.1.50/24

ip route show
default via 10.0.0.1 dev eth0

# Шлюз 10.0.0.1 не входит в сеть 192.168.1.0/24 — маршрут нерабочий

IP-адрес интерфейса и адрес шлюза по умолчанию обязаны находиться в одной подсети (с учётом маски). Если провайдер выдал 192.168.1.50/24, шлюз должен быть вида 192.168.1.1, а не из другой сети.

Два сервера с одинаковым IP конфликтуют в локальной сети — в логах это видно как постоянные обрывы соединения и сообщения ARP о дублировании.

dmesg | grep -i duplicate
IPv4: 192.168.1.50 is already in use! (kernel arp)

Такое случается при ручном назначении статических IP без учёта DHCP-пула или при клонировании VPS без смены сетевых настроек. Проверьте диапазон DHCP на роутере и убедитесь, что статические адреса вынесены за его пределы.

Классы адресов: историческая справка

Класс	Диапазон первого октета	Маска по умолчанию	Актуальность сегодня
A	1–126	/8	Не используется, вытеснена CIDR
B	128–191	/16	Не используется, вытеснена CIDR
C	192–223	/24	Не используется, вытеснена CIDR
D (мультикаст)	224–239	—	Используется для мультикаст-групп

Когда IPv4 уже недостаточно

Проект требует много публичных адресов одновременно (например, тысячи виртуальных хостов с отдельным IP) — аренда стольких IPv4 дорога и часто физически ограничена у провайдера.
Нужна поддержка растущего числа IoT-устройств с прямой адресацией — IPv4 с NAT усложняет такие сценарии, IPv6 снимает это ограничение за счёт огромного адресного пространства.
Партнёр или регулятор требует IPv6-совместимость (например, некоторые госзаказы и мобильные сети уже IPv6-first) — тогда IPv4 нужен параллельно, а не вместо.
Хостинг ограничивает число дополнительных IPv4 на аккаунт — если проекту нужно больше публичных адресов, чем разрешает лимит провайдера, это уже архитектурное ограничение, а не техническая настройка.

Проверка результата

Проверьте назначенный адрес: ip addr show должен показать нужный IP с корректной маской на нужном интерфейсе.
Проверьте маршрут по умолчанию: ip route show default должен указывать на шлюз внутри той же подсети.
Проверьте связность: ping -c 3 8.8.8.8 должен получить ответы без потерь пакетов.
Проверьте DNS-резолвинг с этого адреса: curl -4 ifconfig.me должен вернуть именно тот публичный IP, который ожидается.

Расчёт масок и диапазонов подробно разобран в статье про CIDR, а механизм скрытия приватных адресов за одним публичным — в статье про NAT.