Мы пытаемся направить весь трафик с определенного компьютера на шлюз. Это нормально работает для трафика, предназначенного для подсетей за пределами подсети машины. Однако трафик к машинам в той же подсети, что и исходная машина, проходит через шлюз On-Link в Windows. Это означает, что шлюз по умолчанию игнорируется, и трафик в подсети (например, 192.168.50.10 -> 192.168.50.11) течет.
Destination Netmask Gateway Interface Metric
192.168.50.0 255.255.255.0 On-link 192.168.50.214 276
Единственный способ заставить его работать - это добавить постоянный маршрут к шлюзу для трафика подсети и удалить маршрут по ссылке при перезагрузке.
Тогда вопрос.
Что ж, ваш хост, вероятно, получает свой маршрут по умолчанию от DHCP-сервера. Если это так, установите резервирование DHCP. Я предполагаю, что вы могли бы установить маску подсети для этого резервирования хостов на 255.255.255.255, что технически помешало бы хосту доставлять пакеты напрямую на другие хосты в подсети. Весь трафик будет проходить через шлюз по умолчанию. Хакеры по-прежнему должны следовать правилам сети, и это нарушит множество правил, если ваша сеть не будет сегментирована должным образом. Обычно недостаточно просто притвориться, что маска подсети равна / 32 в сегменте / 24, и надеяться, что пользователь ее не изменит. На самом деле это не безопасно.
Представьте себе центр обработки данных, в котором размещены тысячи серверов. Администраторы не просто верят, что все правильно настроили свои IP-адреса и маски подсети, не вызывая конфликта и т. Д. Каждый раз, когда хосты находятся в одном сегменте сети, они могут общаться друг с другом. Проблема в этом случае, по-видимому, заключается в том, чтобы заставить хост перейти в правильный сегмент сети, одинокий сегмент, лишенный каких-либо других узлов, кроме порта на вашем коммутаторе.
Лучшее решение - управляемый коммутатор, вероятно, уровня 3. Как Cisco 3550. Коммутатор будет вести себя как маршрутизатор, маршрутизируя трафик между всеми своими локальными подсетями. Как было рекомендовано ранее, используйте ACL для предотвращения межсетевого взаимодействия. Но вы упомянули, что vlan - это не вариант, поэтому вы, вероятно, не управляете переключателем.
Более творчески:
Создайте реальный или виртуальный сегмент сети, например 10.x.y.z / 30, только с одним шлюзом и без маршрута по умолчанию, предлагаемого dhcp. Блок / 30 cidr требует хорошего понимания сетевых подсетей. разрешите хостам в подсети, которой вы управляете, туннелировать к вашему шлюзу vpn, пройти аутентификацию и только затем получить шлюз по умолчанию. OpenVpn, по крайней мере, позволяет ограничить связь хоста с хостом, поскольку весь трафик, конечно же, маршрутизируется через сервер vpn. Это аналогично использованию Wi-Fi в общедоступной точке доступа, где они блокируют трафик между беспроводными узлами.
Или вы можете использовать прозрачный прокси, опять же с правилами acl, чтобы предотвратить обмен данными между хостами. Не уверен, что это соответствует вашим потребностям.
Таким образом, настоящая проблема заключается в том, чтобы предотвратить обмен данными между хостами в одной подсети. Дискретные подсети - это просто способ фильтрации пакетов arp. Возможно, это может сделать какой-нибудь arp hack.
Есть разница между принудительным прохождением трафика через шлюз и запретом устройствам видеть друг друга в подсети. Я думаю, что вы пытаетесь сделать последнее. Вероятно, потому что вы хотите разместить серверы для нескольких внешних клиентов. Вы смотрите не в том месте, если редактируете таблицу маршрутизации для достижения этой цели.
Я бы порекомендовал решить эту проблему на коммутаторе с помощью ACL. Что конкретно вы можете заблокировать / разрешить, будет зависеть от возможностей вашего коммутатора. Другой альтернативой является блокировка широковещательной передачи ARP, а затем установка статических записей ARP для шлюза по умолчанию (технически кто-то может добавить больше статических записей, чтобы общаться с другими устройствами).
Кроме того, имейте в виду, что если шлюз не настроен на блокировку трафика из этого сегмента, он с радостью направит трафик обратно в ту же сеть.
В конечном итоге мы не нашли способа сделать ни то, ни другое без сценария запуска. Удаление маршрута On-Link не сохранится, что бы мы ни делали, и мы не могли использовать какие-либо другие варианты (прозрачный прокси, VLAN и т. Д.) По причинам, указанным выше.
В итоге мы добавили сценарий запуска для запуска
ROUTE DELETE 192.168.50.0
на старте. Скрипт был помещен в каталог, доступный только нашему пользователю (не администратору), и запускался при запуске. Мы также добавили собственный сценарий Nagios, который запускал эту команду и проверял, не изменилась ли таблица маршрутизации после этого момента.