Показать полную графическую версию : [решено] Маршрут в другую подсеть через шлюз во внутренней подсети
Здравствуйте!
Пробовал решить проблему по подобным темам на разных форумах, однако, то ли я чего не замечаю, то ли лыжи не едут... В общем надежда самостоятельно решить проблему у меня улетучилась. Вот мой вопрос:
Есть внутренняя сеть 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, получаю следующее:
Отклоненное соединение SRV-GATE
Тип журнала: Служба межсетевого экрана
Состояние: Пакет был удален, поскольку его IP-адрес назначения недоступен.
Правило: Нет - см. код результата
Источник: Внутренняя (10.68.1.166:2048)
Назначение: PODRAZDEL (10.67.0.1)
Протокол: Проверка связи
Дополнительные сведения
Число отправленных байтов: 0 Число полученных байтов: 0
Время обработки: 0ms Первоначальный IP-адрес клиента: 10.68.1.166
И из имитатора трафика:
При TCP трафике с 10.68.1.166:* к 10.67.0.13:21
Разрешенный трафик
Запрещенный трафик — не удалось разрешить имя URL-адреса назначения
Имя правила: All traf to PODRAZDEL
Порядковый номер правила: 3
Additional information
От: Внутренняя
Кому: PODRAZDEL
Имя сетевого правила: PODRAZDEL-Внутренняя
Отношения сетей: Маршрут
Протокол: FTP
Фильтр приложения для правила: Фильтр FTP-доступа
Трафик, разрешенный правилами политики межсетевого экрана, может блокироваться веб-фильтрами или фильтрами приложения.
З.Ы.
Если маршут route add 10.67.0.0 mask 255.255.0.0 10.68.0.21 прописать на локальной машине, то трафик между этой машиной и удалённой подсетью ходит без проблем.
Telepuzik
22-12-2011, 00:01
Подымите между маршрутизаторами VPN тунель будет проще настроить. При такой настройке как у Вас работать не будет. А в чем причина необходимости пропускать весь траффик через ISA?
Сейчас, вроде как, победил это дело прописав маршруты в DHCP, просто сразу что-то не сообразил так сделать :search:
А идея была в том, что если шлюзом по-умолчанию будет прописан 10.68.0.101, то, соответсвенно, именно он ответсвенный за маршрутизацию всех пакетов не из моей сети.
Тему пока не закрываю, думаю, в ближайшее время может возникнуть похожая проблема с маршрутизацией.
а не проще ли на маршрутизаторе разрулить траффик что бы он раздавал что нужно и куда нужно?
тупой Static Routing умеют многие L2 свитчи, а как я поняла этого хватит.
ну и да, 121/249 в DHCP тоже решают проблему :)
cameron, действительно, посмотрел, и мои так могут, но никогда этого не делал, да и так как сейчас сделал пока работает :)
Как и писал ранее, возник новый вопрос, и тут уже точно должен TMG решать...
У нас есть два Интернет-канала, и балансировку я уже успешно настроил, однако через один из каналов должны идти пакеты с/на подразделения. Схема такая:
_________
/--|10.68.4.1|---(10.68.4.0/24)
_________ / |_________|
| | / _________
| |----------------|10.68.5.1|---(10.68.5.0/24)
/--78.X.X.97--| ISP1 | \ |_________|
_________ / | |--( INET ) \ _________
| | / |_________| \--|10.68.6.1|---(10.68.6.0/24)
| |--78.X.X.98--/ _________ |_________|
(10.68.0.0/255.255.252.0)---| TMG | | |
| | | |
| |------------------------------| ISP2 |-----( INET )
|_________| | |
|_________|
С подразделений пакеты поступают на маршрутизатор 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
Создал сетевое правило Внутренняя сеть-ПОДРАЗДЕЛЕНИЯ маршрут.
В политику межсетевого экрана добавил правило Разрешить весь исходящий трафик из Внутренняя сеть в сеть ПОДРАЗДЕЛЕНИЯ всем пользователям.
В итоге, получаем следующее:
Отклоненное соединение SRV-GATE
Тип журнала: Служба межсетевого экрана
Состояние: Пакет был удален, поскольку его IP-адрес назначения недоступен.
Правило: Нет - см. код результата
Источник: Внутренняя (10.68.1.166:2048)
Назначение: ПОДР1 (10.68.4.1)
Протокол: Проверка связи
Дополнительные сведения
Число отправленных байтов: 0 Число полученных байтов: 0
Время обработки: 0ms Первоначальный IP-адрес клиента: 10.68.1.166
Или в имитаторе трафика:
Разрешенный трафик
Имя правила: Внутренняя сеть-ПОДРАЗДЕЛЕНИЯ
Порядковый номер правила: 4
Additional information
От: Внутренняя
Кому: ПОДР1
Имя сетевого правила: Внутренняя сеть-ПОДРАЗДЕЛЕНИЯ
Отношения сетей: Маршрут
Протокол: Нераспознанные IP-данные
Фильтр приложения для правила:
Трафик, разрешенный правилами политики межсетевого экрана, может блокироваться веб-фильтрами или фильтрами приложения.
Что я делаю не так?
С подразделений пакеты поступают на маршрутизатор 10.68.[4,5,6].1 он пробрасывает провайдеру, и от провайдера через маршрутизатор 78.X.X.97 пакеты брасаются на интерфейс TMG 78.X.X.98, который должен пробросить пакеты в сеть 10.68.0.0/22. Ну и, аналогично, в обратную сторону... »
я прошу прощения за свою недогадливость, но что это?
недокостыльный Static NAT или вырвиглазный VPN ?=)
почему не поднять IPsec Site-to-site между TMG и %чем_угодно_ в_другом_офисе%? :)
или, если там один провайдер - взять у них PtP, за трубу на низкой скорости или без гарантированной полосы много не возьмут.
cameron, как сказать?... На сколько мне известно, провайдер ЭТО и называет PtP :) С его стороны так исторически сложилось, и поменять что либо в условиях как нашей организации, так и провайдера, в достаточно короткий срок, ничего не получится, поэтому приходится бороться с тем что есть... До TMG у меня стоял шлюз на Линухе, и там всё работало как часы, однако, обстоятельства сложились не в его пользу...
провайдер ЭТО и называет PtP »
это не ptp.
До TMG у меня стоял шлюз на Линухе, и там всё работало как часы, однако, обстоятельства сложились не в его пользу... »
было бы неплохо понять что там было сделано до убивания. но это не суть.
рисуйте схему, что и где и как.
а главное причём тут провайдерский роутер и почему вы не можете на тех 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 .
Ну и в обратную сторону - в обратном порядке.
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. вы можете заменить провайдерские кошки на ваше обуродование?
Вот примеры трассировок через имеющийся линуксовый шлюз:
tracert 10.68.4.1
Tracing route to 10.68.4.1 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.68.0.1
2 1 ms <1 ms <1 ms 78.X.X.97
3 2 ms 2 ms 2 ms 10.10.10.2
4 620 ms 617 ms 616 ms 10.68.4.1
Trace complete.
Или с самого шлюза:
# traceroute 10.68.4.1
traceroute to 10.68.4.1 (10.68.4.1), 30 hops max, 40 byte packets
1 78.X.X.97 (78.X.X.97) 0.696 ms 0.699 ms 0.545 ms
2 10.10.10.2 (10.10.10.2) 2.262 ms 3.188 ms 2.820 ms
3 192.168.97.22 (192.168.97.22) 630.748 ms 617.407 ms 645.132 ms
Да, полагаю, со стороны как провайдера, так и нас что-то поменять можно, но так как все эти дела прописаны в договорах, то что-то изменить теперь можно будет лишь в 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 и смотрите коды результата.
соотно что там нужно наколдовать на кошках, которые бегают (судя по трассировке) через аж две приватных сетки - я не знаю.
да, трасерт со шлюза загадочен. вам так не кажется?
route add 10.68.x.0 mask 255.255.255.0 10.68.0.1 /p »
Не совсем понял, почему 10.68.0.1? Этот адрес принадлежит Линукс-шлюзу, который я должен убрать, т.е. вместо него должен встать TMG, который сейчас 10.68.0.101. Может быть нужно 78.Х.Х.97?
эти же сети должны быть прописаны в Intenal сети TMG. »
Если создана %SUBNET%, то эту подсеть прописать в Internal не даёт, говорит сети не должны пересекаться.
Нужно ли делать сетевое правило?
Может быть нужно 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 в сеть Внутренняя, появилось такое сообщение.
Описание: Сеть "Внутренняя" не связана с принадлежащими к ней сетевыми платами.
Диапазоны в плате "Подключение по локальной сети 3", не принадлежащие к сети "Внутренняя": 10.68.6.1-10.68.6.255;
Правильная настройка сети подразумевает, что диапазоны IP-адресов каждой сети уровня массива должны включать все IP-адреса, маршрутизируемые через сетевые платы этой сети согласно их таблицам маршрутизации. В противном случае допустимые пакеты могут быть отброшены как поддельные.
Обратите внимание, что это событие может однократно создаваться после добавления маршрута, создания удаленной сети или настройки балансировки сетевой нагрузки. Его можно проигнорировать, если оно больше не возникнет.
Таблица маршрутизации сетевой платы ISP1 включает диапазоны IP-адресов, не определенные в сети уровня массива Внешняя, к которой она привязана. По этой причине, когда пакеты будут проходить через данную сетевую плату из указанных ниже диапазонов IP-адресов, либо к этим диапазонам, они будут считаться поддельными и отбрасываться. Для устранения данной неполадки добавьте отсутствующие диапазоны IP-адресов в сеть массива.
Пакеты из следующих диапазонов IP-адресов будут считаться поддельными и отбрасываться:
Внутренняя:10.68.6.1-10.68.6.255;
Таблица маршрутизации сетевой платы ISP2 включает диапазоны IP-адресов, не определенные в сети уровня массива Внешняя, к которой она привязана. По этой причине, когда пакеты будут проходить через данную сетевую плату из указанных ниже диапазонов IP-адресов, либо к этим диапазонам, они будут считаться поддельными и отбрасываться. Для устранения данной неполадки добавьте отсутствующие диапазоны IP-адресов в сеть массива.
Пакеты из следующих диапазонов IP-адресов будут считаться поддельными и отбрасываться:
Внутренняя:10.68.6.1-10.68.6.255;
Да, 78.X.X.97 для сети 10.68.[4,5,6].0/24 является гейтом. »
что для TMG явлется гейтом? в сети ISP1?
После добавления подсети 10.68.6.0/24 в сеть Внутренняя, появилось такое сообщение. »
вообще похоже что я вас обманула, такой финт не прокатит, потому что гейтом для этих сетей является внеший адрес, а не внутренний, поэтому в интернал их вписывать не нужно.
в общем уберите эти диапазоны из internal сети , оставьте только FW правила регламентирующие хождение траффика между сабнетами и internal и запись в таблице маршрутизации.
что будет?
cameron, прошу прощения за задержку.
Прежде всего хочу выразить вам огомную благодарность в помощи! Спасибо! Победил! :up:
Этот же шлюз (78.X.X.97) является гейтом для ISP1.
Удалил из меню "сети" всё, что делал раньше касательно подразделений. Создал в сетевых объектах подсети подразделений. Добавил статические маршруты, и настроил маршрутизацию из сети Внутренняя к подсетям подразделений. Ну и сделал сетевое правило "Разрешать весь исходящий трафик из сетей Внутренняя, локальный компьютер, подразделения[1,2,3] в сети Внутренняя, локальный компьютер, подразделения[1,2,3] всем пользователям" и оно заработало.
Ещё раз большое спасибо!
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.