Sitka_Charley
20-05-2011, 16:35
Здравствуйте! У нас большая организация. За сетку отвечает один отдел, за прикладное ПО другой отдел, за оборудование третий, и.т.д. Налицо разделение труда, когда за разные участки несут ответственность разные отделы, есть в этом плюсы и минусы. Поговорим сейчас о минусах: сами конфигурировать сеть, мы - прикладники, не можем.
Так вот. Сетевой отдел отличается большой ленью, заявки рассматривают неохотно, ну за серьезную работу в переконфигурировании системы вобще берутся неохотно. Квалификация их, оставляет желать лучшего. Нам потребовался доступ к внешним адресам с некоего сервера (назовем его для краткости "хочу наружу" на платформе Windows 2003 Server (а вернее стороннего ПО, которое на нем функционирует) по порту 27500 через брандмауэр Forefront TMG; сервер расположен в одной из локальных подсетей. Между этой локальной подсетью и брандмауэром находятся как минимум два шлюза. Эти шлюзы пробрасывают внутренние адреса в любую сторону, но белые или внешние адреса пробрасывать далее до брандмауэра они не отлажены.
Если бы сервер "хочу наружу" находился бы в той же подсети что и брандмауэр, проблем бы не было. Брандмауэр в таком случае был бы выставлен просто шлюзом по умолчанию и все белые адреса были бы доступны, но у нас есть кое-какие проблемы с физической передислокацией "хочу наружу". Поэтому вариант с перемещением отпадает.
Далее. Сетевой отдел отказал нам в проброске белых адресов до брандмауэра на этих своих двух промежуточных шлюзах :( , мотивируя это угрозой для безопасности общей корпоративной сети. Получается внутренний адрес TMG виден всем внутренним узлам нашей большой суперсети (а следовательно функционирует на нем нормально и прокси, который уже настроен на брандмауэр), а вот доступ ЗА НИМ к внешним адресам закрыт. шлюзы сетевиков просто не знают куда их направлять.
Ситуацию усугубляет то обстоятельство, что рвущееся наружу стороннее ПО сервера "хочу наружу" не понимает проксирования, т.е. ему нужен доступ системными средствами роутинга, через прокси -- бесполезно.
Также успешно осуществляется доступ к данному внутреннему серверу "хочу наружу" от внешнего "родительского" сервера через публикацию на брандмауэре. Когда внешний сервер ломится к "хочу наружу", то последний успешно принимает подключение, но когда пытается слать ответ обратно, то в адресе назначения обратный адрес -- внешний шлюзами уже не пропускается.
Если же "хочу наружу" инициирует соединение с сервером сам, то естественно, никуда не попадает по вышеназванным причинам.
Вопрос: как выйти из этой ситуации? может недокументированными или иными средствами брандмауэра/операционной системы сделать IP-инъекцию - подстановку IP адреса в адресе назначения, а именно прописать в "хочу наружу" пунктом назначения внутренний адрес шлюза, а при обращении на этот свой адрес брандмауэр, в свою очередь запустит инъекцию, которая впрыснет вместо внутреннего адреса назначения внешний?
или же как вариант все таки "заставить" серверную программу какими то третьими средствами пробросить адрес 212.212.212.212:27500 через проксирование?
Очень жду и надеюсь на Ваш ответ, добрые люди.
Так вот. Сетевой отдел отличается большой ленью, заявки рассматривают неохотно, ну за серьезную работу в переконфигурировании системы вобще берутся неохотно. Квалификация их, оставляет желать лучшего. Нам потребовался доступ к внешним адресам с некоего сервера (назовем его для краткости "хочу наружу" на платформе Windows 2003 Server (а вернее стороннего ПО, которое на нем функционирует) по порту 27500 через брандмауэр Forefront TMG; сервер расположен в одной из локальных подсетей. Между этой локальной подсетью и брандмауэром находятся как минимум два шлюза. Эти шлюзы пробрасывают внутренние адреса в любую сторону, но белые или внешние адреса пробрасывать далее до брандмауэра они не отлажены.
Если бы сервер "хочу наружу" находился бы в той же подсети что и брандмауэр, проблем бы не было. Брандмауэр в таком случае был бы выставлен просто шлюзом по умолчанию и все белые адреса были бы доступны, но у нас есть кое-какие проблемы с физической передислокацией "хочу наружу". Поэтому вариант с перемещением отпадает.
Далее. Сетевой отдел отказал нам в проброске белых адресов до брандмауэра на этих своих двух промежуточных шлюзах :( , мотивируя это угрозой для безопасности общей корпоративной сети. Получается внутренний адрес TMG виден всем внутренним узлам нашей большой суперсети (а следовательно функционирует на нем нормально и прокси, который уже настроен на брандмауэр), а вот доступ ЗА НИМ к внешним адресам закрыт. шлюзы сетевиков просто не знают куда их направлять.
Ситуацию усугубляет то обстоятельство, что рвущееся наружу стороннее ПО сервера "хочу наружу" не понимает проксирования, т.е. ему нужен доступ системными средствами роутинга, через прокси -- бесполезно.
Также успешно осуществляется доступ к данному внутреннему серверу "хочу наружу" от внешнего "родительского" сервера через публикацию на брандмауэре. Когда внешний сервер ломится к "хочу наружу", то последний успешно принимает подключение, но когда пытается слать ответ обратно, то в адресе назначения обратный адрес -- внешний шлюзами уже не пропускается.
Если же "хочу наружу" инициирует соединение с сервером сам, то естественно, никуда не попадает по вышеназванным причинам.
Вопрос: как выйти из этой ситуации? может недокументированными или иными средствами брандмауэра/операционной системы сделать IP-инъекцию - подстановку IP адреса в адресе назначения, а именно прописать в "хочу наружу" пунктом назначения внутренний адрес шлюза, а при обращении на этот свой адрес брандмауэр, в свою очередь запустит инъекцию, которая впрыснет вместо внутреннего адреса назначения внешний?
или же как вариант все таки "заставить" серверную программу какими то третьими средствами пробросить адрес 212.212.212.212:27500 через проксирование?
Очень жду и надеюсь на Ваш ответ, добрые люди.