Tomsk Sysadmins Forum

Windows => Администрирование => Topic started by: AdVv on February 14, 2005, 15:36:13

Title: Волк, коза , капуста и топология сети.
Post by: AdVv on February 14, 2005, 15:36:13
Думаю ситуация, поднятая в топике знакома многим. Имеется компьютерная сеть небольшого (порядка 50 машин) предприятия. Для выхода пользователей в интернет имеется выделенка, плюс к этому необходимы почтовый, веб и фтп сервер. На внешнем интерфейсе роутера реальный IP, дополнительно к нему выкуплен блок из 8 реальных IP. Доступ по Томску неограничен, для выхода пользователей во вне используется VPN. На первый взгляд все просто - серверам раздаются реальные IP, они помещаются в DMZ. Остальные машины прячутся за NAT. Все довольны. Однако как только один из пользователей устанавливает у себя VPN соединение, весь траффик в собственную DMZ начинает бегать через VPN сервер провайдера, что категорически неудобно.
Как быть ?
Title: Волк, коза , капуста и топология сети.
Post by: demiurg on February 14, 2005, 16:08:04
Quote
Думаю ситуация, поднятая в топике знакома многим. Имеется компьютерная сеть небольшого (порядка 50 машин) предприятия. Для выхода пользователей в интернет имеется выделенка, плюс к этому необходимы почтовый, веб и фтп сервер. На внешнем интерфейсе роутера реальный IP, дополнительно к нему выкуплен блок из 8 реальных IP. Доступ по Томску неограничен, для выхода пользователей во вне используется VPN. На первый взгляд все просто - серверам раздаются реальные IP, они помещаются в DMZ. Остальные машины прячутся за NAT. Все довольны. Однако как только один из пользователей устанавливает у себя VPN соединение, весь траффик в собственную DMZ начинает бегать через VPN сервер провайдера, что категорически неудобно.
Как быть ?
[snapback]964[/snapback]
На машине, где поднят VPN дополнительно добавить маршрут к DMZ через eth0 или как он нам в той ОС что на компе назвается
Title: Волк, коза , капуста и топология сети.
Post by: Egor on February 14, 2005, 17:53:40
Quote
для выхода пользователей во вне используется VPN. (VPN сервер провайдера)
При такой схеме нет контроля (или его сложно реализовать) над трафиком, идущим через vpn. Это учтено и всех устраивает?
Title: Волк, коза , капуста и топология сети.
Post by: DrDeath on February 15, 2005, 13:17:56
Quote
Однако как только один из пользователей устанавливает у себя VPN соединение, весь траффик в собственную DMZ начинает бегать через VPN сервер провайдера, что категорически неудобно.
Как быть ?
[snapback]964[/snapback]
Я бы предложил поднять vpn-сервер на шлюзе. На нем и поднимается впн-соединение с провайдером. На мой взгляд плюсы:
1) Контроль "Кто? Сколько? Чего? выкачал"
2) Решается твоя проблема.
Title: Волк, коза , капуста и топология сети.
Post by: AdVv on February 16, 2005, 14:25:34
Quote
При такой схеме нет контроля (или его сложно реализовать) над трафиком, идущим через vpn. Это учтено и всех устраивает?
[snapback]976[/snapback]
Как раз проблема перекладывается на плечи провайдера. Каждому пользователю выдается собственный логин, а для контроля используется статистика биллинга провайдера.
Title: Волк, коза , капуста и топология сети.
Post by: Egor on February 16, 2005, 18:18:09
Quote
Как раз проблема перекладывается на плечи провайдера. Каждому пользователю выдается собственный логин, а для контроля используется статистика биллинга провайдера.
[snapback]1001[/snapback]
Уровень такого контроля достаточно невысок, также имеется слишком мало методов управления (только на организационном уровне?).

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

Пользователи так называемого "vpn доступа в интернет" имеют прямое подключение к общедоступной сети интернет.

Рекомендуется рассмотреть внедрение варианта с обязательным использованием прокси-серверов пользователями или - если требуется обеспечить именно прямой доступ - вариант, предложенный DrDeath. Эти схемы  дают возможность управлять сетевыми взаимодействиями, а не только учитывать потребление трафика постфактум.