Основная цель веб-сайта — донести до пользователя информацию и оставить благоприятное впечатление. Хороший сайт — удобен, легок, эстетичен и предоставляет всю необходимую информацию по своей тематике. Поэтому у хорошего веб-сайта должен быть хороший дизайн, хорошая навигация, современные технологии web и хорошая структура информации. подробнее...
Партнеры
Метки
Организация VPN доступа между VLAN
Статьи → Технологии М.СорокинПреамбула.
Недавно при работе над архитектурой и модернизацией сети для одной из студий 3D-моделирования, возникла довольно щекотливая ситуация. Суть ее сводилась к следующему. В результате модернизации локальной сети в студии, все структурные подразделения были логически разделены на VLANы с помощью CISCO-роутеров. В отдельный VLAN вывели и рендерный кластер — конкретно о нем и пойдет речь в этой статье.
Рендерный кластер состоит из 108 вычислительных серверов (нод) и 2 менеджеров (основной и резервный). На менеджерах подняты ActiveDirectory, DNS, DHCP, ComputeCluster (де-факто используемый пока только в плане деплоя и RIS). Каждый из менеджер-серверов использует по два NIC — один смотрит во внешнюю сеть, второй — приватный кластерный VLAN.
Проблематика.
Все замечательно, но сложился конфликт интересов. Дело в том, что специфика сетевого 3D-рендеринга требует зачастую прямой проверки что же именно происходит на той или другой ноде (в этом отличие сетевого рендеринга от кластерного — когда задание контролируется исключительно на менеджер-сервере, хотя физически так же считается на нодах). Для этого необходим удаленный доступ на конкретную ноду — дабы увидеть что происходит и как происходит
Поскольку VLANы были созданы специально для предотвращения несанкционированного доступа к рендер-кластеру и дабы сами рендер-ноды использовали свою приватную сеть — такая структура не позволяет удаленный доступ к вычислительным нодам напрямую из общей сети. Но определенным пользователям такой доступ оказался нужен. Что делать?
Самый естественный (и самый распространенный) вариант, когда сначала авторизованный пользователь удаленно заходит на менеджер-сервер, а затем с него удаленно на конкретную вычислительную ноду. Такой вариант естественен для администраторов и ИТ-персонала, но крайне неудобен самим дизайнерам. Ситуация складывалась сложная: дизайнерам была неудобна такая работа, а ИТ-специалисты не хотели открывать маршрутизацию между VLAN — иначе зачем терялся смысл всей архитектуры.
В качестве варианта рассматривался некий «компромисс» между удобством для пользователей и правильностью сетевой архитектуры. Суть компромисса состояла в маршрутизации по TCP/IP порту. Т.е. перенаправление (трансляции) запросов к менеджер-серверу (из общей сети) непосредственно в запросы к конкретной ноде: например, перенаправление запроса от 192.168.022 (РС дизайнера) к 192.168.2.1:30095 (менеджер-сервер внешний интерфейс, трансляция на внутренний) на 10.10.1.95 (нода). Это наиболее распространенный вариант среди cross-запросов. Однако, помимо эстетической стороны дела, было в этом варианте еще одно важное неудобство для ИТ-специалистов — привязка всей таблицы маршрутизации к статическим (или псевдо-DHCP) адресам вычислительных нод. Терялась прелесть обслуживания такой рендер-фермы со стороны ИТ (быстрый деплой и управление).
Изящным решением проблемы оказался… — VPN! Кто сказал, что VPN хорош только для предоставления доступа из внешней сети к внутренним ресурсам? Почему бы не использовать замечательный сервис для кросс-запросов между VLAN (представив что один – внешняя сеть, второй – приватная).
Реализация.
A. Настройка VPN-сервера на Windows 2003.
1. Добавление роли сервера: Add or remove a role
После того как мы добавили роль – переходим к настройке самого сервиса.
На шаге управления несколькими удаленными доступами Managing Multiple Remote Access, выбираем вариант использования собственной службы аутентификации (без РАДИУСа) No if you don't have RADIUS.
На завершающем шаге будет выведено предупреждение о том, что DHHCP-сервис у вас должен быть установлен и настроен.
Б. Создание политики доступа.
Один из тонких моментов, на котором хотелось бы заострить внимание.
В случае если вы попытаетесь сразу соединиться по VPN под
1. Кликаем Start, Administrative Tools, Routing and Remote Access.
2. В окне Routing and Remote Access console, раскрываем список параметров сервера в левой части и кликаем правой кнопкой на Remote Access Policies. Выбираем команду New Remote Access Policy.
Устанавливаем имя политики доступа (любое на ваш выбор) 
Метод доступа — VPN
Политика доступа на основе групп или отдельных пользователей. 
Выбор групп, которым будет предоставляться доступ
Метод аутентификации (на основе AEP, MS_CHAP2 и MS-CHAP) 
Выбор сертификата
Уровень шифрования
Завершение установки политики доступа.
Затем мы рекомендуем удалить все остальные политики, кроме заведенной вами.
Следующий момент – добавить права группе пользователей, кто будет иметь доступ извне.
Открываем окно управления пользователями AD
Для каждого пользователя устанавливаем разрешение удаленного доступа (Allow access). По умолчанию всем запрещен доступ.
Собственно на этом общая настройка закончена. Более тонкий «тюнинг» вы как администратор сможете провести исходя из собственных требований и параметров вашей сети.
ссылки по теме:
How to setup VPN and NAT on Windows Server 2003 as a routerCreating a VPN Client Remote Access Policy
VPN,
VLAN,
удаленный доступ,
Windows 2003,
сервер
31.07.2008, 2397 просмотров.