Маска подсети CIDR: что такое /24, /16 и как считать

CIDR (Classless Inter-Domain Routing) — способ записи IP-адреса вместе с маской подсети: 192.168.1.0/24. Число после косой черты — количество битов, отведённых под сеть.

Как работает CIDR

При /24: 24 бита — сеть, 8 бит — хосты. 2^8 = 256 адресов, из которых 254 доступны для хостов (первый — адрес сети, последний — широковещательный).

192.168.1.0   /24
|------------|------|
   Сеть(24)   Хост(8)

Таблица популярных CIDR

Формула расчёта

# Количество хостов: 2^(32-prefix) - 2
# Для /24: 2^(32-24) - 2 = 2^8 - 2 = 254
# Для /20: 2^(32-20) - 2 = 2^12 - 2 = 4094

Практические примеры

# UFW — разрешить целую подсеть
sudo ufw allow from 10.0.0.0/8

# iptables — блокировать диапазон
iptables -A INPUT -s 192.168.100.0/24 -j DROP

# Nginx — ограничить доступ по IP
location /admin {
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;
}

CIDR в WireGuard и OpenVPN

# WireGuard — AllowedIPs = маршрутизируемые диапазоны
[Peer]
AllowedIPs = 10.0.0.0/8, 172.16.0.0/12

# Весь трафик через VPN
AllowedIPs = 0.0.0.0/0, ::/0

Типичные ошибки при расчёте CIDR

Ошибка "network address not aligned" при настройке маршрута или VLAN — означает, что указанный адрес сети не кратен размеру блока. Для /26 (блок 64 адреса) сеть должна начинаться на 0, 64, 128 или 192 в последнем октете, а не на произвольном числе.

# Неверно: 192.168.1.100/26 — не начало блока
# Верно:   192.168.1.128/26 — начало блока (128, 128+64=192)

ip addr add 192.168.1.100/26 dev eth0
RTNETLINK answers: File exists

Ошибка RTNETLINK answers: File exists в этом контексте обычно означает конфликт с уже существующим маршрутом сети, а не проблему самого CIDR — но первопричина часто именно в неверно посчитанной границе подсети.

UFW отклоняет правило с сообщением "ERROR: Bad source address" — типичная причина: указана маска CIDR без адреса сети (например, /24 без IP) или использован десятичный формат маски вместо префикса.

sudo ufw allow from 10.0.0.0/255.0.0.0 to any port 22
ERROR: Bad source address

UFW принимает только префиксную нотацию: правильная запись — 10.0.0.0/8, а не десятичная маска через слэш.

CIDR и классовая адресация: в чём разница

Когда ручной расчёт CIDR не нужен

• Разовая настройка одного сервера — проще ввести IP в онлайн-калькулятор, чем держать в голове степени двойки.
• Автоматизация через Terraform, Ansible или облачную панель — эти инструменты сами проверяют пересечения подсетей и валидность масок.
• Сеть уже спроектирована провайдером (например, VPC у облачного хостинга) — менять её вручную обычно нельзя и не нужно.
• Нужно быстро проверить, пересекаются ли две подсети — калькулятор покажет диапазоны наглядно, тогда как ручное сравнение битовых масок легко приводит к ошибке в уме.
• Планируется VLSM (маски переменной длины) для нескольких отделов сразу — ручной подбор границ без инструмента почти гарантированно оставит незамеченные пересечения между соседними блоками адресов.

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

1. Посчитайте диапазон для своей подсети и сверьте с калькулятором (cidr.xyz или ipcalc): адрес сети, широковещательный адрес и число хостов должны совпасть.
2. Примените маску на интерфейсе: ip addr add 192.168.1.128/26 dev eth0 — команда не должна вернуть ошибку.
3. Проверьте фактическую маску: ip addr show eth0 — в выводе должен быть указан тот же префикс.
4. Для правил firewall проверьте, что нужный хост попадает в диапазон: ipcalc 192.168.1.130/26 покажет границы сети и подтвердит, что адрес внутри блока.

Расчёт CIDR напрямую связан с адресацией IPv4 — подробнее в статье про структуру IPv4-адресов, а для настройки самих маршрутов — статья про ip route и Netplan.

Частые вопросы

Чем меньше число после слэша в записи CIDR, тем сеть больше или меньше?

Чем меньше число после слэша, тем больше сеть и тем больше адресов она содержит, потому что это число означает количество бит, отведённых именно под адрес сети, а не под хосты. Оставшиеся биты достаются хостам, и чем их больше, тем просторнее диапазон доступных адресов внутри подсети — зависимость здесь обратная, а не прямая.

Что случится, если две подсети с пересекающимися диапазонами окажутся в одной сети маршрутизации?

Пересекающиеся диапазоны двух подсетей в таблице маршрутизации одного устройства создают неоднозначность — система либо откажется добавить конфликтующий маршрут с явной ошибкой, либо применит более специфичный из двух по длине префикса, проигнорировав широкий диапазон для пересекающейся части. Результат зависит от конкретной реализации стека и порядка добавления маршрутов, поэтому пересечения стоит исключать заранее расчётом, а не выяснять постфактум.

Работает ли CIDR-нотация только для IPv4, или для IPv6 тоже?

Сама концепция записи адреса вместе с длиной префикса через слэш общая для обоих протоколов, но IPv6 использует собственную, гораздо более длинную адресацию и свои типичные размеры блоков, непригодные для прямого переноса таблиц и примеров из мира IPv4. Формула подсчёта хостов для IPv4 для IPv6 напрямую не подходит из-за иной разрядности адреса.

Можно ли использовать в приватной сети любой CIDR-блок на выбор, или некоторые диапазоны адресов зарезервированы?

Нет, часть диапазонов адресов зарезервирована отдельными стандартами под конкретные цели вроде приватных сетей, loopback-интерфейса или многоадресной рассылки, и использовать их для других задач не стоит, даже если формально ничто не мешает прописать такой диапазон. Для приватной сети лучше выбирать блок именно из диапазонов, выделенных под внутреннее использование, а не произвольный публичный адрес.