Маршрут в другую подсеть через шлюз во внутренней подсети
 

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

Есть внутренняя сеть 10.68.0.0/255.255.252.0
Адрес шлюза 10.68.0.101
В сети есть маршрутизатор 10.68.0.21, а за ним сеть 10.67.0.0/255.255.0.0

В общем нужно ВЕСЬ трафик в/из 10.67.0.0/255.255.0.0, поступающий на шлюз 10.68.0.101 заруливать через 10.68.0.21

Что я сделал:
Добавил на шлюзе 10.68.0.101 маршут route add 10.67.0.0 mask 255.255.0.0 10.68.0.21
В TMG сделал подсеть PODRAZDEL 10.67.0.0-10.67.255.255
Настроил отношение сетей Route Внутренняя сеть - PODRAZDEL
В политике межсетевого экрана прописал правило Разрешать весь исходящий трафик из Внутренняя сеть в PODRAZDEL всем пользователям

Однако, при попытке какого либо запроса, например к 10.67.0.1, получаю следующее:
И из имитатора трафика:
При TCP трафике с 10.68.1.166:* к 10.67.0.13:21
З.Ы.
Если маршут route add 10.67.0.0 mask 255.255.0.0 10.68.0.21 прописать на локальной машине, то трафик между этой машиной и удалённой подсетью ходит без проблем.

Подымите между маршрутизаторами VPN тунель будет проще настроить. При такой настройке как у Вас работать не будет. А в чем причина необходимости пропускать весь траффик через ISA?

Сейчас, вроде как, победил это дело прописав маршруты в DHCP, просто сразу что-то не сообразил так сделать :search:
А идея была в том, что если шлюзом по-умолчанию будет прописан 10.68.0.101, то, соответсвенно, именно он ответсвенный за маршрутизацию всех пакетов не из моей сети.

Тему пока не закрываю, думаю, в ближайшее время может возникнуть похожая проблема с маршрутизацией.

а не проще ли на маршрутизаторе разрулить траффик что бы он раздавал что нужно и куда нужно?
тупой Static Routing умеют многие L2 свитчи, а как я поняла этого хватит.

ну и да, 121/249 в DHCP тоже решают проблему :)

cameron, действительно, посмотрел, и мои так могут, но никогда этого не делал, да и так как сейчас сделал пока работает :)

Как и писал ранее, возник новый вопрос, и тут уже точно должен TMG решать...

У нас есть два Интернет-канала, и балансировку я уже успешно настроил, однако через один из каналов должны идти пакеты с/на подразделения. Схема такая:
С подразделений пакеты поступают на маршрутизатор 10.68.[4,5,6].1 он пробрасывает провайдеру, и от провайдера через маршрутизатор 78.X.X.97 пакеты брасаются на интерфейс TMG 78.X.X.98, который должен пробросить пакеты в сеть 10.68.0.0/22. Ну и, аналогично, в обратную сторону...

Что я сделал:
Создал внешние сети ПОДР1 (10.68.4.0/24), ПОДР2 (10.68.5.0/24), ПОДР3 (10.68.6.0/24)
Набор сетей ПОДРАЗДЕЛЕНИЯ, состоящий из 3-х перечисленных сетей.
Прописал маршруты route add 10.68.[4,5,6].0 mask 255.255.255.0 78.X.X.97
Создал сетевое правило Внутренняя сеть-ПОДРАЗДЕЛЕНИЯ маршрут.
В политику межсетевого экрана добавил правило Разрешить весь исходящий трафик из Внутренняя сеть в сеть ПОДРАЗДЕЛЕНИЯ всем пользователям.

В итоге, получаем следующее:


Или в имитаторе трафика:
Что я делаю не так?

я прошу прощения за свою недогадливость, но что это?
недокостыльный Static NAT или вырвиглазный VPN ?=)
почему не поднять IPsec Site-to-site между TMG и %чем_угодно_ в_другом_офисе%? :)

или, если там один провайдер - взять у них PtP, за трубу на низкой скорости или без гарантированной полосы много не возьмут.

cameron, как сказать?... На сколько мне известно, провайдер ЭТО и называет PtP :) С его стороны так исторически сложилось, и поменять что либо в условиях как нашей организации, так и провайдера, в достаточно короткий срок, ничего не получится, поэтому приходится бороться с тем что есть... До TMG у меня стоял шлюз на Линухе, и там всё работало как часы, однако, обстоятельства сложились не в его пользу...

это не ptp.
было бы неплохо понять что там было сделано до убивания. но это не суть.

рисуйте схему, что и где и как.
а главное причём тут провайдерский роутер и почему вы не можете на тех 3-х хостах, которые непонятно где, сделать впн к вашей тмг?

cameron, благо ещё ничего не убил, иначе бы уже не приставал с глупыми вопросами... :)

Дело в том, что циски, которые имеют адреса 10.68.[4,5,6].1 и 78.X.X.97 принадлежат провайдеру, и я туда никакого доступа не имею.

На Линуксе у меня сейчас сделано всё так:
Так как подсети 10.68.[4,5,6].0/24 не принадлежат нашей сети, то, естесственно они попадают на шлюз по-умолчанию (в настоящий момент 10.68.0.1), там в iptables сказано пропускать весь трафик в/из 10.68.[4,5,6].0/24 и настроена маршрутизация этих подсетей на 78.x.x.97. Соответсвенно дальше пакеты с интерфейса 78.x.x.98 попадают на шлюз провайдера 78.x.x.97 и оказываются на подразделениях "прилетая" с интерфейса циски 10.68.[4,5,6].1 .
Ну и в обратную сторону - в обратном порядке.

это их internal(inside) интерфейсы, а какие снаружи адреса?
я просто никак не могу понять этого изврата, потому что PTP стоит денег, а в этом случае вы платите ни за что - услуга не предоставляется.
как я понимаю:
у вас есть ЦО:
10.68.0.0/255.255.252.0 с TMG и белым IP.
есть несколько дополнительных офисов, в которых 10.68.x.0/24 но не ясно что с внешними интерфейсами, там стоят кошки которые что-то делают ДО шлюза провайдера, который потом что-то хитро куда то роутит.
вопросы:
1. вместо всего этого месива костылей провайдер в состоянии поднять IPsec на этих трёх кошках до вашей TMG? думаю да.
2. провайдер в состоянии предоставить нормальный PTP?
3. вы можете заменить провайдерские кошки на ваше обуродование?

Вот примеры трассировок через имеющийся линуксовый шлюз:
Или с самого шлюза:
Да, полагаю, со стороны как провайдера, так и нас что-то поменять можно, но так как все эти дела прописаны в договорах, то что-то изменить теперь можно будет лишь в 2013 году - слишком неповоротливая у нас бюррократическая машина. Вот и приходится извращаться.

что, как я вижу, должно быть на TMG.

route add 10.68.x.0 mask 255.255.255.0 10.68.0.1 /p

эти же сети должны быть прописаны в Intenal сети TMG.

в FW policy должно быть правило:

allow - %SUBNETS%/internal/localhost - %SUBNETS%/internal/localhost - all users (что самое интересное, по логике этого правила быть не должно, потому что оно не нужно, но у меня не заработало без него).

после чего проверяйте трассировку с клиента, включайте Logging на его IP и смотрите коды результата.

соотно что там нужно наколдовать на кошках, которые бегают (судя по трассировке) через аж две приватных сетки - я не знаю.
да, трасерт со шлюза загадочен. вам так не кажется?

Не совсем понял, почему 10.68.0.1? Этот адрес принадлежит Линукс-шлюзу, который я должен убрать, т.е. вместо него должен встать TMG, который сейчас 10.68.0.101. Может быть нужно 78.Х.Х.97?

Если создана %SUBNET%, то эту подсеть прописать в Internal не даёт, говорит сети не должны пересекаться.

Нужно ли делать сетевое правило?

а гейтом для неё не он же случаем?
ибо мне думается что так не сработает.

что-то вы неправду говорите.
такое поведение свойственно для Network, а я говорю о Toolbox-networks objects - SubNets

Да, 78.X.X.97 для сети 10.68.[4,5,6].0/24 является гейтом.
После добавления подсети 10.68.6.0/24 в сеть Внутренняя, появилось такое сообщение.

что для TMG явлется гейтом? в сети ISP1?
вообще похоже что я вас обманула, такой финт не прокатит, потому что гейтом для этих сетей является внеший адрес, а не внутренний, поэтому в интернал их вписывать не нужно.
в общем уберите эти диапазоны из internal сети , оставьте только FW правила регламентирующие хождение траффика между сабнетами и internal и запись в таблице маршрутизации.
что будет?

cameron, прошу прощения за задержку.
Прежде всего хочу выразить вам огомную благодарность в помощи! Спасибо! Победил! :up:


Этот же шлюз (78.X.X.97) является гейтом для ISP1.

Удалил из меню "сети" всё, что делал раньше касательно подразделений. Создал в сетевых объектах подсети подразделений. Добавил статические маршруты, и настроил маршрутизацию из сети Внутренняя к подсетям подразделений. Ну и сделал сетевое правило "Разрешать весь исходящий трафик из сетей Внутренняя, локальный компьютер, подразделения[1,2,3] в сети Внутренняя, локальный компьютер, подразделения[1,2,3] всем пользователям" и оно заработало.

Ещё раз большое спасибо!