как настроить vpn сервер windows 2003. Windows 2018 r2 настройка сервера vpn


Подробная инструкция по OpenVPN v2.3.8 на Windows server 2008R2 / Хабр

Представляю подробную инструкцию по OpenVPN v2.3.8 на Windows server 2008R2 c уровнем шифрования TLS. Так же будут подробно описаны все параметры.
Настройка сервера
Для начала качаем дистрибутив с официально сайта. Запускаем установщик openvpn-install-2.3.8-I001-x86_64. В компонентах включаем следующее:

Указываем путь установки (Все дальнейшие действия будут ориентироваться на данный путь указанный в примере):

В процессе установке потребуется установить виртуальный сетевой адаптер, соглашаемся с установкой.

После успешной установки переходим в каталог “C:\Programm Files\OpenVPN” где создаем директорию “SSL” (каталог может называться как угодно, в последующих настройках будет использоваться именно этот каталог), в данном каталоге будут располагаться сертификаты сервера, алгоритмы шифрования и проверка подлинности клиента.

Переходим в каталог “C:\Programm Files\OpenVPN\easy-rsa”, открываем с помощью notepad или notepad++ (более правильный вариант) "vars.bat" (скрипт, содержащий в себе параметры ответов для создания и генерации клиентских/серверных сертификатов и последующих настроек сервера).

В самом низу файла есть следующие параметры, которые нужно настроить под себя:

set KEY_COUNTRY=RU set KEY_PROVINCE=MO set KEY_CITY=MOSCOW set KEY_ORG=OpenVPN set [email protected] set KEY_CN=server set KEY_NAME=server set KEY_OU=OU set PKCS11_MODULE_PATH=changeme rem Параметр по умолчанию set PKCS11_PIN=1234 rem Параметр по умолчанию

Сохраняем.

В этом же каталоге “C:\Programm Files\OpenVPN\easy-rsa”, есть конфигурационный файл “openssl-1.0.0.cnf”, открываем его с помощью notepad или notepad++ (более правильный вариант) и изменяем настройку, отвечающую за срок жизни сертификатов, по умолчанию 365 дней, продлим срок жизни до 3650 дней.

default_days = 3650 # how long to certify for

Сохраняем.

Далее будем генерировать следующее:

ca.crt — Собственный доверенный сертификат (Certificate Authority — далее CA) для подписи клиентских сертификатов и для их проверки при авторизации клиента.dh2024.pem — ключ Диффи Хельмана позволяющий двум и более сторонам получить общий секретный ключserver.crt — сертификат сервераserver.key — ключ сервераta.key — дополнительный ключ для tls-аутентификации (повышение безопасности соединения), сервер и каждый клиент должны иметь копию этого ключа

Открываем командную строку и переходим в каталог “C:\Program Files\OpenVPN\easy-rsa”

cd C:\Program Files\OpenVPN\easy-rsa

Вводим команду “vars” нажимаем Enter (инициируем работу со скриптами, в случае закрытия командной строки, команду “vars” придется вводить заного)

Вводим команду “clean-all” (Очищаем каталог “C:\Program Files\OpenVPN\easy-rsa\keys” c последующим созданием файла“index.txt” (база клиентов, она же database) и “serial” (ключ))

Не закрывая командную строку, проверяем содержимое каталога “ C:\Program Files\OpenVPN\easy-rsa\keys”, должны создаться файлы “index.txt и serial”.

Вводим команду “openvpn --genkey --secret %KEY_DIR%\ta.key”

Не закрывая командную строку, проверяем содержимое каталога “ C:\Program Files\OpenVPN\easy-rsa\keys”, должен создаться файл “ta.key”.

Вводим команду “build-dh” — генерация ключа Диффи Хельмана.

Не закрывая командную строку, проверяем содержимое каталога “ C:\Program Files\OpenVPN\easy-rsa\keys”, должен создаться файл “dh2024.pem”.

Вводим команду “build-ca” — генерация ключа центра сертификации (CA) На все вопросы отвечаем по умолчанию нажатием клавиши Enter, эти параметры мы прописали в “vars.bat”

Не закрывая командную строку, проверяем содержимое каталога “ C:\Program Files\OpenVPN\easy-rsa\keys”, должны создаться файлы “ca.crt и ca.key”.

Вводим команду “build-key-server server” — генерация сертификата сервера. На вопросы Country Name, State Name, Locality Name и т.д. отвечаем по умолчанию нажатием клавиши Enter до самого конца, эти параметры мы прописали в “vars.bat”, далее будет предложено создание сертификата сроком на 3650 дней (данный параметр мы указывали в openssl-1.0.0.cnf) нажимаем “Y”, будет предложено записать сертификат сервера в базу, нажимаем “Y”.

Не закрывая командную строку, проверяем содержимое каталога “ C:\Program Files\OpenVPN\easy-rsa\keys”, должены создаться файлы “server.crt, server.key, server.csr”.

Вводим команду “build-key revokecrt” — команда для создания пользовательского сертификата, но в данном случае мы создаем произвольный сертификат “revokecrt” для последующей генерации файла “crl.pem”, который отвечает за проверку и последующий отзыв сертификатов. Теоретически данную процедуру можно проделать в самом конце и даже жить без нее, но тогда не сможем отзывать сертификаты и конфигурационный файл “server.ovpn” будет выглядеть иначе.

На вопросы Country Name, State Name, Locality Name и т.д. отвечаем по умолчанию нажатием клавиши Enter до вопросов Common Name и Name, на эти вопросы нужно отвечать согласно названию создаваемого сертификата пользователя, в нашем случае это произвольный сертификат “revokecrt” на оставшиеся вопросы нажимаем Enter, далее будет предложено создание сертификата сроком на 3650 дней (данный параметр мы указывали в openssl-1.0.0.cnf) нажимаем “Y”, будет предложено записать сертификат сервера в базу, нажимаем “Y”.

Не закрывая командную строку, проверяем содержимое каталога “ C:\Program Files\OpenVPN\easy-rsa\keys”, должны создаться файлы “revokecrt.crt, revokecrt.key, revokecrt.csr”

Вводим команду “revoke-full revokecrt” – команда отвечает за отзыв сертификата и последующего создания файла “crl.pem”

Не закрывая командную строку, проверяем содержимое каталога “ C:\Program Files\OpenVPN\easy-rsa\keys”, должен создаться файл “crl.pem”

Теперь создадим сертификат пользователя, аналогично сертификату “revokecrt” см. выше. Вводим команду “build-key user1” – создаем сертификат пользователя с именем user1

.

На данном этапе работа с консолью закончена, можно закрыть окно и проверить содержимое каталога “ C:\Program Files\OpenVPN\easy-rsa\keys”, должны создаться файлы “user1.crt, user1.key, user1.csr”

Рекомендую создать папку “Clients” в любом удобном для Вас месте и скопировать туда необходимые файлы для передачи пользователям:

1 — ca.crt2 — user1.crt 3 — user1.key 4 — ta.key

Также хочу обратить Ваше внимание на то, что содержимое папки “keys” удалять нельзя, при создании пользовательских сертификатов или любых изменениях в консоли, делайте копию данного каталога во избежание потерь или случайных генераций сертификатов сервера и обновления базы данных.

Копируем файлы сервера в раннее созданную папку “ssl” в каталоге “ C:\Program Files\OpenVPN\ssl”:

1 — ca.crt 2 — server.crt 3 — server.key 4 — dh2024.pem 5 — ta.key

Переходим в каталог “C:\Program Files\OpenVPN\config” и создадим файл конфигурации сервера “server.ovpn” со следующим содержимым:

# Создаем маршрутизируемый IP туннель. dev tun # Указываем протокол для подключения. proto udp # Указываем порт на котором будем слушать. port 1194 # Указываем что это TLS сервер. tls-server # Указываем путь к доверенному сертификату. ca «C:\\Program Files\\OpenVPN\\ssl\\ca.crt» # Указываем путь к сертификату сервера. cert «C:\\Program Files\\OpenVPN\\ssl\\Server.crt» # Указываем путь к ключу сервера. key «C:\\Program Files\\OpenVPN\\ssl\\Server.key» # Указываем путь к ключю Диффи Хельмана dh «C:\\Program Files\\OpenVPN\\ssl\\dh2024.pem» # Указываем адресацию сети. server 10.8.0.0 255.255.255.0 # Указываем алгоритм шифрования должен быть одинаковый клиент/сервер. cipher AES-128-CBC # Указываем не перечитавать файлы ключей при перезапуске туннеля. persist-key # Указываем путь к ключу безопасности и устанавливаем параметр сервера 0 tls-auth «C:\\Program Files\\OpenVPN\\ssl\\ta.key» 0 # Разрешаем общаться клиентам внутри тоннеля. client-to-client # Указываем каталог с описаниями конфигураций каждого из клиентов. client-config-dir «C:\\Program Files\\OpenVPN\\ccd» # Указываем файл с описанием сетей между клиентом и сервером. ifconfig-pool-persist «C:\\Program Files\\OpenVPN\\ccd\\ipp.txt» # Указывает сверку по отозванным сертификатам. crl-verify «C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\crl.pem» # Указываем путь к логу со статусом. status «C:\\Program Files\\OpenVPN\\log\\logopenvpn-status.log» # Указываем путь к логу. log «C:\\Program Files\\OpenVPN\\log\\openvpn.log» # Указывает MTU для туннеля, должны быть одинаковые параметры клиент/сервер. tun-mtu 1500 # Включаем сжатие. comp-lzo # Устранение проблем с передачей MTU. mssfix # Указывает отсылать ping на удаленный конец тунеля после указанных n-секунд, # если по туннелю не передавался никакой трафик. # Указывает, если в течении 120 секунд не было получено ни одного пакета, # то туннель будет перезапущен. keepalive 10 120 # Указываем уровень логирования. verb 3

Сохраняем.

На сервере где будет крутиться OpenVPN необходимо проделать следующее:

1 – Если вы используете встроенный Брандмауэр Windows, создайте разрешающее правило для входящих и исходящих подключений по протоколу UDP на порт 1194.

2 – В службах сервера найдите OpenVPN Service и установите запуск на автоматический, это позволит автоматически запускаться сервису при перезагрузке сервера.

C рабочего стола сервера запускаем “OpenVPN GUI”, в трее дважды щелкаем по значку “OpenVPN GUI” откроется окно лога, если после запуска сервиса в пункте 2 нечего не произошло, нажимаем слева внизу подключиться и если все хорошо, мы должны увидеть следующее содержимое:

Сервис VPN на сервере запущен и готов принимать клиентов.

Настройка клиента
Запускаем ранее скаченный установщик openvpn-install-2.3.8-I001-x86_64, выбор компонентов оставляем по умолчанию, путь сохраняется прежний.

После успешной установки переходим в каталог “C:\Program Files\OpenVPN\config” и создаем файл конфигурации клиента “test.ovpn” со следующим содержимым:

# Создаем маршрутизируемый IP туннель. dev tun # Указываем протокол для подключения. proto udp # Указываем IP аддрес сервера с портом. remote X.X.X.X 1194 # Указываем задержку в секундах для построения маршрута. route-delay 3 # Указываем чтобы клиент забирал информацию о маршрутизации с сервера. client # Указываем что мы являемся TLS клиентом. tls-client # Параметр защиты от MitM атак. ns-cert-type server # Указываем путь к доверенному сертификату. ca «C:\\Program Files\\OpenVPN\\ssl\\ca.crt» # Указываем путь к клиентскому сертификату. cert «C:\\Program Files\\OpenVPN\\ssl\\user1.crt» # Указываем путь к клиентскому ключу. key «C:\\Program Files\\OpenVPN\\ssl\\user1.key» # Указываем путь к ключу безопасности и устанавливаем параметр клиента 1 tls-auth «C:\\Program Files\\OpenVPN\\ssl\\ta.key» 1 # Указываем алгоритм шифрования должен быть одинаковый клиент/сервер. cipher AES-128-CBC # Включаем сжатие. comp-lzo # Устранение проблем с передачей MTU. mssfix # Указывает MTU для туннеля, должны быть одинаковые параметры клиент/сервер. tun-mtu 1500 # Указываем, сли в течении 60 секунд не было получено ни одного пакета, # то туннель будет перезапущен. ping-restart 60 # Указывает отсылать ping на удаленный конец тунеля после указанных n-секунд, # если по туннелю не передавался никакой трафик. ping 10 # Указываем уровень логирования. verb 3

Сохраняем.

C рабочего стола запускаем “OpenVPN GUI”, в трее дважды щелкаем по значку “OpenVPN”, откроется окно лога, нажимаем подключиться и если все хорошо, то мы увидим следующее:

Запускаем пинг на 10.8.0.1 и видим что сеть доступна (10.8.0.1 адрес, который получил виртуальный сетевой адаптер на сервере). На сервере мы увидим лог подключения:

Собственно на этом этапе можно закончить и все в дальнейшем будет работать. Но я хотел бы еще кое-что добавить. Для уменьшения количества файлов у клиента и добавление еще одного пункта в безопасности (пароль на подключение), можно сделать следующее, на этапе создания сертификата пользователя на сервере, выполняем команду “build-key-pkcs12 user2” вместо “build-key user1”, выполняем все аналогично первой команде, до пункта Export Password, в этом пункте необходимо указать пароль, например 12345, данный пароль по факту назначается на сертификат “user2.p12”, при попытке подключения через “OpenVPN”, программа обращается к сертификату и требует пароль (зная пароль, его можно изменить, удалить и т.д).

В таком случае, комплект для пользователя будет состоять из:

1 – user2.p12 2 – ta.key

Конфигурационный файл “test.ovpn” должны быть следующего содержания:

# Создаем маршрутизируемый IP туннель. dev tun # Указываем протокол для подключения. proto udp # Указываем IP аддрес сервера с портом. remote X.X.X.X 1194 # Указываем задержку в секундах для построения маршрута. route-delay 3 # Указываем чтобы клиент забирал информацию о маршрутизации с сервера. client # Указываем что мы являемся TLS клиентом. tls-client # Параметр защиты от MitM атак. ns-cert-type server # Указываем путь к сертификату. pkcs12 «C:\\Program Files\\OpenVPN\\ssl\\user2.p12» # Указываем путь к ключу безопасности и устанавливаем параметр клиента 1 tls-auth «C:\\Program Files\\OpenVPN\\ssl\\ta.key» 1 # Указываем алгоритм шифрования должен быть одинаковый клиент/сервер. cipher AES-128-CBC # Включаем сжатие. comp-lzo # Устранение проблем с передачей MTU. mssfix # Указывает MTU для туннеля, должны быть одинаковые параметры клиент/сервер. tun-mtu 1500 # Указываем, сли в течении 60 секунд не было получено ни одного пакета, # то туннель будет перезапущен. ping-restart 60 # Указывает отсылать ping на удаленный конец тунеля после указанных n-секунд, # если по туннелю не передавался никакой трафик. ping 10 # Указываем уровень логирования. verb 3

Сохраняем.

Пробуем подключиться, вводим пароль 12345

Если все хорошо видим следующее:

Ну и на последок, как отозвать сертификат пользователя и вообще посмотреть список выданных сертификатов. Сам список храниться по следующему пути “C:\Program Files\OpenVPN\easy-rsa\keys\index.txt”

Для того чтобы отозвать сертификат, заходим в командную строку. Переходим в каталог “C:\Programm Files\OpenVPN\easy-rsa”:

cd C:\Program Files\OpenVPN\easy-rsa

Вводим команду “vars” нажимаем Enter (инициируем работу со скриптами). Вводим команду для отзыва сертификата пользователя “revoke-full user2” (указываем название заведенного раннее пользователя).

После заходим в “index.txt” “C:\Program Files\OpenVPN\easy-rsa\keys\index.txt” и видим, что сертификат отозван “R”.

Не готов сказать на 100%, но судя по описанию, файл “index.txt” проверяется каждый час, соответственно через час, сертификат будет заблокирован, ну или просто достаточно перезапустить сервис на сервере.

Еще рекомендую использовать отдельную учетную запись для службы “OpenVPN Service” и в случае если пользователи будут работать с этим сервером, где развернут VPN, обязательно уберите права у простых пользователей на каталог “C:\Program Files\OpenVPN”.

Всем спасибо, надеюсь, данная статься поможет многим, кто сталкивается с вопросами и не находил подходящих ответов, разжевал как мог.

habr.com

VPN сервер PPTP для платформы Windows Server 2008 / 2008R2 (Настройка VPN Часть 1)

Если в случае с *nix системами мы все делаем в командной строке и статья состоит из команд, то для Windows Server статья будет с картинками . В предыдущей статье мы настроили PPTP VPN на Linux Server. Теперь настроим PPTP VPN на сервере под управлением Windows Server 2008R2.

На самом деле все что в этой статье написано, будет так же работать и настраиваться на Windows Server 2003 и 2008 (Хотя и будет выглядеть в некоторых местах по другому.):) Так что можно сказать что это мульти-мануал. Я не буду рассматривать поднятие роли Службы политики сети и доступа так как там нет ничего сложного. Так что далее считаем что данная служба у Вас поднята и работает (Например раздает интернет).

Начнем. Открывваем Диспетчер сервера — Роли — Маршрутизация и удлаенный доступ, щелкаем по роли ПКМ и выбираем Свойства, на вкладке Общие ставим галочку в полях IPv4-маршрутизатор, выбираем локальной сети и вызова по требованию, и IPv4-сервер удаленного доступа:

Теперь нам необходимо настроить Безопасность подключений. Для этого перейдем на вкладку Безопасность и выберем Методы проверки подлинности, поставьте галочки на Протокол EAP и Шифрованная проверка (Microsoft, версия 2, MS-CHAP v2):

Далее перейдем на вкладку IPv4, там укажем какой интерфейс будет принимать подключения VPN и пул адресов для выдачи VPN клиентам (Интерфейсом выставьте Разрешить RAS выбирать адаптер):

После нажатия на кнопку ОК служба будет перезапущена, и роль VPN сервера будет добавлена. Теперь у вас появился новый пункт под названием Порты. Теперь нам необходимо отключить не нужные нам службы и настроить PPTP. Нажмине на пункт Порты — ПКМ и выберите свойства. В открывшемся окне выберите WAN Miniport (PPTP) и нажмите настроить внизу формы. Выставьте все как на скриншоте ниже:

Максимальное число портов, это количество клиентов которые могут к Вам подключится. Даже если пул адресов больше этого значения, сервер будет отвергать подключения свыше этого числа.

Теперь укажем каким пользователям разрешено подключатся к данному серверу по VPN. Перейдите в Диспетчере сервера: Конфигурация — Локальные пользователи и группы — Пользователи — Выберите пользователя и нажмите ПКМ — Свойства. На вкладке Входящие звонки — Права доступа к сети — выставьте Разрешить доступ. (Если Ваш сервер работает под управлением Active Directory, то настройки необходимо вводить в соответствующей остастке)

На этом настройка закончена. Можете создать подключение и попробовать подключится. Что бы посмотреть подключенных клиентов на данный момент используйте оснастку Маршрутизация и удаленный доступ — Клиенты Удаленного доступа. Так же для контроля и диагностики используйте журнал событий Служб политики сети и доступа.

Хотелось бы напомнить, что подключение с использованием PPTP VPN являются не самыми безопасными, так как авторизация происходит по паре Логин — Пароль. В следующих статьях я расскажу как настроить L2TP соединение по предварительному ключу, что позволит существенно повысить безопасность VPN соединения и использовать IPSec.

Не забудьте пробросить порт на Вашем маршрутизаторе и открыть его в FireWall:

  • PPTP — TCP порт 1723 (Прием\Отправка)

melfis.ru

как настроить vpn сервер windows 2003

Всем доброго времени суток. У меня такая проблема. Мне начальство поставило задачу, в кратчайшие сроки сделать VPN-сеть, так чтобы два наших филиала могли работать как бы по локальной сети, и чтобы был центральный сервер. А я с VPN никогда дела не имел и боюсь, пока сам буду разбираться, уже все дедлайны пройдут, и мне несдобровать. Подскажите плз, как настроить vpn сервер windows 2003! Буду очень признателен за любую помощь!

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

Процесс разобьем на несколько этапов. Итак, приступим.

Во-первых, на всякий случай напомним, что PPTP-сервер для защищенного подключения других рабочих станций можно настроить только для серверных версий Windows 2000/2003. «Обычный» Windows для этих целей не подходит.

Система настраивается как сервер удаленного доступа (RAS) в службе маршрутизации и удаленного доступа (RRAS).

 

Этап 1. Создание VPN сервера.

1. Открываем службу "Маршрутизация и удаленный доступ" и заходим в свойства сервера.

2. Выставляем параметр «локальной сети и вызова по требованию" и "сервер удаленного доступа" как показано на рисунке.

3. Заходим на вкладку «IP», выбираем название внутреннего адаптера и создаем статический пул адресов, который будет отличаться от внутреннего, так как внутренний будет присваиваться VPN-клиентам.

4. Дальше на вкладке «PPP» снимаем галочку с пункта «Многоканальные подключения». Это должно ускорить работу интернета.

5. Во вкладке «Журнал событий» выставляем параметр «вести журнал всех событий»

 

Этап 2. Конфигурация портов.

1. Заходим в свойства пункта «Порты». RRAS по умолчанию создаст пять портов PPTP, пять портов L2TP и один «Прямой параллельный». Для того, чтобы сервер работал стабильно, желательно удалить лишние порты (прямой параллельный, L2TP, и прочие) и создать нужное количество портов, количество которых должно быть большим, чем число одновременных подключений.

2. Теперь нужно удалить порты WAN(L2TP)

3. Выставляем нужное число PPTP портов (количество портов должно быть больше, чем число предполагаемых одновременных подключений).

4. В результате откроется новое окно

 

Этап 3. Конфигурация NAT.

1. Заходим в "IP-маршрутизация" / "NAT-преобразование сетевых адресов". Если вы хотели дать доступ лишь по VPN соединению, тогда нужно удалить внутренний интерфейс, если нет, тогда оставьте все как есть.

2. Дальше нужно добавить RAS интерфейс. В командной строке набираем "netsh routing ip nat add interface Внутренний (в английском Windows - " internal") private", как на рисунке ниже. Также крайне полезно запретить привязку протокола NetBios к интерфейсу Внутренний (internal), в том случае, если интерфейс активен. Это имеет большое значение в том случае, если RAS-сервер используется для подключения клиентов по Dial-up (дозвон) и поможет устранить некоторые проблемы при работе сервера в сети. Если же NetBios на этом интерфейсе разрешен, то сервер будет производить регистрацию своих NetBios-имен с IP-адресами интерфейсов, к которым установлена привязка этой службы. Появление IP- адреса в этих регистрациях интерфейса Внутренний (internal) может создать проблемы в работе.

Редактируем реестр. В разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRemoteAccessParametersIp добавляем параметр DisableNetbiosOverTcpip типа DWORD и устанавливаем значение - 1. После этого службу надо будет перезапустить.

3. RAS интерфейс появится автоматически.

 

Этап 4. Создание клиентов.

1. Заходим в "Управление компьютером" - "Локальные пользователи и группы" - "Пользователи"

2. Создаем пользователя и заходим на вкладку "Входящие звонки".

3. Разрешаем пользователю доступ, он у нас будет тестовым. Другим пользователям рекомендуется указывать их IP-адрес в пункте "Статический IP-адрес пользователя"

 

Этап 5. Настройка VPN соединения.

1. Заходим в группу "Политика удаленного доступа" - "Разрешить доступ,если разрешены входящие подключения" и открываем свойства пункта.

2. Жмем кнопку "Изменить профиль..."

3. Заходим на вкладку "Проверка подлинности"

4. Оставляем параметры проверки подлинности MS-CHAP для Windows и CHAP для других операционных систем.

5. Заходим на вкладку «Шифрование» и выбираем параметры шифрования. Все настройки, которые вводим при настройке VPN-соединений у клиентов должны быть идентичны.

Перезапускаем сервер.

Вот и все! Ваша задача выполнена.

www.socialit.ru

Виртуализация сети в Hyper-V. Настройка HNV-шлюза на базе Windows Server 2012 R2 / Блог компании Microsoft / Хабр

В нескольких предыдущих постах, посвященных технологии виртуализации сети (Hyper-V Network Virtualization, HNV), я рассказал об архитектуре, настройках, а также новых возможностях HNV в Windows Server 2012 R2. Сегодня речь пойдет о, пожалуй, самой сложной теме – построении HNV-шлюза на базе Windows Server 2012 R2 для предоставления виртуализованным сетевым сегментам доступа во внешний мир. Будет много скриншотов.

В большинстве случаев виртуальным машинам (ВМ), развернутым в виртуализованных сетях, необходимо взаимодействие с внешним миром – для связи с другими объектами ЦОД-а, для выхода в Интернет, для доступа к корпоративной сети компании, которая расположила в ЦОД-е эти самые ВМ и пр. Применительно к технологии HNV внешним миром является все что угодно, находящееся за пределами виртуализованной сети. И прежде чем двигаться дальше, необходимо лишний раз определиться с терминологией, которая за два года существования HNV слегка видоизменилась.

Итак, определяющим понятием HNV является сеть заказчика (Customer Network), обладающая уникальным идентификатором Routing Domain ID (RDID). Это и есть та самая виртуализованная сеть. Для Customer Network существует несколько синонимов, в зависимости от того, каким инструментом вы пользуетесь:
  • в VMM это VM Network;
  • в PowerShell это Routing Domain;
  • во многих статьях и блогах это Tenant или Tenant Virtual Network.
Но все эти термины суть Customer Network. Каждая сеть заказчика состоит из одной или более виртуальных подсетей (Virtual Subnet), и у каждой виртуальной подсети есть свой уникальный 24-битный идентификатор VSID. Маршрутизация пакетов между ВМ, принадлежащими одной сети заказчика, осуществляется автоматически, независимо от того, расположены ли эти машины в одной виртуальной подсети или в разных, на одном физическом хосте, или на разных. А вот если нужна связь с внешним миром, то есть необходимо передать пакеты за пределы Customer Network, то должен быть настроен HNV-шлюз (HNV Gateway, HNVGW). HNV-шлюз может представлять собой либо готовое аппаратное решение, либо хост на базе Windows Server 2012 R2. На текущий момент на рынке доступны три аппаратных решения: В этом посте я сосредоточусь на создании HNV-шлюза на базе Windows Server 2012 R2, при этом управление HNV в моей демонстрационной сети, в том числе настройка шлюза, будет осуществляться с помощью System Center 2012 R2 Virtual Machine Manager (VMM). Используя далее сокращение VMM, я предполагаю именно версию R2, если явно не указано иное.

Напомню, что строго говоря, HNV – это технология Windows Server 2012 и выше, и она может быть настроена без VMM, просто с помощью командлетов PowerShell. Привожу ссылки на примеры соответствующих скриптов без использования и с использованием HNV-шлюза. Но в реальных сценариях для управления HNV применяется VMM, который берет на себя роль централизованного хранения и распространения политик HNV.

Архитектурно HNV-шлюз на базе Windows Server 2012 R2 представляет собою физический хост, на котором запущена одна или несколько ВМ, выполняющих маршрутизацию пакетов из виртуализованных сетей во внешний мир и обратно. Обращаю внимание, это именно физический хост. Реализовать HNV-шлюз просто в виде виртуалки не получится уже хотя бы потому, что для инкапсуляции пакетов (см. пост о концепции HNV) необходима роль Hyper-V, а вложенную виртуализацию Hyper-V не поддерживает.

Справедливости ради стоит отметить, что технически шлюз можно построить и на базе Windows Server 2012. Но при этом, во-первых, шлюз с Windows Server 2012 потребует запуска стольких ВМ, сколько у вас Customer Networks, и масштабирование такого решения затруднительно. Во-вторых, для управления таким шлюзом с помощью VMM необходимо будет написать провайдер для VMM. Использование же Windows Server 2012 R2 + System Center 2012 R2 Virtual Machine Manager – это практически готовый HNV-шлюз «из коробки». В Windows Server 2012 R2 реализован мультитенантный шлюз, позволяющий задействовать одну ВМ для маршрутизации трафика различных виртуализованных сетей, а в System Center 2012 R2 Virtual Machine Manager уже встроен провайдер для управления таким шлюзом.

Какие варианты работы HNV-шлюза существуют? Таковых два.

Private Cloud (Routing)
Первый вариант реализует маршрутизацию трафика из Customer Network в сеть ЦОД-а, причем маршрутизация может быть как прямой, так и c трансляцией адресов (NAT).

На рисунке изображена прямая маршрутизация, которая имеет смысл, если пространства CA-адресов разных тенантов (Customer Networks) не пересекаются и им нужен доступ в корпоративную сеть. Или, как на рисунке, есть только один тенант с несколькими подсетями. Для частного облака, когда тенанты, например, представляют собой виртуализованные сети различных департаментов крупного предприятия, вполне возможный вариант.

При использовании NAT каждому тенанту HNV-шлюз ставит в соответствие выделенный IP-адрес на своем внешнем интерфейсе, и все пакеты от виртуальных машин тенанта отправляются во внешний мир с этим выделенным IP в поле «IP-адрес отправителя».

Hybrid Cloud (Site to site VPN)
Второй вариант предполагает построение туннеля типа «сеть-сеть» от HNV-шлюза до необходимой точки, например, через Интернет до корпоративной сети заказчика.

Это как раз типовой хостерский сценарий, когда ВМ заказчика располагаются в ЦОД-е хостера и связываются через VPN с сетью заказчика. Технология HNV при этом позволяет заказчику сохранить настройки IP и не бояться за работоспособность софта внутри ВМ, а хостеру –расположить у себя виртуалки с нужными заказчику IP, изолируя эти виртуалки от других ВМ и не настраивая VLAN-ы.

Завершая архитектурный раздел поста, отмечу кратко в чем же заключается мультитенантность шлюза на базе Windows Server 2012 R2.

Представьте себе, что в ЦОД-е виртуализованы сети двух заказчиков, Contoso и Woodgrove, использующие абсолютно одинаковые CA-пространства: 10.0.0.0/24. Как «развести» пакеты этих заказчиков на HNV-шлюзе? Первое возможное решение – создать на шлюзе для каждого заказчика свою ВМ и указать ее в настройках соответствующей сети заказчика в качестве default gateway. Таким образом, пакеты, направленные во внешний мир из Contoso, всегда будут приходить на сетевой интерфейс одной ВМ шлюза, пакеты из Woodgrove – на интерфейс второй ВМ и т. д. Как упоминалось, шлюз на базе Windows Server 2012 именно такой подход и использовал бы.

В Windows Server 2012 R2 для маршрутизации появилась возможность использовать так называемые ячейки (compartments). В виртуальной машине для каждого тенанта создается некий объект «ячейка» (compartment), в которую включаются виртуальные сетевые интерфейсы, IP-адреса, таблица маршрутизации, ARP-таблица и пр. Элементы одной ячейки изолированы от элементов другой ячейки. Маршрутизация пакетов от Contoso, таким образом, осуществляется в рамках соответствующей ячейки и не пересекается, не влияет на маршрутизацию пакетов Woodgrove в другой ячейке, даже если записи в таблицах маршрутизации этих ячеек выглядят одинаково. Такой подход позволяет использовать одну ВМ для маршрутизации пакетов разных тенантов без каких-либо конфликтов.

Как видно на рис. выше, существует ячейка по умолчанию (default compartment), которая включает в себя сетевые настройки, задаваемые при создании ВМ, и две ячейки для тенантов, появившиеся в процессе настройки HNV-шлюза.

Подкрепившись теорией, перейдем непосредственно к созданию шлюза. Для простоты я рассмотрю вариант шлюза без кластеризации, хотя понятно, что в реальном ЦОД-е такой важный элемент виртуализации предполагает работу в режиме высокой доступности. Детальный документ о том, как сделать HNV-шлюз высокодоступным можно найти здесь. Основные шаги по созданию шлюза включают в себя следующее:
  • настройка логических сетей и сетей ВМ;
  • настройка хоста для роли шлюза
  • подготовка ВМ для шлюза
  • добавление шлюза в VMM
  • настройка шлюза для конкретных сетей ВМ
Давайте по порядку.
Настройка логических сетей и сетей ВМ
Этот пункт довольно подробно описан в одном из предыдущих постов, поэтому покажу лишь, как логические и виртуальные сети выглядят у меня в лабораторном свечном ЦОД-ике Contoso.

Для нашей задачи нужны три логические сети: внешний сегмент (Contoso_External_LN01), сеть для управления шлюзом (Contoso_Management_LN01) и сеть (Contoso_HNV_LN01), поверх которой собственно создаются виртуализованные сети. IP-пул сети Contoso_HNV_LN01 задает PA-пространство, а в свойствах этой сети обязательно должен быть помечен чекбокс, разрешающий использование технологии HNV.

Сети ВМ (VM Networks, они же сети заказчиков, они же Customer Networks) выглядят так:

Вы видите две сети ВМ для компаний Adatum и Fabrikam, использующие пересекающееся адресное пространство (10.30.1.0/24). В колонке Gateway Connection видно, что пока ни одна из сетей ВМ не использует шлюз.

Настройка хоста для роли шлюза
В общем-то любой хост с Windows Server 2012 R2, которым управляет VMM, можно настроить в качестве HNV-шлюза. По-хорошему, у этого хоста должно быть несколько физических сетевых интерфейсов, смотрящих в нужные сегменты (внешний, сегмент управления, сегмент HNV). Однако из архитектурной части поста следует, что собственно маршрутизацией пакетов в шлюзе занимается ВМ. Поэтому сколько физических сетевушек должно быть в хосте, выполняющем роль шлюза, определяется вопросами производительности, надежности (можно использовать тиминг, например) и, конечно, логикой того, как и куда вы хотите отправлять пакеты. Конкретно в моем стенде хост-шлюз содержит всего один физический сетевой интерфейс, мне этого пока вполне хватает для экспериментов.

Но в любом случае, в свойствах хоста, выбранного на роль шлюза, следует установить вот этот чекбокс

Он предотвратит запуск на шлюзе любых «рядовых» ВМ, предполагающих использование HNV. В реальной ситуации вы вообще вряд ли будете запускать на шлюзе еще что-то, кроме компонент самого шлюза.

Подготовка ВМ для шлюза
Теперь поговорим о той самой ВМ, которая будет осуществлять маршрутизацию пакетов с помощью compartments. Проще всего развернуть ее с помощью сервисного шаблона (service template). В этом случае можно сразу же сказать VMM, чтобы при развертывании ВМ в ней была поднята служба RRAS, чтобы для высокой доступности таких машин было поднято две на кластере и пр. Но, во-первых, мы договорились сделать все руками, чтобы лучше понять, что происходит, во-вторых, сервисные шаблоны не поддерживают ВМ второго поколения, которые разворачиваются, да и работают пошустрее.

Поэтому я создал шаблон ВМ второго поколения на базе VHDX с образом Windows Server 2012 R2. В этом процессе нет ничего необычного, покажу лишь сетевые настройки в шаблоне.

Вы видите три виртуальных сетевых адаптера (vNIC): один подключен ко внешней сети (см. рис.), второй к сети управления, третий можно в шаблоне оставить в состоянии Not Connected, а в процессе или сразу после развертывания ВМ, подключить его через виртуальный коммутатор (Hyper-V Extensible Switch) к сети, в которой используется HNV. Обычно при описании шлюза эту сеть называют Backend.

Разворачиваем теперь ВМ на основе этого шаблона на хост, который мы выбрали и настроили в качестве шлюза в предыдущем пункте. Обратите внимание на имя, которые вы дадите этой ВМ. Оно понадобится впоследствии при конфигурации шлюза.

После того, как ВМ развернута, зайдем в нее, подключим сетевой адаптер к Backend-сети, отключим Firewall и для удобства переименуем сетевые адаптеры так, чтобы имена отражали их предназначение, например

Теперь в ВМ (я назвал ее GatewayVM01) необходимо установить роль Remote Access. Делается это стандартно через Server Manager, Manage -> Add Roles and Features. Нажимаем Next, пока не дойдем до выбора роли, выбираем Remote Access, затем снова Next, пока не дойдем до Role Services, где помечаем две службы

Жмем до упора Next и Install. После завершения установки нажимаем Open the Getting Started Wizard

и в окне открывшегося мастера выбираем Deploy VPN only.

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

Тем самым мы настроили хост и соответствующую ВМ, и теперь все готово, чтобы добавить эту «заготовку» в качестве HNV-шлюза в консоль VMM для последующей конфигурации.

Добавление шлюза в VMM
В консоли VMM переходим в раздел Fabric, нажимаем Add Resources и выбираем Network Service. На первой странице мастера даем шлюзу осмысленное имя и описание

Затем выбираем Microsoft в качестве производителя и Microsoft Windows Server Gateway в списке моделей

На странице Credentials необходимо выбрать Run As account для доступа к устройству. Эта запись должна иметь административные права на ВМ шлюза. В нашем случае ВМ не включалась в домен, поэтому указываем запись с паролем локального администратора. Если в VMM такой записи нет, ее тут же можно создать.

Самый, пожалуй, интересный параметр – строка подключения (Connection String), в которой с помощью трех параметров VMHost, GatewayVM и BackendSwitch необходимо указать имя хоста и ВМ «заготовки» и имя виртуального коммутатора на хосте, через который ВМ подключается к Backend-сети. Обратите внимание, что в строке подключения нет пробелов, разделителем служит точка с запятой (;).

Кроме трех перечисленных выше существует еще несколько параметров, описание которых можно найти здесь (см. п.16). В частности, DirectRoutingMode=True настроит шлюз на работу в режиме прямой маршрутизации.

При заданной выше строке подключения сертификаты не используются, поэтому на странице Certificates просто нажимаем Next.

На странице Provider нажимаем кнопку Test и убеждаемся, что все тесты проходят без ошибок.

На странице Host Group указываем, какие хостовые группы могут пользоваться данным шлюзом

Проверяем настройки на станице Summary, и если все правильно, жмем Finish.

Проверьте, что соответствующие задачи в разделе Jobs успешно завершены. Остается настроить сетевые интерфейсы только что созданного HNV-шлюза. В разделе Fabric -> Networking -> Network Service консоли VMM щелкните правой кнопкой мыши по шлюзу, выберите Properties и перейдите на закладку Connectivity. Здесь нужно включить Front End Connection и Back End Connection и выбрать правильные сетевые адаптеры ВМ и соответствующие сайты логических подсетей.

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

Дело за малым, настроить требуемые сети ВМ на использование созданного HNV-шлюза.

Настройка шлюза для конкретных сетей ВМ
В консоли VMM переходим в раздел VMs and Services, щелкаем VM Networks, выбираем нужную сеть ВМ и нажимаем кнопку Properties. Идем на закладку Connectivity и разрешаем использование HNV-шлюза этой сетью. Для сети Fabrikam, например, включаем NAT

VMM автоматически выделит из IP-пула логической сети, ассоциированной с внешним интерфейсом HNV-шлюза, адрес, в который будут транслироваться адреса отправителей всех пакетов из сети Fabrikam. Но вы можете вручную выбрать IP из пула, указав его в поле IP address

Закрыв окно свойств, в нижней части консоли VMM можно увидеть, какой конкретно внешний адрес используется для данной сети ВМ

Аналогично поступаем для сети Adatum и всех других виртуализованных сетей, которым нужен внешний доступ с поддержкой NAT.

Теперь давайте посмотрим, как настраивается подключение ко внешнему миру через VPN, то есть реализуем сценарий Hybrid Cloud (Site to site VPN). При этом я предполагаю, что VPN-устройство в корпоративной сети уже настроено, использует протокол IKEv2 и аутентификацию на основе Preshared Key, что типично для туннелей «сеть-сеть», и его внешний IP нам известен.

В свойствах той же сети ВМ Fabrikam на уже знакомой закладке Connectivity помечаем самый верхний чекбокс

При этом в окне свойств сети ВМ появляется новая закладка VPN Connections, где нужно кнопкой Add добавить VPN-подключение, указать его имя и IP-адрес VPN-устройства, до которого строится туннель

В разделе Authentication указываем подготовленную запись Run As account с прописанным Preshared Key,

и в разделе Routes прописываем нужные маршруты, например

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

Можно посмотреть на расширенные настройки в Advanced, скажем поменять VPN-протокол или параметры шифрования, но если ничего этого не требуется, то жмем ОК. В нижней части консоли VMM для настроенной сети ВМ теперь будет отображаться что-то вроде

Как только из любой ВМ, запущенной в виртуализованной сети Fabrikam, попробуем сделать ping на адрес из подсети, указанной с настройках VPN-туннеля, например, 10.30.50.101, HNV-шлюз поднимет туннель и установит связь с заданным VPN-устройством, а через него с корпоративной сетью

Дело сделано!

Если информации из этого поста оказалось недостаточно, можете воспользоваться подробным пошаговым руководством для создания лабораторного стенда.

Остается открытым один вопрос, как собственно происходит маршрутизация пакетов при использовании HNV-шлюза, как это выглядит внутри шлюза? Но это уже уровень сложности 400 для особо искушенных. :) Хотя, если таковые найдутся, готов написать.

Надеюсь, материал был полезен.

Спасибо!

habr.com

Windows Server 2008 R2 в качестве VPN-сервера. « Blog of Khlebalin Dmitriy

Windows Server 2008 R2 в качестве VPN-сервера.

Итак, в рамках нашего текущего проекта по реконструкции сети, было принято решение «задраить люки», то есть отказаться от удаленных подключений всякими ТимВьюверами, Хамачами, Р-админами и прочими клиентами, а пересадить всех на VPN. В ходе чего ASA была предоставлена возможность подключаться к сети Cisco AnyConnect, виндовым подключением по L2TP, ну и как альтернативу, вышеперечисленным и не всегда доступным подключениям, решили поставить PPTP на винде.

Соответственно для того чтоб это заработало, для начала надо разрешить доступ на фаерволе, в моем случае это ASA, по этому создаем правила на ней.

В акцесс листах разрешаем

 

В правилах NAT следующие правила

 

 

khlebalin.wordpress.com