Доступ к внешнему адресу минуя ограничения шлюзов
 

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

Так вот. Сетевой отдел отличается большой ленью, заявки рассматривают неохотно, ну за серьезную работу в переконфигурировании системы вобще берутся неохотно. Квалификация их, оставляет желать лучшего. Нам потребовался доступ к внешним адресам с некоего сервера (назовем его для краткости "хочу наружу" на платформе Windows 2003 Server (а вернее стороннего ПО, которое на нем функционирует) по порту 27500 через брандмауэр Forefront TMG; сервер расположен в одной из локальных подсетей. Между этой локальной подсетью и брандмауэром находятся как минимум два шлюза. Эти шлюзы пробрасывают внутренние адреса в любую сторону, но белые или внешние адреса пробрасывать далее до брандмауэра они не отлажены.

Если бы сервер "хочу наружу" находился бы в той же подсети что и брандмауэр, проблем бы не было. Брандмауэр в таком случае был бы выставлен просто шлюзом по умолчанию и все белые адреса были бы доступны, но у нас есть кое-какие проблемы с физической передислокацией "хочу наружу". Поэтому вариант с перемещением отпадает.

Далее. Сетевой отдел отказал нам в проброске белых адресов до брандмауэра на этих своих двух промежуточных шлюзах :( , мотивируя это угрозой для безопасности общей корпоративной сети. Получается внутренний адрес TMG виден всем внутренним узлам нашей большой суперсети (а следовательно функционирует на нем нормально и прокси, который уже настроен на брандмауэр), а вот доступ ЗА НИМ к внешним адресам закрыт. шлюзы сетевиков просто не знают куда их направлять.

Ситуацию усугубляет то обстоятельство, что рвущееся наружу стороннее ПО сервера "хочу наружу" не понимает проксирования, т.е. ему нужен доступ системными средствами роутинга, через прокси -- бесполезно.

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

Если же "хочу наружу" инициирует соединение с сервером сам, то естественно, никуда не попадает по вышеназванным причинам.

Вопрос: как выйти из этой ситуации? может недокументированными или иными средствами брандмауэра/операционной системы сделать IP-инъекцию - подстановку IP адреса в адресе назначения, а именно прописать в "хочу наружу" пунктом назначения внутренний адрес шлюза, а при обращении на этот свой адрес брандмауэр, в свою очередь запустит инъекцию, которая впрыснет вместо внутреннего адреса назначения внешний?

или же как вариант все таки "заставить" серверную программу какими то третьими средствами пробросить адрес 212.212.212.212:27500 через проксирование?

Очень жду и надеюсь на Ваш ответ, добрые люди.

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

Причем это может быть по трем причинам:
а) отсутствие маршрута на белые адреса (ваша версия);
б) блокировка трафика access-list;
в) внутренняя политика, которая запрещает обращение в Интернет без прокси.

Учитывая, что Ваших знаний вероятно недостаточно, чтобы работать в сетевом отделе, то единственным разумным выходом для Вас является заявка на обеспечение работы указанного сервера.
Версия, что белые адреса не могут ходить в Вашей локальной сети проваливает в свете Вашего утверждения, что если бы сервер был в одной сети с TMG, то все работало... т.о. похоже, что проблема либо в access-list, либо в маршрутизации.
И то и другое решается через заявку :)

Технические детали:
Маршрутизация решается либо через deafult gw, либо через PBR (если у Вас cisco или оборудования hi-end).
Access-list - ну, тут даже написать нечего.

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

Ps: впрочем, если Вы пытаетесь поднять игровой сервер, то правильно Ваши сетевики запрещают Вам такое безобразие :)

Уважаемый ORS, Вы явно не поняли сути вопроса. Конечно в свете мудрости Ваших знаний может мои знания выглядят шаландой по сравнению с Титаником, но вопрос здесь в том, что как Вы уже могли понять, а не строить предположения -- access листы это, или внутренняя политика. Я четко сказал что отсутствуют маршруты на белые адреса, во всем остально проблем нет. Прокси позволяет, брандмауэр позволяет, нет только маршрута на белые адреса в промежуточных шлюзах, из-за чего до брандмауэра просто не доходят запросы на белые адреса от искомого сервера через промежуточные шлюзы. Чего здесь Вам собственно непонятно?
Политиками Компании хождение к белым адресам наружу формально запрещено. Это допускается только в ДМЗ подсетях. Однако Руководство требует опять же обойти формальные ограничения для одного конкретного сервера. В ДМЗ подсеть напрямую смотрящую на брандмауэр переместить физически сервер в настоящий момент нет возможности.

Насчет недостаточной квалификации, мы просто не имеем права лезть в дела сетевого отдела, вот почему мы не может отконфигурировать сетевое оборудование

С каких это пор cisco не считается оборудованием hi-end, если так поумничать между делом, как сделали в данном случае Вы?

Если у Вас сетевое оборудование hi-end, то Вам поможет Policy-Based-Routing.

В принципе можно было бы еще в DMZ поднять VPN-сервер (на базе RRAS) - ваш сервер бы подключался через внутреннюю сеть к VPN и, используя в качестве основного gw VPN, мог бы выйти в Интернет.