Я работаю в компании, которая использует 3 подсети: 10.0.0.0/16, 10.1.0.0/16 и 10.2.0.0/16. 3 подсети соединены с помощью коммутаторов уровня 3 (10.0.100.200, 10.1.100.200, 10.2.100.200), все машины в каждой подсети используют коммутатор уровня 3 в качестве шлюза по умолчанию, который затем направляет трафик на реальный шлюз, который в настоящее время 10.1.0.2
Я недавно настроил новый шлюз на 10.0.0.1 и начал тестировать этот новый шлюз, для моих клиентских машин в подсети 10.0.0.0/16 это не проблема, я просто изменил шлюз по умолчанию, назначенный этим машинам через DHCP. на новый адрес, и трафик прошел через новый шлюз, а не на коммутатор уровня 3.
Я хочу протестировать это и на другом сайте, так как у нас есть разные команды в каждом здании, которым нужен доступ к разным веб-сайтам, и я хочу убедиться, прежде чем мы переключим все, что каждая команда может получить доступ к тому, что им нужно для работы.
Итак, на рабочей станции Windows в сети 10.2.0.0/16 я попытался установить шлюз машины по умолчанию на 10.0.0.1, я проверил, куда идет трафик, и он все еще идет через старый шлюз (используя tracert для 8.8.8.8 он попадает туда, но через старый шлюз, используя tracert 10.0.0.1, он достигает 10.0.0.1). Я считаю, что настройка шлюза по умолчанию отменяется статической таблицей маршрутов на коммутаторах уровня 3.
Я пытаюсь выяснить, можно ли установить статический маршрут на рассматриваемых машинах, чтобы они могли направлять свой трафик шлюза на 10.0.0.1 и избегать его переопределения переключателями уровня 3.
Я использовал:
route add 0.0.0.0 mask 0.0.0.0 10.0.0.1 if 0x2
Это было принято Windows, но, повторяя мои тесты tracert, трафик все еще идет через старый шлюз. Я надеялся, что смогу:
route add 0.0.0.0 mask 0.0.0.0 10.0.0.1 if 0x2
route add 10.0.0.1 mask 0.0.0.0 10.0.100.200 if 0x2
route add 10.0.100.200 mask 0.0.0.0 10.2.100.200 if 0x2
Но это также не удалось, запустив вторую и третью команды, которые Windows сообщила:
The route addition failed: The specified mask parameter is invalid. (Destination & Mask) != Destination.
Итак, я знаю, что команды, которые я выполняю, не будут работать, но можно ли заставить Windows направлять свой трафик через переключатели уровня 3 на мой новый шлюз, или я веду бесплодный поиск?
Если мне нужно изменить статические маршруты на коммутаторах уровня 3, я не возражаю сделать это, у меня в любом случае запланировано окно обслуживания на воскресенье, поэтому я могу немного повозиться. Я бы предпочел не делать этого в рабочее время по понятным причинам.
Чтобы прояснить связи между сайтами, каждый переключатель уровня 3 имеет следующие соединения:
gateway , fibre link 1, fibre link 2
10.0.100.200, , 192.168.10.1
10.1.100.200, 192.168.20.1, 192.168.10.2
10.2.100.200, 192.168.20.2,
Итак, чтобы мой трафик достиг 10.0.0.1 с 10.2.249.28 (моя тестовая машина), он должен пройти через 10.2.100.200> 192.168.20.1> 192.168.10.1> 10.0.0.1
Речь идет о коммутаторах уровня 3 Netgear FSM7326P и GSM7328FS.
Если, как я начинаю подозревать, я не могу этого сделать, задав статические маршруты в Windows, можно ли определить статический маршрут для отдельных IP-адресов на коммутаторах уровня 3? Поскольку я в настоящее время тестирую, мне нужен трафик только с 3 или 4 машин, которые я настрою для тестирования, чтобы он проходил через новый шлюз, я хочу, чтобы весь другой трафик продолжал течь, как и раньше.
Шлюз по умолчанию в системе определяет, какой адрес в ее локальном широковещательном домене отправлять данные для адресов, находящихся за пределами напрямую подключенных подсетей. Поскольку 10.0.0.1 находится за пределами 10.2.0.0/16, хосту на 10.2.0.0 все еще нужно знать, на какой адрес в 10.2.0.0 отправлять пакеты, чтобы их пересылать. Как только пакет попадает на шлюз в пределах 10.2.0.0, этот шлюз решает, как его обработать.
В зависимости от вашего сетевого оборудования могут быть возможны творческие статические маршруты на основе списков контроля доступа.
На мой взгляд, лучше всего было бы подключить новый маршрутизатор / шлюз (10.0.0.1) к другим подсетям. В зависимости от используемого оборудования вы можете сделать это с помощью дополнительных физических каналов или взаимно совместимого транкингового протокола. Подключив новый шлюз ко всем трем подсетям, вы сможете вручную подключить другие компьютеры для тестирования.
Тем не менее, я не понимаю, что именно вы тестируете, для чего все три из этих / 16 должны иметь возможность выбирать несколько шлюзов. Если вы просто хотите убедиться, что это работает, ваш первоначальный тест подсети, кажется, подтверждает это.
Поскольку вы используете Windows, это проблематично. Под Linux или FreeBSD это не проблема.
В Windows Server 2012 R2 и Windows 8.1 есть командлеты powershell для включения прямого доступа за пределами подсети, Get-NetOffloadGlobalSetting показывает текущее состояние, а Set-NetOffloadGlobalSetting -NetworkDirectAcrossIPSubnets позволяет настроить значение.
Хотя PowerShell понимает синтаксис «NetworkDirectAcrossIPSubnets» в клиентских операционных системах, эта функция доступна только для серверов, ее установка в клиентской ОС приведет к ошибке.
Если у вас есть сервер с виртуальными машинами Windows, которым требуется доступ к шлюзу за пределами их собственной подсети, и вы не можете использовать NetworkDirectAcrossIPSubnets - вы можете установить другую виртуальную машину с маршрутизатором, работающим под unix-подобной ОС, например pfSense - он может иметь несколько адресов вне подсети, при условии, что хотя бы один адрес находится в той же подсети, что и шлюз, и он может выполнять NAT 1: 1 для ваших виртуальных машин Windows.