IP-адреса, подсети и CIDR: разбираем с нуля

Когда вы создаёте виртуальную сеть в облаке или готовите кластер Kubernetes, интерфейс просит ввести CIDR подсети. Ошибка на этом шаге дорогая: диапазон задаётся один раз и потом обычно не меняется. Ниже разберём, как устроен IPv4-адрес, что такое маска подсети, как читать запись /24 и как посчитать разбиение сети руками. Статические и динамические IP-адреса — в нашей статье.

IPv4-адрес — 32-битное число. Для удобства его записывают четырьмя десятичными октетами через точку: 192.168.1.100. Каждый октет занимает 8 бит и принимает значения от 0 до 255 (RFC 791).

Та же запись в двоичном виде:

192.168.1.100 → 11000000.10101000.00000001.01100100

Всего комбинаций 2^32, то есть примерно 4,3 млрд адресов: от 0.0.0.0 до 255.255.255.255. Часть из них зарезервирована под служебные задачи, поэтому реально доступных для публичной адресации заметно меньше.

Логически адрес делится на две части:

• сетевая часть (network) — общая для всех узлов одной подсети;
• хостовая часть (host) — уникальный номер узла внутри этой подсети.

Граница между ними не зашита в сам адрес. Её задаёт маска подсети или, что то же самое, длина префикса в CIDR-нотации.

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

До середины 1990-х граница сеть/хост определялась классом адреса, то есть значением первого октета. Классовая схема ушла вместе с введением CIDR, но понимать её полезно: в документации и настройках оборудования до сих пор встречаются отсылки к «сети класса C».

Главная проблема классовой схемы: между /16 и /24 ничего нет. Компании, которой нужно 500 адресов, приходилось выдавать сеть класса B на 65 тысяч. CIDR снял это ограничение, разрешив любую длину префикса.

Маска подсети — 32-битное число, в котором единицы отмечают биты сетевой части, а нули — биты хостовой. Записывают её либо в десятичном виде (255.255.255.0), либо префиксом CIDR (/24). Это две формы одной и той же величины.

Посмотрим на примере, как маска режет адрес:

IP:    192.168.1.100  →  11000000.10101000.00000001.01100100
Маска: 255.255.255.0  →  11111111.11111111.11111111.00000000
Сеть:  192.168.1.0    →  11000000.10101000.00000001.00000000

Первые 24 бита маски — единицы, значит сетевая часть занимает три октета, а на хосты остаётся последний октет (8 бит). Все адреса от 192.168.1.0 до 192.168.1.255 принадлежат одной подсети.

Два адреса из этого диапазона хостам не назначаются:

• адрес сети (первый, 192.168.1.0) идентифицирует саму подсеть и используется в таблицах маршрутизации;
• широковещательный адрес (последний, 192.168.1.255) адресует одновременно все узлы подсети.

Остаются адреса с 192.168.1.1 по 192.168.1.254, то есть 254 узла. Отсюда общая формула расчёта подсети: для префикса длиной N всего адресов 2^(32-N), доступных хостам — 2^(32-N) − 2 (RFC 950). Исключения из формулы — префиксы /31 и /32, о них ниже.

CIDR (Classless Inter-Domain Routing) — бесклассовая схема адресации, принятая взамен классовой. Она задаёт границу сеть/хост произвольной длиной префикса, а не фиксированными классами A, B и C. Запись выглядит как адрес, слеш и число бит сетевой части: 192.168.1.0/24.

Число после слеша читается буквально — сколько первых бит адреса относятся к сети:

• /24 — 24 бита сети, 8 бит хостов: 256 адресов, 254 хоста;
• /16 — 16 бит сети, 16 бит хостов: 65 536 адресов;
• /32 — все 32 бита отданы сети, это один конкретный узел;
• /0 — нулевая сетевая часть, то есть любой адрес: такая запись используется как маршрут по умолчанию (default route).

Чем длиннее префикс, тем меньше подсеть. Несколько примеров диапазонов:

10.0.0.0/8       — от 10.0.0.0 до 10.255.255.255
172.16.0.0/12    — от 172.16.0.0 до 172.31.255.255
192.168.1.0/24   — от 192.168.1.0 до 192.168.1.255
192.168.1.128/25 — половина /24: от .128 до .255, 126 хостов

Полезное свойство CIDR — агрегация: соседние подсети одинакового размера объединяются в одну запись маршрута с более коротким префиксом. Две сети /25 складываются в /24, четыре /26 тоже дают /24.

Справочная таблица для быстрого расчёта подсети: префикс, десятичная маска, число адресов и число доступных хостов. Значения хостов посчитаны по формуле 2^(32-N) − 2.

* /31 — особый случай. На линках точка-точка оба адреса пары назначаются интерфейсам, адрес сети и широковещательный адрес не выделяются (RFC 3021). Так экономятся два адреса на каждом линке, где раньше расходовался /30.

Часть адресного пространства зарезервирована и в публичном интернете не маршрутизируется. Три приватных диапазона определены RFC 1918:

Из этих диапазонов нарезают сети домашних роутеров, офисные сегменты и виртуальные сети в облаках. Выход в интернет такие адреса получают через NAT.

Есть ещё несколько диапазонов, которые стоит узнавать в лицо:

• 127.0.0.0/8 — loopback. Адрес 127.0.0.1 указывает на сам узел, интерфейсам в сети он не назначается (RFC 1122).
• 169.254.0.0/16 — link-local. Узел назначает себе такой адрес сам, когда не получил ответа от DHCP (RFC 3927). Если на виртуальной машине внезапно появился адрес из этого диапазона, ищите проблему с DHCP.
• 100.64.0.0/10 — Shared Address Space для операторских сетей с Carrier-Grade NAT. Диапазон выделен отдельно, чтобы адресация провайдера не пересекалась с приватными сетями клиентов (RFC 6598).

Практический вывод: планируя адресацию в облаке, сверяйтесь со списком занятых диапазонов на своей стороне. Пересечение CIDR двух сетей, которые потом свяжут VPN-туннелем, маршрутизацией не лечится: трафик просто не уйдёт в туннель.

Задача. Есть сеть 192.168.10.0/24. Нужно разделить её на четыре подсети, в каждой примерно по 60 узлов.

1. Считаем биты под хосты. 60 узлов плюс адрес сети и широковещательный адрес — минимум 62 адреса. Ближайшая степень двойки: 2^6 = 64. Значит, под хостовую часть нужно 6 бит, под сетевую остаётся 32 − 6 = 26. Префикс подсети — /26, доступных хостов в ней 64 − 2 = 62.
2. Проверяем, помещаются ли подсети в исходную сеть. В /24 ровно 256 адресов, в /26 — 64. 256 / 64 = 4. Четыре подсети помещаются без остатка.
3. Находим границы. Шаг между подсетями равен размеру блока, то есть 64 адресам в последнем октете:

Та же логика работает для любого шага: нужно 30 хостов — берите /27 с блоком в 32 адреса, нужно 14 — /28 с блоком в 16.

Запас при планировании облачной сети. Виртуальная сеть и подсеть в облаке получают CIDR при создании, и поменять его потом, как правило, не получится: диапазон приходится пересоздавать вместе с ресурсом. Отсюда правило: считайте не текущее число машин, а потолок на горизонте жизни проекта. Для небольшого стенда хватит /24, для кластера Kubernetes, где адреса расходуют ещё и поды, закладывайте диапазон крупнее.

IPv6-адрес длиннее в четыре раза: 128 бит против 32. Записывают его восемью группами по четыре шестнадцатеричных символа через двоеточие, причём группы нулей сокращаются двойным двоеточием (RFC 4291):

2001:0db8:85a3:0000:0000:8a2e:0370:7334
2001:db8:85a3::8a2e:370:7334

Что важно знать тем, кто уже освоил CIDR в IPv4:

• нотация та же: адрес, слеш, длина префикса;
• стандартный размер подсети для оконечных сегментов — /64;
• аналог приватных адресов RFC 1918 — диапазон Unique Local Addresses fc00::/7 (RFC 4193);
• адреса сети и broadcast в привычном смысле в IPv6 отсутствуют, широковещательную рассылку заменяет multicast.

Арифметика хостов в IPv6 теряет смысл: в одном /64 помещается 2^64 адреса, поэтому подсети нарезают не по числу узлов, а по топологии.

В VK Cloud сетевой слой собирается в разделе «Сети». Там создаются виртуальные сети (VPC) и подсети, виртуальные машины объединяются в локальные сети. В том же разделе настраиваются балансировщик нагрузки, VPN по схеме site-to-site (IPsec IKEv1/v2 с аутентификацией по общему ключу), Public DNS и Private DNS, Firewall и Floating IP. CIDR вы указываете на этапе создания подсети, и дальше от этого выбора зависят остальные настройки: правила межсетевого экрана, маршруты и диапазоны, которые анонсируются в VPN-туннель.

Для Kubernetes планирование адресов строже. Managed Kubernetes от VK Cloud поддерживает два поколения кластеров, и у второго поколения есть сетевое предусловие: для проекта должна быть подключена SDN Sprut. Отличается и модель ответственности. Во втором поколении сервисный балансировщик нагрузки, через который идёт доступ к Kubernetes API, вместе со своим IP-адресом размещается в сервисном проекте платформы, а не в проекте пользователя.

Эта изоляция не абсолютна: группы безопасности, созданные для кластера, живут в пользовательском проекте, и правка их правил может привести кластер в неработоспособное состояние. Прежде чем менять правила «для теста», сверьтесь с документацией по сетевым требованиям кластера.

Чек-лист перед созданием сети в облаке:

1. Выпишите все диапазоны, с которыми новая сеть будет связана: офис, другие проекты, сети подрядчиков. Пересечений быть не должно.
2. Оцените потолок числа адресов, а не текущую потребность. Для кластера учитывайте адреса подов и сервисов, а не только узлов.
3. Заложите место под будущие подсети: делить /16 на /24 проще, чем переезжать с тесного диапазона.
4. Зафиксируйте схему адресации в документации проекта, включая назначение каждой подсети.

Для разовой проверки удобнее утилита в терминале, чем онлайн-форма. Классический вариант — ipcalc:

apt install ipcalc
ipcalc 192.168.10.64/26

# Вывод:
# Address:   192.168.10.64
# Netmask:   255.255.255.192 = 26
# Network:   192.168.10.64/26
# HostMin:   192.168.10.65
# HostMax:   192.168.10.126
# Broadcast: 192.168.10.127
# Hosts/Net: 62

Утилита сразу показывает адрес сети, первый и последний адреса для узлов, широковещательный адрес и число доступных хостов. Для IPv6 и более подробного разбора подойдёт sipcalc. Из онлайн-инструментов выручают subnet-calculator.com и cidr.xyz, где диапазон наглядно подсвечивается по битам.