на сайт
на сайт

Поиск  Правила  Войти
Главная страница » Главный раздел » Traffic Inspector - технические вопросы.
Страницы: 1
RSS
Настройка Windows Server 2008R2 для TI
 
#1
0
15.10.2014 19:47:00
Доброго времени суток.

Есть простая сеть:


Собственно всё было хорошо, но появилась задача учитывать посещённые ресурсы некоторыми подразделениями. Выбрали в качестве одного из возможных решений - решение от Smart Soft - TI v3.

Собственно соединили всё как показано выше, и решили "пощупать" что TI из себя представляет и насколько он применим в наших условиях. Собственно как не трудно догадаться - у нас ничего не заработало.

на коммутаторе ядра с помощью PBR завернули трафик от целевого тестового хоста (172.16.2.3) не на основной маршрутизатор (IP: 192.168.0.1) а на сервер с Traffic Inspector (IP: 172.16.0.1)

на котором собственно два интерфейса:
LAN1: 192.168.0.6 / 255.255.255.252 с маршрутом по-умолчанию 192.168.0.5
LAN2: 172.16.0.1 / 255.255.255.248 без маршрута по-умолчанию, но зато со статическим маршрутом
route -p add 172.16.0.0 mask 255.255.0.0 172.16.0.2 metric 100

на сервере установлена служба "маршрутизация и удалённый доступ"
так же в реестре стоит параметр DWORD IPEnableRouter = 1

собственно трассировка с клиента показывает следующее:
1-й хоп: 172.16.2.1 (ядро сети - тут Ок)
2-й хоп: 172.16.0.1 ("внутренний" интерфейс сервера с TI - тут тоже Ок)
дальше собственно пока TTL не упадёт до 0 пакет крутится на 172.16.0.1 
3-й хоп: 172.16.0.1
....
....
n-й хоп: 172.16.0.1

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

Специалистов по Windows у нас нет, скорее всего что-то не докрутили специфичное для этой платформы. Может кто-нибудь из форумчан подскажет что именно надо сделать с Windows Server чтобы он заработал как обычный маршрутизатор (NAT осуществляется выше, нужно просто учитывать трафик и пропускать его дальше по Default GW через интерфейс NET1)

Заранее спасибо.
 
 
 
#2
0
15.10.2014 20:56:00

отзеркалили бы порт на один интерфейс машины с ти, в ти включили бы режим прослушки - и учитывали бы трафик нужных и ненужных сегментов.



по схеме: покуда имеете серверную ос (типа 2к8), включите на ней роль маршрутизатора(оснастку RRAS) и рулите стат маршрутами через неё(в нат интерфейсы не добавляйте и будет оно тупым роутером если стат маршруты есть на соседних бордерах нужные да на этой ОСи)+отключите встроенный фв+сначала настройте вообще БЕЗ ти чтоб работало.


 


схема имеет право жить. просто где-то немного запутались.
 
 
 
#3
0
16.10.2014 13:21:00
Всем спасибо за ответ. проблема была в кривой работе PBR. При указании маршрута на DGS-3620 или через Default или через Static route - всё заработало, при PBR-маршруте получается ситуация, как описано выше.

Спасибо за потраченное время. Вопрос далее будет решаться на форуме D-Link.
 
 
 
#4
0
22.10.2014 13:51:00
Всё заработало!

Зря я "гнал" на D-Link и Windows Server. Выше нарисована эквивалентная "логическая сеть", но проблема была в том, что TI мы настраивали у нас на стенде, следовательно компьютер с TI стоял не в серверной, а у нас в отделе. И РЕАЛЬНАЯ схема выглядела так:



Вы скажете, что это ничего не меняет? Вот и я так думал, но на самом деле меняет и очень много. Рассмотри движение IP-пакетов от клиента в "Группа №2" во внешнюю сеть, например до Google DNS (8.8.8.8)
1 хоп: from: 172.16.2.2 to: 8.8.8.8 gw:172.16.2.1 - через свич доступа пакет по L2 без изменений через транк попадает на свич ядра, где попадает под PBR ACL:

create access_profile profile_id 6 profile_name PBR ip source_ip_mask 0.0.0.0 destination_ip_mask 0.0.0.0
config access_profile profile_id 6 add acc 1 ip source_ip 172.16.2.2 mask 255.255.255.255 port all perm
на который сверху наложены такие правила:
create policy_route name test
config policy_route name test acl profile_id 6 access_id 1 nexthop 172.16.0.1 state enable route_preference default

т.е. говоря по-русски: весь IP-трафик у которого поле from равно 172.16.2.2 в случае если роут не известен в локальной таблице L3-коммутатора перенаправлять на роутер 172.16.0.1 (комп с TI)
т.е. второй выглядит так:
2-й хоп: from: 172.16.2.2 to: 8.8.8.8 gw:172.16.0.1
далее пакет обрабатывается маршрутизатором Windows/TI и по локальной таблице маршрутизации уходит на шлюз 192.168.0.5, т.е. пакет выглядит так:
3-й хоп: from: 172.16.2.2 to: 8.8.8.8 gw:192.168.0.5
и тут он снова попадает на коммутатор ядра, где в свою очередь попадает на PBR
т.е. пакет никогда не дойдёт до 192.168.0.5 :)

Правильное решение в PBR включить ещё и проверку VLAN-тега пакета, т.е. как только я правило переписал так:
create access_profile profile_id 6 profile_name PBR ip source_ip_mask 0.0.0.0 vlan 0x0fff
config access_profile profile_id 6 add acc 1 ip source_ip 172.16.2.2 mask 255.255.255.255 vlan vlan12 port all perm

всё заработало :)

p.s. tcpump и wireshark - таки сила!
 
 
 
#5
0
16.05.2019 22:47:00
Цитата
Всё заработало!

Зря я "гнал" на D-Link и Windows Server. Выше нарисована эквивалентная "логическая сеть", но проблема была в том, что TI мы настраивали у нас на стенде, следовательно компьютер с TI стоял не в серверной, а у нас в отделе. И РЕАЛЬНАЯ схема выглядела так:

Вы скажете, что это ничего не меняет? Вот и я так думал, но на самом деле меняет и очень много. Рассмотри движение IP-пакетов от клиента в "Группа №2" во внешнюю сеть, например до Google DNS (8.8.8.8)/
1 хоп: from: 172.16.2.2 to: 8.8.8.8 gw:172.16.2.1 - через свич доступа пакет по L2 без изменений через транк попадает на свич ядра, где попадает под PBR ACL:

create access_profile profile_id 6 profile_name PBR ip source_ip_mask 0.0.0.0 destination_ip_mask 0.0.0.0
config access_profile profile_id 6 add acc 1 ip source_ip 172.16.2.2 mask 255.255.255.255 port all perm
на который сверху наложены такие правила:
create policy_route name test
config policy_route name test acl profile_id 6 access_id 1 nexthop 172.16.0.1 state enable route_preference default

т.е. говоря по-русски: весь IP-трафик у которого поле from равно 172.16.2.2 в случае если роут не известен в локальной таблице La2 сервера перенаправлять на роутер 172.16.0.1 (комп с TI)
т.е. второй выглядит так. Линейдж сервера рекомендую смотреть на la2on качественная подборка и отличный выбор для истинных ценителей:
2-й хоп: from: 172.16.2.2 to: 8.8.8.8 gw:172.16.0.1
далее пакет обрабатывается маршрутизатором Windows/TI и по локальной таблице маршрутизации уходит на шлюз 192.168.0.5, т.е. пакет выглядит так:
3-й хоп: from: 172.16.2.2 to: 8.8.8.8 gw:192.168.0.5
и тут он снова попадает на коммутатор ядра, где в свою очередь попадает на PBR
т.е. пакет никогда не дойдёт до 192.168.0.5 :)

Правильное решение в PBR включить ещё и проверку VLAN-тега пакета, т.е. как только я правило переписал так:
create access_profile profile_id 6 profile_name PBR ip source_ip_mask 0.0.0.0 vlan 0x0fff
config access_profile profile_id 6 add acc 1 ip source_ip 172.16.2.2 mask 255.255.255.255 vlan vlan12 port all perm

всё заработало :)

p.s. tcpump и wireshark - таки сила!


Благодарю вас за статью. Благодарю гуглу я нашел ее и сумел решил аналогичную проблему. Низкий поклон!
MartiRay2019-05-16 22:51:53
 
 
 
Страницы: 1
Читают тему (гостей: 2)