Перейти к содержанию
Каталог товаров
0

Маска подсети сервера: как сверить адрес, префикс и шлюз

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

Опубликовано: 29 октября 2026
Маска подсети сервера: как сверить адрес, префикс и шлюз
Автор: Сергей Коваль Технический рецензент: Михаил Биркос Редакционная политика блога
Читать полный материал

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

Сетевые картыЗапросить подбор

Как читать запись с косой чертой

В записи CIDR число после косой черты — длина префикса в битах. Для IPv4 префикс /24 соответствует маске 255.255.255.0. Это описание границ сети, а не скорости подключения и не номера VLAN.

Пример для разбора, а не готовая конфигурация: у адреса 192.168.10.20/24 сетевой префикс — 192.168.10.0/24. Адрес 192.168.10.30 относится к нему, а 192.168.11.30 — уже нет. Расчёт относится к показанной маске; при её изменении изменится и результат.

Зачем одновременно знать адрес, маску и шлюз

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

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

Как возникает ошибка

Предположим, в проекте указан /24, но на сервере настроили /16. Теперь сервер может считать некоторые удалённые адреса локальными и пытаться найти их на канальном уровне вместо отправки по предусмотренному пути. Замена коммутатора не исправляет эту логическую ошибку сама по себе.

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

Что проверить до изменения настроек

Сверьте адрес и префикс каждого используемого интерфейса, маршруты к нужной сети, шлюз и назначение сетевого сегмента. Отдельно проверьте отсутствие дублирующего адреса. Не меняйте параметры единственного удалённого подключения без предусмотренного пути возврата.

Если используются VLAN, сопоставьте адресную сеть с проектом VLAN и портами. Механизм тегирования разобран в статье о tagged и untagged портах. Одинаковая маска не доказывает, что два сервера находятся в одном VLAN или могут обмениваться пакетами.

Когда дополнительное оборудование не требуется

Если причина в префиксе или маршруте, сначала исправляют план и настройки по согласованной процедуре. Покупка второй сетевой карты не является универсальным лечением. Сетевые карты выбирают под конкретный интерфейс и требования к подключению, а не под одну запись CIDR. Эта памятка помогает собрать исходные данные; она не заменяет проект сети с политиками доступа и резервированием.

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

Сколько адресов содержит /24?

Всего 256 IPv4-адресов. В обычной подсети часть адресов имеет специальное назначение; количество адресов для узлов нужно считать по конкретной схеме.

У /31 всегда нет usable-адресов?

Нет. RFC 3021 описывает применение /31 на соединениях point-to-point. Общее правило вычитания двух адресов к этому случаю неприменимо.

Маска и VLAN — одно и то же?

Нет. Маска описывает IP-префикс, а VLAN относится к сегментации канального уровня. Их настройки должны соответствовать проекту, но одна не заменяет другую.

Источники

Материал подготовлен при участии ИИ по официальной документации. Собственные испытания не заявлены. Факты сверены 29 октября 2026 года.

Автор

Сергей Коваль, коммерческий директор

Технический рецензент

Михаил Биркос, главный технический специалист

Также вас может заинтересовать