Проблемы Маршрутизации

[MetelicaSA]

Всем привет!

Проблема такова - есть необходимость добавить статические маршруты в координаторы сети. Делаю как по инструкции:

команда inet route add Х.X.X.X gw X.X.X.X netmask X.X.X.X

После чего выходит ошибка:

SIOADDRT: No such process

Command: inet route add X.X.X.X gw X.X.X.X Failed to add new static route.

<RT_ADD> Command: inet route add X.X.X.X gw X.X.X.X Failed to add new static route.

пробовал вручную добавлять маску сети командой netmask. Разницы нет - ошибка.

Причем пробовал на разных координаторах HW1000 Q2, HW100B X1, HW100C все одно - добавить маршрут не получается.

У кого есть идеи или сталкивался с такой ситуацией - прошу помощи!

[ПлотниковВН]

Возможно команду необходимо давать под администратором (enable - go to administrator mode).

No such process - нет процесса (или процесс недоступен). Проверьте права пользователя под которым выполняете данную команду.

[MetelicaSA]

Увы, как раз выполняю данную команду под администратором сетевого узла. Под пользователем команда inet route вообще недоступна. Пароли администратора и пользователя на узлах задаю сам лично.

[Rinya]

Опишите немного подробнее куда вы пишите маршруты. не обязательно указывать реальные адреса. Главное понимать откуда и куда маршрут.

[MetelicaSA]

Есть несколько сетей 192.168.1.0, 192.168.2.0, 192.168.3.0 и т.д. Главный сетевой узел (hw1000) находится в сети 192.168.1.0, остальные сети (hw100B) веделены под филиалы. Вот пытаюсь прописать маршруты на главном узле.

[MetelicaSA]

Да и вообще сейчас пробовал добавлять случайные сети 172.19.7.0, 85.93.40.0 вообщем все, что могло прийти в голову, результат - та же ошибка. Хотя, мое мнение, абсолютно не важно какой маршрут добавлять, как сказал Rinya: "понимать откуда и куда маршрут".

[Rinya]

какого вида маршрут вы пишите. вот к примеру у меня был случай. есть сеть 192.168.1.0 она находилась за циской, адрес интерфейса который смотрит в мою сеть 192.11.11.11 (к примеру). вот чтоб пакеты от компов стоящих за моим координатором проходили в эту сеть я писал статический маршрут типа inet route add 192.168.1.0 gw 192.11.11.11 netmask ***x

[Rinya]

в вашем случае, если я правильно понял, есть головной офис и филиалы. за координаторами стоят компы без клиентов. Вам необходимо чтоб клиенты допустим филиала могли общаться с клиентами в головном.

если я прав, то это схема туннеля.

[MetelicaSA]

Да сеть уже работает через систему туннелей. Все хорошо компьютеры в разных сетях видят друг друга... Думаю стоит начать сначала. История долгая получится... Установили мы в центральном офисе сервер на Windows Server 2008 R2. Подняли DHCP, DNS, AD. На марштрутизаторах Vipnet настроил DNS Forwarding на сервер по адресу 192.168.1.6. Все хорошо служба работает, компьютеры в удаленных филиалах пингуют сервер и компьютеры "центра" по имени, правда приходится все настройки (на компьютерах филлиалов) забивать самому.

Пример: Сервер в "центре" туннелируется по адресу 192.168.1.6 и сетью 192.168.1.0.

Филиал с сетью 192.168.18.0. Компьютер филиала имеет адрес 192.168.18.2, DNS 192.168.1.6 шлюз 192.168.18.10. Координатор филиала: 1 порт (внтуренний) адрес 192.168.18.10, 2 порт (внешний 192.168.0.2) (с динамической трансляцией адресов).

И тут я заметил новую фишку на координаторах - DHCP-relay. Все просто, настроил порт за которым DHCP-сервер (он ссылается на сервер 192.168.1.6) по внешнему адресу 192.168.0.2. Настроил порт прослушивания DHCP-запросов, за которым компьютеры филиала (внутренний порт 192.168.18.10). Но клиенты не получают адрес по DHCP (я даже резервирование по MAC-адресу включил). Для теста все фильтры на координаторах настроил на "Пропускать все по всем портам". Все равно адрес по DHCP не идет.

Вот тогда то я решил, в качестве бреда, прописать статические маршруты и налетел на ошибку.

[Rinya]

А в журналах на координаторах ничего не фиксируется? Может там есть блокированные пакеты.

[MetelicaSA]

В том то и дело, что ни в "центре", ни в филиале в журналах маршрутизаторов пусто по UDP 67-68. Я на всякий еще и все фильтры в маршрутизаторах (broadcast, nat и прочие) отключил на время тестирования... Сегодня возникла новая идея, опробую - отпишусь.

[MetelicaSA]

После нескольких недель танцов у меня получилось, но все по порядку....

Пишу строки ниже для таких как я, начинающих администраторов, а также для тех, кто продукт VipNet изучал и настраивал самостоятельно....

1) По прописыванию маршрутов. Хотя в официальной документации конкретных примеров прописывания маршрутов я не нашел (а с ОС Linux я мало знаком) пришлось доходить методом "тыка".

а) Прописать маршрут в другую сеть (в которую не смотрит ни один из интерфейсов координатора) можно, только параметр GW должен указывать на Ваш шлюз по-умолчанию. Тоесть шлюз, указанный командой inet route add default gw Х.Х.Х.Х

В этом и был мой прокол, я пытался указать виртуальный IP-адрес (выделяемый Vipnet) координатора одного из филиалов, в результате и получал ошибку (смотри выше).

б) Вывод: Координатор не примет маршрут взятый "с потолка", это в ОС windows можно добавить любой маршрут в таблицу. Маршрут должен соответствовать сети, в которую смотрит хотя бы один из физических или виртуальных IP-адресов, присвоенных портам коориднатора ИЛИ параметр GW должен указывать на Ваш шлюз по-умолчанию.

По поводу DHCP-Relay.....

Цитата из документа ПАК ViPNet Coordinator HW. Сценарии использования пункт организация работы клиентов с удаленным DHCP-сервером:

Внимание! Между филиалами и центральным офисом должны быть организованы выделенные каналы связи с прямой маршрутизацией.

Ну я сразу к своему провайдеру (Ростелеком). Говорю - нам вот так организовать надо, на что получил ответ: "А так это же VPN, 6000 руб\мес с каждого филиала". Подумал, круто, VPN в VPN`e и сумма "замечательная" получается с 18 филиалов.

В итоге сделал так:

1) В филиале включил dhcp-relay, который переправляет запросы клиентов на внешний статический IP-адрес центрального офиса в глобальной сети, в моем случае 85.93.Х.Х .

2) В центре на роутере сделал перенаправление пакетов UDP 67-68 на внешний порт главного координатора. На самом координаторе включил DHCP-relay и сделал перенаправление пакетов UDP 67-68 на DHCP-сервер соответственно.

3) В итоге получил блокирование пакетов UDP 67 от сервера клиенту, в моем случае от 192.168.1.6 к 192.168.18.0. На координаторе в журнале IP-пакетов выдается ошибка 104 - соединение уже существует. Решается эта проблема через трансляцию IP-адресов. опять же на своем примере:

в секцию NAT центрального координатора добавил:

rule= num 0 proto udp from anyip to 192.168.18.10:67-68 change dst=10.0.0.20:67-68

192.168.18.10 - внутренний Ip-адрес координатора в филиале

10.0.0.20 - виртуальный ip-адрес координатора в филиале или его accessip

И вот в итоге компьютер в филиале получил долгожданный выделенный IP-адрес с сервера. УРА!! Остается закрыть все дыры, которые я наделал в фильтрах координаторов и настроить NAP на сервере