Openvpn весь трафик через туннель windows

Глава 5. Расширенные сценарии развертывания в tun режиме

Базовая конфигурация VPN относительно проста, но интеграция этого VPN с остальной частью сети является гораздо более сложной задачей. В этой главе мы рассмотрим некоторые расширенные сценарии развертывания OpenVPN, выходящие за рамки базовой установки и настройки VPN. Некоторые из этих сценариев основаны на реальных вопросах пользователей из списков рассылки OpenVPN, форума и канала IRC. Мы рассмотрим следующие темы:

• Включение (Windows) общего доступа к файлам через VPN
• Интеграция с механизмами внутренней аутентификации, такими как PAM и LDAP
• Фильтрация VPN-трафика (межсетевой экран)
• Маршрутизация на основе политик для повышения безопасности
• Работа с общедоступными и частными сетевыми адаптерами в Windows 7
• Использование OpenVPN с прокси HTTP или SOCKS

Примеры, представленные в этой главе, основаны на примерах из предыдущей главы, Глава 4, Режим клиент/сервер с устройствами tun. В частности, будут использоваться базовые файлы конфигурации производственного уровня и добавление дополнительных разделов безопасности.

Включение общего доступа к файлам через VPN

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

Одним из наиболее распространенных вариантов использования VPN является предоставление удаленным работникам доступа к ресурсам в корпоративной сети. Файлы в корпоративной сети часто хранятся на файловом сервере под управлением Windows. Для просмотра общих файловых ресурсов Windows с использованием сетевых имен потребуется сервер WINS.

Опять же, очень распространенная схема доступа к ресурсам в сети на стороне сервера изображена здесь:

Локальная сеть на стороне сервера — 192.168.122.0/24, и в этой подсети расположены ресурсы, к которым VPN-клиенты должны получить доступ.

Мы начнем с файла basic-udp-server.conf и добавим три строки:

proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
topology subnet
persist-key
persist-tunkeepalive 10 60

remote-cert-tls client
tls-auth  /etc/openvpn/movpn/ta.key 0
dh        /etc/openvpn/movpn/dh2048.pem
ca        /etc/openvpn/movpn/movpn-ca.crt
cert      /etc/openvpn/movpn/server.crt
key       /etc/openvpn/movpn/server.key

user nobody
group nobody # use 'group nogroup' on Debian/Ubuntu

verb 3
daemon
log-append /var/log/openvpn.log

push "route 192.168.122.0 255.255.255.0"
push "redirect-gateway"
push "dhcp-option WINS 192.168.122.1"

Сохраните этот файл как movpn-05-01-server.conf.

Первая дополнительная строка добавляет серверную локальную сеть в набор сетей, которые необходимо маршрутизировать через VPN. Вторая строка — перенаправляет весь сетевой трафик через VPN-туннель. Эта строка необходима, чтобы гарантировать, что адаптер OpenVPN TAP-Win считается приватным. Общий доступ к файлам возможен только при использовании приватных сетевых адаптеров (в отличие от общественных сетевых адаптеров). Последняя добавленная строка указывает серверу OpenVPN передать дополнительную опцию DHCP, содержащую IP-адрес сервера WINS, клиенту OpenVPN.

Мы запускаем сервер OpenVPN, используя этот файл конфигурации. Снова используем машину на базе Windows 7 Professional 64 бит в качестве клиента OpenVPN, на которой установлена версия OpenVPN 2.3.5-I001 X86_64.

Запустите приложение OpenVPN GUI, выберите конфигурацию basic-udp-client и нажмите Connect.

Как мы делали в примере из раздела Маршрутизация и маршрутизация на стороне сервера в предыдущей главе, мы гарантируем, что сервер OpenVPN пересылает IP-трафик и что на шлюзе на стороне сервера добавлен дополнительный маршрут для правильной маршрутизации VPN-трафика обратно через VPN-сервер.

После того, как VPN-соединение было установлено мы переходим к Центру управления сетями и общим доступом чтобы убедиться что адаптер TAP (названный vpn0 в следующем скриншоте) отмечен как необщественный и является частью либо Домашней, либо Рабочей сети/группы/места/. Если адаптер TAP помечен как общественный — это означает, что Windows не доверяет трафику, поступающему от этого адаптера и будет отказывать в обмене файлами через VPN. В разделе этой главы Сетевые расположения Windows — общие и частные, мы подробно рассмотрим эту тему.

Как мы видим, соединение OpenVPN vpn0 является частью Рабочей сети — это означает что общий доступ к файлам разрешен.

Первый способ проверить работает ли общий доступ к файлам — это перейти к файловому серверу, используя его IP-адрес. Вы можете сделать это, открыв окно командной строки и введя следующие строки:

C:> start \192.168.122.1

На этом этапе появится диалоговое окно аутентификации.

Введите свои учетные данные для файлового сервера. Теперь откроется окно проводника Windows с содержимым удаленных общих ресурсов.

Использование имен NetBIOS

Вместо просмотра файловых ресурсов по их IP-адресам гораздо удобнее использовать сетевое имя файлового сервера Windows. Для этого клиенту Windows необходим адрес сервера WINS. Строка push "dhcp-option WINS 192.168.122.1" передает этот адрес WINS для всех подключающихся клиентов OpenVPN. После того, как VPN-соединение установлено, мы можем проверить — используется ли соответствующий WINS-сервер, введя команду ipconfig /all в командной оболочке.

IP-адрес сервера WINS указан в строке Primary WINS Server (Основной сервер WINS), которая указывает, что Windows будет использовать этот сервер для разрешения имен WINS.

Теперь, когда Центр управления сетями и общим доступом открыт — файловый сервер будет отображаться с именем NetBIOS (FILESERVER):

Когда мы нажмем на этот значок, то увидим доступные общие ресурсы на файловом сервере:

Когда мы снова нажмем на общий ресурс, появляется диалоговое окно аутентификации. Введите свои учетные данные для файлового сервера. Откроется окно проводника Windows с содержимым удаленного общего ресурса как при использовании IP-адреса.

Использование nbtstat для устранения проблем с подключением

Средство командной строки Windows nbtstat очень полезно при устранении проблем с совместным использованием файлов Windows. Вы можете найти имя Windows NetBIOS и просмотреть доступные общие ресурсы или найти имя NetBIOS, которое соответствует определенному IP-адресу. В обоих случаях вывод будет примерно таким:

Использование LDAP в качестве механизма внутренней аутентификации

Обычно безопасность VPN основана на паре сертификат/закрытый ключ X.509, которой должны обладать все пользователи VPN для получения доступа. Безопасность вашей VPN может быть еще более повышена, если пользователям также необходимо указать имя пользователя и пароль при подключении к серверу OpenVPN.

На стороне сервера проверка имени пользователя и пароля может быть выполнена с использованием нескольких механизмов:

• Использование файла паролей на стороне сервера, который содержит имя пользователя и его хешированные пароли.
• Использование PAM (сокращение от Pluggable Authentication Module), который обычно включен во все операционные системы Linux/UNIX.
• Использование центрального сервера каталогов на основе легкорасширяемого протокола доступа к каталогам (Lightweight Directory Access Protocol — LDAP). Обратите внимание, что LDAP и Active Directory также могут использоваться с различными модулями PAM.

Также возможно выполнить аутентификацию в домене Windows Active Directory, поскольку это очень похоже на использование автономного сервера LDAP. В нашем примере мы покажем как аутентифицировать пользователей на сервере LDAP.

Самый простой способ поддержки внутренней аутентификации LDAP — использовать модуль openvpn-plugin-ldap. В большинстве дистрибутивов Linux этот модуль необходимо устанавливать отдельно. Например, в системах на основе RPM вы должны использовать следующую команду:

sudo yum install openvpn-auth-ldap

Мы начнем с файла basic-udp-server.conf и добавим одну строку:

proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
topology subnet
persist-key
persist-tun
keepalive 10 60

remote-cert-tls client
tls-auth  /etc/openvpn/movpn/ta.key 0
dh        /etc/openvpn/movpn/dh2048.pem
ca        /etc/openvpn/movpn/movpn-ca.crt
cert      /etc/openvpn/movpn/server.crt
key       /etc/openvpn/movpn/server.key

user nobody
group nobody # use 'group nogroup' on Debian/Ubuntu

verb 3
daemon
log-append /var/log/openvpn.log
plugin /usr/lib64/openvpn/plugin/lib/openvpn-authldap.so 
              "/etc/openvpn/movpn/movpn_ldap.conf"

Сохраните этот файл как movpn-05-02-server.conf и создайте файл movpn_ldap.conf:

<LDAP>
  URL             ldaps://ldap.example.org
  Timeout         15
  TLSEnable       no
  FollowReferrals yes
  TLSCACertFile   /etc/pki/tls/certs/ca-bundle.crt
  TLSCACertDir    /etc/pki/tls/certs
</LDAP>

<Authorization>
  BaseDN        "ou=LocalUsers,dc=example,dc=org"
  SearchFilter  "(&(uid=%u)(authorizedService=login))"
  RequireGroup  false
</Authorization>

Это очень простой файл конфигурации authldap, использующий защищенный сервер LDAP, который находится по адресу URI ldaps://ldap.example.org, порт 636 и фильтр поиска LDAP на основе идентификатора пользователя (uid=%u) и атрибута LDAP authorizedService=login. URI указывает на SSL-соединение с сервером с помощью службы ldaps://. Эти параметры сильно зависят от используемого сервера LDAP, но плагин openvpn-ldap-auth можно адаптировать практически к любой конфигурации. Например, в этой настройке для подключения к серверу LDAP не используется привязка. Тем не менее, этот, а также другие варианты подключения могут быть добавлены.

Далее мы добавляем в конфигурацию клиента basic-udp-client.ovpn строку:

Сохраните его как movpn-05-02-client.ovpn и запустите клиент. Сначала клиент устанавливает соединение с сервером, используя свой сертификат X.509 и файл приватного ключа, после чего пользователю предлагается ввести имя пользователя и пароль.

Если введены правильные учетные данные, то соединение будет установлено.

В противном случае сервер отказывает в доступе.

Вместо использования плагина openvpn-ldap-auth, мы также можем использовать плагин PAM. Затем OpenVPN запросит подсистему PAM для аутентификации. Если подсистема PAM правильно настроена для аутентификации пользователей по базе данных LDAP, то будут достигнуты те же функциональные возможности. Файл конфигурации сервера OpenVPN будет выглядеть следующим образом:

proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
topology subnet
persist-key
persist-tun
keepalive 10 60

remote-cert-tls client
tls-auth  /etc/openvpn/movpn/ta.key 0
dh        /etc/openvpn/movpn/dh2048.pem
ca        /etc/openvpn/movpn/movpn-ca.crt
cert      /etc/openvpn/movpn/server.crt
key       /etc/openvpn/movpn/server.key

user nobody
group nobody # use 'group nogroup' on Debian/Ubuntu

verb 3
daemon
log-append /var/log/openvpn.log

plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-pam.so "login login USERNAME password PASSWORD"

Устранение неполадок в аутентификации LDAP

Устранение неполадок в подключаемом модуле аутентификации LDAP может быть непростым делом. Прежде всего, важно убедиться что VPN-сервер способен подключаться к LDAP-серверу и информация о пользователе может быть получена. Для этого очень удобен инструмент ldapsearch. Этот инструмент входит в пакет утилит клиента OpenLDAP.

Используя BaseDN и SearchFilter из файла movpn_ldap.conf, мы можем запросить сервер LDAP:

$ ldapsearch -x -H ldaps://ldap.example.org 
     -b ou=LocalUsers,dc=example,dc=org 
      "(&(uid=janjust)(authorizedService=login))"

Опция -x обозначает анонимную (неаутентифицированную) привязку к серверу, а опция -H указывает URI сервера. Обратите внимание, что URI отличается от имени хоста, так как он будет включать протокол (SSL или обычный текст), а также имя хоста. Вывод ldapsearch должен быть чем-то вроде этого:

# extended LDIF
#
# LDAPv3
# base <ou=LocalUsers,dc=example,dc=org> with scope subtree
# filter: (&(uid=janjust)(authorizedService=login))
# requesting: ALL
#

# janjust, LocalUsers, example.org
dn: uid=janjust,ou=LocalUsers,dc=example,dc=org
loginShell: /bin/bash
uid: janjust
cn: Jan Just Keijser
...
authorizedService: login

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Убедитесь что это работает, прежде чем пытаться подключить клиента OpenVPN. Если это работает, но клиент не может подключиться к серверу OpenVPN, то увеличте детальность на сервере и отслеживайте сообщения LDAP. Добавьте следующую строку в конец файла конфигурации и перезапустите сервер:

Переподключите клиента и просмотрите журнал сервера на наличие сообщений аутентификации LDAP. В случае неудачной попытки подключения журналы сервера будут содержать такие строки:

LDAP bind failed: Invalid credentials

Incorrect password supplied for LDAP DN
"uid=janjust,ou=LocalUsers,dc=example,dc=org".

[...] PLUGIN_CALL: POST /usr/lib64/openvpn/plugin/lib/openvpn-auth-ldap.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1

[...] PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib64/openvpn/plugin/lib/openvpn-authldap.so

[...] TLS Auth Error: Auth Username/Password verification failed for peer

Whereas a successful connection attempt will show
[...] PLUGIN_CALL: POST /usr/lib64/openvpn/plugin/lib/openvpn-authldap.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0

[...] TLS: Username/Password authentication succeeded for username 'janjust'

В этих сообщениях журнала детали, относящиеся к соединению, такие как IP-адрес клиента и номер порта UDP, были заменены на [...].

Фильтрация OpenVPN

Как и любой другой интерфейс в системе или на сервере, интерфейсы адаптера tun и tap могут быть отфильтрованы с помощью соответствующего программного обеспечения брандмауэра операционной системы. Во многих случаях, как для целей маршрутизации, так и для фильтрации, лучше всего логически разместить сервер OpenVPN в центральном сетевом расположении, например, на пограничном маршрутизаторе или рядом с ним. Для дома это будет кабельный или DSL-модем. В корпоративных сетях — как правило, фактический основной маршрутизатор, такой как периферийное устройство Cisco или Juniper.

В зависимости от платформы и ваших собственных или бизнес-предпочтений, брандмауэр может быть отдельным устройством между сервером OpenVPN и незащищенным Интернетом, или же может быть программным обеспечением, работающим в той же системе, что и ваш сервер OpenVPN. Большие установки могут даже иметь несколько брандмауэров.

Первое изображение показывает сеть с отдельным межсетевым экраном, установленным между cервером OpenVPN и пограничным маршрутизатором и интернетом:

На следующем рисунке показано, как логически межсетевой экран и сервер OpenVPN могут находиться на одном компьютере:

Такие проекты, как pfSense (https://www.pfsense.org) и OpenWRT (https://openwrt.org) интегрировали интернет-соединения, локальные сети и VPN в единую систему. В этих системах используется программное обеспечение, предоставляющее простой графический интерфейс для управления беспроводными сетями, подключениями к Интернету, экземплярами VPN и набором правил брандмауэра для их защиты.

Для наших примеров мы собираемся разрешить только порты 80 и 443 от VPN-клиентов для остальной части сети.

Пример FreeBSD

Во FreeBSD мы будем использовать pf для фильтрации трафика внутри и вне нашей VPN. Во FreeBSD интерфейс OpenVPN имеет значение tun0. Во-первых, pf должен быть включен в rc.conf:

Для начала создайте чрезвычайно простой набор правил в файле по умолчанию /etc/pf.conf:

Затем запустите pf:

root@server:~-> /etc/rc.d/pf start
Enabling pf
No ALTQ support in kernel
ALTQ related functions disabled

Используя pfctl, мы можем перечислить правила и их счетчики:

root@server:~-> pfctl -vvv -s rules
No ALTQ support in kernel
ALTQ related functions disabled
@0 pass all flags S/SA keep state
  [ Evaluations: 209      Packets: 13     Bytes: 624
States: 2     ]
  [ Inserted: uid 0 pid 71163 State Creations: 7 ]

На данный момент у нас есть простой набор правил, который просто пропускает все пакеты на всех интерфейсах. Поскольку это не книга по освоению pf — мы не будем вдаваться в подробности всей конфигурации. Вот пример фильтра, который разрешает весь трафик на всех интерфейсах, кроме tun0. Трафик на tun0 будет отфильтрован как входящий, поэтому с VPN-клиентов можно устанавливать подключения к локальной сети только через порты 80 и 443. Исходящий трафик на tun0 будет разрешен.

# Mastering OpenVPN - FreeBSD Filtering Example
vpn_if="tun0"
out_if="xn0"
in_if="xn0"

lanv4="10.50.0.0/24"
lanv6="2001:db8:900::/64"
vpnv4="10.200.0.0/24"
vpnv6="2001:db8:100::/64"

pass on {$in_if, $out_if} all
pass out on $vpn_if all
block in on $vpn_if
pass in on $vpn_if inet proto tcp to $lanv4 port {http, https}
pass in on $vpn_if inet6 proto tcp to $lanv6 port {http, https}

---

Подсказка

И OpenVPN и FreeBSD имеют фильтр пакетов pf. В приведенном выше примере мы используем pf, поддерживаемый ядром, а не встроенный в OpenVPN.

---

Пример Windows

Предполагая, что у вас уже есть сервер OpenVPN работающий на системе Windows 7 Professional, вы будете получать доступ к настройке брандмауэра через Панель управления. После того, как Панель управления открыта, введите firewall в поле поиска и нажмите на Windows Firewall. Из параметров, доступных на левой боковой панели окна, нажмите Advanced Settings. Это представит утилиту настройки брандмауэра.

Нажмите Advanced settings, чтобы открыть программу Windows Firewall with Advanced Security, как показано на следующем рисунке:

Попав в утилиту, нам нужно создать два входящих правила. Первое правило будет блокировать весь трафик от VPN, а второе — разрешит трафик через порты 80 и 443 от VPN.

После открытия New Inbound Rule Wizard выберите параметр для создания настраиваемого правила, как показано на следующем снимке экрана. Это позволяет нам определить все конкретные диапазоны входящих адресов и порты, необходимые для эффективности.

На второй странице выберите переключатель Все программы, чтобы применить это правило ко всем программам:

На третьем экране входящего правила укажите TCP-порты 80 и 443 для входящего правила и разрешите их со всех удаленных портов. Это показано на следующем снимке экрана:

Для странице диапазона укажите локальные диапазоны IP-адресов VPN:

• 10.200.0.0/24 (IPv4)
• 2001:db8:100::/64 (IPv6)

Затем разрешите все удаленные IP-адреса, выбрав Any IP address (это значение по умолчанию). Позже, при создании правила блокировки, вы оставите значения по умолчанию — оба для Все порты на этой странице.

---

Подсказка

Вы также можете применить это к диапазонам IP-адресов VPN, чтобы разрешить только адресам хостов VPN связываться с ресурсами VPN. Отказ от этого ограничения разрешает доступ другим удаленным подсетям, которые вы, возможно, захотите направить (например, с помощью --iroute).

---

Далее выберите Allow the connection из списка действий. Позже, при создании правила блокировки, вам нужно будет выбрать Block the connection на этой странице.

Отметьте все три поля на странице мастера Profile. Это позволит правилу функционировать независимо от назначенного профиля интерфейса (Public, Private или Domain). Мы обсудим это позже.

Последняя страница мастера входящих правил позволяет вам задать имя. Введите какое-нибудь описание, которое позволит администратору быстро определить правило и то, как оно применяется. В нашем случае мы устанавливаем имя VPN – Allow 80, 443 для правила разрешения.

Теперь, когда правило разрешения создано — снова выполните эти шаги и создайте правило блокировки. Это правило блокирует весь трафик от VPN. В сочетании с правилом разрешения, которое мы уже создали, это позволит нашим VPN-клиентам подключаться только через VPN через порты 80 и 443.

Используйте следующие настройки для вашего правила блокировки на каждой странице мастера:

• Rule Type должен быть Custom
• Для параметра Program выберите All programs
• Выберите All Ports для локальных и удаленных портов
• Scope должна быть Any IP address (для локальных и удаленных)
• Action должно быть Block the connection
• Выберите Select all profiles в Profile
• Установить Name как VPN – Block All

После сохранения у вас будет пара правил VPN в верхней части списка.

Брандмауэр Windows в режиме повышенной безопасности — это первый тип брандмауэра. Он означает, что как только правило брандмауэра соответствует данному сетевому пакету, обработка набора правил прекращается и применяется указанное действие в этом правиле. Фильтр пакетов iptables в Linux — это еще один фильтр первого соответствия. Другие фильтры пакетов, такие как pf в OpenBSD, соответствуют последним, что означает, что правила продолжают обрабатываться до конца.

Подсказка

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

Для выполнения многих задач типа «сервер» в настольной версии Windows обычно требуется, чтобы администратор пошел по проторенному пути. Например, Windows Server 2008 имеет лучшие инструменты редактирования брандмауэра, чем Windows 7 Professional, которая используется в приведенном выше примере.

Маршрутизация на основе политик

Маршрутизация на основе политик использует брандмауэр или другой фильтр пакетов для маршрутизации трафика на основе не только IP-адресов источника и назначения, но также портов источника и назначения. Одним из распространенных способов использования маршрутизации на основе политик является отправка всего незащищенного трафика порта 80 через VPN, но при этом другой трафик, такой как SSL-трафик через порт 443 может проходить через общий Интернет.

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

Каждый брандмауэр или программное обеспечение для фильтрации пакетов обрабатывает политику маршрутизации по-своему. Нам не удалось настроить брандмауэр Windows 7 для маршрутизации на основе портов источника или назначения и даже фильтр пакетов OpenBSD pf имеет определенные предостережения.

На следующем рисунке показано простое решение о маршрутизации политики порта 80 или 443, соответствующее нашему примеру сценария из предыдущего раздела:

Сетевые расположения Windows — общедоступные или частные

Постоянный вопрос в списках рассылки OpenVPN состоит в том, как изменить сетевое расположение виртуального сетевого адаптера TAP-Win OpenVPN с общедоступного на частное. Этот вопрос возник с появлением Windows Vista. Ответ на него, к сожалению, довольно длинный. В этом разделе мы рассмотрим различные методы, которые позволяют нам изменять сетевое расположение адаптера TAP-Win на клиентах Windows.

Фон

Начиная с Windows Vista, Microsoft представила концепцию сетевых расположений. В Windows 7 есть три сетевых расположения: Домашнее, Рабочее и Общедоступное. Эти сетевые расположения применяются ко всем сетевым адаптерам: проводным, беспроводным, а также виртуальным сетевым адаптерам TAP-Win от OpenVPN.

Домашнее сетевое расположение предназначено для домашней сети и обеспечивает высокий уровень доверия. Оно также включает функцию Домашняя группа, благодаря которой компьютер может легко подключаться ко всем другим устройствам дома. Точно так же расположение Рабочей сети обеспечивает высокий уровень доверия на работе, позволяя компьютеру обмениваться файлами, подключаться к принтерам и т.д. В Windows 8 домашняя и рабочая сетевые папки объединяются в частную сеть.

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

Когда брандмауэр Windows включен — профиль частного брандмауэра применяется ко всем сетевым адаптерам в домашней и рабочей сети, а профиль общего брандмауэра применяется ко всем сетевым адаптерам в общедоступной сети.

Чтобы доверять сетевому адаптеру, он должен объявить шлюз по умолчанию или сетевой адаптер должен быть частью домена Windows. Есть некоторая документация об этом онлайн: http://blogs.technet.com/b/networking/archive/2009/02/20/why-is-my-networkdetected-as-unknown-by-windows-vista-or-windows-server-2008.aspx

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

Изменение местоположения адаптера TAP-Win с помощью redirect-gateway

OpenVPN может установить шлюз по умолчанию на удаленном адаптере TAP-Win с помощью директивы конфигурации:

Обычно рекомендуется добавить параметр def1 к этой опции. Опция def1 заставляет OpenVPN не добавлять новый шлюз по умолчанию (в терминах сети — маршрут 0.0.0.0/0.0.0.0), а вместо этого добавляет два маршрута с маской сети 128.0.0.0 как объяснено в предыдущей главе. Недостатком опции def1 является то, что Windows не распознает адаптер TAP-Win как имеющий шлюз по умолчанию. Для получения дополнительной информации о различных альтернативах опции redirect-gateway см. Главу 4, Режим клиент/сервер с устройствами tun.

Чтобы протестировать эту опцию, мы добавляем строку в файл basic-udp-server.conf:

proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
topology subnet
persist-key
persist-tun
keepalive 10 60

remote-cert-tls client
tls-auth  /etc/openvpn/movpn/ta.key 0
dh        /etc/openvpn/movpn/dh2048.pem
ca        /etc/openvpn/movpn/movpn-ca.crt
cert      /etc/openvpn/movpn/server.crt
key       /etc/openvpn/movpn/server.key

user nobody
group nobody # use 'group nogroup' on Debian/Ubuntu

verb 3
daemon
log-append /var/log/openvpn.log

push "redirect-gateway"

Теперь сохраните его как movpn-05-03-server.conf. Запустите сервер OpenVPN, используя этот файл конфигурации и подключите клиента Windows 7, используя конфигурацию по умолчанию basic-udp-client.ovpn.

На этот раз, после успешного подключения клиента, Windows спросит, в каком месте разместить новую сеть:

Выберите рабочую сеть, после чего Windows позволит вам выбрать собственное имя и значок для сети VPN:

Мы выбрали имя VPN, выберите другой значок и нажмите ОК.

Адаптер TAP-Win теперь является доверенным и в этой сети разрешен общий доступ к файлам Windows, а также другим доверенным протоколам.

Одним из недостатков использования redirect-gateway является то, что адаптер VPN теперь является единственным адаптером со шлюзом по умолчанию и, следовательно, является доверенным. Адаптер беспроводной сети, подключенный к сети Wi-Fi eduroam, теперь не имеет маршрута по умолчанию и внезапно становится частью неопознанной сети и больше не является доверенным. Это можно увидеть на следующем скриншоте Центра управления сетями и общим доступом Windows 7:

Самый большой недостаток использования redirect-gateway без def1 становится очевидным когда VPN-соединение останавливается или прерывается. Поскольку шлюз по умолчанию на клиенте Windows OpenVPN был заменен — больше невозможно надежно восстановить шлюз по умолчанию, который существовал до запуска VPN и потери всех подключений к Интернету. В большинстве случаев (беспроводное) подключение к локальной сети необходимо перезапустить для восстановления шлюза.

Использование редактора групповой политики для принудительного использования адаптера в качестве частного

Второй подход к изменению местоположения адаптера TAP-Win заключается в использовании редактора групповой политики Windows. Используя этот инструмент можно заставить адаптер TAP-Win (или любой неопознанный адаптер) быть либо частным, либо общедоступным:

1. Откройте командную строку и запустите редактор групповой политики:

• Выберите Политики диспетчера списка сетей и дважды щелкните Неопознанные сети на правой панели, как показано на следующем снимке экрана:

• Откроется новое окно Свойства неопознанных сетей. Установите Тип расположения на Частный и нажмите OK, как показано на следующем скриншоте:

Перезапустите клиент OpenVPN без флага redirect-gateway.

Теперь Windows автоматически пометит адаптер как Частный и снова спросит в какую сеть следует установить адаптер: Дом или Работа. Однако на этот раз значок и имя выбранного типа сети изменить нельзя.

---

Подсказка

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

---

Изменение местоположения адаптера TAP-Win с использованием дополнительных шлюзов

Более элегантный подход к изменению местоположения адаптера заключается в добавлении дополнительного адреса шлюза в конфигурацию сервера:

push "route 0.0.0.0 0.0.0.0"

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

В Windows 7 метрика адаптера обычно рассчитывается автоматически как сумма метрики шлюза и метрики интерфейса. Метрики интерфейса основаны на типе и скорости адаптера. Поскольку TAP-Win адаптер OpenVPN зарегистрирован как адаптер 10 Мбит/с, он всегда будет иметь более высокую метрику (то есть будет менее предпочтительным), чем проводные или беспроводные адаптеры, которые имеющие более высокие скорости.

Эти метрики могут быть отображены с помощью команды netsh int ip show config:

C:>netsh int ip show config

Configuration for interface "vpn0"
    DHCP enabled:                         Yes
    IP Address:                           10.200.0.2
    Subnet Prefix:                        10.200.0.0/24 (...)
    Default Gateway:                      10.200.0.1
    Gateway Metric:                       70
    InterfaceMetric:                      30
    DNS servers configured through DHCP:  192.0.2.12
    Register with which suffix:           Primary only
    WINS servers configured through DHCP: 192.0.2.60

Configuration for interface "wifi0"
    DHCP enabled:                         Yes
    IP Address:                           192.0.2.233
    Subnet Prefix:                        192.0.2.0/24 (...)
    Default Gateway:                      192.0.2.254
    Gateway Metric:                       0
    InterfaceMetric:                      20
    DNS servers configured through DHCP:  192.0.2.17
                                          192.0.2.12
    Register with which suffix:           None
    WINS servers configured through DHCP: 192.0.2.121
                                          192.0.2.20

Можно отключить автоматический расчет метрики и вернуться к поведению более старых версий Windows. Для этого перейдите в диалоговое окно Дополнительные параметры TCP/IP пункта Свойства TCP/IPv4 сетевого адаптера:

В этом случае метрика, указанная в окне Свойства TCP/IPv4, будет определять маршрут по умолчанию в системе. Если показатель адаптера TAP-Win выше, чем у адаптера без VPN, то фактически весь трафик направляется через VPN!

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

Перенаправление всего трафика в сочетании с дополнительными шлюзами

В качестве последнего примера того, как можно повлиять на местоположение в сети с помощью параметров конфигурации OpenVPN, мы добавим дополнительный шлюз и перенаправим шлюз по умолчанию с помощью def1:

proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
topology subnet
persist-key
persist-tun
keepalive 10 60

remote-cert-tls client
tls-auth  /etc/openvpn/movpn/ta.key 0
dh        /etc/openvpn/movpn/dh2048.pem
ca        /etc/openvpn/movpn/movpn-ca.crt
cert      /etc/openvpn/movpn/server.crt
key       /etc/openvpn/movpn/server.key

user nobody
group nobody # use 'group nogroup' on Debian/Ubuntu

verb 3
daemon
log-append /var/log/openvpn.log

push "route 0.0.0.0 0.0.0.0"
push "redirect-gateway def1"

Сохраните файл как movpn-05-04-server.conf. Запустите сервер OpenVPN, используя этот файл конфигурации и подключите клиента Windows 7, используя конфигурацию по умолчанию basic-udp-client.ovpn.

После переподключения клиента OpenVPN таблица маршрутизации IPv4 теперь содержит следующие записи:

Первый маршрут — это оригинальный шлюз. Второй маршрут — это дополнительный маршрут 0.0.0.0/0 для адаптера TAP-Win. Он заставляет Windows доверять адаптеру. Третий и четвертый маршруты устанавливаются командой redirect-gateway def1 путем добавления маршрутов 0.0.0.0/1 и 128.0.0.0.

OpenVPN предоставляет два новых маршрута, которые являются более конкретными, чем маршрут по умолчанию 0.0.0.0/0. Маршрутизация TCP/IP указывает что всегда следует выбирать более конкретный маршрут, независимо от метрики интерфейса. Поэтому весь трафик перенаправляется через VPN-туннель.

В окне Центр управления сетями и общим доступом теперь сети как LAN, так и VPN отображаются как доверенные:

Преимущества этого подхода заключаются в следующем:

• Как исходная сеть (Wi-Fi eduroam в предыдущем примере) так и сеть VPN являются доверенными. Это означает, что общий доступ к файлам и принтерам доступен в обеих сетях.
• Весь сетевой трафик правильно перенаправляется через VPN, независимо от метрики интерфейса.
• Когда соединение VPN обрывается или останавливается, исходный шлюз по умолчанию корректно восстанавливается.

Быстрая проверка ссылки https://www.whatismyip.com покажет, что весь трафик теперь маршрутизируется через VPN. Еще один способ убедиться в этом — использовать tracert в командной оболочке Windows:

c:>tracert -4 -d www

Трассировка маршрута к www.nikhef.nl [192.16.199.160]
с максимальным числом прыжков 30:

  1    95 ms    119 ms    83 ms   10.200.0.1
  3   103 ms    119 ms    83 ms   192.0.2.133
  4   115 ms    101 ms   101 ms   192.16.199.160

Трассировка завершена.

Подсказка

В Mac OS X клиент Tunnelblick для OpenVPN имеет возможность проверить, изменился ли внешний IP после подключения к VPN, а затем уведомить пользователя, если этот IP не изменился.

Первый переход в выводе traceroute — это адрес VPN-сервера, который доказывает, что шлюзом по умолчанию в системе теперь действительно является VPN-адаптер.

Использование OpenVPN с HTTP или SOCKS прокси

OpenVPN поддерживает работу через прокси HTTP или SOCKS без аутентификации, с базовой аутентификацией и с аутентификацией NTLM. Мы рассмотрим как прокси-серверы HTTP, так и SOCKS, как с аутентификацией, так и без нее.

HTTP прокси

HTTP прокси требуют использования TCP для туннельного транспорта OpenVPN. Если вы в настоящее время используете UDP — необходимо обновить аргумент протокола как на сервере, так и в конфигурации клиента:

После настройки добавьте поддержку прокси для клиента — добавив директиву конфигурации --http-proxy. В качестве примера давайте предположим, что вашей локальной сети требуется анонимный прокси-сервер для исходящих соединений и этот сервер находится на 192.168.4.4 на порту по умолчанию 1080. Ваша конфигурация будет выглядеть примерно так:

http-proxy 192.168.4.4 1080 none

Это позволит вашему клиентскому соединению OpenVPN подключаться к удаленному серверу OpenVPN через прокси-сервер в вашей локальной сети. HTTP-прокси с аутентификацией не сильно отличается — просто замените none в предыдущей команде на информацию аутентификации:

http-proxy 192.168.4.4 1080 stdin basic

Предыдущая команда подключается к тому же прокси-серверу и порту что и раньше, но запрашивает стандартный ввод для имени пользователя и пароля, которые используются для базовой аутентификации HTTP. Кроме того, поддерживаемые методы аутентификации включают в себя файл аутентификации, который похож на основной файл паролей OpenVPN — просто имя пользователя и пароль в виде открытого текста в двух отдельных строках:

некий_пользователь
некий_пароль

Путь к файлу аутентификации и имя файла передаются вместо ключевого слова stdin в предыдущем примере. Настройка auto позволяет OpenVPN определять, откуда запрашивать учетные данные, в том числе через консоль управления.

Некоторые прокси-серверы HTTP могут ограничивать доступ или аутентификацию на основе переданного агента пользователя HTTP или других параметров HTTP. Они могут быть определены с помощью аргумента конфигурации http-proxy-option для почти любой произвольной опции HTTP. Типичными примерами являются строка агента пользователя и строка версии HTTP:

http-proxy-option VERSION 1.1
http-proxy-option AGENT "Definitely NOT OpenVPN"

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

Если вы хотите, чтобы OpenVPN повторял соединения с прокси-сервером HTTP, укажите параметр --http-proxy-retry. Это приведет к тому, что OpenVPN будет имитировать сброс SIGUSR1 в процессе OpenVPN, вызывая переподключение туннеля.

SOCKS прокси

В дополнение к HTTP-прокси — OpenVPN поддерживает SOCKS-прокси. Если вы хотите больше узнать о различиях между прокси-серверами HTTP и SOCKS, в Википедии есть хорошее сравнение по адресу http://en.wikipedia.org/wiki/SOCKS, или вы можете просмотреть Рабочее предложение (RFC) для конкретного протокола по следующим URL:

• SOCKS5: https://www.ietf.org/rfc/rfc1928.txt
• HTTP: https://www.ietf.org/rfc/rfc2616.txt

Для наших примеров мы снова предположим, что прокси-сервер 192.168.4.4 использует порт по умолчанию 1080. Но на этот раз это будет SOCKS5 прокси. В отличие от примера прокси-сервера HTTP для туннельного транспорта со стандартным прокси-сервером SOCKS5 разрешено использовать UDP или TCP. Однако есть предостережения по этому поводу.

Добавьте следующую строку в конфигурацию клиента OpenVPN чтобы указать его для нашего примера прокси-сервера:

socks-proxy-server 1080 socks_auth.txt

Как и в случае с другими файлами аутентификации — достаточно простого текстового файла с именем пользователя и паролем в отдельных строках:

Как и раньше, stdin работает вместо пути и имени файла для файла аутентификации. Кроме того, если требуется переподключение/повторная попытка в случае потери соединения или сбоя прокси-сервера, укажите параметр --socks-proxy-retry, чтобы позволить OpenVPN имитировать SIGUSR1 для перезапуска VPN.

Подсказка

Вы можете использовать протокол SSH для создания локального сервера SOCKS5 и туннелирования OpenVPN через этот туннель. Одно из ограничений заключается в том, что для прокси-сервера SSH SOCKS5 требуются только TCP-соединения. Ваш трафик в OpenVPN может быть TCP/UDP, но сам туннель OpenVPN должен быть --proto tcp.

Резюме

В этой главе вы узнали, как интегрировать OpenVPN в существующую сеть и компьютерную инфраструктуру. Это относится к серверной части. Мы также увидели как использовать LDAP в качестве бэкэнд-системы аутентификации и как использовать маршрутизацию на основе политик для плавной интеграции VPN, предлагаемой OpenVPN, в обычную сеть. На стороне клиента мы рассмотрели интеграцию OpenVPN в операционную систему Windows, а также сценарий, при котором с сервером OpenVPN нельзя связаться напрямую.

Это, конечно, лишь несколько примеров расширенных сценариев развертывания и мы ограничились только режимом tun. Это было сделано специально чтобы показать, что режим tun подходит для большинства развертываний OpenVPN. Существуют сценарии развертывания для которых требуется режим tap или даже мостовое соединение и они рассматриваются в следующей главе.

Install and configure OpenVPN server and route all client internet traffic through the VPN tunnel.

My Test environment is

Server: Windows Server 2012 Datacenter
OpenVPN Version : 2.4.6
Client Machine: Windows 10

Let start the server configuration.

1. Download the installer from here and run it on the server computer.

Please install OpenVPN to
C:Program FilesOpenVPN
During the install please select the below option

Once the installation complete do the below prerequisites

1.Enable IPEnableRouter on the registry. Go to the below location

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters

On the right side edit «IPEnableRouter» and modify the value to Decimal «1» (See the image below)

2.Restart the Server
3.Open Service and start the «Routing and Remote Access» service and set the startup type to «Automatic»

The below steps are copied from the following link.

https://community.openvpn.net/openvpn/wiki/Easy_Windows_Guide

Certificates and Keys

Navigate to the C:Program FilesOpenVPNeasy-rsa folder in the command prompt:
Press Windows Key + R
Type «cmd.exe» and press Enter.
cmd.exe
Navigate to the correct folder:

cd "C:Program FilesOpenVPNeasy-rsa"

Initialize the OpenVPN configuration:

init-config

NOTE: Only run init-config once, during installation.

Open the vars.bat file in a text editor:

notepad vars.bat

Edit the following lines in vars.bat, replacing «US», «CA,» etc. with your company’s information:

set KEY_COUNTRY=US
set KEY_PROVINCE=CA
set KEY_CITY=SanFrancisco
set KEY_ORG=OpenVPN
set KEY_EMAIL=mail@host.domain

Save the file and exit notepad.

Run the following commands:

vars

clean-all

Building Certificates and Keys

The certificate authority (CA) certificate and key:

build-ca

When prompted, enter your country, etc. These will have default values, which appear in brackets. For your «Common Name,» a good choice is to pick a name to identify your company’s Certificate

Authority. For example, «OpenVPN-CA»:

Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [OpenVPN]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:OpenVPN-CA
Email Address [mail@host.domain]:

The server certificate and key:

build-key-server server

When prompted, enter the «Common Name» as «server»
When prompted to sign the certificate, enter «y»
When prompted to commit, enter «y»

Client certificates and keys:

For each client, choose a name to identify that computer, such as «mike-laptop» in this example.

build-key mike-laptop

When prompted, enter the «Common Name» as the name you have chosen (e.g. «mike-laptop»)

Repeat this step for each client computer that will connect to the VPN.

Generate Diffie Hellman parameters (This is necessary to set up the encryption)

build-dh

Configuration Files(Server)

Find the sample configuration files:

Start Menu -> All Programs -> OpenVPN -> OpenVPN Sample Configuration Files

Server Config File

Open server.ovpn

Find the following lines:

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

Edit them as follows:

ca "C:\Program Files\OpenVPN\config\ca.crt"
cert "C:\Program Files\OpenVPN\config\server.crt"
key "C:\Program Files\OpenVPN\config\server.key"
dh "C:\Program Files\OpenVPN\config\dh1024.pem"

Save the file as C:Program FilesOpenVPNeasy-rsaserver.ovpn

Client Config Files

This is similar to the server configuration

Open client.ovpn

Find the following lines:

ca ca.crt
cert client.crt
key client.key

Edit them as follows:

ca "C:\Program Files\OpenVPN\config\ca.crt"
cert "C:\Program Files\OpenVPN\config\mike-laptop.crt"
key "C:\Program Files\OpenVPN\config\mike-laptop.key"

Notice that the name of the client certificate and key files depends upon the Common Name of each client.
You can also include the ca, cert and key content in the client file. You have to copy the file content inside the tag , and .

Edit the following line, replacing «my-server-1» with your server’s public Internet IP Address or Domain Name.
remote my-server-1 1194

Save the file as C:Program FilesOpenVPNeasy-rsamike-laptop.ovpn (in this example. Each client will need a different, but similar, config file depending upon that client’s Common Name.)
Copying the Server and Client Files to Their Appropriate Directories
Copy these files from C:Program FilesOpenVPNeasy-rsa to C:Program FilesOpenVPNconfig on the server:

ca.crt
dh1024.pem
server.crt
server.key
server.ovpn

Copy these files from C:Program FilesOpenVPNeasy-rsa on the server to C:Program FilesOpenVPNconfig on each client :

ca.crt
mike-laptop.crt
mike-laptop.key
mike-laptop.ovpn

start the OpenVPN service on the server and connect OpenVPN on the client machine

Now use the below configuration for route clients internet traffic through Open VPN Tunnel

On the server config file add or enable the following lines

push "dhcp-option DNS 8.8.8.8"
push "redirect-gateway def1"

Save the config file and restart OpenVPN Service

On the client config file add or enable the following lines

redirect-gateway def1

Reconnect the client and it will route traffic through OpenVPN Tunnel.

В определенных обстоятельствах служба VPN может не шифровать весь трафик, и в зависимости от того, как настроен клиент VPN, мы можем туннелировать определенный трафик через VPN, а другой трафик через нашего интернет-оператора или через Wi-Fi, последний в обход VPN-сервера. Из-за этих настроек возможна утечка конфиденциальных данных о нас при использовании VPN. Если мы подключаемся через VPN и он настроен неправильно, мы можем непреднамеренно предоставить конфиденциальные данные, которые мы не предоставили бы в других обстоятельствах (в общедоступной сети Wi-Fi).

Бывают случаи, когда часть трафика может ускользнуть из частного туннеля, который генерирует VPN, в зависимости от наших потребностей, это может быть серьезным недостатком безопасности или характеристикой VPN. Мы должны помнить о концепции « Сплит-VPN «, Split-VPN или разделенный туннель состоит в том, что определенный трафик будет проходить через VPN-сервер от клиента, но другой трафик не будет проходить через указанный сервер, а будет проходить напрямую через нашего оператора, без предоставления нам конфиденциальности данных и аутентификации. Если вы настроили VPN для перенаправления всего сетевого трафика через сервер и обнаружите, что у вас есть разделенный туннель, тогда действительно возникают проблемы, потому что это не та конфигурация, которую вы сделали.

Тесно связанный с VPN, когда мы туннелируем весь трафик, у нас есть еще одна особенность VPN — это « Аварийная кнопка «, Эта функция позволит нам блокировать трафик, уходящий с нашего компьютера, в случае отказа VPN, то есть, если VPN выйдет из строя, маршруты ПК, смартфона или устройства, которое мы используем, не будут изменены, мы будем просто прекратите подключение к Интернету, но никакие данные не будут отфильтрованы.

Как убедиться, что весь трафик проходит через VPN

Быстрый способ убедиться, что весь сетевой трафик проходит через VPN-сервер, — это использовать любую службу для проверки общедоступного IP-адреса нашего соединения. Если мы перенаправляем весь трафик, это означает, что мы должны видеть общедоступный IP-адрес VPN-сервера, к которому мы подключились, и мы не увидим общедоступный IP-адрес нашего фактического соединения.

Еще один способ проверить, проходит ли весь трафик через VPN, — это проверить маршруты нашего ПК, сервера или устройства. На Windows На компьютерах необходимо открыть командную строку и ввести следующее:

route print

В таблице маршрутизации для сетей IPv4 или IPv6, когда мы подключены к нашему домашнему маршрутизатору, должен появиться шлюз по умолчанию с соответствующим маршрутом ко всей локальной сети и различным подсетям различных сетевых интерфейсов, которые у нас есть. Как видите, первый маршрут перенаправляет весь трафик на шлюз по умолчанию: сетевое назначение 0.0.0.0 (любое), маска 0.0.0.0 (любое), а шлюз — 10.11. 1.1, который является нашим маршрутизатором, а интерфейс 10.11.1.2 — нашим IP.

В таблице маршрутизации для сетей IPv4 или IPv6, когда мы подключаемся к VPN-серверу с перенаправлением трафика, должен отображаться шлюз по умолчанию с соответствующим маршрутом ко всей локальной сети и различным подсетям различных сетевых интерфейсов, которые у нас есть. Как видите, первый маршрут перенаправляет весь трафик на шлюз по умолчанию: сетевое назначение 0.0.0.0 (любое), маска 0.0.0.0 (любое), а шлюз — 10.11. 1.1, который является нашим маршрутизатором, а интерфейс 10.11.1.2 — нашим IP.

И во втором маршруте мы увидим, что с любым адресатом и маской 128.0.0.0 он пересылается через IP 10.8.0.5, который является IP-адресом VPN-туннеля, нам понадобятся оба маршрута для правильного доступа к Интернету с любой службой.

В других операционных системах вы также можете проверить таблицу маршрутизации и убедиться в правильности маршрутов, например, в Linux системы можно поставить:

ip route show

Как перенаправить весь трафик через VPN

В зависимости от программного обеспечения, которое вы используете в различных существующих стандартах VPN, мы будем перенаправлять трафик полностью или только в определенные подсети. Первое, что нужно иметь в виду, это то, что такие сервисы, как Surfshark VPN, NordVPN, PureVPN и другие, всегда перенаправляют трафик, независимо от того, используют ли они IPsec, OpenVPN или WireGuard.

VPN-соединение, созданное в Windows 10

Если у вас Windows 10 и вы создали VPN-соединение с протоколами, поддерживаемыми операционной системой, что отображается в сетевых подключениях, вам нужно будет проверить следующее, чтобы убедиться, что мы перенаправляем весь трафик:

1. Вам нужно перейти в Панель управления / Центр сетей и ресурсов.
2. Вы находите VPN-соединение, щелкаете правой кнопкой мыши на «Свойства», на вкладке «Сети» выбираете Интернет-протокол версии 4 (TCP / IPv4), мы снова нажимаем кнопку «Свойства».
3. В открывшемся окне мы нажимаем на кнопку Advanced, здесь мы убеждаемся, что опция «Использовать шлюз по умолчанию в удаленной сети» отмечена. Нажимаем принять и перезапускаем VPN-соединение.

VPN-соединение с OpenVPN в любой операционной системе

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

push "redirect-gateway def1"

Таким образом, «push» сообщит VPN-клиенту, что он должен отправлять абсолютно весь трафик через VPN-сервер. В случае, если у нас есть VPN-клиент, с помощью которого выполняется «split-vpn», когда он получает этот push, он автоматически перенаправляет весь сетевой трафик, но мы можем этого избежать и иметь доступ только к локальной домашней сети следующим образом:

route-nopull
route 192.168.1.0 255.255.255.0 10.8.0.1

Сеть 192.168.1.0/24 будет локальной сетью, а IP 10.8.0.1 будет там, где сервер OpenVPN будет прослушивать.

VPN-соединение с WireGuard в любой операционной системе

В случае использования WireGuard VPN, если вы хотите перенаправить весь трафик, в файле конфигурации клиента необходимо указать:

AllowedIPs = 0.0.0.0/0

Если вы хотите получить доступ только к определенным подсетям и использовать split-vpn, вам следует сделать:

AllowedIPs = 192.168.1.0/24

VPN-соединение — любой IPsec

Если вы используете программу для подключения к VPN-серверам с IPsec, способ перенаправления всего трафика через VPN — указать «0.0.0.0/0», это что-то универсальное и действует как для WireGuard, так и для остальных протоколов VPN. что мы можем использовать.

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

25.11.2013 — Обзор вcтроенных технологий OpenVPN

Данная статья написана после успешного внедрения технологии OpenVPN. Автор рассматривает ряд технологий реализованных в OpenVPN с описанием конфигурационных команд.

Для начала немного предистории. У  нашего клиента возникла задача объединить центральный и удаленный офис в одну сеть, а так ИТ инфраструктура у нас на обслуживании — мы тут же принялись подбирать решение этого вопроса.

Было предложено немало решений, от «железных» до роли в Windows Server или одной из *nix систем, но все это требовало дополнительных вложений (покупка маршрутизатора, приобритение ПО или приобритение дополнительной рабочей станции). Поэтому наш выбор пал на OpenVPN!

Что такое OpenVPN?

OpenVPN — свободная реализация технологии Виртуальной Частной Сети (VPN) с открытым исходным кодом для создания зашифрованных каналов типа точка-точка или сервер-клиенты между компьютерами. Она позволяет устанавливать соединения между компьютерами, находящимися за NAT-firewall, без необходимости изменения их настроек. OpenVPN была создана Джеймсом Йонаном (James Yonan) и распространяется под лицензией GNU GPL.

Для обеспечения безопасности управляющего канала и потока данных, OpenVPN использует библиотеку OpenSSL. Благодаря этому задействуется весь набор алгоритмов шифрования, доступных в данной библиотеке. Также может использоваться пакетная авторизация HMAC, для обеспечения большей безопасности, и аппаратное ускорение для улучшения производительности шифрования. Эта библиотека использует OpenSSL, а точнее протоколы SSLv3/TLSv1. OpenVPN используется в операционных системах Solaris, OpenBSD, FreeBSD, NetBSD, GNU/Linux, Apple Mac OS X, QNX и Microsoft Windows.

OpenVPN предлагает пользователю несколько видов аутентификации:

1)     Предустановленный ключ — самый простой метод. Параметр в конфигурации :

secret «путь» static.key — Представляет собой файл, в котором находится ключ.

2)     Сертификатная аутентификация — наиболее гибкий в настройках метод. Параметр в конфигурации:

ca – Корневой сертификат SSL/TLS

dh — Для сервера OpenVPN необходимо создать параметры Diffie Hellman’а (только для сервера)

cert – сертификат

key – закрытый ключ (Этот файл должен храниться в секрете)

*Каждый клиент и сервер должен иметь свои собственные файлы с сертификатом и ключем.  Сервер и все клиенты будут использовать один и тот же ca-файл.

Можно воспользоваться командой buil-key-pkcs12 для создания одного файла, в котором будут 3 файла (ca, cert и key). Так же можно на сгенерированный файл установить пароль.

3)      С помощью логина и пароля, — может использоваться без создания клиентского сертификата (серверный сертификат всё равно нужен). Параметр конфигурации:

auth-user-pass-verify — Сервер

auth-user-pass — Клиент

Хочу больше безопасности

Для еще большей безопасности чем предоставляет SSL/TLS, создайте «HMAC-файрвол», чтобы заблокировать DoS-атаки и UDP-флуд. Генерация:

 openvpn —genkey —secret ta.key

*(файл будет создан в каталоге по умолчанию)

Сервер и каждый клиент должен иметь копию этого ключа. Второй параметр должен быть ‘0’ на сервере и ‘1 ‘на клиентах. Соответственно:

tls-auth ta.key 0 – для сервера

tls-auth ta.key 1 – для клиента

*Этот файл является секретным

Выбор криптографического шифра

Этот элемент конфигурации также должен быть скопирован в конфигурацию клиента. Параметр в конфиге:

cipher BF-CBC                   # Blowfish (default)
cipher AES-128-CBC         # AES
cipher DES-EDE3-CBC      # Triple-DES

Поддерживаемые транспортные протоколы

OpenVPN проводит все сетевые операции через TCP, либо UDP. Указав в конфиге:

prototcp—server – для сервера

proto tcp  — для клиента

Передача сетевых параметров клиентам

Также возможна работа через большую часть прокси серверов, включая HTTP, через NAT и сетевые фильтры. Сервер может быть настроен на назначение сетевых настроек клиенту. Например: IP адрес, настройки маршрутизации и параметры соединения. Параметры в конфиге:

server 10.8.0.0 255.255.255.0 — Настройка режима сервера и адреса VPN-сети, из которой OpenVPN  будет раздавать адреса клиентам. Первый адрес сервер возьмет себе 10.8.0.1 а остальные раздаст клиентам.

push «route 192.168.10.0 255.255.255.0» — Передача клиенту маршрутов, чтобы позволить ему связаться с другими частными подсетями

push «route-gateway 10.8.0.1» — Передача клиенту шлюза для связи с другими частными сетями

push «dhcp-option DNS 10.8.0.1»
push «dhcp-option WINS 10.8.0.1» — Некоторые Windows-специфичные сетевые настройки могут быть переданы клиентам, такие как адреса DNS или WINS-серверов.

push «route-gateway 10.8.0.1» — передача клиенту шлюза для связи с другими частными сетями.

Внимание! Если мы будем передавать параметры push «route 192.168.10.0 255.255.255.0» и push «route-gateway 10.8.0.1»  могут возникнуть следующие проблемы:

Если мы запускаем OpenVPN GUI на ОС Windows с правами простого пользователя то в логе будут следующие строки:

C:WINDOWSsystem32route.exe ADD 10.0.0.0 MASK 255.0.0.0 172.16.0.1

ROUTE: route addition failed using CreateIpForwardEntry: Отказано в доступе.   [status=5 if_index=13]

Решение:

1)      Запускаем OpenVPN GUI от администратора, т.к. для записи маршрута, требуются повышение прав

2)      Запускаем OpenVPN как службу, но если для аутентификации используете pkcs12  и вы задали пароль для файла .p12,  у вас не выскочит окошка с вводом пароля, а значит не будет даже попытки соединения.

OpenVPN как мост

OpenVPN предлагает два различных варианта сетевых интерфейсов, используя драйвер TUN/TAP. Возможно создать Layer 3-based IP туннель, называемый TUN, и Layer 2-based Ethernet — TAP, способный передавать Ethernet трафик. Если вы хотите использовать Ethernet-мост, вам необходимо заменить server и dev tun на, соответственно, server-bridge и dev tap. Параметр в конфиге:

dev tap

server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100  — Настройка сервера для режима Ethernet-моста (for Ethernet bridging)

Сжатие трафика

Также возможно использование библиотеки компрессии LZO, для сжатия потока данных. Параметр в конфиге:

Comp-lzo — Включить сжатие в VPN-соединении. Если вы включите его здесь, вы также должны включить его в файле конфигурации клиента.

Какой TCP/UDP-порт должен слушать OpenVPN?

Используемый порт 1194 выделен Internet Assigned Numbers Authority для работы данной программы. Версия 2.0 позволяет контролировать несколько одновременных туннелей, в отличие от версии 1.0, позволявшей создавать только 1 туннель на 1 процесс. Использование в OpenVPN стандартных протоколов TCP и UDP позволяет ему стать альтернативой IPsec в ситуациях, когда Интернет-провайдер блокирует некоторые VPN протоколы.

Если вы хотите запустить несколько экземпляров OpenVPN на одной и той же машине, используйте отдельный номер порта для каждого экземпляра. Вам нужно будет открыть этот порт на фаерволе. Параметр в конфиге:

port 1194

Обязательно к вышесказанному

Для ОС Windows необходимо имя TAP-Win32-адаптера из панели Сетевые подключения если у вас больше чем один такой адаптер.  В XP SP2 или выше вам, возможно, понадобиться выборочно отключить брандмауэр Windows для TAP-адаптера. Не-Windows системы обычно не требуют этого. Параметр в конфиге:

dev-node MyTap

Если у вас один сертификат для всех клиентов, что делать?

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

Внимание! ЕСЛИ У ВАС НЕ СГЕНЕРИРОВАННА ИНДИВИДУАЛЬНАЯ ПАРА СЕРТИФИКАТ/КЛЮЧ ДЛЯ КАЖДОГО КЛИЕНТА И КАЖДЫЙ КЛИЕНТ НЕ ИМЕЕТ СВОЕГО УНИКАЛЬНОГО «COMMON NAME», РАСКОММЕНТИРУЙТЕ ЭТУ СТРОКУ В КОНФИГЕ.

;duplicate-cn

Весь трафик через туннель

Будучи активированной, это директива скажет всем клиентам перенаправить их шлюз по умолчанию через VPN, в результате чего весь IP-трафик, такой как просмотр веб-страниц и DNS-поиск пойдет через VPN (Машине с OpenVPN-сервером, возможно, потребуется NAT’ить весь трафик с TUN/TAP-интерфейса, идущий в Интернет, чтобы все это работало должным образом). Предостережение: Можно нарушить сетевую конфигурацию клиента если пакеты локального DHCP-сервера клиента будут направлены (get routed) через туннель. 

Решение: убедитесь, что локальный DHCP-сервер клиента доступен через более определенный (specific) маршрут, чем маршрут по умолчанию
 — 0.0.0.0/0.0.0.0.

Параметр в конфиге:

push «redirect-gateway«

Ой!

Если OpenVPN упадет или будет перезапущен, повторно подключающимся клиентам могут быть назначены из пула такие же виртуальные IP-адреса, которые были назначены им в прошлый раз. Сопоставления клиент <-> виртуальный IP-адрес хранятся в этом файле. Параметр в конфиге:

ifconfig-pool-persist ipp.txt

Не хотим много клиентов или хотим?

Максимальное количество одновременно подключенных клиентов, которое мы хотим разрешить. Параметр в конфиге:

max-clients 100

Клиент, ты точно тут?

Директива проверки работоспособности, включающая отсылку ping-подобных сообщений туда и обратно через соединение для того, чтобы каждая сторона знала когда другая сторона внезапно пропадет (gone down). Пинг каждые 10 секунд, с предположением, что удаленный узел недоступен, если не получено ни одного пинга за период времени равный 120 секундам. Параметр в конфиге:

keepalive 10 120

Дополнительно

Раскомментируйте эту директиву, чтобы позволить различным клиентам «видеть» друг друга. По умолчанию клиенты будут видеть только сервер. Чтобы клиенты видели только сервер, вам также необходимо будет надлежащим образом настроить файрвол сервера для TUN/TAP-интерфейса. Параметр в конфиге:

;client-to-client

Логи

Содержимое небольшого файла состояния, показывающего текущие соединения, усекается и перезаписывается раз в минуту. Параметр в конфиге:

status openvpn-status.log

Установить соответствующий уровень детализации лог-файла.

0 — молчаливый (silent), за исключением фатальных ошибок
4 — разумно для обычного использования
5 и 6 помогут найти и устранить (debug) проблемы с соединением
9 — чрезвычайно подробный

Параметр в конфиге:

verb 3

Не записывать повторяющиеся сообщения.  Не более 20 последовательно идущих одинаковых сообщений будут выведены в лог. Параметр в конфиге:

mute 20

Безопасность со стороны клиента

Все последующие команды указываются только в конфиге клиентов.

Проверка сертификата сервера путем контроля того, что в сертификате значение поля nsCertType установленным в значение «server».  Это важная меры предосторожности для защиты от потенциальной атаки. Чтобы использовать эту функцию, вам необходимо сгенерировать ваш сертификат для сервера с полем nsCertType, установленным в значение «server».  Скрипт build-key-server в папке easy-rsa. Параметр в конфиге:

ns-cert-type server

Подключаемся через WiFi

Беспроводные сети часто производят дубликаты пакетов.  Установите этот флаг для того, чтобы отключить предупреждения для пакетов, которые дублируются. Параметр в конфиге:

mute-replay-warnings

Бесконечно пробовать разрешить имя хоста OpenVPN-сервера.  Очень полезно на машинах, которые не являются постоянно подключенными к интернету, например, для ноутбуков. Параметр в конфиге:

resolv-retry infinite

Вывод. Рассмотрев долеко не все технологии встроенные в OpenVPN, а лишь не большую часть, можно сказать что OpenVPN очень хорошая штука! Юзайте!

Рассмотрим настройку OpenVPN-клиент на Windows.

Мы рассмотрели настройку OpenVPN сервер на Mikrotik, давайте теперь настроим нашего тестового пользователя.

Качаем дистрибутив

Для начала нам необходимо скачать OpenVPN Client с сайта разработчиков.

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

Конфигурация

Далее нам необходимо через текстовый редактор создать конфигурационный файл формата .opvn, которые по умолчанию лежат по пути %programfiles%OpenVPNconfig. 

Примеры конфигураций

Статический маршрут

Такой конфиг идеально подходит для удаленных клиентов, которым нужны удаленные ресурсы внутри сети, где стоит OpenVPN, например, для удаленных сотрудников.

Мы указываем route наша подсеть наша маска

Статический маршрут

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

client dev tun proto tcp remote IP или DNS 1194 auth—nocache ca CA.crt cert ovpn—client.crt key ovpn—client.key remote—cert—tls server cipher AES—256—CBC resolv—retry infinite nobind persist—key persist—tun verb 3 auth—nocache auth—user—pass route 192.168.0.0 255.255.255.0

Весь трафик через VPN

Конфигурация, которая заворачивает весь трафик клиента в нашу сеть.

Весь трафик через VPN

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

client dev tun proto tcp remote IP или DNS 1194 auth—nocache ca CA.crt cert ovpn—client.crt key ovpn—client.key remote—cert—tls server cipher AES—256—CBC resolv—retry infinite nobind persist—key persist—tun verb 3 auth—nocache auth—user—pass redirect—gateway def1 bypass—dhcp

Сертификаты внутри файла конфигурации

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

Для того, чтобы вытащить текст сертификатов — достаточно просто открыть их в текстовом редакторе и скопировать код.

Сертификаты внутри файла

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

client dev tun proto udp remote IP или DNS 1194 resolv—retry infinite nobind persist—key persist—tun cipher AES—256—CBC remote—cert—tls server auth—user—pass verb 3 redirect—gateway def1 bypass—dhcp <ca> ———BEGIN CERTIFICATE——— ———END CERTIFICATE——— </ca> <cert> ———BEGIN CERTIFICATE——— ———END CERTIFICATE——— </cert> <key> ———BEGIN ENCRYPTED PRIVATE KEY——— ———END ENCRYPTED PRIVATE KEY——— </key>

Несколько конфигураций

Допустим у нас есть потребность на одном компьютере иметь несколько конфигураций. Для этого, нам необходимо создать по пути %programfiles%OpenVPNconfig папки с названием нашей конфигурации, внутри разместить конфигурационный файл .opvn и сертификаты. Названия конфигурационных файлов должны быть разные, даже если они лежат в разных папках.

Просмотры: 647

Starting the client

As in the server configuration, it’s best to initially start the OpenVPN server from the command line (or on Windows, by right-clicking on the client.ovpn file), rather than start it as a daemon or service:

openvpn [client config file] 

A normal client startup on Windows will look similar to the server output above, and should end with the Initialization Sequence Completed message.

Now, try a ping across the VPN from the client. If you are using routing (i.e. dev tun in the server config file), try:

ping 10.8.0.1

If you are using bridging (i.e. dev tap in the server config file), try to ping the IP address of a machine on the server’s ethernet subnet.

If the ping succeeds, congratulations! You now have a functioning VPN.

Troubleshooting

If the ping failed or the OpenVPN client initialization failed to complete, here is a checklist of common symptoms and their solutions:

• You get the error message: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity). This error indicates that the client was unable to establish a network connection with the server.Solutions:
  • Make sure the client is using the correct hostname/IP address and port number which will allow it to reach the OpenVPN server.
  • If the OpenVPN server machine is a single-NIC box inside a protected LAN, make sure you are using a correct port forward rule on the server’s gateway firewall. For example, suppose your OpenVPN box is at 192.168.4.4 inside the firewall, listening for client connections on UDP port 1194. The NAT gateway servicing the 192.168.4.x subnet should have a port forward rule that says forward UDP port 1194 from my public IP address to 192.168.4.4.
  • Open up the server’s firewall to allow incoming connections to UDP port 1194 (or whatever TCP/UDP port you have configured in the server config file).
• You get the error message: Initialization Sequence Completed with errors— This error can occur on Windows if (a) You don’t have the DHCP client service running, or (b) You are using certain third-party personal firewalls on XP SP2.Solution: Start the DHCP client server and make sure that you are using a personal firewall which is known to work correctly on XP SP2.
• You get the Initialization Sequence Completedmessage but the ping test fails — This usually indicates that a firewall on either server or client is blocking VPN network traffic by filtering on the TUN/TAP interface.Solution: Disable the client firewall (if one exists) from filtering the TUN/TAP interface on the client. For example on Windows XP SP2, you can do this by going to Windows Security Center -> Windows Firewall -> Advanced and unchecking the box which corresponds to the TAP-Windows adapter (disabling the client firewall from filtering the TUN/TAP adapter is generally reasonable from a security perspective, as you are essentially telling the firewall not to block authenticated VPN traffic). Also make sure that the TUN/TAP interface on the server is not being filtered by a firewall (having said that, note that selective firewalling of the TUN/TAP interface on the server side can confer certain security benefits. See the access policies section below).
• The connection stalls on startup when using a proto udpconfiguration, the server log file shows this line:
  

  TLS: Initial packet from x.x.x.x:x, sid=xxxxxxxx xxxxxxxx

  however the client log does not show an equivalent line.

  Solution: You have a one-way connection from client to server. The server to client direction is blocked by a firewall, usually on the client side. The firewall can either be (a) a personal software firewall running on the client, or (b) the NAT router gateway for the client. Modify the firewall to allow returning UDP packets from the server to reach the client.

See the FAQ for additional troubleshooting information.

---

Configuring OpenVPN to run automatically on system startup

The lack of standards in this area means that most OSes have a different way of configuring daemons/services for autostart on boot. The best way to have this functionality configured by default is to install OpenVPN as a package, such as via RPM on Linux or using the Windows installer.

Linux

If you install OpenVPN via an RPM or DEB package on Linux, the installer will set up an initscript. When executed, the initscript will scan for .conf configuration files in /etc/openvpn, and if found, will start up a separate OpenVPN daemon for each file.

Windows

The Windows installer will set up a Service Wrapper, but leave it turned off by default. To activate it, go to Control Panel / Administrative Tools / Services, select the OpenVPN service, right-click on properties, and set the Startup Type to Automatic. This will configure the service for automatic start on the next reboot.

When started, the OpenVPN Service Wrapper will scan the Program FilesOpenVPNconfig folder for .ovpn configuration files, starting a separate OpenVPN process on each file.

---

Controlling a running OpenVPN process

Running on Linux/BSD/Unix

OpenVPN accepts several signals:

• SIGUSR1 — Conditional restart, designed to restart without root privileges
• SIGHUP — Hard restart
• SIGUSR2 — Output connection statistics to log file or syslog
• SIGTERM, SIGINT — Exit

Use the writepid directive to write the OpenVPN daemon’s PID to a file, so that you know where to send the signal (if you are starting openvpn with an initscript, the script may already be passing a —writepid directive on the openvpn command line).

Running on Windows as a GUI

See the OpenVPN GUI page.

Running in a Windows command prompt window

On Windows, you can start OpenVPN by right clicking on an OpenVPN configuration file (.ovpn file) and selecting «Start OpenVPN on this config file».

Once running in this fashion, several keyboard commands are available:

• F1 — Conditional restart (doesn’t close/reopen TAP adapter)
• F2 — Show connection statistics
• F3 — Hard restart
• F4 — Exit

Running as a Windows Service

When OpenVPN is started as a service on Windows, the only way to control it is:

• Via the service control manager (Control Panel / Administrative Tools / Services) which gives start/stop control.
• Via the management interface (see below).

Modifying a live server configuration

While most configuration changes require you to restart the server, there are two directives in particular which refer to files which can be dynamically updated on-the-fly, and which will take immediate effect on the server without needing to restart the server process.

client-config-dir — This directive sets a client configuration directory, which the OpenVPN server will scan on every incoming connection, searching for a client-specific configuration file (see the the manual page for more information). Files in this directory can be updated on-the-fly, without restarting the server. Note that changes in this directory will only take effect for new connections, not existing connections. If you would like a client-specific configuration file change to take immediate effect on a currently connected client (or one which has disconnected, but where the server has not timed-out its instance object), kill the client instance object by using the management interface (described below). This will cause the client to reconnect and use the new client-config-dir file.

crl-verify — This directive names a Certificate Revocation List file, described below in the Revoking Certificates section. The CRL file can be modified on the fly, and changes will take effect immediately for new connections, or existing connections which are renegotiating their SSL/TLS channel (occurs once per hour by default). If you would like to kill a currently connected client whose certificate has just been added to the CRL, use the management interface (described below).

Status File

The default server.conf file has a line

status openvpn-status.log

which will output a list of current client connections to the file openvpn-status.log once per minute.

Using the management interface

The OpenVPN management interface allows a great deal of control over a running OpenVPN process. You can use the management interface directly, by telneting to the management interface port, or indirectly by using an OpenVPN GUI which itself connects to the management interface.

To enable the management interface on either an OpenVPN server or client, add this to the configuration file:

management localhost 7505

This tells OpenVPN to listen on TCP port 7505 for management interface clients (port 7505 is an arbitrary choice — you can use any free port).

Once OpenVPN is running, you can connect to the management interface using a telnet client. For example:

ai:~ # telnet localhost 7505
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
>INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
help
Management Interface for OpenVPN 2.0_rc14 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 15 2005
Commands:
echo [on|off] [N|all]  : Like log, but only show messages in echo buffer.
exit|quit              : Close management session.
help                   : Print this message.
hold [on|off|release]  : Set/show hold flag to on/off state, or
                         release current hold and start tunnel.
kill cn                : Kill the client instance(s) having common name cn.
kill IP:port           : Kill the client instance connecting from IP:port.
log [on|off] [N|all]   : Turn on/off realtime log display
                         + show last N lines or 'all' for entire history.
mute [n]               : Set log mute level to n, or show level if n is absent.
net                    : (Windows only) Show network info and routing table.
password type p        : Enter password p for a queried OpenVPN password.
signal s               : Send signal s to daemon,
                         s = SIGHUP|SIGTERM|SIGUSR1|SIGUSR2.
state [on|off] [N|all] : Like log, but show state history.
status [n]             : Show current daemon status info using format #n.
test n                 : Produce n lines of output for testing/debugging.
username type u        : Enter username u for a queried OpenVPN username.
verb [n]               : Set log verbosity level to n, or show if n is absent.
version                : Show current version number.
END
exit
Connection closed by foreign host.
ai:~ #

For more information, see the OpenVPN Management Interface Documentation.

---

Expanding the scope of the VPN to include additional machines on either the client or server subnet.

Including multiple machines on the server side when using a routed VPN (dev tun)

Once the VPN is operational in a point-to-point capacity between client and server, it may be desirable to expand the scope of the VPN so that clients can reach multiple machines on the server network, rather than only the server machine itself.

For the purpose of this example, we will assume that the server-side LAN uses a subnet of 10.66.0.0/24and the VPN IP address pool uses 10.8.0.0/24 as cited in the server directive in the OpenVPN server configuration file.

First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive:

push "route 10.66.0.0 255.255.255.0"

Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8.0.0/24) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).

Make sure that you’ve enabled IP and TUN/TAP forwarding on the OpenVPN server machine.

Including multiple machines on the server side when using a bridged VPN (dev tap)

One of the benefits of using ethernet bridging is that you get this for free without needing any additional configuration.

Including multiple machines on the client side when using a routed VPN (dev tun)

In a typical road-warrior or remote access scenario, the client machine connects to the VPN as a single machine. But suppose the client machine is a gateway for a local LAN (such as a home office), and you would like each machine on the client LAN to be able to route through the VPN.

For this example, we will assume that the client LAN is using the 192.168.4.0/24 subnet, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.

Before setup, there are some basic prerequisites which must be followed:

• The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.
• The client must have a unique Common Name in its certificate («client2» in our example), and the duplicate-cn flag must not be used in the OpenVPN server configuration file.

First, make sure that IP and TUN/TAP forwarding is enabled on the client machine.

Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:

client-config-dir ccd

In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually Program FilesOpenVPNconfig. When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.

The next step is to create a file called client2 in the ccd directory. This file should contain the line:

iroute 192.168.4.0 255.255.255.0

This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Next, add the following line to the main server config file (not the ccd/client2 file):

route 192.168.4.0 255.255.255.0

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between client2’s subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.

client-to-client
push "route 192.168.4.0 255.255.255.0"

This will cause the OpenVPN server to advertise client2’s subnet to other connecting clients.

The last step, and one that is often forgotten, is to add a route to the server’s LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won’t need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn’t know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

Including multiple machines on the client side when using a bridged VPN (dev tap)

This requires a more complex setup (maybe not more complex in practice, but more complicated to explain in detail):

• You must bridge the client TAP interface with the LAN-connected NIC on the client.
• You must manually set the IP/netmask of the TAP interface on the client.
• You must configure client-side machines to use an IP/netmask that is inside of the bridged subnet, possibly by querying a DHCP server on the OpenVPN server side of the VPN.

---

Pushing DHCP options to clients

The OpenVPN server can push DHCP options such as DNS and WINS server addresses to clients (some caveats to be aware of). Windows clients can accept pushed DHCP options natively, while non-Windows clients can accept them by using a client-side up script which parses the foreign_option_nenvironmental variable list. See the man page for non-Windows foreign_option_n documentation and script examples.

For example, suppose you would like connecting clients to use an internal DNS server at 10.66.0.4 or 10.66.0.5 and a WINS server at 10.66.0.8. Add this to the OpenVPN server configuration:

push "dhcp-option DNS 10.66.0.4"
push "dhcp-option DNS 10.66.0.5"
push "dhcp-option WINS 10.66.0.8"

To test this feature on Windows, run the following from a command prompt window after the machine has connected to an OpenVPN server:

ipconfig /all

The entry for the TAP-Windows adapter should show the DHCP options which were pushed by the server.

---

Configuring client-specific rules and access policies

Suppose we are setting up a company VPN, and we would like to establish separate access policies for 3 different classes of users:

• System administrators — full access to all machines on the network
• Employees — access only to Samba/email server
• Contractors — access to a special server only

The basic approach we will take is (a) segregate each user class into its own virtual IP address range, and (b) control access to machines by setting up firewall rules which key off the client’s virtual IP address.

In our example, suppose that we have a variable number of employees, but only one system administrator, and two contractors. Our IP allocation approach will be to put all employees into an IP address pool, and then allocate fixed IP addresses for the system administrator and contractors.

Note that one of the prerequisites of this example is that you have a software firewall running on the OpenVPN server machine which gives you the ability to define specific firewall rules. For our example, we will assume the firewall is Linux iptables.

First, let’s create a virtual IP address map according to user class:

Class	Virtual IP Range	Allowed LAN Access	Common Names
Employees	10.8.0.0/24	Samba/email server at 10.66.4.4	[variable]
System Administrators	10.8.1.0/24	Entire 10.66.4.0/24 subnet	sysadmin1
Contractors	10.8.2.0/24	Contractor server at 10.66.4.12	contractor1, contracter2

Next, let’s translate this map into an OpenVPN server configuration. First of all, make sure you’ve followed the steps above for making the 10.66.4.0/24 subnet available to all clients (while we will configure routing to allow client access to the entire 10.66.4.0/24 subnet, we will then impose access restrictions using firewall rules to implement the above policy table).

First, define a static unit number for our tun interface, so that we will be able to refer to it later in our firewall rules:

dev tun0

In the server configuration file, define the Employee IP address pool:

server 10.8.0.0 255.255.255.0

Add routes for the System Administrator and Contractor IP ranges:

route 10.8.1.0 255.255.255.0
route 10.8.2.0 255.255.255.0

Because we will be assigning fixed IP addresses for specific System Administrators and Contractors, we will use a client configuration directory:

client-config-dir ccd

Now place special configuration files in the ccd subdirectory to define the fixed IP address for each non-Employee VPN client.

ccd/sysadmin1

ifconfig-push 10.8.1.1 10.8.1.2

ccd/contractor1

ifconfig-push 10.8.2.1 10.8.2.2

ccd/contractor2

ifconfig-push 10.8.2.5 10.8.2.6

Each pair of ifconfig-push addresses represent the virtual client and server IP endpoints. They must be taken from successive /30 subnets in order to be compatible with Windows clients and the TAP-Windows driver. Specifically, the last octet in the IP address of each endpoint pair must be taken from this set:

[  1,  2] [  5,  6] [  9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]

This completes the OpenVPN configuration. The final step is to add firewall rules to finalize the access policy. For this example, we will use firewall rules in the Linux iptables syntax:

# Employee rule
iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 10.66.4.4 -j ACCEPT

# Sysadmin rule
iptables -A FORWARD -i tun0 -s 10.8.1.0/24 -d 10.66.4.0/24 -j ACCEPT

# Contractor rule
iptables -A FORWARD -i tun0 -s 10.8.2.0/24 -d 10.66.4.12 -j ACCEPT

---

Using alternative authentication methods

OpenVPN 2.0 and later include a feature that allows the OpenVPN server to securely obtain a username and password from a connecting client, and to use that information as a basis for authenticating the client.

To use this authentication method, first add the auth-user-pass directive to the client configuration. It will direct the OpenVPN client to query the user for a username/password, passing it on to the server over the secure TLS channel.

Next, configure the server to use an authentication plugin, which may be a script, shared object, or DLL. The OpenVPN server will call the plugin every time a VPN client tries to connect, passing it the username/password entered on the client. The authentication plugin can control whether or not the OpenVPN server allows the client to connect by returning a failure (1) or success (0) value.

Using Script Plugins

Script plugins can be used by adding the auth-user-pass-verify directive to the server-side configuration file. For example:

auth-user-pass-verify auth-pam.pl via-file

will use the auth-pam.pl perl script to authenticate the username/password of connecting clients. See the description of auth-user-pass-verify in the manual page for more information.

The auth-pam.pl script is included in the OpenVPN source file distribution in the sample-scriptssubdirectory. It will authenticate users on a Linux server using a PAM authentication module, which could in turn implement shadow password, RADIUS, or LDAP authentication. auth-pam.pl is primarily intended for demonstration purposes. For real-world PAM authentication, use the openvpn-auth-pamshared object plugin described below.

Using Shared Object or DLL Plugins

Shared object or DLL plugins are usually compiled C modules which are loaded by the OpenVPN server at run time. For example if you are using an RPM-based OpenVPN package on Linux, the openvpn-auth-pam plugin should be already built. To use it, add this to the server-side config file:

plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login

This will tell the OpenVPN server to validate the username/password entered by clients using the loginPAM module.

For real-world production use, it’s better to use the openvpn-auth-pam plugin, because it has several advantages over the auth-pam.pl script:

• The shared object openvpn-auth-pam plugin uses a split-privilege execution model for better security. This means that the OpenVPN server can run with reduced privileges by using the directives user nobody, group nobody, and chroot, and will still be able to authenticate against the root-readable-only shadow password file.
• OpenVPN can pass the username/password to a plugin via virtual memory, rather than via a file or the environment, which is better for local security on the server machine.
• C-compiled plugin modules generally run faster than scripts.

If you would like more information on developing your own plugins for use with OpenVPN, see the README files in the plugin subdirectory of the OpenVPN source distribution.

To build the openvpn-auth-pam plugin on Linux, cd to the plugin/auth-pam directory in the OpenVPN source distribution and run make.

Using username/password authentication as the only form of client authentication

By default, using auth-user-pass-verify or a username/password-checking plugin on the server will enable dual authentication, requiring that both client-certificate and username/password authentication succeed in order for the client to be authenticated.

While it is discouraged from a security perspective, it is also possible to disable the use of client certificates, and force username/password authentication only. On the server:

client-cert-not-required

Such configurations should usually also set:

username-as-common-name

which will tell the server to use the username for indexing purposes as it would use the Common Name of a client which was authenticating via a client certificate.

Note that client-cert-not-required will not obviate the need for a server certificate, so a client connecting to a server which uses client-cert-not-required may remove the cert and key directives from the client configuration file, but not the ca directive, because it is necessary for the client to verify the server certificate.

---

How to add dual-factor authentication to an OpenVPN configuration using client-side smart cards

• About dual-factor authentication
• What is PKCS#11?
• Finding PKCS#11 provider library.
• How to configure a cryptographic token
• How to modify an OpenVPN configuration to make use of cryptographic tokens
  • Determine the correct object.
  • Using OpenVPN with PKCS#11.
  • PKCS#11 implementation considerations.
  • OpenSC PKCS#11 provider.
• Difference between PKCS#11 and Microsoft Cryptographic API (CryptoAPI).

About dual-factor authentication

Dual-factor authentication is a method of authentication that combines two elements: something you have and something you know.

Something you have should be a device that cannot be duplicated; such a device can be a cryptographic token that contains a private secret key. This private key is generated inside the device and never leaves it. If a user possessing this token attempts to access protected services on a remote network, the authorization process which grants or denies network access can establish, with a high degree of certainty, that the user seeking access is in physical possession of a known, certified token.

Something you know can be a password presented to the cryptographic device. Without presenting the proper password you cannot access the private secret key. Another feature of cryptographic devices is to prohibit the use of the private secret key if the wrong password had been presented more than an allowed number of times. This behavior ensures that if a user lost his device, it would be infeasible for another person to use it.

Cryptographic devices are commonly called «smart cards» or «tokens», and are used in conjunction with a PKI (Public Key Infrastructure). The VPN server can examine a X.509 certificate and verify that the user holds the corresponding private secret key. Since the device cannot be duplicated and requires a valid password, the server is able to authenticate the user with a high degree of confidence.

Dual-factor authentication is much stronger than password-based authentication, because in the worst-case scenario, only one person at a time can use the cryptographic token. Passwords can be guessed and can be exposed to other users, so in the worst-case scenario an infinite number of people could attempt to gain unauthorized access when resources are protected using password-only authentication.

If you store the secret private key in a file, the key is usually encrypted by a password. The problem with this approach is that the encrypted key is exposed to decryption attacks or spyware/malware running on the client machine. Unlike when using a cryptographic device, the file cannot erase itself automatically after several failed decryption attempts.

What is PKCS#11?

This standard specifies an API, called Cryptoki, to devices which hold cryptographic information and perform cryptographic functions. Cryptoki, pronounced «crypto-key» and short for cryptographic token interface, follows a simple object-based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a cryptographic token.

Source: RSA Security Inc. https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-11-cryptographic-token-interface-standard.htm.

To summarize, PKCS#11 is a standard that can be used by application software to access cryptographic tokens such as smart cards and other devices. Most device vendors provide a library that implements the PKCS#11 provider interface — this library can be used by applications in order to access these devices. PKCS#11 is a cross-platform, vendor-independent free standard.

Finding PKCS#11 provider library

The first thing you need to do is to find the provider library, it should be installed with the device drivers. Each vendor has its own library. For example, the OpenSC PKCS#11 provider is located at /usr/lib/pkcs11/opensc-pkcs11.so on Unix or at opensc-pkcs11.dll on Windows.

How to configure cryptographic token

You should follow an enrollment procedure:

• Initialize the PKCS#11 token.
• Generate RSA key pair on the PKCS#11 token.
• Create a certificate request based on the key pair, you can use OpenSC and OpenSSL in order to do that.
• Submit the certificate request to a certificate authority, and receive a certificate.
• Load the certificate onto the token, while noting that the id and label attributes of the certificate must match those of the private key.

A configured token is a token that has a private key object and a certificate object, where both share the same id and label attributes.

A simple enrollment utility is Easy-RSA 2.0 which is part of OpenVPN 2.1 series. Follow the instructions specified in the README file, and then use the pkitool in order to enroll.

Initialize a token using the following command:

$ ./pkitool --pkcs11-slots /usr/lib/pkcs11/
$ ./pkitool --pkcs11-init /usr/lib/pkcs11/  

Enroll a certificate using the following command:

$ ./pkitool --pkcs11 /usr/lib/pkcs11/   client1

How to modify an OpenVPN configuration to make use of cryptographic tokens

You should have OpenVPN 2.1 or above in order to use the PKCS#11 features.

Determine the correct object

Each PKCS#11 provider can support multiple devices. In order to view the available object list you can use the following command:

$ openvpn --show-pkcs11-ids /usr/lib/pkcs11/

The following objects are available for use.
Each object shown below may be used as parameter to
--pkcs11-id option please remember to use single quote mark.

Certificate
       DN:             /CN=User1
       Serial:         490B82C4000000000075
       Serialized id:  aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600

Each certificate/private key pair have unique «Serialized id» string. The serialized id string of the requested certificate should be specified to the pkcs11-id option using single quote marks.

pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

Using OpenVPN with PKCS#11

A typical set of OpenVPN options for PKCS#11

pkcs11-providers /usr/lib/pkcs11/
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

This will select the object which matches the pkcs11-id string.

Advanced OpenVPN options for PKCS#11

pkcs11-providers /usr/lib/pkcs11/provider1.so /usr/lib/pkcs11/provider2.so
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'
pkcs11-pin-cache 300
daemon
auth-retry nointeract
management-hold
management-signal
management 127.0.0.1 8888
management-query-passwords

This will load two providers into OpenVPN, use the certificate specified on pkcs11-id option, and use the management interface in order to query passwords. The daemon will resume into hold state on the event when token cannot be accessed. The token will be used for 300 seconds after which the password will be re-queried, session will disconnect if management session disconnects.

PKCS#11 implementation considerations

Many PKCS#11 providers make use of threads, in order to avoid problems caused by implementation of LinuxThreads (setuid, chroot), it is highly recommend to upgrade to Native POSIX Thread Library (NPTL) enabled glibc if you intend to use PKCS#11.

OpenSC PKCS#11 provider

OpenSC PKCS#11 provider is located at /usr/lib/pkcs11/opensc-pkcs11.so on Unix or at opensc-pkcs11.dll on Windows.

Difference between PKCS#11 and Microsoft Cryptographic API (CryptoAPI)

PKCS#11 is a free, cross-platform vendor independent standard. CryptoAPI is a Microsoft specific API. Most smart card vendors provide support for both interfaces. In the Windows environment, the user should select which interface to use.

The current implementation of OpenVPN that uses the MS CryptoAPI (cryptoapicert option) works well as long as you don’t run OpenVPN as a service. If you wish to run OpenVPN in an administrative environment using a service, the implementation will not work with most smart cards because of the following reasons:

• Most smart card providers do not load certificates into the local machine store, so the implementation will be unable to access the user certificate.
• If the OpenVPN client is running as a service without direct interaction with the end-user, the service cannot query the user to provide a password for the smart card, causing the password-verification process on the smart card to fail.

Using the PKCS#11 interface, you can use smart cards with OpenVPN in any implementation, since PKCS#11 does not access Microsoft stores and does not necessarily require direct interaction with the end-user.

---

Routing all client traffic (including web-traffic) through the VPN

Overview

By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN. General web browsing, for example, will be accomplished with direct connections that bypass the VPN.

In certain cases this behavior might not be desirable — you might want a VPN client to tunnel all network traffic through the VPN, including general internet web browsing. While this type of VPN configuration will exact a performance penalty on the client, it gives the VPN administrator more control over security policies when a client is simultaneously connected to both the public internet and the VPN at the same time.

Implementation

Add the following directive to the server configuration file:

push "redirect-gateway def1"

If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:

push "redirect-gateway local def1"

Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site’s HTTP proxy.

On Linux, you could use a command such as this to NAT the VPN client traffic to the internet:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

This command assumes that the VPN subnet is 10.8.0.0/24 (taken from the server directive in the OpenVPN server configuration) and that the local ethernet interface is eth0.

When redirect-gateway is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:

push "dhcp-option DNS 10.8.0.1"

will configure Windows clients (or non-Windows clients with some extra server-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.

Caveats

Redirecting all network traffic through the VPN is not entirely a problem-free proposition. Here are some typical gotchas to be aware of:

• Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease.
• Issues exist with respect to pushing DNS addresses to Windows clients.
• Web browsing performance on the client will be noticably slower.

For more information on the mechanics of the redirect-gateway directive, see the manual page.

---

Running an OpenVPN server on a dynamic IP address

While OpenVPN clients can easily access the server via a dynamic IP address without any special configuration, things get more interesting when the server itself is on a dynamic address. While OpenVPN has no trouble handling the situation of a dynamic server, some extra configuration is required.

The first step is to get a dynamic DNS address which can be configured to «follow» the server every time the server’s IP address changes. There are several dynamic DNS service providers available, such as dyndns.org.

The next step is to set up a mechanism so that every time the server’s IP address changes, the dynamic DNS name will be quickly updated with the new IP address, allowing clients to find the server at its new IP address. There are two basic ways to accomplish this:

• Use a NAT router appliance with dynamic DNS support (such as the Linksys BEFSR41). Most of the inexpensive NAT router appliances that are widely available have the capability to update a dynamic DNS name every time a new DHCP lease is obtained from the ISP. This setup is ideal when the OpenVPN server box is a single-NIC machine inside the firewall.
• Use a dynamic DNS client application such as ddclient to update the dynamic DNS address whenever the server IP address changes. This setup is ideal when the machine running OpenVPN has multiple NICs and is acting as a site-wide firewall/gateway. To implement this setup, you need to set up a script to be run by your DHCP client software every time an IP address change occurs. This script should (a) run ddclientto notify your dynamic DNS provider of your new IP address and (b) restart the OpenVPN server daemon.

The OpenVPN client by default will sense when the server’s IP address has changed, if the client configuration is using a remote directive which references a dynamic DNS name. The usual chain of events is that (a) the OpenVPN client fails to receive timely keepalive messages from the server’s old IP address, triggering a restart, and (b) the restart causes the DNS name in the remote directive to be re-resolved, allowing the client to reconnect to the server at its new IP address.

More information can be found in the FAQ.

---

Connecting to an OpenVPN server via an HTTP proxy.

OpenVPN supports connections through an HTTP proxy, with the following authentication modes:

• No proxy authentication
• Basic proxy authentication
• NTLM proxy authentication

First of all, HTTP proxy usage requires that you use TCP as the tunnel carrier protocol. So add the following to both client and server configurations:

proto tcp

Make sure that any proto udp lines in the config files are deleted.

Next, add the http-proxy directive to the client configuration file (see the manual page for a full description of this directive).

For example, suppose you have an HTTP proxy server on the client LAN at 192.168.4.1, which is listening for connections on port 1080. Add this to the client config:

http-proxy 192.168.4.1 1080

Suppose the HTTP proxy requires Basic authentication:

http-proxy 192.168.4.1 1080 stdin basic

Suppose the HTTP proxy requires NTLM authentication:

http-proxy 192.168.4.1 1080 stdin ntlm

The two authentication examples above will cause OpenVPN to prompt for a username/password from standard input. If you would instead like to place these credentials in a file, replace stdin with a filename, and place the username on line 1 of this file and the password on line 2.

---

This example is intended show how OpenVPN clients can connect to a Samba share over a routed dev tun tunnel. If you are ethernet bridging (dev tap), you probably don’t need to follow these instructions, as OpenVPN clients should see server-side machines in their network neighborhood.

For this example, we will assume that:

• the server-side LAN uses a subnet of 10.66.0.0/24,
• the VPN IP address pool uses 10.8.0.0/24 (as cited in the server directive in the OpenVPN server configuration file),
• the Samba server has an IP address of 10.66.0.4, and
• the Samba server has already been configured and is reachable from the local LAN.

If the Samba and OpenVPN servers are running on different machines, make sure you’ve followed the section on expanding the scope of the VPN to include additional machines.

Next, edit your Samba configuration file (smb.conf). Make sure the hosts allow directive will permit OpenVPN clients coming from the 10.8.0.0/24 subnet to connect. For example:

hosts allow = 10.66.0.0/24 10.8.0.0/24 127.0.0.1

If you are running the Samba and OpenVPN servers on the same machine, you may want to edit the interfaces directive in the smb.conf file to also listen on the TUN interface subnet of 10.8.0.0/24:

interfaces  = 10.66.0.0/24 10.8.0.0/24

If you are running the Samba and OpenVPN servers on the same machine, connect from an OpenVPN client to a Samba share using the folder name:

\10.8.0.1\sharename

If the Samba and OpenVPN servers are on different machines, use folder name:

\10.66.0.4sharename

For example, from a command prompt window:

net use z: \10.66.0.4sharename /USER:myusername

---

Implementing a load-balancing/failover configuration

Client

The OpenVPN client configuration can refer to multiple servers for load balancing and failover. For example:

remote server1.mydomain
remote server2.mydomain
remote server3.mydomain

will direct the OpenVPN client to attempt a connection with server1, server2, and server3 in that order. If an existing connection is broken, the OpenVPN client will retry the most recently connected server, and if that fails, will move on to the next server in the list. You can also direct the OpenVPN client to randomize its server list on startup, so that the client load will be probabilistically spread across the server pool.

remote-random

If you would also like DNS resolution failures to cause the OpenVPN client to move to the next server in the list, add the following:

resolv-retry 60

The 60 parameter tells the OpenVPN client to try resolving each remote DNS name for 60 seconds before moving on to the next server in the list.

The server list can also refer to multiple OpenVPN server daemons running on the same machine, each listening for connections on a different port, for example:

remote smp-server1.mydomain 8000
remote smp-server1.mydomain 8001
remote smp-server2.mydomain 8000
remote smp-server2.mydomain 8001

If your servers are multi-processor machines, running multiple OpenVPN daemons on each server can be advantageous from a performance standpoint.

OpenVPN also supports the remote directive referring to a DNS name which has multiple A records in the zone configuration for the domain. In this case, the OpenVPN client will randomly choose one of the A records every time the domain is resolved.

Server

The simplest approach to a load-balanced/failover configuration on the server is to use equivalent configuration files on each server in the cluster, except use a different virtual IP address pool for each server. For example:

server1

server 10.8.0.0 255.255.255.0

server2

server 10.8.1.0 255.255.255.0

server3

server 10.8.2.0 255.255.255.0

---

Hardening OpenVPN Security

One of the often-repeated maxims of network security is that one should never place so much trust in a single security component that its failure causes a catastrophic security breach. OpenVPN provides several mechanisms to add additional security layers to hedge against such an outcome.

tls-auth

The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

• DoS attacks or port flooding on the OpenVPN UDP port.
• Port scanning to determine which server UDP ports are in a listening state.
• Buffer overflow vulnerabilities in the SSL/TLS implementation.
• SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:

openvpn --genkey --secret ta.key

This command will generate an OpenVPN static key and write it to the file ta.key. This key should be copied over a pre-existing secure channel to the server and all client machines. It can be placed in the same directory as the RSA .key and .crt files.

In the server configuration, add:

tls-auth ta.key 0

In the client configuration, add:

tls-auth ta.key 1

proto udp

While OpenVPN allows either the TCP or UDP protocol to be used as the VPN carrier connection, the UDP protocol will provide better protection against DoS attacks and port scanning than TCP:

proto udp

user/group (non-Windows only)

OpenVPN has been very carefully designed to allow root privileges to be dropped after initialization, and this feature should always be used on Linux/BSD/Solaris. Without root privileges, a running OpenVPN server daemon provides a far less enticing target to an attacker.

user nobody
group nobody

Unprivileged mode (Linux only)

On Linux OpenVPN can be run completely unprivileged. This configuration is a little more complex, but provides best security.

In order to work with this configuration, OpenVPN must be configured to use iproute interface, this is done by specifying —enable-iproute2 to configure script. sudo package should also be available on your system.

This configuration uses the Linux ability to change the permission of a tun device, so that unprivileged user may access it. It also uses sudo in order to execute iproute so that interface properties and routing table may be modified.

OpenVPN configuration:

• • Write the following script and place it at: /usr/local/sbin/unpriv-ip:

#!/bin/sh
sudo /sbin/ip $*

• • Execute visudo, and add the followings to allow user ‘user1’ to execute /sbin/ip:

user1 ALL=(ALL)  NOPASSWD: /sbin/ip

• You can also enable a group of users with the following command:

%users ALL=(ALL)  NOPASSWD: /sbin/ip

• • Add the following to your OpenVPN configuration:

dev tunX/tapX
iproute /usr/local/sbin/unpriv-ip

• Please note that you must select constant X and specify tun or tap not both.
  • As root add persistant interface, and permit user and/or group to manage it, the following create tunX (replace with your own) and allow user1 and group users to access it.

openvpn --mktun --dev tunX --type tun --user user1 --group users

• Run OpenVPN in the context of the unprivileged user.

Further security constraints may be added by examining the parameters at the /usr/local/sbin/unpriv-ip script.

chroot (non-Windows only)

The chroot directive allows you to lock the OpenVPN daemon into a so-called chroot jail, where the daemon would not be able to access any part of the host system’s filesystem except for the specific directory given as a parameter to the directive. For example,

chroot jail

would cause the OpenVPN daemon to cd into the jail subdirectory on initialization, and would then reorient its root filesystem to this directory so that it would be impossible thereafter for the daemon to access any files outside of jail and its subdirectory tree. This is important from a security perspective, because even if an attacker were able to compromise the server with a code insertion exploit, the exploit would be locked out of most of the server’s filesystem.

Caveats: because chroot reorients the filesystem (from the perspective of the daemon only), it is necessary to place any files which OpenVPN might need after initialization in the jail directory, such as:

• the crl-verify file, or
• the client-config-dir directory.

Larger RSA keys

The RSA key size is controlled by the KEY_SIZE variable in the easy-rsa/vars file, which must be set before any keys are generated. Currently set to 1024 by default, this value can reasonably be increased to 2048 with no negative impact on VPN tunnel performance, except for a slightly slower SSL/TLS renegotiation handshake which occurs once per client per hour, and a much slower one-time Diffie Hellman parameters generation process using the easy-rsa/build-dh script.

Larger symmetric keys

By default OpenVPN uses Blowfish, a 128 bit symmetrical cipher.

OpenVPN automatically supports any cipher which is supported by the OpenSSL library, and as such can support ciphers which use large key sizes. For example, the 256-bit version of AES (Advanced Encryption Standard) can be used by adding the following to both server and client configuration files:

cipher AES-256-CBC

Keep the root key (ca.key) on a standalone machine without a network connection

One of the security benefits of using an X509 PKI (as OpenVPN does) is that the root CA key (ca.key) need not be present on the OpenVPN server machine. In a high security environment, you might want to specially designate a machine for key signing purposes, keep the machine well-protected physically, and disconnect it from all networks. Floppy disks can be used to move key files back and forth, as necessary. Such measures make it extremely difficult for an attacker to steal the root key, short of physical theft of the key signing machine.

---

Revoking Certificates

Revoking a certificate means to invalidate a previously signed certificate so that it can no longer be used for authentication purposes.

Typical reasons for wanting to revoke a certificate include:

• The private key associated with the certificate is compromised or stolen.
• The user of an encrypted private key forgets the password on the key.
• You want to terminate a VPN user’s access.

Example

As an example, we will revoke the client2 certificate, which we generated above in the «key generation» section of the HOWTO.

First open up a shell or command prompt window and cd to the easy-rsa directory as you did in the «key generation» section above. On Linux/BSD/Unix:

. ./vars
./revoke-full client2

On Windows:

vars
revoke-full client2

You should see output similar to this:

Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
Revoking Certificate 04.
Data Base Updated
Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
client2.crt: /C=KG/ST=NA/O=OpenVPN-TEST/CN=client2/emailAddress=me@myhost.mydomain
error 23 at 0 depth lookup:certificate revoked

Note the «error 23» in the last line. That is what you want to see, as it indicates that a certificate verification of the revoked certificate failed.

The revoke-full script will generate a CRL (certificate revocation list) file called crl.pem in the keyssubdirectory. The file should be copied to a directory where the OpenVPN server can access it, then CRL verification should be enabled in the server configuration:

crl-verify crl.pem

Now all connecting clients will have their client certificates verified against the CRL, and any positive match will result in the connection being dropped.

CRL Notes

• When the crl-verify option is used in OpenVPN, the CRL file will be re-read any time a new client connects or an existing client renegotiates the SSL/TLS connection (by default once per hour). This means that you can update the CRL file while the OpenVPN server daemon is running, and have the new CRL take effect immediately for newly connecting clients. If the client whose certificate you are revoking is already connected, you can restart the server via a signal (SIGUSR1 or SIGHUP) and flush all clients, or you can telnet to the management interfaceand explicitly kill the specific client instance object on the server without disturbing other clients.
• While the crl-verify directive can be used on both the OpenVPN server and clients, it is generally unnecessary to distribute a CRL file to clients unless a server certificate has been revoked. Clients don’t need to know about other client certificates which have been revoked because clients shouldn’t be accepting direct connections from other clientsin the first place.
• The CRL file is not secret, and should be made world-readable so that the OpenVPN daemon can read it after root privileges have been dropped.
• If you are using the chrootdirective, make sure to put a copy of the CRL file in the chroot directory, since unlike most other files which OpenVPN reads, the CRL file will be read after the chroot call is executed, not before.
• A common reason why certificates need to be revoked is that the user encrypts their private key with a password, then forgets the password. By revoking the original certificate, it is possible to generate a new certificate/key pair with the user’s original common name.

---

Important Note on possible «Man-in-the-Middle» attack if clients do not verify the certificate of the server they are connecting to.

To avoid a possible Man-in-the-Middle attack where an authorized client tries to connect to another client by impersonating the server, make sure to enforce some kind of server certificate verification by clients. There are currently five different ways of accomplishing this, listed in the order of preference:

• [OpenVPN 2.1 and above]Build your server certificates with specific key usage and extended key usage. The RFC3280 determine that the following attributes should be provided for TLS connections:
  

  Mode	Key usage	Extended key usage
  Client	digitalSignature	TLS Web Client Authentication
  keyAgreement
  digitalSignature, keyAgreement
  Server	digitalSignature, keyEncipherment	TLS Web Server Authentication
  digitalSignature, keyAgreement

  You can build your server certificates with the build-key-server script (see the easy-rsadocumentation for more info). This will designate the certificate as a server-only certificate by setting the right attributes. Now add the following line to your client configuration:

  remote-cert-tls server

• [OpenVPN 2.0 and below] Build your server certificates with the build-key-server script (see the easy-rsa documentation for more info). This will designate the certificate as a server-only certificate by setting nsCertType=server. Now add the following line to your client configuration:
  

  ns-cert-type server

  This will block clients from connecting to any server which lacks the nsCertType=server designation in its certificate, even if the certificate has been signed by the ca file in the OpenVPN configuration file.

• Use the tls-remotedirective on the client to accept/reject the server connection based on the common name of the server certificate.
• Use a tls-verifyscript or plugin to accept/reject the server connection based on a custom test of the server certificate’s embedded X509 subject details.
• Sign server certificates with one CA and client certificates with a different CA. The client configuration ca directive should reference the server-signing CA file, while the server configuration cadirective should reference the client-signing CA file.