Волк, коза , капуста и топология сети.

[AdVv]

Думаю ситуация, поднятая в топике знакома многим. Имеется компьютерная сеть небольшого (порядка 50 машин) предприятия. Для выхода пользователей в интернет имеется выделенка, плюс к этому необходимы почтовый, веб и фтп сервер. На внешнем интерфейсе роутера реальный IP, дополнительно к нему выкуплен блок из 8 реальных IP. Доступ по Томску неограничен, для выхода пользователей во вне используется VPN. На первый взгляд все просто - серверам раздаются реальные IP, они помещаются в DMZ. Остальные машины прячутся за NAT. Все довольны. Однако как только один из пользователей устанавливает у себя VPN соединение, весь траффик в собственную DMZ начинает бегать через VPN сервер провайдера, что категорически неудобно.
Как быть ?

[demiurg]

Думаю ситуация, поднятая в топике знакома многим. Имеется компьютерная сеть небольшого (порядка 50 машин) предприятия. Для выхода пользователей в интернет имеется выделенка, плюс к этому необходимы почтовый, веб и фтп сервер. На внешнем интерфейсе роутера реальный IP, дополнительно к нему выкуплен блок из 8 реальных IP. Доступ по Томску неограничен, для выхода пользователей во вне используется VPN. На первый взгляд все просто - серверам раздаются реальные IP, они помещаются в DMZ. Остальные машины прячутся за NAT. Все довольны. Однако как только один из пользователей устанавливает у себя VPN соединение, весь траффик в собственную DMZ начинает бегать через VPN сервер провайдера, что категорически неудобно.
Как быть ?

[snapback]964[/snapback]

На машине, где поднят VPN дополнительно добавить маршрут к DMZ через eth0 или как он нам в той ОС что на компе назвается

[Egor]

для выхода пользователей во вне используется VPN. (VPN сервер провайдера)

При такой схеме нет контроля (или его сложно реализовать) над трафиком, идущим через vpn. Это учтено и всех устраивает?

[DrDeath]

Однако как только один из пользователей устанавливает у себя VPN соединение, весь траффик в собственную DMZ начинает бегать через VPN сервер провайдера, что категорически неудобно.
Как быть ?

[snapback]964[/snapback]

Я бы предложил поднять vpn-сервер на шлюзе. На нем и поднимается впн-соединение с провайдером. На мой взгляд плюсы:
1) Контроль "Кто? Сколько? Чего? выкачал"
2) Решается твоя проблема.

[AdVv]

При такой схеме нет контроля (или его сложно реализовать) над трафиком, идущим через vpn. Это учтено и всех устраивает?

[snapback]976[/snapback]

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

[Egor]

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

[snapback]1001[/snapback]

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

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

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

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