Ethernet bridging essentially involves combining an ethernet interface with one or more virtual TAP interfaces and bridging them together under the umbrella of a single bridge interface. Ethernet bridges represent the software analog to a physical ethernet switch. The ethernet bridge can be thought of as a kind of software switch which can be used to connect multiple ethernet interfaces (either physical or virtual) on a single machine while sharing a single IP subnet.
By bridging a physical ethernet NIC with an OpenVPN-driven TAP interface at two separate locations, it is possible to logically merge both ethernet networks, as if they were a single ethernet subnet.
Bridging Setup
This example will guide you in configuring an OpenVPN server-side ethernet bridge. Multiple clients will be able to connect to the bridge, and each client’s TAP interface will be assigned an IP address that is part of the server’s LAN.
There are two methods for handling client IP address allocation:
- Let OpenVPN manage its own client IP address pool using the server-bridge directive, or
- configure the DHCP server on the LAN to also grant IP address leases to VPN clients.
In this example, we will use the first method where the OpenVPN server manages its own IP address pool on the LAN subnet, separate from the pool used by the DHCP server (if one exists). Both methods are described more fully in this FAQ item.
For our example, we will use these bridge settings:
| Setting | bridge-start parameter | Value |
| Ethernet Interface | eth | eth0 |
| Local IP Address | ip | 192.168.8.4 |
| Local Netmask | eth_netmask | 255.255.255.0 |
| Local Broadcast Address | eth_broadcast | 192.168.8.255 |
| VPN client address pool | 192.168.8.128 to 192.168.8.254 | |
| Virtual Bridge Interface | br | br0 |
| Virtual TAP Interface | tap | tap0 |
The first step is to follow the HOWTO up to the «Starting up the VPN and testing for initial connectivity» section. Next, proceed below according to whether you are setting up the bridge on Linux or Windows.
Bridge Server on Linux
First, make sure you have the bridge-utils package installed.
Edit the bridge-start script below. Set the br, tap, eth, eth_ip, eth_netmask, and eth_broadcast parameters according to the physical ethernet interface you would like to bridge. Make sure to use an interface which is private and which is connected to a LAN which is protected from the internet by a firewall. You can use the Linux ifconfig command to get the necessary information about your network interfaces to fill in the bridge-start parameters.
Now run the bridge-start script. It will create a persistent tap0 interface and bridge it with the active ethernet interface.
Next, we will edit the OpenVPN server configuration file to enable a bridging configuration.
Comment out the line which says dev tun and replace it instead with:
dev tap0
Comment out the line that begins with server and replace it with:
server-bridge 192.168.8.4 255.255.255.0 192.168.8.128 192.168.8.254
iptables -A INPUT -i tap0 -j ACCEPT iptables -A INPUT -i br0 -j ACCEPT iptables -A FORWARD -i br0 -j ACCEPT
The OpenVPN bridge can now be started and stopped using this sequence::
- run bridge-start
- run openvpn
- stop openvpn
- run bridge-stop
At this point, the bridging-specific aspects of the configuration are complete, and you can continue where you left off in the HOWTO.
Bridge Server on Windows XP
This configuration requires Windows XP or higher on the bridge side. To my knowledge, Windows 2000 does not support bridging, however a Windows 2000 machine can be a client on a bridged network, where the other end of the OpenVPN connection where the bridging is occurring is a Linux or Windows XP machine.
When OpenVPN is installed on Windows, it automatically creates a single TAP-Win32 adapter which will be assigned a name like «Local Area Connection 2». Go to the Network Connections control panel and rename it to «tap-bridge».
Next select tap-bridge and your ethernet adapter with the mouse, right click, and select Bridge Connections. This will create a new bridge adapter icon in the control panel.
Set the TCP/IP properties on the bridge adapter to an IP of 192.168.8.4 and a subnet mask of 255.255.255.0.
Next, edit the OpenVPN server configuration file to enable a bridging configuration.
Comment out the line which says dev tun and replace it instead with:
dev tap dev-node tap-bridge
Comment out the line that begins with server and replace it with:
server-bridge 192.168.8.4 255.255.255.0 192.168.8.128 192.168.8.254
At this point, the bridging-specific aspects of the configuration are complete, and you can continue where you left off in the HOWTO.
Bridge Client configuration
Use the sample OpenVPN client configuration as a starting point. Comment out the line which says dev tun and replace it instead with:
dev tap
Finally, ensure that the client configuration file is consistent with the directives used in the server configuration. The major thing to check for is that the proto (udp or tcp) directives are consistent. Also make sure that comp-lzo and fragment, if used, are present in both client and server config files.
Ethernet Bridging Notes
When using an ethernet bridging configuration, the first step is to construct the ethernet bridge — a kind of virtual network interface which is a container for other ethernet interfaces, either real as in physical NICs or virtual as in TAP interfaces. The ethernet bridge interface must be set up before OpenVPN is actually started.
There is no portable method for generating an ethernet bridge interface — each OS has its own method (see below for examples).
Once the bridge interface has been created, and appropriate ethernet interfaces have been added to it, OpenVPN may be started.
- A bridge interface is a kind of virtual network interface which is formed by combining one or more ethernet interfaces, each of which may be a physical NIC or a virtual TAP interface used for VPN tunneling.
- When you set up an ethernet bridge, you should manually set the IP address and subnet of the bridge interface and not use an ifconfig directive in the OpenVPN config. This is because unlike a TUN/TAP interface, OpenVPN cannot programmatically set the IP address and netmask of a bridge interface.
- The OpenVPN config should specify the TAP interface component of the bridge interface in its devdirective, not the name of the bridge interface itself.
- On Windows, use the dev-node directive to name the TAP-Win32 adapter which was added to the bridge (the dev-node name refers to the adapter name as shown in the Network Connections panel).
- On Linux/BSD/Unix, for the dev tap directive, use the explicit TUN/TAP unit number which you added to the bridge such as dev tap0.
- If you are running OpenVPN in point-to-point mode, omit an ifconfig directive, and if you are using client/server mode, use the server-bridge directive on the server.
- When bridging, you must manually set the TCP/IP settings on the bridge interface. For example on Linux, this can be done with an ifconfig command while on Windows XP it can be done by setting the TCP/IP properties of the bridge interface in the Network Connections panel (the Network Connections panel on Windows XP and higher allows for point-and-click bridging).
- Make sure to only bridge TAP interfaces with private ethernet interfaces which are protected behind a firewall. Never bridge a TAP interface with the same ethernet interface you use to connect to the internet, as that would create a potential security hole.
- The addresses used for local and remote should not be part of the bridged subnet — otherwise you will end up with a routing loop.
- An important point to understand with Ethernet bridging is that each network interface which is added to the bridge will lose its individual identity in terms of specific settings such as IP address and netmask. Only the TCP/IP settings of the bridge interface itself will be relevent.
- A common mistake that people make when manually configuring an Ethernet bridge is that they add their primary ethernet adapter to the bridge before they have set the IP and netmask of the bridge interface. The result is that the primary ethernet interface «loses» its settings, but the equivalent bridge interface settings have not yet been defined, so the net effect is a loss of connectivity on the ethernet interface.
- In most cases, it is possible to set up a usable bridge configuration with the ethernet-bridge itself only configured on the server side, not the client side. If this is done, the client machines will become multi-homed when they connect to the server, i.e. they will still have their regular ethernet interface, but upon connection to the OpenVPN server, they will now have a new TAP interface which is bridged with the server’s ethernet interface (and possibly all of the TAP interfaces of other connecting clients as well if the client-to-client directive is used on the server).
Notes — Ethernet Bridging on Windows
The Windows Notes page has additional information on ethernet bridging.
Notes — Ethernet Bridging on Linux, Setup Scripts
These scripts will handle bridge setup and shutdown on Linux. They are available in the sample-scripts subdirectory of the OpenVPN tarball.
sample-scripts/bridge-start
#!/bin/bash
#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################
# Define Bridge Interface
br="br0"
# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"
# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="192.168.8.4"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.8.255"
for t in $tap; do
openvpn --mktun --dev $t
done
brctl addbr $br
brctl addif $br $eth
for t in $tap; do
brctl addif $br $t
done
for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast
sample-scripts/bridge-stop
#!/bin/bash
####################################
# Tear Down Ethernet bridge on Linux
####################################
# Define Bridge Interface
br="br0"
# Define list of TAP interfaces to be bridged together
tap="tap0"
ifconfig $br down
brctl delbr $br
for t in $tap; do
openvpn --rmtun --dev $t
done
Глава 6. «Режим клиент/сервер» с tap-устройствами
Другая модель развертывания для OpenVPN является — один сервер с несколькими удаленными клиентами, способных к маршрутизации трафика Ethernet. Мы называем эту модель развертывания режимом клиент-сервер с tap-устройствами.
Основное различие между режимами tun и tap заключается в типе используемого адаптера. tap-адаптер обеспечивает полностью виртуальный интерфейс Ethernet (уровень 2), в то время как адаптер tun рассматривается большинством операционных систем как двухточечный (уровень 3).
Компьютеры, подключенные с использованием (виртуальных) адаптеров Ethernet, могут образовывать единый широковещательный домен, который необходим для определенных приложений. С двухточечными адаптерами это невозможно. Также обратите внимание, что не все операционные системы поддерживают tap-адаптеры. Например, iOS и Android поддерживают только tun-устройства.
В этой главе мы начнем с базовой настройки клиент-сервер, которая очень похожа на базовую настройку, описанную в Главе 4, Режим клиент-сервер с tun-устройствами. Однако существуют тонкие различия, которые будут обсуждаться на нескольких примерах. Кроме того, режим tap включает настройку мостового соединения, при котором обычный сетевой адаптер соединяется с виртуальным tap-адаптером. Эта тема будет подробно обсуждаться как для операционных систем Linux, так и для Windows.
В этой главе будут рассмотрены следующие темы:
- Базовая настройка
- Включение клиент-клиентского трафика с использованием
pf - Bridging
- Соединение в Linux
- Соединение в Windows
- Использование внешнего DHCP-сервера
- Проверка широковещательного и не IP-трафика
- Сравнение режима Tun с режимом Tap
Базовая настройка
Базовая настройка OpenVPN в режиме tap практически такая же, как и в режиме tun. В режиме tap мы используем следующую строку в файле конфигурации сервера:
В режиме tun мы используем следующие строки:
Опция topology subnet не требуется, но представляет схему сетевой адресации, которая является более разумной и будет использоваться по умолчанию в будущей версии OpenVPN.
Для полноты картины сначала создадим файл конфигурации сервера:
proto udp
port 1194
dev tap
server 10.222.0.0 255.255.255.0
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
verb 3
daemon
log-append /var/log/openvpn.log
Мы будем использовать этот основной файл конфигурации сервера в режиме tap в этой главе и других. Сохраните его как tap-udp-server.conf, чтобы мы могли использовать его позже.
Заметка
Параметр topology subnet был удален, поскольку параметр topology является параметром конфигурации, специфичным для tun. В режиме tap сервер всегда раздает каждому клиенту по одному IP-адресу с соответствующей маской сети.
Точно так же мы создаем файл конфигурации клиента, который снова почти идентичен файлу basic-udp-client.conf из главы 4, Режим клиент/сервер с устройствами tun:
proto udp
port 1194
dev tap
client
remote openvpnserver.example.com
nobind
remote-cert-tls server
tls-auth /etc/openvpn/movpn/ta.key 1
ca /etc/openvpn/movpn/movpn-ca.crt
cert /etc/openvpn/movpn/client1.crt
key /etc/openvpn/movpn/client1.key
Сохраните этот файл как tap-udp-client.conf. Аналогично, для клиентов Windows создайте файл конфигурации tap-udp-client.ovpn.
Запустите сервер OpenVPN и подключите клиент, используя эти файлы конфигурации. Журнал соединений на стороне сервера покажет некоторые тонкие различия по сравнению с настройкой в режиме tun, которые выделены в следующем разделе:
OpenVPN 2.3.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL]
[PKCS11] [MH] [IPv6] built on Dec 2 2014
library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.03
[…]
TUN/TAP device tap0 opened
TUN/TAP TX queue length set to 100
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbinip link set dev tap0 up mtu 1500
sbinip addr add dev tap0 10.222.0.1/24 broadcast 10.222.0.255
GID set to nobody
UID set to nobody
UDPv4 link local (bound): [undef]
UDPv4 link remote: [undef]
MULTI: multi_init called, r=256 v=256
IFCONFIG POOL: base=10.222.0.2 size=253, ipv6=0
Initialization Sequence Completed
CLIENT_IP:60728 TLS: Initial packet from [AF_INET]CLIENT_IP:60728,
sid=d4d7f1fd 988e4ff3
[…]
client1/CLIENT_IP:60728 PUSH: Received control message:
'PUSH_REQUEST'
client1/CLIENT_IP:60728 SENT CONTROL [client1]: 'PUSH_REPLY,routegateway 10.222.0.1,ping 10,ping-restart 60,ifconfig 10.222.0.2
255.255.255.0' (status=1)
client1/CLIENT_IP:60728 MULTI: Learn: 8e:66:e4:43:35:a1 ->
client1/CLIENT_IP:60728
Последняя строка журнала подключения к серверу — самая интересная: строка MULTI: Learn показывает, что сервер теперь использует MAC-адрес удаленного клиента, чтобы отличать его от других клиентов, тогда как в режиме tun он может полагаться исключительно на IP-адрес, назначенный клиенту. Это необходимо, так как клиент на основе tap может также отправлять не-IP трафик, в котором не используется IP-адрес.
Включение клиент-клиентского трафика
Когда к серверу подключено несколько клиентов виртуальной частной сети (VPN) — им не разрешается обмениваться трафиком. Это верно как для режима tap, так и для режима tun. Чтобы включить трафик между клиентами, есть два варианта:
- Использование параметра конфигурации
client-to-client. Он позволяет OpenVPN обрабатывать трафик клиент-клиент внутри системы, минуя таблицы системной маршрутизации, а также правила системного брандмауэра/iptables. - Использование системной таблицы маршрутизации и правил брандмауэра/iptables для отправки трафика от одного клиента другому и обратно.
Первый вариант — самый быстрый как с точки зрения конфигурации, так и с точки зрения производительности. Если нет ограничений на трафик между VPN-клиентами — добавьте строку client-to-client в файл конфигурации tap-udp-server.conf, сохраните его как movpn-06-01-server.conf и перезапустите сервер OpenVPN, используя этот файл конфигурации:
$ openvpn --config movpn-06-01-server.conf
Переподключите VPN-клиентов. Первому клиенту назначен IP-адрес 10.222.0.2, а второму — 10.222.0.3. Теперь клиенты могут связаться друг с другом:
Высокая задержка (то есть время проверки связи более 300 мс) на предыдущем снимке экрана немедленно показывает один из недостатков использования трафика клиент-клиент по VPN. Весь трафик проходит через сервер OpenVPN, таким образом, пинг от client1 к client2 занимает больше времени:
- Сообщение запроса ping отправляется с
client1на сервер OpenVPN. - Сервер OpenVPN пересылает сообщение на
client2. client2отправляет обратно ответное сообщение ping снова на сервер.- Сервер OpenVPN пересылает ответ ping обратно на
client1.
Если клиенты VPN подключены через сеть с высокой латентностью, то использование VPN модели клиент-сервер увеличит задержку при отправке трафика между клиентами. OpenVPN — это такая же модель VPN клиент-сервер как и большинство доступных коммерческих решений VPN. Существуют некоторые одноранговые VPN-решения, но они выходят за рамки этой книги.
Фильтрация трафика между клиентами
Недостатком опции client-to-client является отсутствие фильтрации. Когда эта опция добавлена, весь трафик между всеми клиентами разрешен в обход правил системного брандмауэра/iptables.
Вторым способом обеспечения прохождения трафика между клиентами является использование таблиц маршрутизации системы. В режиме tun это сделать довольно просто, но немного сложнее при использовании режима tap. Когда client1 желает связаться с client2, он сначала должен знать MAC (аппаратный) адрес client2 . Запрос ARP отправляется через адаптер tap клиента и достигает сервера OpenVPN. Серверный процесс OpenVPN перенаправляет ARP-запрос из своего собственного tap-адаптера и ожидает ответа. Однако ответ должен прийти от другого VPN-клиента, который подключен к тому же адаптеру. Таким образом — ARP-запрос должен быть отправлен обратно всем подключенным клиентам сервера OpenVPN. Обычно повторная выдача ARP-запроса не выполняется и трафик клиент-клиент терпит неудачу.
В современных ядрах Linux (2.6.34+ или в ядрах с опциями обратного переноса) для каждого интерфейса может быть установлен специальный флаг proxy_arp_pvlan. Этот флаг указывает ядру Linux повторно отправить ARP-запрос обратно с того же интерфейса, откуда он поступил. Именно этот флаг необходим для работы трафика клиент-клиент. Таким образом мы включаем трафик клиент-клиент в режиме tap, не используя опцию client-to-client, устанавливая этот флаг:
# echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp_pvlan
Заметка
Этот системный флаг можно установить только после настройки адаптера tap0. Адаптер tap может быть создан до запуска OpenVPN (см. Раздел Мостовое соединение в Linux) или флаг может быть установлен после запуска OpenVPN. В этом случае, он может быть установлен автоматически с использованием скрипта, как описано в Главе 7, Скрипты и плагины.
Когда client1 хочет связаться с client2 — поток сетевого трафика с этим установленным флагом выглядит следующим образом:
client1отправляет запрос ARP из своего tap-адаптера.- Сервер OpenVPN получает ARP-запрос и перенаправляет его из собственного адаптера tap0.
- ARP-запрос проходит через системную маршрутизацию и таблицу пересылки iptables.
- Если запрос разрешен — он отправляется всем сетевым интерфейсам на сервере OpenVPN, включая адаптер tap0, откуда был отправлен. Последнее вызвано флагом
proxy_arp_pvlan. - OpenVPN получает ARP-запрос и перенаправляет его всем подключенным клиентам OpenVPN.
client2получает запрос и отвечает. ARP-ответ теперь отправляется обратно на сервер OpenVPN.- Сервер OpenVPN пересылает ARP-ответ
client1. client1теперь знает, где найтиclient2и может отправлять сетевой трафикclient2.
Второй шаг позволяет нам отфильтровать трафик между разными клиентами. Правила фильтрации (например, с использованием iptables) могут быть добавлены для разрешения только определенных типов трафика или только трафика между специальными клиентами. Например, следующее правило iptables блокирует трафик между первым и вторым клиентом OpenVPN:
# iptables -I FORWARD -i tap0 -o tap0
-s 10.222.0.2 -d 10.222.0.3 -j DROP
Обратите внимание, что блокируя трафик в одном направлении, оба клиента не смогут связаться друг с другом. Для однонаправленной блокировки требуются более продвинутые правила iptables.
Заметка
Нет эквивалента для флага proxy_arp_pvlan в операционных системах Windows или Mac OS, но это неточно.
Недостаток метода proxy_arp_pvlan
Основным недостатком использования этого флага ядра является то, что он не превращает VPN в один широковещательный домен Ethernet. С флагом proxy_arp_pvlan клиенты VPN могут связываться друг с другом с помощью ARP-сообщений. Однако они не будут получать широковещательный трафик, приходящий от других клиентов. Когда используется опция client-to-client — все подключенные VPN-клиенты автоматически получают широковещательные сообщения друг друга, но фильтрация трафика сложнее (как мы увидим в следующем разделе).
Фильтрация трафика с использованием фильтра OpenVPN pf
Второй метод фильтрации трафика от клиентов OpenVPN — это использование встроенного фильтра OpenVPN pf. Этот фильтр также полностью поддерживается в OpenVPN Access Server — коммерческом предложении от OpenVPN Technologies Inc. Поддержка фильтра pf является элементарной по сравнению с большинством брандмауэров, но она полностью функциональна и доступна на всех платформах. Теперь мы пройдемся по шагам для использования этого фильтра в свободной версии OpenVPN. Этот пример приведен только в качестве доказательства концепции; станет ясно, что для обслуживания на уровне продакшена необходим другой подход и/или инструмент.
Чтобы использовать фильтр pf — должен использоваться интерфейс управления OpenVPN. Это достигается с помощью следующего файла конфигурации:
proto udp
port 1194
dev tap
server 10.222.0.0 255.255.255.0
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
verb 3
daemon
log-append /var/log/openvpn.log
client-to-client
management 127.0.0.1 12000 stdin
management-client-auth
management-client-pf
Сохраните этот файл как movpn-06-02-server.conf и запустите сервер OpenVPN. Сервер OpenVPN запросит (новый) пароль управления. Этот пароль будет использоваться для аутентификации всех соединений с интерфейсом управления; VPN-клиенты аутентифицируются отдельно. Параметр management-client-pf требует чтобы также был установлен параметр management-client-auth. Недостатком же является то, что теперь каждый клиент должен предоставить (поддельные) имя пользователя и пароль и каждому клиенту должен быть предоставлен доступ на стороне сервера с использованием интерфейса управления.
Файл конфигурации клиента теперь становится:
proto udp
port 1194
dev tap
client
remote openvpnserver.example.com
nobind
remote-cert-tls server
tls-auth /etc/openvpn/movpn/ta.key 1
ca /etc/openvpn/movpn/movpn-ca.crt
cert /etc/openvpn/movpn/client1.crt
key /etc/openvpn/movpn/client1.key
auth-user-pass
Сохраните его как movpn-06-02-client.conf (или movpn-06-02-client.ovpn для Windows).
На стороне сервера сначала запустите интерфейс управления, используя telnet:
# telnet 127.0.0.1 12000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
ENTER PASSWORD:
SUCCESS: password is correct
>INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
Затем запустите клиент OpenVPN. Соединение с сервером не будет завершено пока клиенту не будет предоставлен доступ через интерфейс управления. В интерфейсе управления вы увидите это:
>CLIENT:CONNECT,0,0
>CLIENT:ENV,n_clients=0
>CLIENT:ENV,IV_VER=2.3.6
>CLIENT:ENV,IV_PLAT=linux
>CLIENT:ENV,IV_PROTO=2
[…]
После получения всех строк >CLIENT авторизуйте клиента для подключения. Для этого требуются идентификатор клиента (CID) и идентификатор ключа (KID). Это параметры в самых первых строках >CLIENT при подключении клиента OpenVPN. В этом примере и CID, и KID равны 0. Чтобы предоставить этот клиентский доступ, команда client-auth-nt CID KID должна быть введена в интерфейсе управления:
client-auth-nt 0 0
SUCCESS: client-auth command succeeded
>CLIENT:ESTABLISHED,0CLIENT:CONNECT,0,0
Первый клиент OpenVPN теперь имеет доступ. Теперь мы можем применить правила контроля доступа к этому клиенту, используя команду client-pf CID. Это многострочная команда. После первой строки мы сначала указываем подсети, к которым этому клиенту разрешен доступ:
[SUBNETS ACCEPT]
-10.0.0.0/8
Мы предоставляем клиенту доступ ко всем подсетям, кроме 10.0.0.0/8.
Далее мы указываем, к каким клиентам этот клиент может обратиться:
[CLIENTS ACCEPT]
-client3
Мы разрешаем клиенту связываться со всеми другими клиентами VPN, кроме клиента с именем сертификата /CN = client3. С помощью двух операторов END, одного с квадратными скобками и одного — без, мы закрываем команду client-pf:
client-pf 0
[SUBNETS ACCEPT]
-10.0.0.0/8
[CLIENTS ACCEPT]
-client3
[END]
END
SUCCESS: client-pf command succeeded
Этот клиент OpenVPN теперь сможет обращаться ко всем подсетям на стороне сервера, кроме 10.0.0.0/8, и может связываться со всеми другими клиентами OpenVPN, кроме client3.
У этого подхода много недостатков, но он работает на всех платформах. Основными недостатками являются следующие:
- Каждый клиент должен предоставить поддельное имя_пользователя/пароль
- Каждый клиент должен быть аутентифицирован с использованием интерфейса управления
- Для каждого клиента должен быть установлен фильтр
pf - Интерфейс управления в настоящее время не имеет команд для просмотра текущих фильтров
В настоящее время для свободной версии OpenVPN нет инструмента для отправки этих команд в интерфейс управления. Однако коммерческое программное обеспечение OpenVPN Access Server обеспечивает необходимый механизм для применения правил фильтрации.
Использование устройства tap (мост)
Особый вариант использования конфигурации на основе tap — мостовое соединение. Термин мостовое соединение применяется к функции операционной системы для соединения двух сетевых адаптеров вместе. Когда два (или более) адаптера соединены мостом — весь трафик Ethernet, полученный на одном из адаптеров, перенаправляется на все остальные адаптеры, которые являются частью этого моста. Это позволяет объединить (соединить) два сегмента сети вместе и создать впечатление что это один широковещательный домен Ethernet. Типичные случаи использования мостов:
- Клиенты VPN должны быть полностью и прозрачно интегрированы в LAN на стороне сервера. Обратите внимание, что тот же эффект часто может быть достигнут с помощью настройки
proxy-arp. - Некоторые старые компьютерные игры разрешают многопользовательские игры только тогда, когда все компьютеры являются частью одного и того же широковещательного домена.
- Некоторые устаревшие сетевые протоколы, особенно оригинальный протокол Microsoft NetBIOS (не основанный на TCP/IP), не работают должным образом на сетевых маршрутизаторах или даже предполагают полностью «плоское» сетевое пространство со всеми клиентами, подключенными напрямую.
Мостовые соединения также имеют недостатки, в частности, снижение производительности. Весь сетевой трафик, поступающий на один из мостовых интерфейсов, дублируется на все остальные интерфейсы. Из-за этого довольно легко перегрузить мост многоадресным или широковещательным трафиком. В особенности при настройке VPN с клиентами, использующими соединения с высокой задержкой или низкой пропускной способностью (например, работники на выезде) — эта потеря производительности может быстро сделать настройку OpenVPN непригодной для использования.
Следует также отметить, что мостовая настройка часто не требуется. Благодаря современным операционным системам и протоколам совместного доступа к файлам настройка на основе tun может достичь тех же результатов, прилагая меньше усилий и повышая производительность.
К сожалению, до сих пор распространено заблуждение что для использования общего доступа к файлам Windows через установку OpenVPN необходимо использовать мосты. В разделе Включение общего доступа к файлам через VPN в Главе 5, Расширенные сценарии развертывания в туннельном режиме, подробное объяснение дается о том, как достичь общего доступа к файлам с помощью tun-установки и сервера WINS.
В некоторых случаях мостовая установка остается желательной или необходимой. Теперь мы покажем, как настроить мостовую конфигурацию OpenVPN на платформах Linux и Windows.
Соединение в Linux
Рассмотрим следующую схему сети:
На стороне сервера используется сетевой мост между адаптером LAN eth0 и виртуальным адаптером OpenVPN tap. В Linux это достигается созданием адаптера tap до запуска OpenVPN. Для этого должен быть установлен системный пакет bridge-utils. Шаги следующие:
- Сначала мы создаем скрипт для запуска сетевого моста:
#!/bin/bash
br="br0"
tap="tap0"
eth="eth0"
br_ip="192.168.122.1"
br_netmask="255.255.255.0"
br_broadcast="192.168.122.255"
# Create the tap adapter
openvpn --mktun --dev $tap
# Create the bridge and add interfaces
brctl addbr $br
brctl addif $br $eth
brctl addif $br $tap
# Configure the bridge
ifconfig $tap 0.0.0.0 promisc up
ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $br_ip netmask $br_netmask broadcast $br_broadcast
- Сохраните его как
movpn-bridge-startи убедитесь, что он исполняется с помощью следующей команды:
# chmod 755 movpn-bridge-start
- Затем запустите мост, используя следующую команду:
# ./movpn-bridge-start
Mon Jan 5 18:40:02 2015 TUN/TAP device tap0 opened
Mon Jan 5 18:40:02 2015 Persist state set to: ON
- Теперь мы создаем файл конфигурации для мостовых настроек, используя следующие команды:
tls-server
proto udp
port 1194
dev tap0 ## the '0' is extremely important
server-bridge 192.168.122.1 255.255.255.0 192.168.122.128
192.168.122.200
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
persist-key
persist-tun
keepalive 10 60
user nobody
group nobody
verb 3
daemon
log-append /var/log/openvpn.log
- Сохраните его как
movpn-06-03-server.conf. Аргументами кserver-bridgeявляются сетевой шлюз, маска подсети, начало пула и конец пула. Адреса пула — это адреса, которые могут быть назначены клиентам.
Заметка
Строка dev tap0 в предыдущем примере имеет решающее значение для работы мостового соединения. Мы создали адаптер tap для моста до запуска OpenVPN. Чтобы использовать этот адаптер — мы должны явно указать имя адаптера. В противном случае OpenVPN создаст новый адаптер без моста при запуске.
- Запустите сервер OpenVPN и подключите клиента с помощью файла конфигурации
tap-udp-client.conf, созданного ранее в этой главе. На клиенте Linux в журнале подключений будет показано следующее:
TUN/TAP device tap0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
/sbin/ip link set dev tap0 up mtu 1500
/sbin/ip addr add dev tap0 192.168.122.128/24 broadcast
192.168.122.255
Initialization Sequence Completed
Клиенту назначается первый адрес — 192.168.122.128 из пула доступных адресов.
- Наконец, мы проверяем, что можем достичь хоста в локальной сети на стороне сервера:
[client]$ ping -c 4 192.168.122.246
PING 192.168.122.246 (192.168.122.246) 56(84) bytes of data.
64 bytes from 192.168.122.246: icmp_req=1 ttl=64 time=287 ms
64 bytes from 192.168.122.246: icmp_req=2 ttl=64 time=289 ms
64 bytes from 192.168.122.246: icmp_req=3 ttl=64 time=285 ms
64 bytes from 192.168.122.246: icmp_req=4 ttl=64 time=287 ms
--- 192.168.122.246 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 285.397/287.496/289.568/1.570 ms
Разрыв моста
Когда процесс сервера OpenVPN останавливается — сетевой мост также не отключается автоматически. Поскольку мост был создан до запуска самого OpenVPN — он сохраняется до тех пор, пока не будет разорван вручную. Следующие команды останавливают и удаляют мост, созданный командой movpn-start-bridge:
# ifconfig br0 down
# brctl delif br0 eth0
# brctl delif br0 tap0
# brctl delbr br0
# openvpn --rmtun --dev tap0
Соединение в Windows
Рассмотрим следующую схему сети:
Единственная разница между предыдущим сетевым макетом и этим — выбор используемых IP-адресов.
В Windows адаптер OpenVPN TAP-Win устанавливается при установке самого OpenVPN. Обычно имя для адаптера TAP-Win назначается операционной системой и будет примерно таким же, как для Подключение по локальной сети 4. Аналогично имя адаптера Ethernet, к которому подключена локальная сеть, также будет иметь имя подобное Подключение по локальной сети 2.
Для ясности (и некоторого здравого смысла) мы хотим переименовать интерфейс VPN (TAP):
- Сначала мы идем в Центр управления сетями и общим доступом, а затем Изменение параметров адаптера.
- Переименуйте адаптер TAP-Win как
tapbridgeщелкнув по нему правой кнопкой мыши и выбрав Переименовать. На используемом тестовом компьютере адаптер Ethernet, подключенный к локальной сети, был переименован в eth0. В столбце Состояние укажите сетевую группу, к которой принадлежит интерфейс. В нашем случае он принадлежит TheShire. - Выберите два адаптера, которые необходимо соединить, зажав клавишу Ctrl и щелкнув по каждому адаптеру, а затем щелкнув правой кнопкой мыши и выбрав Настройка моста.
- Убедитесь, что вновь созданный Сетевой мост является частью той же сети, что и исходный адаптер eth0. Вы также можете видеть что оригинальный сетевой адаптер теперь имеет метку Мост в поле Состояние:
- Нет необходимости настраивать статический IP-адрес для моста. Сетевой мост имеет свой собственный (виртуальный) MAC-адрес (или Физический адрес на следующем скриншоте) и, следовательно, ему присваивается свой собственный IP-адрес DHCP-сервером в локальной сети на стороне сервера:
- Создайте файл конфигурации сервера OpenVPN с помощью текстового редактора или Блокнота:
tls-server
proto udp
port 1194
dev tap
dev-node tapbridge ## == the name of the TAP-Win adapter
server-bridge 192.168.3.15 255.255.255.0 192.168.3.128
192.168.3.250
remote-cert-tls client
tls-auth "c://program files/openvpn/config/ta.key" 0
dh "c://program files/openvpn/config/dh2048.pem"
ca "c://program files/openvpn/config/movpn-ca.crt"
cert "c://program files/openvpn/config/server.crt"
key "c://program files/openvpn/config/server.key"
persist-key
persist-tun
keepalive 10 60
verb 3
Сохраните файл конфигурации как movpn-06-04-server.ovpn в каталоге конфигурации OpenVPN (обычно это C:Program FilesOpenVPNconfig).
Заметка
Файл конфигурации сервера для версии OpenVPN для Windows аналогичен файлу конфигурации для Linux. Основными отличиями являются полные пути к файлам сертификатов и ключей, а также способ указания адаптера TAP-WIN с помощью ключевых слов dev и dev-node. Также обратите внимание, что параметры user/group и daemon/logging были удалены.
- Запустите сервер OpenVPN (с повышенными привилегиями):
C:> cd program filesopenvpnconfig
C:> ..binopenvpn --config movpn-06-04-server.ovpn
Обратите внимание, что версия OpenVPN для Windows в командной строке выглядит и ведет себя почти так же, как версия для командной строки Linux.
- Брандмауэр Windows отобразит предупреждение безопасности, когда OpenVPN попытается настроить VPN. Нажмите Разрешить доступ, чтобы предоставить разрешение OpenVPN для настройки VPN как показано на следующем снимке экрана:
- Если мы вернемся к экрану Настройки адаптера — теперь мы видим что и адаптер локальной сети eth0 и адаптер TAP-Win tapbridge в состоянии Включен и имеют статус Мост. Это показано на следующем снимке экрана:
-
Затем подключите клиент Windows с помощью файла конфигурации
tap-udp-client.ovpn, созданного ранее в этой главе. Клиенту будет назначен первый адрес —192.168.3.128из пула доступных адресов. -
Наконец, мы проверяем, что можем достичь хоста в локальной сети на стороне сервера:
- На сервере нажмите функциональную клавишу F4 в командном окне для остановки процесса сервера OpenVPN. Для настройки производственного уровня желательно запускать и останавливать OpenVPN с помощью службы OpenVPN, устанавливаемой вместе с OpenVPN.
Использование внешнего DHCP-сервера
В мостовой конфигурации можно еще больше интегрировать клиентов в серверную сеть. В большинстве сетей для назначения IP-адресов используется DHCP-сервер. Обычно OpenVPN назначает IP-адреса своим клиентам с помощью одной из следующих команд:
server 10.200.0.0 255.255.255.0
Или с помощью следующей команды:
server-bridge 192.168.3.15 255.255.255.0 192.168.3.128
192.168.3.250
Также можно использовать внешний DHCP-сервер для назначения адресов клиентам OpenVPN. Для этого просто удалите спецификацию любых диапазонов IP-адресов после параметра server-bridge как показано в следующем (ориентированном на Linux) файле конфигурации:
tls-server
proto udp
port 1194
dev tap0 ## the '0' is extremely important
server-bridge
remote-cert-tls client
tls-auth etcopenvpn/movpn/ta.key 0
dh etcopenvpn/movpn/dh2048.pem
ca etcopenvpn/movpn/movpn-ca.crt
cert etcopenvpn/movpn/server.crt
key etcopenvpn/movpn/server.key
persist-key
persist-tun
keepalive 10 60
user nobody
group nobody
verb 3
daemon
log-append varlog/openvpn.log
Сохраните его как movpn-06-05-server.conf и запустите сервер OpenVPN.
Когда клиент подключается и запрашивает IP-адрес с помощью DHCP — запрос будет перенаправлен на сервер DHCP в локальной сети на стороне сервера. DHCP-сервер назначает адрес, который отправляется обратно клиенту через сервер OpenVPN.
На клиенте OpenVPN это можно проверить, посмотрев IP-адрес соединения vpn0:
Чтобы убедиться, что этот адрес был назначен сервером DHCP на стороне сервера, мы проверяем таблицу клиентов DHCP на сервере DHCP:
Третья запись в DHCP Client Table на предыдущем скриншоте содержит MAC Address адаптера TAP-Win клиента OpenVPN. Это доказывает, что серверный DHCP-сервер назначил адрес клиенту OpenVPN.
Проверка широковещательного и не IP-трафика
Инструменты tcpdump и wireshark полезны для устранения неполадок в «почти работающей» настройке OpenVPN. Wireshark доступен для Linux, Mac OS X и Windows. Его можно использовать как инструмент командной строки, но чаще всего используется версия на основе графического интерфейса. На большинстве Unix/Linux-платформ также доступен инструмент командной строки tcpdump.
Теперь мы будем использовать tcpdump и wireshark для просмотра потока пакетов через установку VPN на основе tap.
Протокол разрешения адресов трафика
Одним из самых основных типов трафика Ethernet, присутствующего во всех сетях, является трафик протокола разрешения адресов (ARP). ARP является ярким примером протокола Ethernet, который не передается по двухточечным каналам связи (например, при настройке OpenVPN на основе туннеля). Физический уровень (уровень 1) обычно представляет собой электрическую или оптическую связь между системами. В случае VPN — туннель занимает место этого физического соединения. Следующим шагом в модели OSI является уровень Ethernet (уровень 2). Протокол ARP часто используется для обнаружения других систем на этом уровне.
Подсказка
Ethernet является сетевым протоколом уровня 2, а точка-точка — сетевым протоколом уровня 3. Различные уровни протокола определяются моделью Open Systems Interconnection (OSI).
Чтобы наблюдать за потоком ARP-трафика мы сначала запускаем сервер OpenVPN, используя ранее созданный файл конфигурации movpn-06-01-server.conf. Затем подключаем двух клиентов Linux к серверу. После того, как все соединения были успешно установлены — мы запускаем tcpdump на одном из клиентов:
Теперь мы отправляем один пакет ping от одного клиента — другому и смотрим на вывод tcpdump:
На снимке экрана показан трафик ARP между client1 (в данном случае 10.200.0.10) и client2 (10.200.0.11).
- Первый пакет в выводе выше от клиента, которым был инициирован
ping. Клиент должен знать Ethernet MAC-адрес компьютера, который мы проверяем, и, следовательно, он отправляет запрос ARP. - Поскольку мы указали
client-to-clientв файле конфигурации сервераmovpn-06-01-server.conf— ARP-запрос пересылается всем подключенным клиентам и второй клиент OpenVPN отвечает своим MAC-адресом. - Второй пакет — это ответ от второго клиента, указывающий его собственный MAC-адрес.
- Теперь, когда адрес известен,
client1отправляетping. Он отображается какIPv4 ICMP echo request. - Ответ получен от второго клиента. Это четвертый пакет (
IPv4 ICMP echo reply).
Трафик NetBIOS
Common Internet File Sharing (CIFS) начинался как закрытый протокол NetBEUI. Поддержка совместного использования файлов и принтеров осуществлялась через протокол Novell Internetwork Packet eXchange (IPX), а затем был добавлен протокол TCP/IP. В настоящее время протокол обмена файлами Windows развился и поддерживается только через TCP/IP. Поддержка устаревших файловых протоколов все еще присутствует в более старых версиях Windows и именно эту устаревшую поддержку мы будем использовать для запуска трафика не-IP.
Сначала мы устанавливаем и включаем транспортный протокол NWLink IPX/SPX на адаптере TAP-WIN. Затем мы подключаем клиента Windows к установке OpenVPN, которая была запущена с использованием файла конфигурации movpn-06-01-server.conf. В этой конфигурации включен client-to-client; таким образом, все подключенные клиенты должны видеть весь широковещательный трафик Ethernet, поступающий от этого клиента.
Когда клиент Windows успешно подключится к VPN-серверу — он начнет отправлять трафик для объявления своего имени и другой информации об обмене файлами Windows. Он попытается сделать это через TCP/IP, но также с использованием сообщений IPX.
Мы используем Wireshark на втором VPN-клиенте и отслеживаем трафик на интерфейсе tap. На следующем снимке экрана показано, что Windows-клиент WINDOWSXP действительно отправляет широковещательный трафик NetBIOS через TCP/IP. Это записи с адресом источника 10.222.0.3 и адресом назначения 10.222.0.255. Последний адрес является широковещательным адресом TCP/IP для настроенной нами VPN. Мы также видим, что трафик передается по протоколу IPX. Этот трафик выбран и выделен на скриншоте:
Широковещательные сообщения IPX являются широковещательными сообщениями Ethernet, но они не основаны на IP. Это показывает, что установка OpenVPN в стиле tap с client-to-client разделяет весь трафик Ethernet, включая широковещательный трафик между подключенными клиентами (и самим сервером OpenVPN).
Сравнение режима tun с режимом tap
Как мы уже видели в этой главе — есть много сходств, но также есть и существенные различия между VPN в режиме tun и VPN в режиме tap. В этом разделе мы обсудим эти сходства и различия. Большинство различий проистекает из единственного факта что VPN в режиме tun является не широковещательной, а двухточечной IP-сетью, в то время как сеть в режиме tap обеспечивает полностью виртуальную Ethernet-подобную сеть с поддержкой широковещания. Короче говоря, сеть в режиме tun обеспечивает сетевое подключение уровня 3, тогда как сеть в режиме tap обеспечивает практически все функциональные возможности сети уровня 2.
Особенно с опцией topology subnet настройка на основе TUN напоминает установку без перемычек:
- Опция
server 10.200.0.0 255.255.255.0устанавливает VPN с адресом сервера 10.200.0.1. Каждый клиент получит один адрес из 24 IP-адресной адресации, начиная с 10.200.0.2. - Способ шифрования VPN-трафика и цифровой подписи (HMAC) идентичен.
- Большинство возможностей сценариев применимы к обоим типам VPN. Однако есть некоторые тонкие различия в параметрах для сценария
client-connect. - При правильной настройке конечный пользователь не будет испытывать различий между настройкой на основе tun и VPN-подключением на основе tap.
Эти различия, конечно, гораздо интереснее обсуждать. Некоторые различия очевидны, но есть и некоторые тонкости, которые могут оказать существенное влияние при настройке VPN.
Слой 2 против слоя 3
В сети уровня 2 (т.е. в стиле tap) соседние клиенты могут связаться друг с другом узнав адрес соседа, используя широковещательные ARP-запросы. Широковещательные ARP-запросы позволяют клиентам обнаруживать MAC-адреса других клиентов. Это позволяет клиентам связываться друг с другом по протоколам IP и не-IP.
В сети уровня 3 (в стиле tun) клиенты могут связываться друг с другом только с помощью IP-адресов. MAC-адрес адаптера tun никогда не раскрывается другим VPN-клиентам и даже самому серверу OpenVPN. Из-за этого сетевой пакет уровня 3 немного короче, чем уровня 2. При нормальных обстоятельствах более длинные сетевые пакеты уровня 2 не оказывают негативного влияния на производительность.
Маршрутные различия и iroute
Когда особенно необходима маршрутизация от подсети к подсети между tun и tap есть некоторые существенные различия. В сети в стиле tun необходим файл конфигурации клиента с соответствующим оператором iroute чтобы позволить VPN-серверу получать доступ к клиентам, находящимся в локальной сети на стороне клиента. В качестве примера мы предполагаем, что подсеть 192.168.3.0/24 может быть достигнута через клиента OpenVPN с сертификатом CN=client1. На сервере OpenVPN мы добавили бы файл client-config-dir с именем client1, содержащий инструкцию:
iroute 192.168.3.0 255.255.255.0
И добавили бы системный маршрут в файл конфигурации сервера:
route 192.168.3.0 255.255.255.0
В настройке в стиле tap оператор iroute недопустим и будет просто игнорироваться сервером. Чтобы достичь подсети за VPN-клиентом необходимо добавить системный маршрут на сервере OpenVPN, а шлюз должен указывать на VPN-IP-адрес клиента. Давайте предположим, что для client1 из предыдущего примера назначен фиксированный IP-адрес. Это может быть достигнуто с помощью файла CCD:
ifconfig-push 10.200.0.99 255.255.255.0
В файле конфигурации сервера необходимо добавить маршрут, чтобы таблицы системной маршрутизации знали, что подсеть 192.168.3.0/24 может быть доступна через клиента 10.200.0.99:
route 192.168.3.0 255.255.255.0 10.200.0.99
Это гораздо менее динамично, чем опция режима tun route + iroute.
Фильтрация клиент-клиент
При настройке в стиле tun большая часть трафика может регистрироваться и фильтроваться с использованием правил брандмауэра или iptables. Фильтрация трафика между клиентами OpenVPN намного сложнее при настройке в режиме tap, как было показано ранее в этой главе.
Широковещание трафика и «болтливость» сети
Сеть уровня 3 не позволяет передавать широковещательный трафик по ней. Это и преимущество и недостаток. Некоторые клиент-серверные приложения полагаются на использование широковещательного трафика для связи между сервером и клиентами. Для таких приложений требуется сеть в стиле tap.
Однако широковещательный трафик также имеет тенденцию засорять сети. Даже если на клиенте нет действий пользователя — операционная система будет непрерывно отправлять широковещательный трафик для обнаружения сетевых ресурсов, соседей и т.д. Особенно, когда используются такие протоколы как Universal Plug-and-Play или Apple Bonjour существует много скрытого широковещательного трафика. Для клиентов, подключенных к VPN через сеть с низкой пропускной способностью — это может иметь серьезные последствия для производительности.
Мост
Ключевой особенностью сети в стиле tap является возможность создания мостов. Мостовое соединение невозможно в сети уровня 3.
В некоторых редких случаях эта функция абсолютно необходима, но при любой возможности следует избегать мостовой настройки. Основной причиной неиспользования мостовой настройки является негативное влияние на производительность. Как объяснялось ранее — в мостовой конфигурации весь трафик из локальной сети на стороне сервера перенаправляется через VPN всем клиентам и наоборот. Когда множество клиентов подключены к сетям с низкой пропускной способностью — это может привести к обходу всей сети как на стороне клиента, так и в локальной сети на стороне сервера. Когда клиенты в локальной сети на стороне сервера пытаются обнаружить доступные ресурсы в сети (например, общие файловые ресурсы или принтеры в сети на основе CIFS) — вся сеть будет заполнена широковещательным трафиком. Клиенты локальной сети обычно ждут ответов от всех компьютеров, подключенных к сети, как локальной, так и VPN, прежде чем предлагать доступ к общим сетевым ресурсам или принтерам. Это может быстро привести к недопустимому времени отклика сети в случае когда подключается и отключается большое количество VPN-клиентов.
Резюме
В этой главе мы рассмотрели возможности установки на основе tap в качестве альтернативной модели развертывания OpenVPN. Мы обсудили примеры, подчеркивающие как особенности, так и недостатки такой установки. Особое внимание было уделено настройке с использованием моста, так как существует несколько распространенных заблуждений относительно режима с использованием моста, о чем говорится на форумах поддержки OpenVPN в Интернете.
Мы также увидели, что расширенные функции управления, такие как фильтрация трафика между клиентами OpenVPN, гораздо сложнее реализовать в режиме tap по сравнению с режимом tun.
В следующей главе мы увидим, как можно использовать скрипты и плагины чтобы влиять на то, как сервер OpenVPN назначает IP-адрес клиенту, а также на многие другие функции. Скрипты и плагины могут использоваться как в режиме tap, так и в режиме tun.
Обновлено: 04.01.2023
Опубликовано: 25.01.2017
OpenVPN позволяет настроить VPN-сервер как на платформе Windows Server, так и версии для рабочего компьютера (Windows 10, 8, 7).
Установка сервера
Создание сертификатов
Настройка OpenVPN
Настройка клиента
Доступ к локальной сети
Решение проблем
Установка OpenVPN Server
Переходим на официальный сайт OpenVPN и скачиваем последнюю версию программы для соответствующей версии Windows:
Запускаем скачанный файл — нажимаем Next — I Agree — и выставляем галочку EasyRSA 2/3 Certificate Management Scripts (нужен для возможности сгенерировать сертификаты):
* интерфейсы для старой версии OpenVPN и новой немного различаются. Нам нужно выбрать для установки все пункты.
… снова Next и Install — начнется установка. В процессе мастер может выдать запрос на подтверждение установки виртуального сетевого адаптера — соглашаемся (Install/Установить).
После завершения нажимаем Next — снимаем галочку Show Readme — Finish.
Создание сертификатов
Новая версия OpenVPN позволяет создавать сертификаты на основе Easy RSA 3, старая работает на базе 2-й версии. Наши действия будут различаться в зависимости от данной версии. Рассмотрим процесс формирования сертификата с использованием как RSA3, так и RSA2.
а) Создание сертификатов с RSA 3
1. Переходим в папку установки OpenVPN (по умолчанию, C:Program FilesOpenVPN) и создаем каталог ssl.
2. После переходим в папку C:Program FilesOpenVPNeasy-rsa, переименовываем файл vars.example в vars, открываем его на редактирование и правим одну строку:
set_var EASYRSA_TEMP_DIR «$EASYRSA_PKI/temp»
* мы снимаем комментарий и добавляем temp в конце $EASYRSA_PKI. Если это не сделать, то при попытке сформировать корневого сертификата мы получим ошибку Failed create CA private key.
3. Запускаем командную строку от имени администратора:
4. Переходим в каталог easy-rsa:
cd %ProgramFiles%OpenVPNeasy-rsa
5. Запускаем команду:
EasyRSA-Start.bat
Мы окажемся в среде EasyRSA Shell.
6. Инициализируем PKI:
./easyrsa init-pki
Если система вернет ошибку, выходим из оболочки EasyRSA Shell:
exit
И заходим снова:
EasyRSA-Start.bat
Мы должны увидеть:
init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: C:/Program Files/OpenVPN/easy-rsa/pki
7. Генерируем корневой сертификат (CA):
./easyrsa build-ca
… после ввода Enter обязательно задаем пароль дважды. На запрос ввести Common Name можно просто нажать ввод или написать свое имя:
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:
8. Создаем ключ Диффи-Хеллмана:
./easyrsa gen-dh
9. Для создания сертификата сервера необходимо сначала создать файл запроса:
./easyrsa gen-req cert nopass
* на запрос ввода Common Name просто вводим Enter.
… и на его основе — сам сертификат:
./easyrsa sign-req server cert
После ввода команды подтверждаем правильность данных, введя yes:
Confirm request details: yes
… и вводим пароль, который указывали при создании корневого сертификата.
10. Сертификаты сервера готовы и находятся в каталоге pki. Переносим в C:Program FilesOpenVPNssl следующие файлы:
- ca.crt
- issued/cert.crt
- private/cert.key
- dh.pem
б) Создание сертификатов с RSA 2 (для старых версий OpenVPN)
1. Переходим в папку установки OpenVPN (по умолчанию, C:Program FilesOpenVPN) и создаем каталог ssl.
2. После переходим в папку C:Program FilesOpenVPNeasy-rsa, создаем файл vars.bat, открываем его на редактирование и приводим к следующему виду:
set «PATH=%PATH%;%ProgramFiles%OpenVPNbin»
set HOME=%ProgramFiles%OpenVPNeasy-rsa
set KEY_CONFIG=openssl-1.0.0.cnf
set KEY_DIR=keys
set KEY_SIZE=2048
set KEY_COUNTRY=RU
set KEY_PROVINCE=Sankt-Petersburg
set KEY_CITY=Sankt-Petersburg
set KEY_ORG=Organization
set KEY_EMAIL=master@dmosk.ru
set KEY_CN=DMOSK
set KEY_OU=DMOSK
set KEY_NAME=server.domain.ru
set PKCS11_MODULE_PATH=DMOSK
set PKCS11_PIN=12345678
* в каталоге easy-rsa уже есть файл vars.bat.sample — можно переименовать и использовать его.
** значение HOME не меняем, если оставили путь установки программы по умолчанию; KEY_DIR — каталог, куда будут генерироваться сертификаты; KEY_CONFIG может быть разным — его лучше посмотреть в файле vars.bat.sample или по названию соответствующего файла в папке easy-rsa; KEY_NAME желательно, чтобы соответствовал полному имени VPN-сервера; остальные опции можно заполнить произвольно.
3. Запускаем командную строку от имени администратора:
4. Переходим в каталог easy-rsa:
cd %ProgramFiles%OpenVPNeasy-rsa
4. Запускаем vars.bat:
vars.bat
5. Чистим каталоги от устаревшей информации:
clean-all.bat
* данная команда выполняется один раз, когда на сервере нет информации по ранее созданным сертификатам.
6. Снова запускаем vars.bat (после clean переопределяются некоторые переменные):
vars.bat
Переходим к созданию ключей.
7. Генерируем последовательность центра сертификации:
build-ca.bat
На все запросы нажимаем Enter.
8. Запускаем build-dh.bat (сертификат с использованием алгоритма Диффи-Хеллмана):
openssl dhparam -out keysdh.pem 2048
* команда может выполняться долго — это нормально.
9. Генерируем сертификат для сервера:
build-key-server.bat cert
* где cert — имя сертификата; на все запросы нажимаем Enter. В конце подтверждаем два раза корректность информации вводом y.
10. После переносим из папки C:Program FilesOpenVPNeasy-rsakeys в C:Program FilesOpenVPNssl следующие файлы:
- ca.crt
- cert.crt
- cert.key
- dh.pem
Настройка сервера
Переходим в папку C:Program FilesOpenVPNconfig-auto (или для старой версии C:Program FilesOpenVPNconfig) и создаем файл server.ovpn. Открываем его на редактирование и приводим к следующему виду:
port 443
proto udp
dev tun
dev-node «VPN Server»
dh «C:\Program Files\OpenVPN\ssl\dh.pem»
ca «C:\Program Files\OpenVPN\ssl\ca.crt»
cert «C:\Program Files\OpenVPN\ssl\cert.crt»
key «C:\Program Files\OpenVPN\ssl\cert.key»
server 172.16.10.0 255.255.255.0
max-clients 32
keepalive 10 120
client-to-client
compress
fast-io
cipher AES-256-GCM
persist-key
persist-tun
status «C:\Program Files\OpenVPN\log\status.log»
log «C:\Program Files\OpenVPN\log\openvpn.log»
verb 4
mute 20
* где port — сетевой порт (443 позволит избежать проблем при использовании Интернета в общественных местах, но может быть любым из свободных, например 1194, занятые порты в Windows можно посмотреть командой netstat -a); dev-node — название сетевого интерфейса; server — подсеть, в которой будут работать как сам сервер, так и подключенные к нему клиенты.
** так как в некоторых путях есть пробелы, параметр заносится в кавычках.
*** при использовании другого порта необходимо проверить, что он открыт в брандмауэре или на время тестирования отключить его.
В сетевых подключениях Windows открываем управление адаптерами — TAP-адаптер переименовываем в «VPN Server» (как у нас указано в конфигурационном файле, разделе dev-node):
Теперь открываем службы Windows и находим «OpenVpnService». Открываем ее, настраиваем на автозапуск и включаем:
Если служба в запущенном состоянии, то перезапускаем ее.
Ранее переименованный сетевой интерфейс должен включиться:
VPN-сервер работает. Проверьте, что сетевой адаптер VPN Server получил IP 172.16.10.1. Если он получает что-то, на подобие, 169.254…, выключаем сетевой адаптер — перезапускаем службу OpenVpnService и снова включаем сетевой адаптер.
Если в нашей системе включен брандмауэр, необходимо открыть порт для OpenVPN. Это быстрее всего сделать из командной строки — открываем ее от администратора и вводим:
netsh advfirewall firewall add rule name=»ALLOW OpenVPN» dir=in action=allow protocol=UDP localport=443
* где 443 — наш порт, который мы решили задействовать под OpenVPN; UDP — протокол, который мы настроили в конфигурационном файле сервера.
Настройка клиента
На сервере
На сервере генерируем сертификат для клиента. Для этого сначала чистим файл index.txt в папке C:Program FilesOpenVPNeasy-rsakeys.
Затем запускаем командную строку от имени администратора:
Переходим в каталог easy-rsa:
cd %ProgramFiles%OpenVPNeasy-rsa
Далее наши действия зависят от версии RSA.
а) Создание сертификатов с RSA 3
Запускаем команду:
EasyRSA-Start.bat
Мы окажемся в среде EasyRSA Shell.
Создаем клиентский сертификат:
./easyrsa gen-req client1 nopass
./easyrsa sign-req client client1
Мы должны увидеть запрос на подтверждение намерения выпустить сертификат — вводим yes:
Confirm request details: yes
* в данном примере будет создан сертификат для client1.
После вводим пароль, который указывали при создании корневого сертификата.
Теперь из папки pki копируем файлы:
- issued/client1.crt
- private/client1.key
- ca.crt
- dh.pem
… и переносим их на клиентский компьютер.
б) Создание сертификатов с RSA 2 (для очень старых версий OpenVPN)
Запускаем vars.bat:
vars.bat
И генерируем сертификат первого пользователя:
build-key.bat client1
* на все запросы наживаем Enter, кроме Common Name — в данном поле вводим имя клиента (в нашем случае, просто client1). В конце подтверждаем введенную информацию — y.
** На каждого клиента нужно сгенерировать свой сертификат, в противном случае, им будет присваиваться один и тот же IP-адрес, что будет приводить к конфликту.
Получиться, что-то на подобие:
Country Name (2 letter code) [RU]:
State or Province Name (full name) [Sankt-Petersburg]:
Locality Name (eg, city) [Sankt-Petersburg]:
Organization Name (eg, company) [Organization]:
Organizational Unit Name (eg, section) [DMOSK]:
Common Name (eg, your name or your server’s hostname) [DMOSK]:client1
Name [server.domain.ru]:
Email Address [master@dmosk.ru]:
По умолчанию, для Common Name будет подставляться значение из vars.bat — но с ним сертификат не будет создаваться. Необходимо при создании каждого ключа подставлять значение, равное имени сертификата. Например, как выше — подставлено client1.
Теперь из папки keys копируем файлы:
- client1.crt
- client1.key
- ca.crt
- dh.pem
… и переносим их на клиентский компьютер.
На клиенте
Заходим на официальную страницу загрузки openvpn и скачиваем клиента для Windows:
* по сути, это тот же файл, который скачивался для сервера.
Запускаем скачанный файл и устанавливаем программу, нажимая «Далее».
Переходим в папку C:Program FilesOpenVPNconfig. И копируем в нее сертификаты, которые перенесли с сервера.
Теперь открываем блокнот от имени администратора и вставляем следующие строки:
client
resolv-retry infinite
nobind
remote 192.168.0.15 443
proto udp
dev tun
compress
fast-io
cipher AES-256-GCM
ca ca.crt
cert client1.crt
key client1.key
dh dh.pem
float
keepalive 10 120
persist-key
persist-tun
verb 0
* где 192.168.0.15 443 — IP-адрес OpenVPN-сервера и порт, на котором он принимает запросы. Для боевой среды это будет внешний адрес.
Сохраняем файл с именем config.ovpn в папке C:Program FilesOpenVPNconfig.
Запускаем с рабочего стола программу «OpenVPN GUI» от имени администратора (это важно).
Нажимаем правой кнопкой по появившемуся в трее значку и выбираем «Подключиться»:
Произойдет подключение и значок поменяет цвет с серого/желтого на зеленый.
Доступ к локальной сети
По инструкции выше мы сможем получить доступ только к серверу, на котором установлен OpenVPN. Для получения доступа ко всей внутренней сети, выполним следующие шаги.
1. Настройка реестра
Для включения IP маршрутизации в Windows необходимо в ветке реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters найти параметр IPEnableRouter и задать ему значение 1. Это можно сделать в утилите редактирования реестра (regedit) или командой:
reg add «HKLMSYSTEMCurrentControlSetServicesTcpipParameters» /v IPEnableRouter /t REG_DWORD /d 1 /f
* командную строку необходимо запускать от администратора.
2. Настройка OpenVPN Server
В конфигурационный файл OpenVPN добавим:
push «route 172.16.10.0 255.255.255.0»
push «route 192.168.2.0 255.255.255.0»
* где 172.16.10.0 — VPN сеть; 192.168.2.0 — локальная сеть, в которую необходимо «попасть» пользователям openvpn.
При необходимости использовать DNS внутренней сети также добавим:
push «dhcp-option DNS 192.168.0.15»
push «dhcp-option DNS 192.168.0.16»
push «dhcp-option DOMAIN dmosk.local»
* где 192.168.0.15 и 192.168.0.16 — внутренние DNS-серверы; dmosk.local — домен, который будет добавляться к узлам, обращение к которым идет по неполному имени.
Если нам нужно, чтобы все запросы клиента (в том числе, Интернет) ходили через сервер OpenVPN, добавляем:
push «redirect-gateway def1»
* в таком случае, нам не обязательно добавлять push route, который мы использовали выше.
Перезагружаем службу OpenVpnService.
3. Разрешаем доступ к локальной сети
Заходим в управление сетевыми подключениями (Панель управленияСеть и ИнтернетСетевые подключения). Кликаем правой кнопкой мыши по адаптеру локальной сети — Свойства:
На вкладке Доступ ставим галочку Разрешить другим пользователям сети использовать подключение к Интернету данного компьютера:
… и сохраняем настройки.
Возможные проблемы
Большая часть проблем решается при помощи логов, которые находятся в папке C:Program FilesOpenVPNlog. Уровень детализации лога контролируется параметром verb в конфигурационном файле сервера или клиента.
Также возможны следующие часто возникающие проблемы:
- Проблема: клиент постоянно пытается подключиться к серверу, но соединения не происходит или подключение зависает.
Причина: сервер блокирует подключения по настроенному порту VPN (в нашем примере, 443).
Решение: на сервере необходимо добавить 443 порт в исключения брандмауэра или отключить последний.
- Проблема: при попытке подключиться к серверу выскакивает ошибка «Не удалось подключиться к config».
Причина: ошибка в настройках.
Решение: перепроверьте каждую строчку файла конфигурации. Проверьте наличие всех файлов, на которые ссылаетесь в настройках.
- Проблема: клиенты получают одинаковые IP-адреса.
Причина: подключение выполняется под одним и тем же пользователем.
Решение: сервер выдает одинаковые адреса одинаковым клиентам. Необходимо настроить авторизацию на сервере и выдать каждому клиенту индивидуальные настройки.
- Проблема: соединение происходит, но через несколько минут связь прерывается.
Причина: дублирование IP-адресов.
Решение: данная проблема описана выше (пункт 3).
Возможно, Вы это тоже захотите попробовать
- Настройка OpenVPN-сервера с аутентификацией через LDAP (Active Directory) на Ubuntu Server
- Установка и настройка OpenVPN на Linux CentOS 7
Друзья, приветствую на fast-wolker.ru! Сегодняшний материал жизненно необходим тем, кто задумывает организовать бесплатный и безопасный доступ к своей локальной сети из интернета для удаленной работы из любого места. Существует достаточно решений — одни сложные, требующие денежных вложений.
Другие бесплатны и вполне по силам для самостоятельного и бесплатного внедрения в любой организации. Сегодня мы и решим такую практическую задачу — организуем доступ сотрудников к обычной сети для удаленной работы с помощью программы Open VPN.
Имеется сеть с выделенным IP адресом от провайдера (это обязательное условие для решения нашей задачи!) и нам нужно:
- организовать безопасный и регулярный доступ к сети из другого филиала (со своей сетью) для удаленной работы сотрудников с общей базой данных;
- соединить между собой две разных локальные компьютерные сети;
- компьютеры обоих сетей (клиенты) должны «видеть» друг друга;
- обеспечить удаленным сотрудникам возможность печати документов из общей базы данных на принтеры своего удаленного офиса;
- Доступ к базе данных будет организован через удаленный рабочий стол (терминальный доступ).
Обе наших компьютерных сети не используют домены, Open VPN поэтому — одно из подходящих решений. Мы самостоятельно «поднимем» сначала в нашей сети Openvpn сервер, затем сгенерируем сертификаты пользователей, которые будут подключаться к нему. Настроим наш сервер в соответствии с задачей.
Затем настроим компьютеры со стороны клиентов — установим openvpn и дадим настройки. Материал данной статьи — проверенное и работоспособное решение, оттестированное в течение нескольких лет на различных версиях. Читаем — берем на вооружение!
Содержание
- Как настроить сервер openvpn на windows 10?
- Как настроить сетевой мост между двумя сетями для Open VPN сервера?
- Openvpn клиенты не видят друг друга, как настроить файл конфигурации сервера?
- Как сделать автоматический старт OpenVPN соединения при запуске Windows?
- Как настроить openvpn клиент на Windows10
Как настроить сервер openvpn на windows 10?
Что за программа — Open VPN и зачем она нужна? Данный продукт — бесплатное программное решение в течение многих лет предлагаемое разработчиками для организации бесплатных виртуальных частных сетей. Внутри вашего канала Интернет создается безопасный туннель (в том числе и для решения нашей задачи).
Данные шифруются современными методами шифрования, поэтому расшифровка их без ключа невозможна. Ключи создаются при генерировании сертификата, который выдается пользователю.
Замечательной особенностью open vpn является то что генерация сертификатов производится через собственный «авторизованный центр», и платить за выдачу и продление не нужно. Срок действия сертификата определяется самостоятельно. Изначально программа была разработана для Linux. Но для пользователей Windows так же есть решения на сайте разработчика.
Нужно выбирать версию подходящую для вашей операционной системы. В настоящее время актуальна версия для Windows 10. Ее мы и будем сегодня использовать.
Программа OPEN VPN не имеет обычного механизма автоматического обновления. Новые версии нужно сначала скачивать с сайта разработчика, тестировать. При установке новой версии «поверх» существующей сервер сломается и перестанет работать.
Но пусть вас это не смущает. На одной версии спокойно можно работать года три-четыре. Новые появляются при выходе очередных редакций операционных систем и отличаются размерами ключей, методами шифрования и адаптацией. Как правило, приходится генерить под них новые сертификаты пользователей — ставить всё заново.
Забегая вперед скажу — лучше иметь в сети два таких open vpn сервера — основной и резервный. И издеваться над резервным, а придет время- по образу и подобию обновить основной. Итак, для решения нашей задачи следует сначала подготовить наш будущий сервер к работе. Скачиваем программу с сайта разработчика и устанавливаем на нужный компьютер.
Так как у нас это будет СЕРВЕР, не забываем установить галочку, как на картинке. Данный механизм будет нужен нам чуть позже для изготовления сертификатов и прочего.
После окончания установки идем в «Центр управления сетями и общим доступом» — «изменение параметров адаптера». Обнаруживаем, что установился виртуальный сетевой адаптер (через него будет идти соединение) под именем «Ethernet«.
Если название получилось на русском языке (зависит от версии) — переименовываем на английском . Это важно! Имя адаптера придумываем любое — покороче.
В моем случае необходимо, чтобы клиенты подключаясь к нашей сети видели наши доступные компьютеры, а наши сервера «видели» бы нужные сетевые принтеры в соседней сети. Для этого нам нужно создать сетевой мост — объединить два сетевых устройство между собой.
В нашем случае это наш сетевой адаптер, который «смотрит» в интернет и только что созданный адаптер TAP. Настройки IP обнуляем. Выделяем оба адаптера мышкой и объединяем в «мост»:
После установки устройства «Сетевой мост» нужно сделать ему настройки через «свойства» IP адреса, шлюза, маски а так же адреса DNS -серверов (выданные провайдером) . Если IP не было — назначить постоянный, внутренний. Это важно, без этого наш сервер не заработает!
Настройки IP адаптеров включенных в мост не изменяем и ничего не трогаем!
Отключаем брандмауэр windows. Дополнительно, там же идем в «Разрешение обмена данными с приложениями в брандмауэре Windows, добавляем наш установленный open vpn в список (C:Program FilesOpenVPVBinOpenVPNgui,exe).
Сняли возможную блокировку соединения. Идем далее! Предварительная подготовка почти закончена. Теперь займемся непосредственно сервером. Идем в папку C:Program FilesOpenVPVeasy-rsa
В ней находятся программы с которыми мы сейчас будем взаимодействовать. Открываем командную строку от имени Администратора. Переходим в папку easy-rsa, для чего в командную строку скопируем команду cd C:Program FilesOpenVPNeasy-rsa
Все операции далее совершаем через командную строку. Для создания конфигурации сервера запустим файл init-config.bat
Создастся файл vars.bat, в нем мы заполним информацию, которую будут содержать сертификаты безопасности и с их помощью будут шифроваться данные. Для этого в блокноте открываем файл vars.bat и произвольно заполняем значения (командную строку не закрываем!):
rem down TLS negotiation performance
rem as well as the one-time DH parms
rem generation process.
set DH_KEY_SIZE=2048
rem Private key size
set KEY_SIZE=4096
rem These are the default values for fields
rem which will be placed in the certificate.
rem Change these to reflect your site.
rem Don’t leave any of these parms blank.
set KEY_COUNTRY=US
set KEY_PROVINCE=CA
set KEY_CITY=SanFrancisco
set KEY_ORG=OpenVPN
set KEY_EMAIL=mail@host.domain
set KEY_CN=server
set KEY_NAME=server
set KEY_OU=OU
set PKCS11_MODULE_PATH=changeme
set PKCS11_PIN=1234
Значения «server» не изменяем. Все значения (страна, регион, город, организация, почтовый адрес) проставляем произвольно английским шрифтом. Сохраняем файл. Переходим в командную строку снова. Набираем первой команду Vars.bat
Если OpenVPN устанавливался ранее -набираем команду clean-all.bat Она удалит созданную до этого папку с ключами (keys) со всем содержимым . При установе сервера OpenVPN с нуля делать эту команду необязательно.
Если у вас так как на фото, нормально. Идем далее
Теперь с помощью проводника перейдем в каталог C:Program FilesOpenVPNbin и скопируем файлы библиотек (*.dll) , файл openssl.exe в каталог, где лежат наши исполняемы файлы и который открыт сейчас в командной строке (C:Program FilesOpenVPNeasy-rsa):
Библиотеки нужны в этом каталоге, чтобы не возникало ошибок при создании сертификатов центра авторизации и файла Диффи-Хеллмана. Начнем с последнего. Файл Диффи-Хеллмана препятствует расшифровке информации (если файлы ключей были похищены), а так же отвечает за шифрование. Создадим его для нашего сервера в командной строке набрав команду build-dh.bat
Ждем, пока файл генерируется на основании информации указанной в vars.bat Далее, сгенерируем сертификат нашего удостоверяющего центра. Он будет необходим для дальнейшей выдачи серверного и клиентских сертификатов. Наберем в командной строке команду build-ca.bat Последовательно и не спеша нажимаем клавишу Enter…
…после появления очередной строчки; данные в сертификате будут скопированы по значениям указанным в файле vars.bat Следующий этап — создадим сертификат нашего сервера. В командной строке набираем команду build-key-server.bat server (server -имя серверного сертификата):
Так же последовательно и не спеша нажимаем Enter пока не дойдем до строчки Common Name(eg, your name or your servers hostname Здесь нужно обязательно указать имя сервера ( можно имя компьютера) и нажать Enter.
Далее будут оставшиеся поля и запрос на создание пароля от сертификата. Просто нажимаем Enter. На вопросы записи сертификата и добавления его в базу данных нажимаем Y и Enter
Срок действия сертификата — 10 лет.
Если нужно поменять сроки действия открываем файл openssl 1.00.cnf и в строке default_days редактируем сроки действия серверного и клиентских сертификатов.
Теперь нам необходимо создать файл конфигурации сервера, выбрать протокол соединения, имя сетевого виртуального адаптера, порт соединения и еще много чего.
В папке sample-config лежит пример файла server.ovpn, находим его, открываем блокнотом( от имени администратора!):
Openvpn клиенты не видят друг друга, как настроить файл конфигурации сервера?
Очищаем содержимое server.ovpn и вставляем текст:
# Поднимаем L4-туннель
dev tap
#dev tune
# Имя устройства (указывается имя адаптера openvpn):
dev-node Ethernet
# Протокол, который использую:tcp
#proto udp
proto tcp
# Порт который «слушает» впн (должен быть открыт, не из списка «известных»)
port 13359
#server 10.8.0.0 255.255.255.0
# Данная машина является
#tls-server
#Укажем пулл незанятых разрешенных адресов из нашей локальной сети; укажем IP «моста», его маску а так же диапазон адресов
# Пул разрешенных адресов
server-bridge 192.168.0.1 255.255.255.0 192.168.0.111 192.168.0.121
# Включаю сжатие
comp-lzo
# Разрешаю клиентам видеть друг друга
client-to-client
#назначаю каждому клиенту свой постоянный IP
ifconfig-pool-persist ipp.txt
# Указал ключи и сертификаты (должны находитьcя в папке с конфигом)
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
# Грубо говоря экономим адреса
topology subnet
# Метод шифрования
cipher AES-256-CBC
#при перезагрузке сервера не перечитываем ключи и настройки туннелирования прежние(у меня tap поэтому отключил):
persist-key
#persist-tun
#Максимальный размер блока данных:
tun-mtu 1500
tun-mtu-extra 32
# Немного улучшит пинг
mssfix 1450
# Время жизни клиентов, если не откликнулся — отключает
keepalive 10 120
# Уровень отладки и логирования (подробный лог)
verb 5
# максимальное количество клиентов
max-clients 10
status openvpn-status.log
Жирным выделил то, что можно менять. Ненужные строки можно закомментировать знаком #. Сохраняем файл под именем server.ovpn в папке C:Program FilesOpenVPNconfig Если не получается сохранить — запускаем блокнот (или программу NotePad++) от имени администратора, редактируем и сохраняем файл куда нужно.
Из папки Key скопируем сгенерированные нами файлы ключей и сертификатов, файл dh2048.pem в папку Config — там же уже должен лежать наш файл server.ovpn
Операции с сервером можно считать почти законченными. Давайте стартуем и проверим наш сервер. На рабочем столе запустим ярлык OpenVPNgui в виде оранжевой замочной скважины (от имени Администратора!) На панели задач рядом с основным значком появиться еще один значок подключения. Кликнув по нему мышкой обнаруживаем, что устанавливается соединение. Если сервер стартовал успешно — значок подключения станет зеленым
Как сделать автоматический старт OpenVPN соединения при запуске Windows?
Каждый раз запускать вручную соединение неудобно. В ярлыке OpenVPNgui (свойствах объекта) дописываем аргумент —connect server.ovpn, Ярлык помещаем в «автозагрузку». Я настраивал автозапуск быстро с помощью glary utilites
Вот так это выглядит Команда —connect дает соединение, а настройки его берутся из файла нашего server.ovpn
Если планируется круглосуточная работа сервера — советую настроить операционную систему на автоматический вход без пароля. Это гарантирует самозапуск соединения после перезагрузок, которые бывают при отключении света, установки обновлений.
С сервером закончили. Не забываем открыть порт (указанный в конфиге сервера) на роутере, чтобы предоставить доступ к нашему серверу извне.
Как настроить openvpn клиент на Windows10
Теперь нужно закончить с клиентскими машинами. Для начала сгенерируем клиентские сертификаты. Командная строка еще не закрыта? Набираем команду build-key client (сlient — имя сертификата клиента, можно использовать фамилию, инициалы)
Генерация сертификата происходит как обычно. Доходим до строки Common Name(eg, your name or your servers hostname) и вводим имя сертификата клиента. Оно должно совпадать с введеным ранее! После заполняем строки по умолчанию даем согласие на запись сертификата и добавление его в базу данных.
База данных на сервере обновлена . Таким же образом изготавливаем необходимое количество сертификатов.
Устанавливаем программу Open VPN на компьютере клиента.
Так же появится виртуальный сетевой адаптер, переименовываем его на любое короткое имя по английски.Подготовим конфигурационный файл клиента. Тут все проще.
Можно редактировать конфигурацию нажав на значок подключения через меню «Редактировать конфигурацию»
Скопируем туда следующий текст:
client
#имя сетевого адаптера ovpn
dev tap
#протокол соединения
proto tcp
#IP Адрес и порт сервера
remote ВАШ IP ВАШ порт
# Ключи должны лежать в папке с конфигом
ca ca.crt
cert client.crt
key client.key
cipher AES-256-CBC
nobind
comp-lzo
persist-key
#persist-tun
keepalive 10 60
mute 20
verb 5
Сохраняем файл в папку с программой по пути C:Program FilesOpenVPNconfig cертификат центра авторизации (ca.crt), сертификат и закрытый ключ (client.key,client.crt) мы копируем с сервера и помещаем в папку с файлом client.ovpn.
Нельзя выдавать один и тот же сертификат разным пользователям. Не получиться одновременной работы — кого то будет выбрасывать из сети при попытке соединения.
Если сотрудник уволился — удаляем файлы его сертификата и ключа с сервера. Программа позволяет генерить список отзыва недействительных сертификатов — простая но полноценная программа. Запускаем соединение на клиенте аналогично — через замочную скважину.
Если все сделано правильно — в панели клиента тоже будет зеленый значок. Соединение установлено, можно работать, устанавливать сетевые принтеры. Знатоков прошу в комментариях выкладывать свои версии конфигов сервера — чтобы не читать документацию на английском. Удачи!
Сначала, режим «точка-точка» с использованием предустановленных ключей был единственным доступным вариантом при использовании OpenVPN. В настоящее время существует несколько способов использования OpenVPN, но режим «точка-точка» все еще имеет свое применение. Термин двухточечный режим с использованием предварительно установленных общих ключей часто сокращается до предустановленных ключей.
В режиме «точка-точка» OpenVPN настраивается с использованием предустановленных общих секретных ключей для предварительно определенных конечных точек, и только одна конечная точка может одновременно подключаться к экземпляру сервера. Термин сервер можно считать вводящим в заблуждение, поскольку обе конечные точки более или менее равны, когда речь заходит о функциональности. Конечная точка, инициирующая соединение, считается клиентом, а другая — рассматривается как сервер.
Мы начнем с демонстрации очень простого примера. После этого обсудим больше возможностей, предоставляемые OpenVPN. Мы рассмотрим следующие темы:
- Протокол TCP и разные порты
- Режим TAP
- Секретные ключи OpenVPN
- Маршрутизация
- Полная настройка, включая IPv6
- Настройка без IP
- Трехсторонняя маршрутизация
- Мостовые адаптеры TAP на обоих концах
- Совмещение режима “точка-точка” с сертификатами
Плюсы и минусы ключевого режима
Основным вариантом использования режима предустановленного общего ключа является подключение двух удаленных сетей, например, главного офиса и удаленного офиса небольшой компании. Как только требуется более трех пользователей или конечных точек гораздо проще использовать режим клиент/сервер, как описано в Главе 4, Режим клиент/сервер с настройкой устройств. Пример того, как соединить три местоположения вместе с помощью общих ключей, приведен ниже в этой главе и станет понятно, почему режим с предустановленным ключом не подходит для трех сторон или пользователей.
Основные преимущества использования режима предустановленного ключа:
- Его очень легко настроить
- Нет необходимости в инфраструктуре открытого ключа (public key infrastructure — PKI) или сертификатах X.509
- Может работать на ограниченном оборудовании, таком как коммутаторы или маршрутизаторы на основе Linux
Недостатками использования режима предустановленного ключа являются:
- Как указывает имя точка-точка — только две конечные точки могут пользоваться одним соединением. Поэтому этот режим плохо масштабируется.
- Некоторые оболочки GUI для OpenVPN (например, GNOME NetworkManager) не поддерживают предустановленные ключи. Тоже самое относится к клиентам Android и iOS.
- Секретный ключ должен быть скопирован в удаленную конечную точку с использованием безопасного канала, например с использованием SSH. Иногда это может быть угрозой безопасности.
- Невозможно зашифровать секретный ключ с помощью ключевой фразы, как это возможно при использовании открытых/закрытых ключей X.509.
- Он считается несколько менее безопасным, поскольку безопасность полностью зависит от безопасности и надежности предустановленного секретного ключа. Кроме того, в этом режиме нет идеальной секретности пересылки (perfect forwarding secrecy — PFS). Без PFS злоумышленник может записать весь зашифрованный трафик VPN. Если злоумышленнику удастся в какой-то момент нарушить шифрование, тогда весь записанный трафик VPN может быть дешифрован. С PFS невозможно расшифровать старые данные.
Важно понимать, что OpenVPN на самом деле работает по-разному при использовании предустановленных ключей по сравнению с использованием сертификатов и настройкой клиент/сервер. Пути кода, которые следуют в OpenVPN, на самом деле сильно отличаются, например, согласование канала управления не требуется. Среднестатистический конечный пользователь не увидит эти различия, но их важно знать, когда необходимо устранить неполадки при соединении OpenVPN. Кроме того, при чтении в файле журнала OpenVPN с высокой детальностью вывода (т.е. что-либо выше 5), выходные данные подключения с предустановленным ключом будут выглядеть совершенно иначе по сравнению с выходными данными подключения на основе сертификатов.
Если не указано иное, все примеры в этой главе основаны на конечных точках под управлением CentOS 6 64bit. Версия установленного программного обеспечения OpenVPN v2.3.2 взята из репозитория CentOS-EPEL.
Первый пример
Давайте посмотрим на наш самый первый пример:
- Самый простой и краткий пример подключения двух компьютеров с использованием OpenVPN — это запуск первой конечной точки в режиме прослушивания с использованием фиксированных IP-адресов и сети в стиле tun:
[root@server] # openvpn
--ifconfig 10.200.0.1 10.200.0.2
--dev tun
- Затем запустите клиент OpenVPN:
[root@client] # openvpn
--ifconfig 10.200.0.2 10.200.0.1
--dev tun
--remote openvpnserver.example.com
- В другом окне терминала отобразите сетевое устройство:
[root@client] # ip addr show tun0
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast state UNKNOWN group default
qlen 100 link/none
inet 10.200.0.2 peer 10.200.0.1/32 scope global tun0
valid_lft forever preferred_lft forever
На следующих снимках экрана показано как устанавливается соединение:
- Теперь мы можем пропинговать конечные точки OpenVPN с любого конца, при условии что правила брандмауэра и SELinux позволяют это.
Журнал подключения показывает некоторые интересные детали. Версия OpenVPN на стороне клиента: 2.3.2 x86_64-redhat-linux-gnu. Это подтверждает, что мы запускаем v2.3.2 на 64-битной версии производной RedHat Linux.
Журнал подключения показывает предупреждение:
Mon Sep 8 18:27:29 2014 ******* WARNING *******: all encryption and
authentication features disabled -- all data will be tunnelled as
cleartext
Это предупреждение выводится, поскольку не был указан секретный ключ для шифрования соединения, что делает этот пример небезопасным.
- Устройство Linux
tun0открыто для подключения. Мы указали--dev tun, который сообщает OpenVPN открыть первый доступный адаптерtun. Если теперь запущено второе соединение OpenVPN, следующий экземпляр будет использоватьtun1. - Команда Linux
iproute2 /sbin/ipиспользуется для настройки сетевого адаптераtun0. Указанный IP-адрес назначается вместе с максимальной единицей передачи по умолчанию (maximum transfer unit — MTU) 1500 байтов. - По умолчанию OpenVPN будет использовать UDP-порт 1194 для установления соединения. Если требуется протокол TCP, то аргументы командной строки на обоих концах немного различаются (это показано в следующем разделе).
- Из временных меток, напечатанных в начале каждой строки, видно, что для установления начального соединения требуется 10 секунд.
Если выдается следующее сообщение, то соединение было успешно установлено. Однако в следующих примерах мы увидим, что это необязательно означает, что VPN работает нормально.
Mon Sep 8 18:27:40 2014 Initialization Sequence Completed
Протокол TCP и разные порты
Протоколом по умолчанию, используемым OpenVPN, является UDP, так как обычно он больше подходит для VPN-подключений. Однако, если требуется протокол TCP, предыдущий пример необходимо изменить лишь незначительно: на конце прослушивания запустите экземпляр сервера OpenVPN:
[root@server] # openvpn
--ifconfig 10.200.0.1 10.200.0.2
--dev tun
--proto tcp-server
На стороне клиента команда выглядит следующим образом:
[root@client] # openvpn
--ifconfig 10.200.0.2 10.200.0.1
--dev tun
--proto tcp-client
--remote openvpnserver.example.com
OpenVPN теперь будет подключаться через TCP-порт 1194. Также возможно изменить номер порта, используя параметр --port, например --port 5000.
Режим TAP
Если через VPN-туннель необходимо передавать трафик не-TCP/IP (например устаревший трафик AppleTalk или IPX), то требуется tap-устройство. tap-устройство позволяет интерфейсу передавать полные кадры Ethernet через VPN туннель. Затраты при прохождении полных кадров Ethernet незначительны. Назначение IP для устройства tap отличается от устройства tun, поскольку устройство tap действует как обычный сетевой адаптер, которому необходимо назначить один IP-адрес и сетевую маску.
Предыдущий пример теперь изменен. На конце прослушивания запустите процесс сервера OpenVPN:
[root@server] # openvpn
--ifconfig 10.200.0.1 255.255.255.0
--dev tap
На стороне клиента команда выглядит следующим образом:
[root@client] # openvpn
--ifconfig 10.200.0.2 255.255.255.0
--dev tap
--remote openvpnserver.example.com
Опять же, мы приводим конфигурацию сетевого устройства:
[root@client] # ip addr show tap0
8: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast state UNKNOWN group default qlen 100
link/ether 6e:ea:0e:47:a3:d8 brd ff:ff:ff:ff:ff:ff
inet 10.200.0.2/24 brd 10.200.0.255 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::6cea:eff:fe47:a3d8/64 scope link
valid_lft forever preferred_lft forever
Сравните её с конфигурацией из самого первого примера.
Топология subnet
OpenVPN 2.1 и более поздние версии поддерживают новую топологию, топологию subnet для назначения IP-адресов в сетях в режиме tun, которая очень похожа на IP-адреса, используемые в сетях в стиле tap. При использовании --topology subnet одному интерфейсу туннеля назначаются один IP-адрес и маска сети, а адрес партнера не указывается.
Хотя использовать этот режим топологии для выделенной двухточечной связи не имеет большого смысла, этот параметр можно использовать чтобы сделать настройку режима точка-точка режима tun практически такой же, как соответствующая настройка tap. Чтобы использовать этот новый режим топологии, используйте настройку, описанную ниже.
Начните на конце прослушивания:
[root@server] # openvpn
--ifconfig 10.200.0.1 255.255.255.0
--dev tun
--topology subnet
На стороне клиента команда выглядит следующим образом:
[root@client] # openvpn
--ifconfig 10.200.0.2 255.255.255.0
--dev tun
--topology subnet
--remote openvpnserver.example.com
Строка --ifconfig теперь такая же, как для примера tap. Единственное изменение — добавление --topology subnet на обоих концах.
Туннель открытого текста
Предыдущий пример не использует шифрование или ключи аутентификации; следовательно, вы получаете следующее предупреждение:
Mon Sep 8 18:27:29 2014 ******* WARNING *******: all encryption and authentication features disabled -- all data will be tunnelled as cleartext
Тем не менее, туннель открытого текста имеет свои применения. В доверенной среде, где безопасность обрабатывается на другом уровне (например, с использованием выделенного оптоволоконного кабеля), туннель с открытым текстом обеспечивает лучшую производительность по зашифрованному туннелю, и легче отслеживается поток трафика по туннелю.
Кроме того, если вы заранее знаете, что весь трафик, который будет проходить через туннель, зашифрован сам (например, весь трафик строго HTTPS), то можно использовать туннель открытого текста для избежания двойного шифрования, что может привести к снижению производительности. Особенно при работе OpenVPN на небольшом или встроенном оборудовании (например, Raspberry Pi или даже на некоторых платах Arduino) шифрование наносит большой удар по производительности.
Туннель открытого текста может быть настроен с использованием примеров, приведенных в предыдущем разделе. Если секретный ключ не указан, шифрование и аутентификация (подпись HMAC) автоматически отключаются. Также возможно отключить их явно:
На конце прослушивания запустите:
[root@server] # openvpn
--ifconfig 10.200.0.1 10.200.0.2
--dev tun
--cipher none --auth none
На стороне клиента код выглядит следующим образом:
[root@client] # openvpn
--ifconfig 10.200.0.2 10.200.0.1
--dev tun
--cipher none --auth none
--remote openvpnserver.example.com
После того, как соединение установлено, мы можем проверить что содержимое действительно отправлено в виде открытого текста, используя команду tcpdump (или эквивалентную, например, Wireshark):
- Запустите соединение.
- Запустите
tcpdumpи прослушивайте обычный сетевой интерфейс, а не туннельный и отфильтруйте пакеты OpenVPN (UDP port 1194) с помощью следующей команды:
[root@server] # tcpdump -l -w - eth0 udp port 1194 | strings
- Теперь отправьте текст через туннель, например,
nc(netcat):
- На стороне сервера:
- На стороне клиента:
$ nc 10.200.0.1 31000
hello from openvpn client
goodbye
- Вывод
tcpdumpтеперь должен показать что-то вроде этого:
tcpdump: listening on eth0, link-type EN10MB (Ethernet),
capture size 65535 bytes
V~hello from openvpn client
5goodbye
Символы, показанные в виде текстовых сообщений, являются артефактами инкапсуляции пакетов OpenVPN.
Секретные ключи OpenVPN
Для защиты соединения OpenVPN необходим секретный ключ. Сначала мы сгенерируем такой ключ. Затем его необходимо скопировать в удаленную конечную точку с использованием безопасного канала (например, SCP):
$ openvpn --genkey --secret secret.key
Обратите внимание, что нет необходимости запускать эту команду от пользователя root (отсюда и приглашение $). Полученный файл секретного ключа имеет следующий формат:
##
2048 bit OpenVPN static key
#-
----BEGIN OpenVPN Static key V1-----
1393ae687606c1f7d465d70227bf63e8
8963e9d1401450002d073d6eab1bffde
b06d1a33cc5c45d4a667016339e921d3
3ac36b1a949eb52e9217e41e4b035a7b
987ddfa9d6766d3b5e4c952dc27f518d
12ccff6b2f0966284382ddc0f62b824a
f576f0982beec9d6a4728d0788499a75
0fd7055ef681404fd463d9862d3a40a9
31fca7d87997c70c07b8303a1b85f1ff
76aa7790e7c341353d2b4ea5049b11a2
51346e7dd39fc1f1e53ae57c46cf60c8
24db00a871262fee78050a9df6a57322
0bb0d980b6cf1be90a2f304f99fb9cde
7cdf72d20e7dee555c7c99950aa4d8e6
86a020c3a63125fb99d56181ff4ca20c
d6711eab15a4d6faf706f2601eb6 61b7
-----END OpenVPN Static key V1-----
После публикации ключа здесь — это уже не секрет.
Команда openvpn --genkey генерирует 2048-битный ключ или 256 байт случайных данных. Эти 256 байтов перечислены в шестнадцатеричном формате в файле secret.key, но в настоящее время используются не все 256 байт (как мы увидим позже).
Секретный ключ используется OpenVPN для шифрования и аутентификации(подписи) каждого пакета. Алгоритм шифрования по умолчанию — Blowfish (BF-CBC), а алгоритм HMAC по умолчанию — SHA1. Алгоритм Blowfish использовал 128-битное шифрование, тогда как ключ, используемый для алгоритма SHA1, составляет 160 бит.
Если OpenVPN запускается с увеличенным выходом отладки (--verb 7 или выше), используемые ключи печатаются при запуске:
На конце прослушивания (сервере) запустите демон OpenVPN:
[root@server] # openvpn
--ifconfig 10.200.0.1 10.200.0.2
--dev tun
--secret secret.key
--verb 7
На стороне клиента команда выглядит следующим образом:
[root@client] # openvpn
--ifconfig 10.200.0.2 10.200.0.1
--dev tun
--secret secret.key
--remote openvpnserver.example.com
Вывод журнала на стороне сервера будет содержать строки вида:
Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Encrypt: CIPHER KEY: 1393ae68 7606c1f7 d465d702 27bf63e8
Static Encrypt: CIPHER block_size=8 iv_size=8
Static Encrypt: Using 160 bit message hash 'SHA1' for
HMAC authentication
Static Encrypt: HMAC KEY: 987ddfa9 d6766d3b 5e4c952d c27f518d
12ccff6b
Static Encrypt: HMAC size=20 block_size=20
Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Decrypt: CIPHER KEY: 1393ae68 7606c1f7 d465d702 27bf63e8
Static Decrypt: CIPHER block_size=8 iv_size=8
Static Decrypt: Using 160 bit message hash 'SHA1' for
HMAC authentication
Static Decrypt: HMAC KEY: 987ddfa9 d6766d3b 5e4c952d c27f518d
12ccff6b
Static Decrypt: HMAC size=20 block_size=20
Ключ шифра BF-CBC — это 1393 ae68 7606 c1f7 d465 D702 27bf 63e8, что точно соответствует первой строке файла секретного ключа OpenVPN.
SHA1 ключом HMAC является 987d dfa9 d676 6d3b 5e4c 952d c27f 518d 12cc ff6b, который также можно найти в файле секретного ключа, начиная с пятой строки.
Обратите внимание, что одни и те же ключи используются для шифрования и дешифрования данных, а также аутентификации данных. В следующем разделе мы увидим, как можно использовать разные ключи для шифрования, дешифрования и аутентификации.
Использование нескольких ключей
OpenVPN поддерживает использование направленных ключей, то есть различные ключи используются для входящих и исходящих данных. Это еще больше повышает безопасность. Добавив флаг направления к параметру --secret мы можем указать, что будут использоваться различные ключи. Флаг направления должен быть установлен в 0 на одном конце и в 1 на другом:
На прослушивающем конце (сервере), запустите:
[root@server] # openvpn
--ifconfig 10.200.0.1 10.200.0.2
--dev tun
--secret secret.key 0
--verb 7
На стороне клиента код выглядит следующим образом:
[root@client] # openvpn
--ifconfig 10.200.0.2 10.200.0.1
--dev tun
--secret secret.key 1
--remote openvpnserver.example.com
--verb 7
Вывод журнала на стороне сервера теперь будет содержать строки вида:
Static Encrypt: CIPHER KEY: 1393ae68 7606c1f7 d465d702 27bf63e8
Static Encrypt: HMAC KEY: 987ddfa9 d6766d3b 5e4c952d c27f518d
12ccff6b
Static Decrypt: CIPHER KEY: 31fca7d8 7997c70c 07b8303a 1b85f1ff
Static Decrypt: HMAC KEY: 0bb0d980 b6cf1be9 0a2f304f 99fb9cde
7cdf72d2
Ключи шифрования CIPHER и HMAC теперь явно отличаются от ключей дешифрования CIPHER и HMAC. Кроме того, каждый из этих ключей можно найти в файле OpenVPN secret.key:
- Ключ шифрования
CIPHER KEYначинается с 1 строки длиной 128 бит или 16 байт - Ключ шифрования
HMAC KEYначинается с 5 строки длиной 160 бит или 20 байт - Ключ дешифрования
CIPHER KEYначинается с 9 строки длиной 128 бит или 16 байт - Ключ дешифрования
HMAC KEYначинается с 13 строки длиной 160 бит или 20 байт
Кроме того, вывод журнала на стороне клиента показывает что ключи поменялись местами:
Static Encrypt: CIPHER KEY: 31fca7d8 7997c70c 07b8303a 1b85f1ff
Static Encrypt: HMAC KEY: 0bb0d980 b6cf1be9 0a2f304f 99fb9cde
7cdf72d2
Static Decrypt: CIPHER KEY: 1393ae68 7606c1f7 d465d702 27bf63e8
Static Decrypt: HMAC KEY: 987ddfa9 d6766d3b 5e4c952d c27f518d
12ccff6b
Это необходимо для функционирования VPN-туннеля, так как нобходимые ключи на стороне сервера для шифрования данных, необходимы на стороне клиента для дешифрования данных и наоборот.
Использование разных алгоритмов шифрования и аутентификации
OpenVPN поддерживает несколько различных алгоритмов шифрования и аутентификации (подписи HMAC). Размер ключей, используемых в каждом алгоритме шифрования и HMAC, варьируется, причем текущий максимум составляет значение 256 бит для шифров (например, AES256) и 512 бит для ключа HMAC (например, SHA512). Статический ключ OpenVPN имеет длину 2048 бит что достаточно для 512-битного шифра и 512-битного ключа HMAC.
Если мы укажем AES256 в качестве алгоритма шифрования и SHA512 в качестве алгоритма аутентификации, то увидим что используемые ключи увеличатся в размере:
На конце прослушивания (сервере) запустите:
[root@server] # openvpn
--ifconfig 10.200.0.1 10.200.0.2
--dev tun
--secret secret.key 0
--cipher AES256 --auth SHA512
--verb 7
На стороне клиента код выглядит следующим образом:
[root@client] # openvpn
--ifconfig 10.200.0.2 10.200.0.1
--dev tun
--secret secret.key 1
--cipher AES256 --auth SHA512
--remote openvpnserver.example.com
--verb 7
Вывод журнала на стороне сервера теперь содержит следующие строки:
Static Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Static Encrypt: CIPHER KEY: 1393ae68 7606c1f7 d465d702 27bf63e8
8963e9d1 40145000 2d073d6e ab1bffde
Static Encrypt: CIPHER block_size=16 iv_size=16
Static Encrypt: Using 512 bit message hash 'SHA512' for
HMAC authentication
Static Encrypt: HMAC KEY: 987ddfa9 d6766d3b 5e4c952d c27f518d
12ccff6b 2f096628 4382ddc0 f62b824a
f576f098 2beec9d6 a4728d07 88499a75
0fd7055e f681404f d463d986 2d3a40a9
Static Encrypt: HMAC size=64 block_size=64
Static Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Static Decrypt: CIPHER KEY: 31fca7d8 7997c70c 07b8303a 1b85f1ff
76aa7790 e7c34135 3d2b4ea5 049b11a2
Static Decrypt: CIPHER block_size=16 iv_size=16
Static Decrypt: Using 512 bit message hash 'SHA512' for
HMAC authentication
Static Decrypt: HMAC KEY: 0bb0d980 b6cf1be9 0a2f304f 99fb9cde
7cdf72d2 0e7dee55 5c7c9995 0aa4d8e6
86a020c3 a63125fb 99d56181 ff4ca20c
d6711eab 15a4d6fa f706f260 1eb661b7
Этот журнал может быть сопоставлен с файлом secret.key:
- Ключ шифрования
CIPHER KEYтеперь соответствует первым 2 строкам файла. - Ключ шифрования
HMAC KEYтеперь соответствует строкам 5-8 файла.
Аналогичным образом можно сопоставить ключи дешифрования.
Заметка
VPN-туннель работает так же как и раньше, но теперь с более надежным шифрованием и аутентификацией на месте. Если в будущем будут введены еще более надежные алгоритмы шифрования или HMAC, формат статического ключа OpenVPN необходимо будет обновить.
Маршрутизация
Как указывалось ранее, основной вариант использования сетей типа «точка-точка» заключается в соединении двух удаленных сетей через безопасный туннель. В предыдущем примере безопасный туннель был установлен, но не были добавлены сетевые маршруты.
В этом примере рассмотрим следующую схему сети:
Клиентскую сеть 192.168.4.0/24 (с маской сети 255.255.255.0) необходимо направить через VPN-туннель к серверу.
На сервере мы запускаем:
[root@server] # openvpn
--ifconfig 10.200.0.1 10.200.0.2
--dev tun
--secret secret.key 0
--route 192.168.4.0 255.255.255.0
--daemon --log /var/log/movpn-02-server.log
На стороне клиента код выглядит следующим образом:
[root@client] # openvpn
--ifconfig 10.200.0.2 10.200.0.1
--dev tun
--secret secret.key 1
--remote openvpnserver.example.com
--daemon --log /var/log/movpn-02-client.log
На стороне сервера был добавлен оператор route, для сообщения OpenVPN о том, что сеть 192.168.4.0/24 находится на другом конце туннеля. OpenVPN сам по себе мало что с этим сделает, но выдаст соответствующую системную команду /sbin/route или /sbin/ip route для настройки таблиц системной маршрутизации. Вместо использования оператора OpenVPN --route мы также можем использовать следующую команду:
[root@server] # route add -net 192.168.4.0/24 gw 10.200.0.2
После того, как VPN-соединение было установлено, мы можем альтернативно использовать команду iproute2:
[root@server] # ip route add 192.168.4.0/24 via 10.200.0.2
Вторая строка операторов, добавленных в этом примере, инструктирует OpenVPN демонизировать себя (то есть запускать в фоновом режиме) и записывать все сообщения в файл /var/log/movpn-02-server.log.
Аналогично, тот же оператор daemon+log добавляется на стороне клиента.
Заметка
Оператор --log перезаписывает файл журнала при каждом запуске OpenVPN. Если вы хотите дописывать в предыдущий файл журнала — используйте следующую команду:
--log-append /var/log/movpn-02-server.log
На данный момент пример еще не полностью функционален. Если мы пропингуем хост в локальной сети на стороне клиента с VPN-сервера — мы не получим никакого ответа. Это имеет мало общего с самим OpenVPN, а в основном с маршрутизацией TCP/IP. Большинство вопросов, задаваемых в списке рассылки пользователей OpenVPN и интернет-форуме OpenVPN, на самом деле являются вопросами маршрутизации.
Причина, по которой от клиентской локальной сети не получен ответ, двояка:
- Переадресация IP или маршрутизация должны быть включены на клиенте OpenVPN. Для каждой операционной системы это достигается по-разному. В Linux обычно достаточно добавить или изменить строку в файле
/etc/sysctl.cnfи перезагрузиться. Должна быть изменена следующая строка:
- Можно избежать перезагрузки, выполнив следующую команду:
- Нам также необходимо убедиться в существовании обратного маршрута к серверу OpenVPN в клиентской локальной сети. Это можно сделать добавив маршрут на шлюзе локальной сети или статический маршрут на каждой машине в клиентской локальной сети. В этом примере мы добавляем маршрут на машине Linux, которая подключена к клиентской сети:
# route add -net 10.200.0.0/24 gw 192.168.4.100
Здесь 192.168.4.100 — это локальный IP-адрес клиента OpenVPN.
Заметка
Маршруты, добавленные таким образом, не являются статическими и исчезнут после перезагрузки. Статическое добавление маршрутов зависит от распределения.
Теперь пример работает как и ожидалось. С сервера OpenVPN мы можем пинговать IP-адреса компьютеров в локальной сети на стороне клиента и наоборот:
$ ping -c 2 192.168.4.100
PING 192.168.4.100 (192.168.4.100) 56(84) bytes of data.
64 bytes from 192.168.4.100: icmp_seq=1 ttl=64 time=5.97 ms
64 bytes from 192.168.4.100: icmp_seq=2 ttl=64 time=4.22 ms
$ ping -c 2 192.168.4.10
PING 192.168.4.10 (192.168.4.10) 56(84) bytes of data.
64 bytes from 192.168.4.10: icmp_seq=1 ttl=63 time=7.37 ms
64 bytes from 192.168.4.10: icmp_seq=2 ttl=63 time=6.09 ms
Конфигурационные файлы и командная строка
Как видно из предыдущего примера, аргументы командной строки для OpenVPN могут быстро стать длинными и сложными. Также возможно (и желательно) использовать файлы конфигурации для хранения часто используемых опций для OpenVPN. В общем, каждый параметр может быть указан в командной строке с помощью следующей команды:
--<некоторая опция> <аргументы-опции>
Его также можно указать в файле конфигурации с помощью <некоторая опция> <аргументы-опции>, то есть удалить два дефиса перед аргументом командной строки.
Файл конфигурации указывается в командной строке с помощью параметра --config <путь>. Почти все параметры, указанные в файле конфигурации, обрабатываются так, как если бы они были указаны в командной строке. Как мы увидим позже в этой книге, в файле конфигурации можно хранить встроенные сертификаты и файлы приватного ключа. Нелегко сделать то же самое используя аргументы командной строки.
Также возможно смешивать файлы конфигурации и аргументы командной строки. Это позволяет легко хранить часто используемые параметры в файле конфигурации, который можно переопределить с помощью аргументов командной строки.
Заметка
Не все параметры конфигурации могут быть переопределены. Некоторые параметры могут быть указаны несколько раз (в частности, remote <remote-host>). В этих случаях используется первое вхождение.
Командная строка на стороне сервера из предыдущего примера может быть преобразована в следующий файл конфигурации:
ifconfig 10.200.0.1 10.200.0.2
dev tun
secret secret.key 0
route 192.168.4.0 255.255.255.0
daemon
log /var/log/movpn-02-server.log
Если этот файл конфигурации сохранить как movpn-02-01-server.conf, то команда для запуска сервера становится:
[root@server] # openvpn --config movpn-02-01-server.conf
Обратите внимание, что порядок аргументов командной строки важен. Все параметры, указанные перед параметром --config <путь>, переопределяются параметрами, указанными в файле конфигурации. Все параметры, указанные после параметра --config, отменяют параметры в файле конфигурации (с некоторыми исключениями, как отмечалось ранее).
Полная настройка
На основе предыдущих примеров мы теперь можем построить полную конфигурацию производственного уровня, используя файлы конфигурации, включая маршрутизацию, ведение журнала, поддержку IPv6, а также некоторые другие производственные функции, которые предлагает OpenVPN.
Рассмотрим следующую схему сети:
Для сервера мы создаем следующий файл конфигурации movpn-02-02-server.conf:
dev tun
proto udp
local openvpnserver.example.com
lport 1234
remote openvpnclient.example.com
rport 4321
secret secret.key 0
ifconfig 10.200.0.1 10.200.0.2
route 192.168.4.0 255.255.255.0
tun-ipv6
ifconfig-ipv6 2001:610:120::200:0:1 2001:610:120::200:0:2
user nobody
groupnobody # используйте 'group nogroup' для Debian/Ubuntu
persist-tun
persist-key
keepalive 10 60
ping-timer-rem
verb 3
daemon
log-append /var/log/openvpn.log
Для клиента мы создаем файл movpn-02-02-client.conf:
dev tun
proto udp
local openvpnclient.example.com
lport 4321
remote openvpnserver.example.com
rport 1234
secret secret.key 1
ifconfig 10.200.0.2 10.200.0.1
route 192.168.122.0 255.255.255.0
tun-ipv6
ifconfig-ipv6 2001:610:120::200:0:2 2001:610:120::200:0:1
user nobody
group nobodygroup nobody # use 'group nogroup' on Debian/Ubuntu
persist-tun
persist-key
keepalive 10 60
ping-timer-rem
verb 3
daemon
log-append /var/log/openvpn.log
Файлы конфигурации клиента и сервера очень похожи, за исключением зеркальных адресов и направления зеркальных ключей.
В этих файлах конфигурации появилось несколько новых опций:
- Хотя
proto udpявляется протоколом по умолчанию, разумно явно указать его в файле конфигурации, чтобы избежать путаницы. local <IP>— это локальный IPv4-адрес, на котором OpenVPN будет прослушивать входящие соединения. Если этот адрес не указан — OpenVPN будет прослушивать адрес 0.0.0.0, что означает все интерфейсы.lport— это локальный порт, который будет прослушивать OpenVPN. Значение по умолчанию — 1194, но можно использовать любой допустимый и доступный номер порта.remote <IP>— это удаленный IPv4-адрес, на который процесс сервера OpenVPN будет принимать входящие соединения. Если этот адрес не указан — OpenVPN будет принимать входящие соединения со всех адресов.rport— это удаленный порт, к которому OpenVPN будет подключаться. указывается с использованиемport, но когда используется другой локальный порт, удобнее явно указатьrport.tun-ipv6инструктирует OpenVPN создать туннель, способный пропускать трафик IPv6.ifconfig-ipv6настраивает локальные и удаленные конечные точки IPv6. В этом примере последние три числа адреса IPv6 соответствуют конечным точкам IPv4.user nobodyиgroup nobodyдают указание OpenVPN сменить UNIX-пользователя наnobodyи группу после установки соединения. Это еще больше повышает безопасность, так как атака на туннель с меньшей вероятностью приведет к root-эксплойту. Обратите внимание, что в Debian/Ubuntu используется группаnogroup.persist-tunиpersist-keyинструктируют OpenVPN не поднимать устройство tun повторно или генерировать новый материал ключей при каждом перезапуске туннеля. Эти параметры особенно полезны в сочетании сuser nobody, так как обычно уnobodyнет прав доступа для запуска нового интерфейса tun.keepalive 10 60иping-timer-remявляются полезными опциями, чтобы убедиться, что VPN-соединение остается работоспособным, даже если по туннелю нет трафика.
Вместо того, чтобы указывать очень длинную командную строку для запуска концов туннеля, теперь мы можем запустить оба конца, используя следующие команды:
[root@server] # openvpn --config movpn-02-02-server.conf
[root@client] # openvpn --config movpn-02-02-client.conf
Проверьте файлы openvpn.log на обоих концах для магического предложения:
Thu Sep 11 13:21:51 2014 Initialization Sequence Completed
Наконец, мы проверяем, что можем достичь другого конца туннеля, используя ping и ping6:
# remote IPv4 LAN address
$ ping -c 2 192.168.4.100
PING 192.168.4.100 (192.168.4.100) 56(84) bytes of data.
64 bytes from 192.168.4.100: icmp_seq=1 ttl=64 time=3 ms
64 bytes from 192.168.4.100: icmp_seq=2 ttl=64 time=5 ms
# remote IPv6 tunnel address
$ ping6 -c 2 2001:610:120::200:0:2
PING 2001:610:120::200:0:2(2001:610:120::200:0:2) 56 data bytes
64 bytes from 2001:610:120::200:0:2: icmp_seq=1 ttl=64 time=4 ms
64 bytes from 2001:610:120::200:0:2: icmp_seq=2 ttl=64 time=4 ms
# remote IPv6 LAN address
$ ping6 -c 2 2001:610:120::168:4:100
PING 2001:610:120::168:4:100(2001:610:120::168:4:100) 56 data byte
64 bytes from 2001:610:120::168:4:100: icmp_seq=1 ttl=64 time=6 ms
64 bytes from 2001:610:120::168:4:100: icmp_seq=2 ttl=64 time=3 ms
Обратите внимание — для того, чтобы заставить работать маршрутизацию, нам теперь необходима переадресация IP на обоих концах, а также обратный маршрут для компьютеров в сегменте LAN. В клиентской локальной сети нам нужны маршруты, подобные следующим:
# route add -net 10.200.0.0/24 gw 192.168.4.100
# route add -net 192.168.122.0/24 gw 192.168.4.100
Здесь 192.168.4.100 — это локальный адрес клиента OpenVPN.
В сети на стороне сервера нам необходимо следующее:
# route add -net 10.200.0.0/24 gw 192.168.122.1
# route add -net 192.168.4.0/24 gw 192.168.122.1
Здесь 192.168.122.1 — локальный адрес сервера OpenVPN.
Заметка
В настоящее время требуется всегда указывать адрес IPv4 с помощью ifconfig, даже если туннель только для IPv6. Этот недостаток будет устранен в настройке OpenVPN 2.4+без-IP.
Расширенная настройка без-IP
Возможность OpenVPN разрешать выполнение пользовательских сценариев при запуске VPN-подключения позволяет выполнять некоторые расширенные настройки. В этом примере мы будем использовать пользовательский сценарий up для создания туннеля OpenVPN без назначения IP-адресов конечным точкам туннеля. При настройке маршрутизируемой сети это гарантирует что конечные точки туннеля никогда не будут доступны сами по себе, что добавляет некоторую безопасность, а также может сделать таблицы маршрутизации немного короче.
Этот сценарий был протестирован только в системах Linux, так как требует настройки сетевого интерфейса, недоступной на других платформах. Мы используем ту же схему сети, что и в предыдущем примере, но без адресации IPv6:
Для сервера мы создаем следующий файл конфигурации movpn-02-03-server.conf:
dev tun
secret secret.key
ifconfig-noexec
up /etc/openvpn/up.sh
script-security 2
verb 3
daemon
log-append /var/log/openvpn.log
Вот сопровождающий скрипт up.sh:
#!/bin/bash
/sbin/ifconfig $1 0.0.0.0 up
/sbin/ip route add 192.168.4.0/24 dev $1
Здесь сеть 192.168.4.0/24 — это клиентская локальная сеть, к которой мы хотим обратиться из серверной сети. Для клиента мы создаем файл movpn-02-03-client.conf:
dev tun
secret secret.key
ifconfig-noexec
remote openvpnserver.example.com
up /etc/openvpn/up.sh
script-security 2
verb 3
daemon
log-append varlog/openvpn.log
Вот сопровождающий скрипт up.sh:
#!/bin/bash
/sbin/ifconfig $1 0.0.0.0 up
/sbin/ip route add 192.168.122.0/24 dev $1
Перед началом VPN-подключения убедитесь что сценарии up.sh являются исполняемыми (chmod a+x up.sh):
Запустите оба конца туннеля:
[root@server]# openvpn --config movpn-02-03-server.conf
[root@client]# openvpn --config movpn-02-03-client.conf
Проверьте файлы openvpn.log на обоих концах на наличие магического предложения:
Thu Sep 11 15:57:51 2014 Initialization Sequence Completed
Проверьте адреса, назначенные интерфейсу tun0:
$ ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:504 (504.0 b) TX bytes:504 (504.0 b)
В качестве альтернативы вы можете использовать более современную команду iproute2:
Интерфейс работает, но не имеет IP-адреса. Далее мы проверим таблицу маршрутизации:
$ /sbin/ip route show
[...]
192.168.4.0/24 dev tun0 scope link
[...]
Правильный маршрут присутствует, поэтому, наконец, мы проверяем, что можем пинговать хост в локальной сети на стороне клиента:
[root@centos6-kvm ~]# ping -c 2 192.168.4.10
PING 192.168.4.10 (192.168.4.10) 56(84) bytes of data.
64 bytes from 192.168.4.10: icmp_seq=1 ttl=62 time=5 ms
64 bytes from 192.168.4.10: icmp_seq=2 ttl=62 time=5 ms
Трехсторонняя маршрутизация
Как указано во введении, двухточечные сети являются отличным выбором при подключении небольшого количества конечных точек. В этом примере мы покажем как соединить три места вместе, используя двухточечные туннели. Это также покажет, как быстро простая конфигурация такой установки может стать очень сложной.
Рассмотрим следующую схему сети:
Мы создадим три туннеля между точками и избыточные маршруты. Таким образом, если один из туннелей выйдет из строя, все они останутся видимыми друг для друга. Тем не менее, это достигается за счет снижения производительности. Предположим, что связь между точками A и B не работает. Резервный маршрут идет от A к C и к B, поэтому теперь трафик с точки A на точку B должен сделать дополнительный скачок.
Сначала мы создаем три секретных ключа:
$ openvpn –-genkey –-secret AtoB.key
$ openvpn –-genkey –-secret AtoC.key
$ openvpn –-genkey –-secret BtoC.key
Затем мы передаем эти ключи всем конечным точкам по защищенному каналу (например, используя scp).
Теперь создаем шесть файлов конфигурации: три конфигурации сервера и три конфигурации клиента.
Сначала создайте файл конфигурации сервера BtoA.conf:
dev tun
proto udp
port 1194
remote siteA
secret AtoB.key 0
ifconfig 10.200.0.1 10.200.0.2
route 192.168.4.0 255.255.255.0 vpn_gateway 5
route 192.168.6.0 255.255.255.0 vpn_gateway 10
route-delay
keepalive 10 60
verb 3
daemon
log-append /var/log/openvpn-BtoA.log
Затем создайте CtoA.conf со следующим содержимым:
dev tun
proto udp
port 1195
remote siteAsecret AtoC.key 0
ifconfig 10.200.0.5 10.200.0.6
route 192.168.4.0 255.255.255.0 vpn_gateway 5
route 192.168.5.0 255.255.255.0 vpn_gateway 10
route-delay
keepalive 10 60
verb 3
daemon
log-append /var/log/openvpn-CtoA.log
Далее создайте последний файл конфигурации сервера BtoC.confuse:
dev tun
proto udp
port 1196
remote siteC
secret BtoC.key 0
ifconfig 10.200.0.9 10.200.0.10
route 192.168.4.0 255.255.255.0 vpn_gateway 10
route 192.168.6.0 255.255.255.0 vpn_gateway 5
route-delay
keepalive 10 60
verb 3
daemon
log-append /var/log/openvpn-BtoC.log
Теперь создадим файл конфигурации клиента (коннектора) AtoB.conf:
dev tun
proto udp
port 1194
remote siteB
secret AtoB.key 1
ifconfig 10.200.0.2 10.200.0.1
route 192.168.5.0 255.255.255.0 vpn_gateway 5
route 192.168.6.0 255.255.255.0 vpn_gateway 10
route-delay
keepalive 10 60
verb 3
daemon
log-append /var/log/openvpn-AtoB.log
Далее мы создаем файл конфигурации клиента AtoC.conf:
dev tun
proto udp
port 1195
remote siteC
secret AtoC.key 1
ifconfig 10.200.0.6 10.200.0.5
route 192.168.5.0 255.255.255.0 vpn_gateway 10
route 192.168.6.0 255.255.255.0 vpn_gateway 5
route-delay
keepalive 10 60
verb 3
daemon
log-append /var/log/openvpn-AtoC.log
Наконец, мы создаем файл конфигурации клиента CtoB.conf:
dev tun
proto udp
port 1196
remote siteB
secret BtoC.key 1
ifconfig 10.200.0.10 10.200.0.9
route 192.168.4.0 255.255.255.0 vpn_gateway 10
route 192.168.5.0 255.255.255.0 vpn_gateway 5
route-delay
keepalive 10 60
verb 3
daemon
log-append /var/log/openvpn-CtoB.log
Запустите каждый сервер и подключите соответствующего клиента:
[siteB]# openvpn --config BtoA.conf
[siteA]# openvpn --config AtoB.conf
Проверьте файлы журналов по обе стороны туннеля и убедитесь что маршрутизация (частично) работает, прежде чем переходить к следующему узлу:
[siteB]$ openvpn --config BtoC.conf
[siteC]$ openvpn --config CtoB.conf
и наконец:
[siteC]$ openvpn --config CtoA.conf
[siteA]$ openvpn --config AtoC.conf
На этом этапе должны присутствовать все маршруты, включая избыточные. Например, узел A имеет два маршрута к узлу B (LAN 192.168.5.0/24), как видно из таблицы маршрутизации:
[siteA]$ ip route show
[…]
192.168.5.0/24 via 10.200.0.1 dev tun0 metric 5
192.168.5.0/24 via 10.200.0.5 dev tun1 metric 10
[…]
Мы можем наблюдать следующее из этой таблицы:
- Один прямой туннель до узла B. Этот маршрут имеет самую низкую метрику.
- Один непрямой туннель: сначала на узел C, а затем на B. Этот маршрут имеет более высокую метрику и не выбирается до тех пор, пока не “упадет” первый маршрут.
Преимущество этой настройки заключается в том, что в случае сбоя одного туннеля через 60 секунд соединение и соответствующие ему маршруты сбрасываются. Затем резервный маршрут к другой сети автоматически поднимается и все три узла могут снова связаться друг с другом. После возвращения исходного туннеля маршруты с более высокой метрикой снова получают приоритет и исходная ситуация восстанавливается.
Недостатком этой конфигурации является то, что в течение этих 60 секунд весь трафик теряется. Протоколы маршрутизации, такие как RIPv2 или OSPF, могут помочь обнаружить сбой маршрутов намного быстрее, что приводит к меньшему времени простоя сети.
Маршрут, net_gateway, vpn_gateway и метрики
Следующие операторы конфигурации имеют жизненно важное значение в этой настройке. Слово vpn_gateway — это специальное ключевое слово OpenVPN, которое указывает адрес удаленной конечной точки VPN. Обычно это ключевое слово указывать не нужно, кроме случаев, когда необходимо указать метрику для этого маршрута.
Синтаксис и параметры для директивы route:
route <network> <netmask> vpn_gateway <metric>
Здесь gateway можно либо указать явно в качестве адреса IPv4, либо использовать специальные ключевые слова vpn_gateway или net_gateway. Если шлюз и метрика не указаны, используется vpn_gateway.
Ключевое слово net_gateway полезно для указания подсети, которая не должна явно маршрутизироваться через VPN. В Главе 4, Режим клиент/сервер с tun устройствами , будет дано более подробное объяснение вариантов маршрута.
Метрика имеет метрику по умолчанию, которую можно установить с помощью следующей команды:
Это относится ко всем маршрутам. Если кто-то хочет отменить метрику для определенного маршрута (как мы это сделали в данном примере), то необходимо указать шлюз (в нашем случае vpn_gateway), за которым следует метрика для этого конкретного маршрута.
Инструкция route-delay необходима здесь, чтобы гарантировать добавление маршрутов после того, как все соединения доступны. Без этого маршруты могут быть добавлены слишком рано, что приведет к невозможности добавления маршрута в одну из удаленных подсетей.
Мостовой tap-переходник на обоих концах
Еще один сложный пример использования выделенной двухточечной VPN заключается в соединении двух удаленных сегментов сети. OpenVPN позволяет соединить два сегмента сети с одним и тем же диапазоном IP-адресов, чтобы сформировать один прозрачный сегмент сети. Как правило, делать этого не рекомендуется, поскольку производительность такой соединенной сети не будет оптимальной. В некоторых случаях это неизбежно. Обычно было бы лучше назначить разные подсети обоим концам, но иногда специфичное программное обеспечение привязано к определенному IP-адресу и нет альтернативы кроме как иметь одну подсеть на обоих концах.
Рассмотрим следующую схему сети:
На стороне клиента используется сеть 192.168.4.0/24, а клиент OpenVPN находится по адресу 192.168.4.128. На стороне сервера используется та же подсеть — сервер OpenVPN находится по адресу 192.168.4.65. Цель состоит в том, чтобы соединить две сети вместе для прозрачного видения всех машин на обоих концах.
В режиме dev tap OpenVPN создаст новый или откроет существующий адаптер tap. В большинстве современных операционных систем адаптер tap ведет себя так же как обычный сетевой адаптер и если операционная система поддерживает мостовое подключение адаптера, то адаптер tap можно соединить с другим сетевым адаптером в системе. Известно, что это работает в Linux, Free/Open/NetBSD и Microsoft Windows. В Linux для работы этого примера необходимо установить пакет bridge-utils.
В приведенном примере tap-адаптер соединяется с интерфейсом локальной сети как клиента так и сервера OpenVPN. Чтобы иметь возможность сделать это — tap-адаптер создается в постоянной работоспособности до инициализации VPN-подключения:
# openvpn --mktun --dev tap0
Thu Sep 11 16:57:30 2014 TUN/TAP device tap0 opened
Thu Sep 11 16:57:30 2014 Persist state set to: ON
Затем создается мост и инициализируется. На стороне клиента выполните следующие команды:
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 tap0
# ifconfig eth0 0.0.0.0 up
# ifconfig tap0 0.0.0.0 up
# ifconfig br0 192.168.4.128 netmask 255.255.255.0 up
Проверьте состояние моста и связанных с ним адаптеров, прежде чем продолжить.
Также убедитесь, что доступ к локальной сети все еще возможен:
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.5c260a307224 no eth0
tap0
# ifconfig -a
br0 Link encap:Ethernet HWaddr 5C:26:0A:30:72:24
inet addr:192.168.4.128 Bcast:192.168.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:244 (244.0 b) TX bytes:732 (732.0 b)
eth0 Link encap:Ethernet HWaddr 5C:26:0A:30:72:24
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2087 errors:0 dropped:0 overruns:0 frame:0
TX packets:2427 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:203516 (198.7 KiB) TX bytes:231571 (226.1 KiB)
Interrupt:20 Memory:f5400000-f5420000
tap0 Link encap:Ethernet HWaddr CA:85:1E:AE:AF:59
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:11 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
# ping -c 2 192.168.4.10
Вывод должен быть одинаковым для серверной части; с IP-адресом моста 192.168.4.65.
Далее мы создаем файл конфигурации movpn-02-05.conf, который может быть одинаковым с обеих сторон:
dev tap0
secret secret.key
verb 3
daemon
log-append /var/log/openvpn.log
Заметка
В файле конфигурации используется полное имя устройства tap0. Если значение 0 опущено, то OpenVPN откроет новый tap-адаптер и мост не будет работать.
Далее запускаем клиент и сервер:
[root@server] # openvpn --config movpn-02-05.conf
--remote openvpnclient.example.com
[root@client] # openvpn --config movpn-02-05.conf
--remote openvpnserver.example.com
После завершения последовательности инициализации — сегменты сети соединяются мостом. Проверьте это, пропингуя хост на удаленном конце.
Также полезно наблюдать за трафиком, проходящим через туннель. Недостатком мостовой сети является распространение всего (широковещательного) трафика, генерируемого на одном конце. Это может привести к снижению производительности сети. Если в сети много фонового шума — это отобразится в tcpdump на интерфейсе tap0:
17:19:57.280459 72:24:b4:f0:16:81 > 01:80:c2:00:00:00, 802.3,
length 52: LLC, dsap STP (0x42) Individual, ssap STP (0x42)
Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id
8000.52:54:00:6e:cd:0b.8003, length 35
17:19:59.280486 72:24:b4:f0:16:81 > 01:80:c2:00:00:00, 802.3,
length 52: LLC, dsap STP (0x42) Individual, ssap STP (0x42)
Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id
8000.52:54:00:6e:cd:0b.8003, length 35
17:20:00.112516 52:54:00:6e:cd:0b > 98:4f:ee:00:7d:e1, ethertype
ARP (0x0806), length 42: Request who-has 192.168.122.23 tell
192.168.122.1, length 28
17:20:01.112534 52:54:00:6e:cd:0b > 98:4f:ee:00:7d:e1, ethertype
ARP (0x0806), length 42: Request who-has 192.168.122.23 tell
192.168.122.1, length 28
17:20:01.280468 72:24:b4:f0:16:81 > 01:80:c2:00:00:00, 802.3,
length 52: LLC, dsap STP (0x42) Individual, ssap STP (0x42)
Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id
8000.52:54:00:6e:cd:0b.8003, length 35
17:20:02.112524 52:54:00:6e:cd:0b > 98:4f:ee:00:7d:e1, ethertype
ARP (0x0806), length 42: Request who-has 192.168.122.23 tell
192.168.122.1, length 28
17:20:04.161591 98:4f:ee:00:7d:e1 > ff:ff:ff:ff:ff:ff, ethertype
ARP (0x0806), length 60: Request who-has 192.168.4.100 tell
192.168.4.10, length 46
17:20:05.153670 98:4f:ee:00:7d:e1 > ff:ff:ff:ff:ff:ff, ethertype
ARP (0x0806), length 60: Request who-has 192.168.4.100 tell
192.168.4.10, length 46
Выходные данные этого захвата tcpdump показали, что протокол Spanning Tree Protocol был включен на мосту на стороне сервера, выполнив следующую команду:
Это движение было остановлено, что привело к гораздо меньшему шуму на мосту.
Заметка
Отключайте STP на сетевом мосту, только если знаете, что делаете. В таком случае риск возникновения петель отсутствует, поскольку имеется только один мост и подключено только два устройства.
Запросы ARP, которые видны в захвате tcpdump не так просто подавить. Однако эти запросы очень малы и не должны приводить к значительному снижению производительности. Однако на линии с высокой задержкой эти запросы станут узким местом.
Удаление мостов
Если мост больше не нужен — лучше удалить его и постоянные устройства tap0:
# ifconfig br0 down
# brctl delif br0 tap0
# brctl delif br0 eth0
# brctl delbr br0
# openvpn --rmtun --dev tap0
Thu Sep 11 18:55:22 2014 TUN/TAP device tap0 opened
Thu Sep 11 18:55:22 2014 Persist state set to: OFF
Не забудьте снова подключить сетевой интерфейс eth0.
Совмещение режима точка-точка с сертификатами
В следующем примере мы заимствуем некоторые части из Главы 3, PKI и сертификаты. В режиме клиент/сервер OpenVPN настраивается с помощью публичных ключей инфраструктуры (PKI) с сертификатами X.509 и закрытыми ключами. Также можно использовать сертификаты X.509 и закрытые ключи для настройки туннеля точка-точка. Преимущество использования сертификатов X.509 перед предустановленными ключами состоит в том, что он обеспечивает Perfect Forwarding Secrecy (PFS), что значительно повышает безопасность ваших данных VPN. Без PFS, если злоумышленнику удастся в какой-то момент нарушить шифрование, тогда весь ранее записанный трафик VPN может быть расшифрован. С PFS невозможно расшифровать старые данные.
Чтобы настроить туннель точка-точка с использованием сертификатов, мы должны сначала скопировать сертификат CA и пару сертификат/секретный ключ для обеих конечных точек:
[root@server] # mkdir -p /etc/openvpn/movpn
[root@server] # chmod 700 /etc/openvpn/movpn
[root@server] # cd /etc/openvpn/movpn
[root@server] # PKI=<PKI_DIR>/ssladmin/active
[root@server] # cp -a $PKI/ca.crt movpn-ca.crt
[root@server] # cp -a $PKI/Mastering_OpenVPN_Server.crt server.crt
[root@server] # cp -a $PKI/Mastering_OpenVPN_Server.key server.key
и
[root@client] # mkdir -p /etc/openvpn/movpn
[root@client] # chmod 700 /etc/openvpn/movpn
[root@client] # cd /etc/openvpn/movpn
[root@client] # PKI=<PKI_DIR>/ssladmin/active
[root@client] # cp -a $PKI/ca.crt movpn-ca.crt
[root@client] # cp -a $PKI/client1.crt client1.crt
[root@client] # cp -a $PKI/client1.key client1.key
На стороне сервера нам также необходимо сгенерировать файл параметров Диффи-Хеллмана, который необходим для ключей сеанса VPN. Ключи сеанса являются временными или временными ключами и генерируются когда устанавливается соединение между клиентом и сервером.
Чтобы сгенерировать файл параметров Диффи-Хеллмана, выполните следующие команды:
[root@server] # cd /etc/openvpn/movpn
[root@server] # openssl dhparam -out dh2048.pem 2048
Теперь мы готовы настроить файлы конфигурации OpenVPN. На стороне сервера создайте следующий файл конфигурации и сохраните его как movpn-02-06-server.conf:
proto udp
port 1194
dev tun
tls-server
ifconfig 10.200.0.1 10.200.0.2
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
persist-key
persist-tun
keepalive 10 60
user nobody
group nobody
# use 'group nogroup' on Debian/Ubuntu
verb 3
daemon
log-append /var/log/openvpn.log
На стороне клиента создайте файл конфигурации movpn-02-06-client.conf:
port 1194
dev tun
tls-client
ifconfig 10.200.0.2 10.200.0.1
remote openvpnserver.example.com
remote-cert-tls server
tls-auth /etc/openvpn/movpn/ta.key 1
ca /etc/openvpn/movpn/movpn-ca.crt
cert /etc/openvpn/movpn/client1.crt
key /etc/openvpn/movpn/client1.key
persist-key
persist-tun
keepalive 10 60
user nobody
group nobody
# use 'group nogroup' on Debian/Ubuntu
verb 3
daemon
log-append /var/log/openvpn.log
Далее запускаем клиент и сервер:
[root@server] # openvpn --config movpn-02-06-server.conf
[root@client] # openvpn --config movpn-02-06-client.conf
После завершения последовательности инициализации мы увидим, что созданный туннель имеет те же свойства, что и туннель, созданный с помощью предустановленных ключей.
Резюме
Точка-точка была единственной поддерживаемой конфигурацией в начальных версиях OpenVPN. В этой главе мы начали с очень простого примера «точка-точка». Мы представили больше возможностей OpenVPN и увидели, что есть веские причины использовать этот режим в производственной среде. В последнем случае мостовые tap-адаптеры используются как на клиентской стороне, так и на серверной.
Это единственная глава, в которой объясняется режим «точка-точка». В следующей главе мы правильно настроим сертификаты, необходимые для использования другого режима OpenVPN, модель клиент/сервер.
Виртуальные частные сети (VPN) расширяют
сеть предприятия, размыкая пределы
локальных сетей. С помощью VPN сотрудники,
находящиеся вне предприятия, могут
безопасно подключиться к корпоративной
локальной сети из любой точки Internet.
Аутентифицированный и зашифрованный
туннель VPN прокладывается через Internet,
поэтому затраты на его организацию гораздо
ниже, чем на дорогостоящие двухточечные
специальные сетевые каналы. Многие
администраторы знакомы с решениями RRAS VPN
компании Microsoft и с коммерческими VPN таких
поставщиков, как Cisco Systems и Nortel Networks, но не
всем известно об открытой программе OpenVPN,
которая отличается высокой гибкостью и
располагает функциями VPN. При значительно
меньших затратах, основные функции OpenVPN
такие же, как у коммерческих конкурентов.
OpenVPN распространяется бесплатно, и
администратору приходится тратить время
лишь на настройку конфигурации.
Предприятиям, которые уже располагают
коммерческой VPN, нет смысла менять ее на
OpenVPN. Но если нужно организовать новую VPN для
офиса филиала или лаборатории, либо
требуется недорогое, безопасное решение
для связи с удаленными сетями, то OpenVPN
заслуживает внимания. Программа совместима
со многими операционными системами,
поэтому может стать альтернативой VPN-функциональности
RRAS или Microsoft Internet Security and Acceleration (ISA) Server для
предприятий, использующих платформу Windows. В
данной статье рассматриваются основные
этапы развертывания клиентского решения
OpenVPN и важнейшие характеристики продукта.
Основы OpenVPN
В OpenVPN ряд основных функций защиты VPN
реализован на базе протокола Secure Sockets Layer
(SSL)/Transport Layer Security (TLS), а в других сетевых VPN
для этого используются протоколы IP Security
(IPsec) или PPTP. В отличие от других SSL VPN,
достоинством которых считается
безклиентская установка (соединение SSL VPN
устанавливается через браузер), для OpenVPN
необходим специальный клиент. Кроме того,
OpenVPN представляет собой одноранговое (P2P)
приложение, поэтому одну программу можно
выполнять по обеим сторонам туннеля VPN.
В OpenVPN предусмотрены режимы моста (bridged) и
маршрутизации (routing), в которых сетевой
трафик можно направлять через единственный
порт UDP или TCP по выбору администратора. По
умолчанию OpenVPN использует протокол UDP и порт
1194. Любой сетевой трафик, посылаемый или
принимаемый для сетевого адаптера,
инкапсулируется в зашифрованный пакет и
доставляется в другой конечный пункт
туннеля OpenVPN, где данные расшифровываются и
попадают в удаленную сеть.
Базовая процедура конфигурирования очень
проста. Однако развернуть продукт в более
сложных условиях труднее. От
администратора требуется больше знаний и,
потенциально, усилий для настройки
существующей сетевой топологии, чем в
коммерческих продуктах VPN. Продукт
необходимо сначала протестировать и
освоить в лаборатории, а затем принять
решение о его пригодности для конкретного
предприятия.
Продукт предоставляется в соответствии с
условиями лицензии Open Source GNU General Public License (GPL)
и работает с Windows 2000 и более новыми версиями,
Linux, OpenBSD, FreeBSD, NetBSD, Mac OS X и Solaris. Выбрав
платформу, можно загрузить новейшую версию
OpenVPN с Web-узла http://openvpn.net. Во время подготовки
данного обзора самой новой версией была
OpenVPN 2.0-rc20. Сторонники графического
интерфейса могут загрузить необязательный
графический интерфейс с Web-узла OpenVPN
(http://www.nilings.se/openvpn) и установить его, следуя
простым инструкциям.
По сути OpenVPN представляет собой
приложение командной строки, которое можно
настроить на работу в качестве службы.
Приложение можно запускать с огромным
числом параметров настройки, сочетая ключи
командной строки и элементы файла
конфигурации. Полный список всех
параметров опубликован на странице OpenVPN Man
Page по адресу http://openvpn.net/man.html. Кроме того, для
управления несколькими конечными точками
туннелей на одном сервере можно
использовать несколько файлов
конфигурации.
Определение сетевой топологии
С помощью OpenVPN можно организовать VPN между
сайтами или клиентские туннели. Пакет OpenVPN
отличается гибкостью, и этапы настройки VPN
между сайтами и типа клиент-сервер похожи. В
действительности, одно приложение OpenVPN
устанавливается в обоих конечных пунктах
VPN. Как уже отмечалось, установить VPN в
базовой конфигурации просто, но программа
усложняется при активизации
дополнительных функций. Например, чтобы
запустить и настроить некоторые функции
безопасности, необходимы познания в
шифровании и управлении ключами. OpenVPN
поддерживает несколько механизмов
аутентификации, в том числе сертификаты,
смарт-карты и учетные данные пользователя,
имя пользователя/пароль. Однако чтобы
применить такие меры безопасности, нужно
задействовать сложные компоненты
программы, и для их реализации
администратор должен хорошо знать основы
PKI. На Web-узле OpenVPN опубликованы полезные
документы и примеры, которые могут
пригодиться при настройке этих параметров.
Настройка сервера
Загрузив версию для Windows, следует
скопировать ее на сервер, который будет
применяться в качестве сервера VPN, и
запустить программу установки. Мастер
проводит пользователя по этапам этой
процедуры, которая состоит в развертывании
OpenVPN, программы настройки графического
интерфейса OpenVPN и инструмента генерации
запроса сертификата. Мастер запрашивает
различные параметры, но для базовой
установки достаточно значений, выбираемых
по умолчанию. Программы и исходные файлы
можно найти в папке C:Program FilesOpenVPN.
После завершения установки появляется
дополнительный сетевой адаптер —
устройство с именем TAP-Win32 Adapter V8. Если
планируется настроить OpenVPN в режиме моста,
то необходимо вручную организовать
мостовое соединение нового адаптера с
другим сетевым адаптером, уже имеющимся в
системе. Если предстоит работать в режиме
маршрутизации, то Windows распознает
устройство как сетевой адаптер с IP-адресом.
Обе конфигурации — мостовая и маршрутизации
— будут рассмотрены ниже.
Но сначала следует познакомиться с
основным инструментарием настройки OpenVPN. На
сервере требуется перейти в каталог OpenVPN (по
умолчанию C:Program FilesOpenVPNconfig), скопировать
файл sample.ovpn.txt и дать ему любое другое имя с
расширением .ovpn (например, myOpenVpnConfig.ovpn). В
этом файле содержится подробно
аннотированный пример настройки OpenVPN. После
более близкого знакомства с работой OpenVPN
администратор сможет создать собственный
файл конфигурации OpenVPN длиной всего
несколько строк.
OpenVPN работает подобно P2P VPN, поэтому каждый
активный экземпляр файла в компьютере в
действительности представляет собой еще
одну конечную точку. В данном примере будет
показано, как настроить одну систему в
качестве сервера VPN, который сможет
принимать соединения из любого IP-адреса.
Необходимо открыть новый файл конфигурации
и отыскать текст
remote myremote
Поскольку данный компьютер настраивается
для выполнения функций сервера, он не будет
устанавливать исходящих соединений с
удаленным компьютером. Поэтому указанную
строку следует превратить в комментарий с
помощью точки с запятой (;):
; remote myremote
Если указан адрес удаленного компьютера (например,
remote 10.0.0.10), то будут разрешены соединения
только с этим адресом. Это одна из мер
защиты двухточечного соединения VPN между
двумя удаленными сетями. Однако данная
конечная точка настраивается в качестве VPN-сервера
OpenVPN, так что придется разрешить соединения
от любых удаленных клиентов. По этой
причине мы просто превратили строку в
комментарий. Позднее данный VPN-сервер будет
настроен как удаленный компьютер.
По умолчанию OpenVPN использует UDP-порт с
номером 1194. Если порт нужно изменить —
например, чтобы использовать протокол,
который открывают большинство
администраторов брандмауэров, такой как TCP
443 — следует отыскать строку
; port 1194
и снять комментарий, убрав точку с запятой.
Затем можно изменить номер порта, указав
свой. По умолчанию применяется протокол UDP,
но можно использовать и TCP. UDP более
эффективен, и TCP рекомендуется применять
только в случаях, когда UDP не работает,
например, если брандмауэр блокирует весь
трафик UDP. UDP не требует дополнительных
затрат ресурсов, свойственных TCP, поэтому
его производительность несколько выше,
благодаря меньшему размеру заголовков и
отсутствию встроенной функции
подтверждения доставки пакетов, как в TCP.
Однако OpenVPN шифрует исходные пакеты,
обеспечивая проверку ошибок и повторную
передачу, поэтому общая надежность не
снижается.
Затем следует выбрать сетевой протокол dev
tap или dev tun. Если планируется использовать
OpenVPN в режиме моста, необходимо выбрать dev tap.
В данном примере выполняется настройка
соединения Windows-Windows в мостовой
конфигурации, поэтому выбран протокол dev tap.
В файле конфигурации должен быть элемент
dev tap
Затем настраивается метод аутентификации
соединения. Для соединений, требующих
повышенной безопасности, следует настроить
TLS с собственной парой сертификат/ключ на
обоих концах соединения. В данном примере
для настройки VPN-соединения используется
статический ключ (другие функции
шифрования OpenVPN описаны во врезке «Режимы шифрования»).
Сервер будет принимать только соединения
OpenVPN с таким же статическим ключом.
В меню Start, All Programs, OpenVPN следует щелкнуть на
пункте Generate a static OpenVPN key. В результате
запускается простая консольная программа,
которая генерирует ключ и копирует его в
файл C:Program FilesOpenVPNconfigkey.txt. Любой
обладатель статического ключа сможет
установить соединение с конечной точкой
OpenVPN, поэтому его следует хранить в секрете.
Данный метод похож на процедуру настройки
беспроводного узла доступа Access Point (AP) со
статическим ключом. Статического ключа
достаточно, чтобы связать две удаленные
сети через OpenVPN, но если организован
конечный сервер OpenVPN со многими клиентами,
то лучше применять более надежный метод
аутентификации пользователей, такой как
сертификаты.
Файл конфигурации OpenVPN должен содержать
команду Secret, за которой следует имя файла
ключа:
secret key.txt
Если пример файла конфигурации .ovpn был
предварительно скопирован, то изменять
команду secret не нужно, так как она включена
по умолчанию. Наконец,
полезно добавить в файл конфигурации
следующие две команды:
verb 4
mute 10
Команда
verb задает уровень детализации журнала OpenVPN,
и администратор может задать значение от 0
до 11. Параметр 0 означает, что не
отображается никаких выходных данных,
кроме неисправимых ошибок, а параметр 11
отображает множество данных, полезных при
отладке. Как правило, для большинства
пользователей достаточно значения 4.
Команда mute выдает множество сообщений об
ошибках и статусе. Эта команда полезна, если
повторные попытки клиента установить
соединение заканчиваются неудачей, и нужно,
чтобы журнал не засоряли экземпляры одного
и того же сообщения. Параметр 10 команды mute
означает, что OpenVPN будет отображать не более
10 экземпляров одного сообщения, и отбросит
остальные.
Настройка
конфигурации клиента
Процесс
установки клиента OpenVPN похож на процедуру
для сервера. Нужно развернуть ту же
программу OpenVPN и создать файл конфигурации
.ovpn. Параметры должны соответствовать
параметрам, заданным на сервере, с
немногими исключениями. С помощью
надежного носителя, такого как гибкий диск,
нужно скопировать статический ключ,
подготовленный для сервера (key.txt), на
клиентский компьютер (например, в каталог
C:Program FilesOpenVPNconfig).
Конфигурация
клиента OpenVPN, использующего выбираемый по
умолчанию протокол UDP и порт с номером 1194,
может выглядеть следующим образом:
remote 10.0.0.2
dev tap
ifconfig 192.168.0.100
255.255.255.0
secret key.txt
verb 4
mute 10
Данная конфигурация идентифицирует
удаленный VPN-сервер, с которым установит
соединение клиент, определяет сетевой
протокол как dev tap и назначает клиентский IP-адрес
для OpenVPN. Также назначаются параметры для
Secret, Verb и Mute. Клиентский IP-адрес зависит от
режима OpenVPN — моста или маршрутизации. В
режиме моста этот адрес должен совпадать с
IP-адресом локальной сети.
Мост или маршрутизация?
Итак, конфигурация сервера и клиента OpenVPN
настроена. Но это еще не все. Необходимо
внести в конфигурацию дополнительные
изменения, в зависимости от режима OpenVPN —
мост или маршрутизация. У каждого варианта
есть свои преимущества в зависимости от
нужд предприятия. При организации моста
между двумя сетями все объекты обоих сетей
выглядят как часть единой подсети. Поэтому
приложения, которые ведут
широковещательную передачу данных, смогут
работать через туннель VPN. Однако
увеличивается интенсивность трафика через
VPN, что замедляет связь. Организовать мост
проще, так как не нужно заботиться о
настройке новых сетевых маршрутов,
добиваясь, чтобы все компьютеры на обеих
сторонах VPN могли устанавливать соединения
друг с другом. Однако в режиме моста
локальная сеть предприятия слабее защищена
от входящих клиентов VPN (или сетей), чем в
режиме маршрутизации.
В конечном итоге выбор может зависеть от
необходимого уровня управляемости.
Простота настройки моста — существенное
преимущество, если нужен быстрый, простой
доступ к домашней или малой сети, либо если
пользоваться VPN будет одно лицо. Но если
необходимо развернуть OpenVPN как VPN-концентратор
для большого числа пользователей, то
маршрутизация обеспечивает более высокую
гибкость.
Рассмотрим пример с мостом. В режиме моста
строится мост между OpenVPN TAP-Win32 Adapter V8 и
сетевым адаптером VPN-сервера. В этом режиме
любой сетевой трафик любого адаптера
выглядит так, как будто оба сетевых
адаптера подключены к одной подсети.
Образующий мост адаптер имеет один IP-адрес.
Мост между адаптерами строится в Windows, а не в
файле конфигурации OpenVPN.
После установки программы OpenVPN следует
открыть утилиту Network Connections в панели
управления. Нажав клавишу Ctrl, следует
выделить как сетевой адаптер локальной
сети, так и адаптер OpenVPN TAP-Win32. Когда оба
адаптера будут выделены, нужно щелкнуть
правой кнопкой мыши на одном из адаптеров и
выбрать пункт Bridge Connections из контекстного
меню. Спустя мгновение на экране появится
новый объект мостового сетевого адаптера.
Этот объект функционирует как сетевой
адаптер и, по умолчанию, система назначит
ему IP-адрес DHCP. На одном компьютере можно
создать несколько конечных точек VPN с
помощью нескольких адаптеров OpenVPN TAP-Win32.
Если нужно соединить их в мостовой
конфигурации, то следует присоединить их к
мосту, обратившись к Properties раздела Network Bridge
и выбрав дополнительные адаптеры.
Если OpenVPN работает на многоузловом (multihomed)
компьютере — например, компьютере с
внутренним (корпоративная сеть) и внешним (общедоступный
канал в Internet) интерфейсами — то подключать к
мосту внешний сетевой адаптер нельзя. Мост
должен соединять только внутренний (корпоративная
сеть) сетевой адаптер с адаптером OpenVPN TAP-Win32,
а внешний интерфейс необходимо обязательно
защитить брандмауэром или другим
устройством. Это все, что нужно сделать,
чтобы настроить сервер для работы OpenVPN в
режиме моста. Никаких изменений в серверы
вносить не требуется.
После настройки файлов конфигурации как
на сервере, так и на клиенте, следует
сохранить их и запустить программу OpenVPN,
сначала на сервере. OpenVPN нужно запустить из
системной панели, щелкнув правой кнопкой
мыши на пиктограмме OpenVPN, а затем на кнопке
Connect. На экране появится диалоговое окно
OpenVPN с несколькими сообщениями о состоянии.
Если соединение выполнено успешно, то
пиктограмма становится желтой и программа
ожидает новых соединений. Для запуска
соединения OpenVPN из командной строки нужно
ввести команду
openvpn config
Затем следует подключить клиента,
повторив описанные выше шаги (Экран 1). Если соединение успешно
установлено, то цвет пиктограммы станет
зеленым, и появится сообщение, показанное
на Экране 2. После того, как соединение
установлено, можно обратиться к сетевому
приложению в удаленной сети — например,
протестировать соединение, направив ping-сигнал
на сервер удаленной сети с клиента.
Настройка бесплатной VPN с открытым исходным
текстом завершена.
Какая VPN нужна предприятию?
OpenVPN надежна и устойчива к отказам сети.
Если сетевое соединение прервано при
активной сети VPN, то OpenVPN автоматически
восстанавливает соединение после
восстановления сетевого канала связи. Для
простых случаев, таких как описано в данной
статье, OpenVPN позволяет быстро организовать
туннель OpenVPN, без серьезных дополнительных
затрат. Труднее освоить продукт при
использовании более сложных конфигураций —
например, если требуется пользовательская
аутентификация, выделение пула адресов VPN,
либо прокладка нескольких туннелей за
брандмауэром с помощью NAT (Network Address Translation).
OpenVPN поддерживает эти режимы, но требует
знания технических тонкостей. В таких
случаях проще развернуть коммерческие VPN,
так как у них, как правило, есть графический
интерфейс и предоставляются технические
консультации.
Цена коммерческих VPN также снизилась:
всего за несколько тысяч долларов можно
приобрести коммерческий концентратор VPN
для обслуживания сотен пользователей.
Кроме того, в VPN на базе UDP или TCP устранены
многие несогласованности брандмауэра VPN,
которые мешали работе туннелей IPsec. OpenVPN — не
для всех; средним и крупным компаниям лучше
по-прежнему работать с коммерческими
продуктами VPN. Но в лабораториях и малых
офисах, для которых имеет большое значение
стоимость решения и не требуется сложной
конфигурации, OpenVPN будет незаменим.
Режимы шифрования
OpenVPN поддерживает два типа шифрования:
статический ключ и Transport Layer Security (TLS). В Windows
статический ключ настроить легко. После
установки OpenVPN на одной из сторон VPN следует
запустить генератор ключей OpenVPN и
скопировать новый ключ (на защищенном
носителе) в папку OpenVPN всех других
компьютеров с OpenVPN, которым необходимо
подсоединение к этой конечной точке OpenVPN. В
файле настройки для всех конечных точек
просто укажите имя файла ключа. По
умолчанию OpenVPN использует для шифрования
режим Blowfish Cipher Block chaining (BF-CBC), но можно
выбрать и Advanced Encryption Standard (AES), Data Encryption Standard
(DES), International Data Encryption Algorithm (IDEA), или какой-то
иной, указав параметр шифрования в файле
настройки. Приложение использует функции
шифрования, аутентификации и проверки
сертификатов из библиотеки OpenSSL, поэтому
необходимо отслеживать обновления для OpenSSL.
OpenVPN также поддерживает TLS с
использованием обмена ключами алгоритма
Diffie-Hellman и ключи и сертификаты RSA. Установка
сертификатов и ключей в этом случае подобна
настройке других инфраструктур PKI,
поддерживающих X.509 PKI для аутентификации
сессии. При отсутствии опыта такой
настройки следует просмотреть материалы по
ссылкам на Web-сайте OpenVPN. Версии OpenVPN для Linux и
UNIX имеют большее количество справочных
материалов и программ для настройки TLS, чем
версия для Windows. В примерах этой статьи я
использовал статический ключ, чтобы
сделать акцент на самом процессе настройки
туннеля OpenVPN.
Джеф Фелинг (jeff@blackstatic.com) — Директор по
информационной безопасности компании
aQuantive. Автор книги IT Administrator’s Top 10 Introductory Scripts
for Windows (издательство Charles River Media).
OpenVPN — свободная реализация технологии виртуальной частной сети (VPN) с открытым исходным кодом для создания зашифрованных каналов типа точка-точка или сервер-клиенты между компьютерами. Она позволяет устанавливать соединения между компьютерами, находящимися за NAT и сетевым экраном, без необходимости изменения их настроек. OpenVPN была создана Джеймсом Йонаном (James Yonan) и распространяется под лицензией GNU GPL.
- создание и подключение к виртуальным сетям;
- создание шифрованных подключений (тоннелей) точка-точка;
- возможность подключения через HTTP и SOCKS-поркси, NAT и различные сетевые фильтры;
- надёжная защита передаваемых данных с помощью OpenSSL и различных типов шифрования;
- уменьшение нагрузки на канал за счёт сжатия трафика;
- различные виды аутентификации с возможностью использования сторонних модулей и скриптов.
Оглавление
- 1 Как работает OpenVPN
- 1.1 Установка OpenVPN на машину-сервер
- 1.2 Настраиваем сервер.
- 1.2.1 Как настроить сетевой мост между двумя сетями для Open VPN сервера?
- 1.2.2 Openvpn клиенты не видят друг друга, как настроить файл конфигурации сервера?
- 1.2.3 Как сделать автоматический старт OpenVPN соединения при запуске Windows?
- 1.3 Пора создавать сертификаты
- 1.4 Настройка клиента
- 1.5 Доступ к локальной сети
- 1.5.1 1. Настройка реестра
- 1.5.2 2. Настройка OpenVPN Server
- 1.5.3 3. Разрешаем доступ к локальной сети
- 1.6 Ваш аккаунт
- 2 Возможные проблемы
- 2.1 Заключение
Протокол OpenVPN отвечает за поддержание коммуникации между клиентом и сервером. Как правило, он используется для создания защищённого туннеля между VPN-клиентом и сервером. Читайте так же: “Как обойти блокировку”
Для шифрования и аутентификации OpenVPN использует библиотеку OpenSSL. Кроме того, для передачи данных OpenVPN могут использоваться протоколы UDP или TCP.
- TCP требует отклика от клиента, которому доставлен пакет данных, подтверждения доставки, и для этого ему необходимо установленное заранее соединение. Протокол TCP исключает потери данных, дублирование и перемешивание пакетов, задержки.
- UDP всё это допускает, и соединение для работы ему не требуется. Протокол UDP доставляет пакеты данных гораздо быстрее, потому лучше подходит для приложений, которые рассчитаны на широкую пропускную способность и быстрый обмен.
Установка OpenVPN на машину-сервер
Инсталляция представляет собой стандартную процедуру с некоторыми нюансами, о которых и поговорим подробнее.
- Первым делом необходимо скачать программу по ссылке ниже.Скачать OpenVPN
- Далее запускаем установщик и доходим до окна выбора компонентов. Здесь нам потребуется поставить галку возле пункта с названием «EasyRSA», что позволит создавать файлы сертификатов и ключей, а также управлять ими.
- Следующий шаг – выбор места для инсталляции. Для удобства поместим программу в корень системного диска С:. Для этого просто удалим лишнее. Должно получитьсяC:OpenVPN
Делаем мы это и для того, чтобы избежать сбоев при выполнении скриптов, так как пробелы в пути недопустимы. Можно, конечно, брать их в кавычки, но внимательность может и подвести, а искать ошибки в коде – дело непростое.
- После всех настроек устанавливаем программу в штатном режиме.
Настраиваем сервер.
Создаем:
с:openvpneasy-rsavars.bat
echo off
set path=%path%;c:OpenVPNbin
set HOME=c:OpenVPNeasy-rsa
set KEY_CONFIG=openssl.cnf
set KEY_DIR=c:OpenVPNssl
set KEY_SIZE=1024
set KEY_COUNTRY=RU
set KEY_PROVINCE=mycity
set KEY_CITY= mycity
set KEY_ORG=Comp
set KEY_EMAIL=admin@local
«с:openvpneasy-rsaopenssl.cnf»#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# This definition stops the following lines choking if HOME isn’t
# defined.
HOME =.
RANDFILE = $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the “-extfile” option of the
# «openssl x509» utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by ‘ca’ and ‘req’.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = $ENV::KEY_DIR # Where everything is kept
certs = $dir # Where the issued certs are kept
crl_dir = $dir # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir # default place for new certs.
certificate = $dir/ca.crt # The CA certificate
serial = $dir/serial # The current serial number
crl = $dir/crl.pem # The current CRL
private_key = $dir/ca.key # The private key
RANDFILE = $dir/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crl_extensions = crl_ext
default_days = 3650 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = md5 # which md to use.
preserve = no # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that 🙂
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the ‘anything’ policy
# At this point in time, you must list all acceptable ‘object’
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = $ENV::KEY_SIZE
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret
# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix: PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr: PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
# so use this option with caution!
string_mask = nombstr
# req_extensions = v3_req # The extensions to add to a certificate request
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = $ENV::KEY_COUNTRY
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = $ENV::KEY_PROVINCE
localityName = Locality Name (eg, city)
localityName_default = $ENV::KEY_CITY
0.organizationName = Organization Name (eg, company)
0.organizationName_default = $ENV::KEY_ORG
# we can do this but it is not needed normally 🙂
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default =
commonName = Common Name (eg, your name or your server’s hostname)
commonName_max = 64
emailAddress = Email Address
emailAddress_default = $ENV::KEY_EMAIL
emailAddress_max = 40
# SET-ex3 = SET extension number 3
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ usr_cert ]
# These extensions are added when ‘ca’ signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape’s comment listbox.
nsComment = «OpenSSL Generated Certificate»
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
[ server ]
# JY ADDED — Make a cert with nsCertType set to «server»
basicConstraints=CA:FALSE
nsCertType = server
nsComment = «OpenSSL Generated Server Certificate»
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign
# Some might want this also
# nsCertType = sslCA, emailCA
# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy
# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where ‘obj’ is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always
Копируем index.txt.start в index.txt, а serial.start в serial в папку ssl
Как настроить сетевой мост между двумя сетями для Open VPN сервера?
В моем случае необходимо, чтобы клиенты подключаясь к нашей сети видели наши доступные компьютеры, а наши сервера «видели» бы нужные сетевые принтеры в соседней сети. Для этого нам нужно создать сетевой мост — объединить два сетевых устройство между собой.
В нашем случае это наш сетевой адаптер, который «смотрит» в интернет и только что созданный адаптер TAP. Настройки IP обнуляем. Выделяем оба адаптера мышкой и объединяем в «мост»:
После установки устройства «Сетевой мост» нужно сделать ему настройки через «свойства» IP адреса, шлюза, маски а так же адреса DNS -серверов (выданные провайдером) . Если IP не было — назначить постоянный, внутренний. Это важно, без этого наш сервер не заработает!
Настройки IP адаптеров включенных в мост не изменяем и ничего не трогаем!
Отключаем брандмауэр windows. Дополнительно, там же идем в «Разрешение обмена данными с приложениями в брандмауэре Windows, добавляем наш установленный open vpn в список (C:Program FilesOpenVPVBinOpenVPNgui,exe).
Сняли возможную блокировку соединения. Идем далее! Предварительная подготовка почти закончена. Теперь займемся непосредственно сервером. Идем в папку C:Program FilesOpenVPVeasy-rsa
В ней находятся программы с которыми мы сейчас будем взаимодействовать. Открываем командную строку от имени Администратора. Переходим в папку easy-rsa, для чего в командную строку скопируем команду cd C:Program FilesOpenVPNeasy-rsa
Все операции далее совершаем через командную строку. Для создания конфигурации сервера запустим файл init-config.bat
Создастся файл vars.bat, в нем мы заполним информацию, которую будут содержать сертификаты безопасности и с их помощью будут шифроваться данные. Для этого в блокноте открываем файл vars.bat и произвольно заполняем значения (командную строку не закрываем!):
rem down TLS negotiation performance
rem as well as the one-time DH parms
rem generation process.
set DH_KEY_SIZE=2048
rem Private key size
set KEY_SIZE=4096
rem These are the default values for fields
rem which will be placed in the certificate.
rem Change these to reflect your site.
rem Don’t leave any of these parms blank.
set KEY_COUNTRY=US
set KEY_PROVINCE=CA
set KEY_CITY=SanFrancisco
set KEY_ORG=OpenVPN
set KEY_EMAIL=mail@host.domain
set KEY_CN=server
set KEY_NAME=server
set KEY_OU=OU
set PKCS11_MODULE_PATH=changeme
set PKCS11_PIN=1234
Значения «server» не изменяем. Все значения (страна, регион, город, организация, почтовый адрес) проставляем произвольно английским шрифтом. Сохраняем файл. Переходим в командную строку снова. Набираем первой команду Vars.bat
Если OpenVPN устанавливался ранее -набираем команду clean-all.bat Она удалит созданную до этого папку с ключами (keys) со всем содержимым . При установе сервера OpenVPN с нуля делать эту команду необязательно.
Если у вас так как на фото, нормально. Идем далее
Теперь с помощью проводника перейдем в каталог C:Program FilesOpenVPNbin и скопируем файлы библиотек (*.dll) , файл openssl.exe в каталог, где лежат наши исполняемы файлы и который открыт сейчас в командной строке (C:Program FilesOpenVPNeasy-rsa):
Библиотеки нужны в этом каталоге, чтобы не возникало ошибок при создании сертификатов центра авторизации и файла Диффи-Хеллмана. Начнем с последнего. Файл Диффи-Хеллмана препятствует расшифровке информации (если файлы ключей были похищены), а так же отвечает за шифрование. Создадим его для нашего сервера в командной строке набрав команду build-dh.bat
Ждем, пока файл генерируется на основании информации указанной в vars.bat Далее, сгенерируем сертификат нашего удостоверяющего центра. Он будет необходим для дальнейшей выдачи серверного и клиентских сертификатов. Наберем в командной строке команду build-ca.bat Последовательно и не спеша нажимаем клавишу Enter…
…после появления очередной строчки; данные в сертификате будут скопированы по значениям указанным в файле vars.bat Следующий этап — создадим сертификат нашего сервера. В командной строке набираем команду build-key-server.batserver (server -имя серверного сертификата):
Так же последовательно и не спеша нажимаем Enter пока не дойдем до строчки Common Name(eg, your name or your servers hostname Здесь нужно обязательно указать имя сервера ( можно имя компьютера) и нажать Enter. Далее будут оставшиеся поля и запрос на создание пароля от сертификата. Просто нажимаем Enter. На вопросы записи сертификата и добавления его в базу данных нажимаем Y и Enter
Срок действия сертификата — 10 лет.
Если нужно поменять сроки действия открываем файл openssl 1.00.cnf и в строке default_days редактируем сроки действия серверного и клиентских сертификатов.
Теперь нам необходимо создать файл конфигурации сервера, выбрать протокол соединения, имя сетевого виртуального адаптера, порт соединения и еще много чего.
В папке sample-config лежит пример файла server.ovpn, находим его, открываем блокнотом( от имени администратора!):
Openvpn клиенты не видят друг друга, как настроить файл конфигурации сервера?
Очищаем содержимое server.ovpn и вставляем текст:
# Поднимаем L4-туннель
dev tap
#dev tune
# Имя устройства (указывается имя адаптера openvpn):
dev-node Ethernet
# Протокол, который использую:tcp
#proto udp
proto tcp
# Порт который «слушает» впн (должен быть открыт, не из списка «известных»)
port 13359
#server 10.8.0.0 255.255.255.0
# Данная машина является
#tls-server
#Укажем пулл незанятых разрешенных адресов из нашей локальной сети; укажем IP «моста», его маску а так же диапазон адресов
# Пул разрешенных адресов
server-bridge 192.168.0.1 255.255.255.0 192.168.0.111 192.168.0.121
# Включаю сжатие
comp-lzo
# Разрешаю клиентам видеть друг друга
client-to-client
#назначаю каждому клиенту свой постоянный IP
ifconfig-pool-persist ipp.txt
# Немного улучшит пинг
mssfix
# # Грубо говоря экономим адреса
topology subnet
# Метод шифрования
cipher AES-256-CBC
#при перезагрузке сервера:
persist-key
persist-tun
#Максимальный размер блока данных:
tun-mtu 1500
tun-mtu-extra 32
# Немного улучшит пинг
mssfix 1450
# Время жизни клиентов, если не откликнулся — отключает
keepalive 10 120
# Уровень отладки
verb 3
# максимальное количество клиентов
max-clients 10
status openvpn-status.log
Жирным выделил то, что можно менять. Ненужные строки можно закомментировать. Сохраняем файл под именем server.ovpn в папке C:Program FilesOpenVPNconfig Если не получается сохранить — запускаем блокнот (или программу NotePad++) от имени администратора, редактируем и сохраняем файл куда нужно.
Из папки Key скопируем сгенерированные нами файлы ключей и сертификатов, файл dh2048.pem в папку Config — там же уже должен лежать наш файл server.ovpn
Операции с сервером можно считать почти законченными. Давайте стартуем и проверим наш сервер. На рабочем столе запустим ярлык OpenVPNgui в виде оранжевой замочной скважины (от имени Администратора!) На панели задач рядом с основным значком появиться еще один значок подключения. Кликнув по нему мышкой обнаруживаем, что устанавливается соединение. Если сервер стартовал успешно — значок подключения станет зеленым
Как сделать автоматический старт OpenVPN соединения при запуске Windows?
Каждый раз запускать вручную соединение неудобно. В ярлыке OpenVPNgui (свойствах объекта) дописываем аргумент —connect server.ovpn, Ярлык помещаем в «автозагрузку». Я настраивал автозапуск быстро с помощью glary utilites
Вот так это выглядит Команда —connect дает соединение, а настройки его берутся из файла нашего server.ovpn
Если планируется круглосуточная работа сервера — советую настроить операционную систему на автоматический вход без пароля. Это гарантирует самозапуск соединения после перезагрузок, которые бывают при отключении света, установки обновлений.
С сервером закончили. Не забываем открыть порт (указанный в конфиге сервера) на роутере, чтобы предоставить доступ к нашему серверу извне.
Пора создавать сертификаты
Открываем командную строку от имени администратора и выполняем последовательно:
- vars
- clean-all
- build-ca
#(принимаем все значения по умолчанию нажатием клавиши Enter) - build-dh
- build-key-server SERVER_NAME(на ваш выбор)
#При запросе на ввод Common name необходимо снова ввести наше SERVER_NAME
Далее во избежание проблем с созданием сертификата клиента очищаем index.txt папке ssl - buid-key KLIENT(на ваш выбор)
- openvpn –genkey –secret %KEY_DIR%ta.key
Создаем server.ovpn в папке config и редактируем его.
Создаем server.ovpn в папке config и редактируем его.
server.ovpn dev tun
proto tcp-server
port 5190
tls-server
server 192.168.0.0 255.255.255.0
comp-lzo
dh C:OpenVPNssldh1024.pem
ca C:OpenVPNsslca.crt
cert C:OpenVPNsslServer.crt
key C:OpenVPNsslServer.key
tls-auth C:OpenVPNsslta.key 0
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
keepalive 10 120
status C:OpenVPNlogopenvupn-status.log
log C:OpenVPNlogopenvpn.log
verb 3
Отправляем CA.crt, klient.crt, klient.key, ta.key из «c:openvpnssl» нашим клиентам (помещаем их в такую же директорию « c:openvpnssl»).
Настройка клиента
На сервере:
На сервере генерируем сертификат для клиента. Для этого сначала чистим файл index.txt в папке C:Program FilesOpenVPNeasy-rsakeys.
Затем запускаем командную строку от имени администратора:
Переходим в каталог easy-rsa:
cd %ProgramFiles%OpenVPNeasy-rsa
Запускаем vars.bat:
vars.bat
И генерируем сертификат первого пользователя:
build-key.bat client1
* на все запросы наживаем Enter, кроме Common Name — в данном поле вводим имя клиента (в нашем случае, просто client1). В конце подтверждаем введенную информацию — y.
** На каждого клиента нужно сгенерировать свой сертификат, в противном случае, им будет присваиваться один и тот же IP-адрес, что будет приводить к конфликту.
Получиться, что-то на подобие:
Country Name (2 letter code) [RU]:
State or Province Name (full name) [Sankt-Petersburg]:
Locality Name (eg, city) [Sankt-Petersburg]:
Organization Name (eg, company) [Organization]:
Organizational Unit Name (eg, section) [DMOSK]:
Common Name (eg, your name or your server’s hostname) [DMOSK]:client1
Name [server.domain.ru]:
Email Address [master@dmosk.ru]:
По умолчанию, для Common Name будет подставляться значение из vars.bat — но с ним сертификат не будет создаваться. Необходимо при создании каждого ключа подставлять значение, равное имени сертификата. Например, как выше — подставлено client1.
Теперь из папки keys копируем файлы:
- client1.crt
- client1.key
- ca.crt
- dh.pem
… и переносим их на клиентский компьютер.
На клиенте:
Заходим на официальную страницу загрузки openvpn и скачиваем клиента для Windows:
* по сути, это тот же файл, который скачивался для сервера.
Запускаем скачанный файл и устанавливаем программу, нажимая «Далее».
Переходим в папку C:Program FilesOpenVPNconfig. И копируем в нее сертификаты, которые перенесли с сервера.
Теперь открываем блокнот от имени администратора и вставляем следующие строки:
client
resolv-retry infinite
nobind
remote 192.168.0.15 443
proto udp
dev tun
comp-lzo
ca ca.crt
cert client1.crt
key client1.key
dh dh.pem
float
cipher DES-CBC
keepalive 10 120
persist-key
persist-tun
verb 0
* где 192.168.0.15 443 — IP-адрес OpenVPN-сервера и порт, на котором он принимает запросы. Для боевой среды это будет внешний адрес.
Сохраняем файл с именем config.ovpn в папке C:Program FilesOpenVPNconfig.
Запускаем с рабочего стола программу «OpenVPN GUI» от имени администратора (это важно).
Нажимаем правой кнопкой по появившемуся в трее значку и выбираем «Подключиться»:
Произойдет подключение и значок поменяет цвет с серого/желтого на зеленый.
Доступ к локальной сети
По инструкции выше мы сможем получить доступ только к серверу, на котором установлен OpenVPN. Для получения доступа ко всей внутренней сети, выполним следующие шаги.
1. Настройка реестра
Для включения IP маршрутизации в Windows необходимо в ветке реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters найти параметр IPEnableRouter и задать ему значение 1. Это можно сделать в утилите редактирования реестра (regedit) или командой:
reg add “HKLMSYSTEMCurrentControlSetServicesTcpipParameters” /v IPEnableRouter /t REG_DWORD /d 1 /f
* командную строку необходимо запускать от администратора.
2. Настройка OpenVPN Server
В конфигурационный файл OpenVPN добавим:
push “route 172.16.10.0 255.255.255.0”
push “route 192.168.2.0 255.255.255.0”
* где 172.16.10.0 — VPN сеть; 192.168.2.0 — локальная сеть, в которую необходимо «попасть» пользователям openvpn.
При необходимости использовать DNS внутренней сети также добавим:
push “dhcp-option DNS 192.168.0.15”
push “dhcp-option DNS 192.168.0.16”
push “dhcp-option DOMAIN dmosk.local”
* где 192.168.0.15 и 192.168.0.16 — внутренние DNS-серверы; dmosk.local — домен, который будет добавляться к узлам, обращение к которым идет по неполному имени.
Если нам нужно, чтобы все запросы клиента (в том числе, Интернет) ходили через сервер OpenVPN, добавляем:
push “redirect-gateway def1”
* в таком случае, нам не обязательно добавлять push route, который мы использовали выше.
Перезагружаем службу OpenVpnService.
3. Разрешаем доступ к локальной сети
Заходим в управление сетевыми подключениями (Панель управленияСеть и ИнтернетСетевые подключения). Кликаем правой кнопкой мыши по адаптеру локальной сети – Свойства:
На вкладке Доступ ставим галочку Разрешить другим пользователям сети использовать подключение к Интернету данного компьютера:
… и сохраняем настройки.
Ваш аккаунт
Возможные проблемы
Большая часть проблем решается при помощи логов, которые находятся в папке C:Program FilesOpenVPNlog. Уровень детализации лога контролируется параметром verb в конфигурационном файле сервера или клиента.
Также возможны следующие часто возникающие проблемы:
- Проблема: клиент постоянно пытается подключиться к серверу, но соединения не происходит или подключение зависает.
Причина: сервер блокирует подключения по настроенному порту VPN (в нашем примере, 443).
Решение: на сервере необходимо добавить 443 порт в исключения брандмауэра или отключить последний. - Проблема: при попытке подключиться к серверу выскакивает ошибка «Не удалось подключиться к config».
Причина: ошибка в настройках.
Решение: перепроверьте каждую строчку файла конфигурации. Проверьте наличие всех файлов, на которые ссылаетесь в настройках. - Проблема: клиенты получают одинаковые IP-адреса.
Причина: подключение выполняется под одним и тем же пользователем.
Решение: сервер выдает одинаковые адреса одинаковым клиентам. Необходимо настроить авторизацию на сервере и выдать каждому клиенту индивидуальные настройки. - Проблема: соединение происходит, но через несколько минут связь прерывается.
Причина: дублирование IP-адресов.
Решение: данная проблема описана выше (пункт 3).
Заключение
Организация собственной VPN-сети позволит вам максимально защитить передаваемую информацию, а также сделать интернет-серфинг более безопасным. Главное – быть внимательнее при настройке серверной и клиентской части, при правильных действиях можно будет пользоваться всеми преимуществами частной виртуальной сети.
- https://CyberSoft.ru/internet/vpn-klienty/236-openvpn.html
- https://windd.ru/kak-polzovatsya-openvpn-gui/
- https://lumpics.ru/configuring-openvpn-server-on-windows/
- https://habr.com/ru/sandbox/58689/
- https://fast-wolker.ru/kak-polzovatsya-openvpn.html
- https://www.dmosk.ru/instruktions.php?object=openvpn-server-windows
Есть: несколько филиалов компании все компьютеры которых в сети 192.168.13.0/24 работают под WindowsXP SP3
Задача: организовать связь между филиалами
Замечание: При использовании OpenVPN есть два варианта реализации: с использованием tun или tap интерфейсов (tun = L3-туннель, tap = L2-туннель).
Мы выбрали tun по двум причинам:
1. Тестирование показало нестабильную работу моста из tap интерфейса (TAP Win32 Adapter v9) и интерфейса смотрящего в локальную сеть (проверялось с сетевыми картами RTL8139 и Realtek PCIe GBE Family Controller) в WindowsXP sp3: через различные промежутки времени «отваливался» внутренний интерфейс шлюза.
2. При использовании tap сегменты соединяются как будто они соединены обычным кабелем через свитчи (во всех сегментах одинаковые маски подсети). В нашем случае во время внедрения такая конфигурация была возможна, но при увеличении числа активных сетевых устройств пришлось бы переводить все сетевые устройства на маску 255.255.0.0.
По этим причинам и был выбран вариант с использованием tun, но предварительно в сегментах сети провели подготовительные работы по изменению номера подсети (192.168.14.0/24).
Первоначальная установка состоит из трех основных этапов:
Установка OpenVPN
Windows:
Качаем инсталлятор http://openvpn.se/download.html
Устанавливаем в D:OpenVPN
Созданный адаптер переименовываем в openvpn
Если используется конфигурация на tap-адаптерах, то создаем сетевой мост на компьютерах.
Выделяем адаптер смотрящий в локальную сеть lan_xxx и OpenVPN. ПКМ — Подключения типа мост
Ждем некоторое время пока создастся мост.
В настройках tcp/ip моста указываем параметры адаптера локальной сети (как правило IP и маску)
Иногда появляется сообщение что нужно выбирать адаптеры без общего доступа.
Тогда снимаем общий доступ с wan подключения и пробуем опять сделать мост.
При возврате wan подключению общего доступа могут также появляться ошибки.
Тогда нужно в параметрах tcp/ip подключения wan выставить автоматическое получение ip адреса. И после разрешения общего доступа проверить и при необходимости исправить TCP/IP конфигурацию моста и wan подключения.
Созданный мост переименовываем в OpenVPN Bridge
Конфигурируем TrafficInspector
Конфигуратор — Настройка служб TI — Далее — Далее — Далее — Внутренние интерфейсы выбираем OpenVPN Bridge — Далее — Далее — Внешний интерфейс WAN — Далее — Далее — Далее — Готово
Linux:
ставим пакеты openvpn и openvpn-blacklist, и openssl для генерации сертификатов если еще не установлено
Настройка ротации логов open vpn для webmin:
Log File Rotation — Add a new log file to rotate
Log file paths — путь к лог файлам
Rotation schedule Default (weekly) — периодичность, на свое усмотрение
Maximum size before rotating Default (Never) bytes — если нужно можно указать максимальный размер лога
Number of old logs to keep Default (4) — количество хранимых копий
Compress old log files? Да — сжатие архивных логов
Delay compression till next cycle? Да — сжимать предпоследнюю копию, последнюю не сжимать.
Truncate log file in place? Да — очистить текущий лог файл.
Rotate even if log file is empty? Нет — пустой лог файл можно не сжимать
Ignore log file if missing? Да — пропустить если нет лога
Re-create log file after rotation? No, don’t re-create — не нужно файл пересоздавать, мы его не удаляем
Store old rotated logs in Directory Default (Same directory as log file) — оставлять архивный лог где и был
Extension for rotated filenames По умолчанию — добавляются цифры к архивной копии
Email log file before deleting? — настройки отсылки лога по e-mail оставим все по умолчанию
Commands to run before rotation — пусто
Commands to run after rotation
invoke-rc.d rsyslog reload > /dev/nullOnly run scripts once for all files? Да
Генерация ключей
Windows:
Генерируем ключи и корневые сертификаты
Копия папки easy-rsa есть в USERBessonov_Evgeniynet
http://www.kryukov.biz/wiki/Openvpn
Все операции выполняются на сервере. ключ и сертификат необходимо генерировать для каждого клиента отдельно.
Идем в C:Program FilesOpenVPNeasy-rsa
Запускаем init-config.bat
Правим vars.bat
@echo off
set HOME=%ProgramFiles%OpenVPNeasy-rsa
set KEY_CONFIG=%ProgramFiles%OpenVPNeasy-rsaopenssl.cnf
set KEY_DIR=keys
set KEY_SIZE=1024
set KEY_COUNTRY=RU
set KEY_PROVINCE=RU
set KEY_CITY=OMSK
set KEY_ORG=rr
set KEY_EMAIL=admin@ru55.ru
В командных файлах в этой папке необходимо проверить правильность указания пути к openssl.exe (по умолчанию указано только имя файла поэтому в каждой строке где есть указание на запуск openssl перед командой добавляем ..bin иначе командный файл не найдет исполняемый файл и выдаст ошибку.
Далее открываем консоль и запускаем по очереди:
vars.bat установит переменные окружения для этого сеанса консоли
clean-all.bat советуют запускать для очистки лишней информации (на всякий случай запустим)
build-ca.bat создает корневой сертификат и ключ
Замечание: При использовании файла openssl.cnf который включен в дистрибутив будут появляться ошибки типа:
WARNING: can’t open config file: c:openssl/ssl/openssl.cnf
error on line 150 of D:OpenVPNeasy-rsaopenssl.cnf
568:error:0E065068:configuration file routines:STR_COPY:variable has no value:.cryptoconfconf_def.c:618:line 150
В таком случае можно за комментировать строки в которых найдены ошибки (в данном случае это строка 150)
build-key-server.bat server — создает ключ и сертификат сервера (вместо server указываем dns-имя нашего сервера)
Внимательно смотрим на диалоговые вопросы. Некоторые ответы уже определены в переменных и можно просто жать Enter. На запрос commonName вписываем имя сервера.
build-key.bat client — создает ключ и сертифика клиента (вместо client указываем dns-имя клиентского компьютера. запускать для каждого клиента)
Внимательно смотрим на диалоговые вопросы. Некоторые ответы уже определены в переменных и можно просто жать Enter. На запрос commonName вписываем имя клиента.
build-dh.bat — создает Diffie Hellman параметры.
Назначение файлов:
Файл Машина Назначение Доступ
ca.crt Сервер и клиенты Сертификат корневого СА Публичный
ca.key Только на сервере Необходим для подписи других Секретный
сертификатов
dh1024.pem Только на сервере Diffie Hellman параметры Публичный
server.crt Только на сервере Сертификат сервера Публичный
server.key Только на сервере Ключ сервера Секретный
client.crt Только на клиенте Сертификат клиента Публичный
client.key Только на клиенте Ключ клиента Секретный
Linux (debian-6.0.2):
Источник: http://www.netlly.ru/index.php?option=c … &Itemid=28
Ставим OpenVPN и OpenSSL
aptitude install openvpn opensslКопируем скрипты генерации сертификатов и ключей
cp -R /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn/Правим параметры
vi /etc/openvpn/easy-rsa/vars
export KEY_COUNTRY=RU
export KEY_PROVINCE=RU
export KEY_CITY=Omsk
export KEY_ORG=ru55
export KEY_EMAIL= adm@ru55.ruИнициализируем PKI (Public Key Infrastructure)
cd /etc/openvpn/easy-rsa/
./vars
./clean-all Генерируем Certificate Authority (CA) сертификат и ключ
Большинство параметров подхватятся из файла vars. Только параметр Common Name надо указать явно
Common Name (eg, your name or your server’s hostname) [ ]: ru55
Генерируем параметры Диффи — Хеллмана
Генерируем сертификат и секретный ключ сервера
./build-key-server serverВсе параметры принимаем по умолчанию. На запрос Common Name вводим server
Common Name (eg, your name or your server’s hostname) [ ]:server
На вопросы Sign the certificate? и 1 out of 1 certificate requests certified, commit? отвечаем положительно
Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y
Генерируем сертификат и секретный ключ клиента
Все параметры принимаем по умолчанию. На запрос Common Name вводим client
Common Name (eg, your name or your server’s hostname) [ ]:client
На вопросы Sign the certificate? и 1 out of 1 certificate requests certified, commit? отвечаем положительно
Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y
вместо client указать номер подсети для которой готовится клиент.
Создание файлов конфигурации (tun)
Windows
Сервер winxp
server.ovpn
dev tun
tls-server
server 10.8.0.0 255.255.255.0
ifconfig 10.8.0.1 255.255.255.0
tun-mtu 1480
client-config-dir ccd
#routes
route 10.8.0.0 255.255.255.0 #IP Range of VPN
route 192.168.14.0 255.255.255.0 #10.8.0.2 #IP Range of Debian
route 192.168.15.0 255.255.255.0 #10.8.0.5 #IP Range of Router
push "route 192.168.13.0 255.255.255.0" #Say to clients that RI160 has 192.168.13.0/24 LAN
#keys
ca "C:\Program Files\OpenVPN\config\keys\ca.crt"
cert "C:\Program Files\OpenVPN\config\keys\ri160.crt"
key "C:\Program Files\OpenVPN\config\keys\ri160.key"
dh "C:\Program Files\OpenVPN\config\keys\dh1024.pem"
client-to-client
ifconfig-pool-persist ipp.txt #в этот файл пишутся IP адреса клиентов
port 1194
proto udp
#user nobody #указание пользователя от имени которого будет работать сервис, только для Linux
#group nobody #указание группы от имени которой будет работать сервис, только для Linux
comp-lzo
persist-tun
persist-key
verb 3
#log-append /opt/var/log/openvpn/openvpn.log #только для Linux
#status /opt/var/log/openvpn/status.log #только для Linux
keepalive 10 60 #период рестарта неактивной сессииФайлы из директории ccd:
debian:
push «route 192.168.15.0 255.255.255.0» #IP Range of router (для выполнения на клиенте, в данном случае debian)
iroute 192.168.14.0 255.255.255.0
router:
push «route 192.168.14.0 255.255.255.0» #IP Range of debian (для выполнения на клиенте, в данном случае router)
iroute 192.168.15.0 255.255.255.0
При добавлении клиента дописываем его сеть в группу #routes файла server.ovpn (файла конфигурации сервера, в linux может называться по другому) и добавляем в клиентские конфиги в папке ccd
Linux:
Сервер Linux
Конфигурируем OpenVPN — сервер.
Базовый конфиг такой же как и для сервера под windows. нужно только исправить пути к ключам
запуск/остановка openvpn-сервера /etc/init.d/openvpn start/stop
Правила для Iptables
$iptables -A INPUT -p ALL -i tun0 -j ACCEPT
$iptables -A FORWARD -i tun0 -j ACCEPT
$iptables -A FORWARD -o tun0 -j ACCEPT
$iptables -A OUTPUT -i tun0 -j ACCEPT
$iptables -A OUTPUT -o tun0 -j ACCEPT
Клиент Linux
Файл конфигурации openvpn.conf:
client
dev tun
proto udp
remote 92.126.212.219
tun-mtu 1480
persist-key
persist-tun
ca "/opt/etc/openvpn/keys/ca.crt"
cert "/opt/etc/openvpn/keys/router.crt"
key "/opt/etc/openvpn/keys/router.key"
ns-cert-type server
comp-lzo
verb 3
log-append /opt/var/log/openvpn/openvpn.log
status /opt/var/log/openvpn/status.log
keepalive 10 60Создание файлов конфигурации (tap)
Windows
На сервере в папке C:Program FilesOpenVPNconfig создаем файл server.ovpn следующего содержания:
ca "C:\Program Files\OpenVPN\config\keys\ca.crt"
cert "C:\Program Files\OpenVPN\config\keys\server.crt"
key "C:\Program Files\OpenVPN\config\keys\server.key"
dh "C:\Program Files\OpenVPN\config\keys\dh1024.pem"
dev tap
server-bridge 192.168.1.254 255.255.255.0 192.168.1.190 192.168.1.199
comp-lzoНа клиентах в папке C:Program FilesOpenVPNconfig создаем файл client.ovpn следующего содержания:
ca "C:\Program Files\OpenVPN\config\keys\ca.crt"
cert "C:\Program Files\OpenVPN\config\keys\client.crt"
key "C:\Program Files\OpenVPN\config\keys\client.key"
dev tap
client
remote 92.126.212.219 1194
ifconfig 192.168.1.190 255.255.255.0 # явное указание IP-адреса, назначаемого интерфейсу
comp-lzoЗапускаем клиента для проверки соединения
Сначала на сервере запускаем OpenVPN GUI, щелкаем ПКМ по значку в трее — Connect
Ждем пока соединение установится и компьютеры станут зелеными.
Затем тоже самое на клиенте. После успешного подключения компьютеры в трее на клиенте станут зелеными и в статусе появится сообщение об успешном подключении и присвоении IP адреса 192.168.1.190
Копируем ключи и сертификаты
Файлы ca.crt, dh1024.pem, server.crt, server.key кладем на сервере в папку C:Program FilesOpenVPNconfigkeys
Файлы ca.crt, client.crt, client.key кладем на клиенте в папку C:Program FilesOpenVPNconfigkeys
Настраиваем запуск в качестве службы (для windows, в linux за это отвечает параметр в скрипте запуска, по умолчанию всегда запускается как служба)
Настройка на клиенте и на сервере будет почти одинакова.
В списке служб находим OpenVPN Service открываем свойства и в строке Параметры запуска прописываем:
—config server.ovpn для сервера
—config client.ovpn для клиента
Меняем тип запуска службы на Автоматически. Применяем сделанные изменения и запускаем службу.
Редактировался Evgen (27.03.2012, 12:45:21)
1. Установка OpenVPN.
1.1. Скачиваем программу с оф. сайта для своей версии windows.
1.2. При установке ставим галочку EasyRSA
Путь установки — по умолчанию (C:Program FilesOpenVPN).
2. Настройка конфигов OpenVPN.
2.1. Заходим в директорию, куда установили программу (по умолчанию C:Program FilesOpenVPN) и переходим в easy-rsa.
Будет удобней и наглядней, если проводить работы в Командной строке (cmd) от администратора.
2.2. Во-первых, запускаем init-config.bat
2.3. Затем, отредактируем vars.bat, чтобы адаптировать его к своей среде. Конкретно, нас интересует последний блок:
set KEY_COUNTRY=RU
set KEY_PROVINCE=MSK
set KEY_CITY=Moscow
set KEY_ORG=OpenVPN
set KEY_EMAIL=mail@host.domain
set KEY_CN=GLX-SERVER
set KEY_NAME=GALAXY
set KEY_OU=GALAXY
set PKCS11_MODULE_PATH=GALAXY
set PKCS11_PIN=1234
2.4. Для удобства рекомендуется переименовать название сетевого TAP-адаптера (Панель управленияСеть и ИнтернетСетевые подключения) во что-то более понятное. Например, VPN-Server.
3. Генерация TLS ключей.
3.1. Создаём новые пустые файлы index и serial:vars
clean-all
3.2. Генерируем корневой сертификат CA (только один раз):vars
build-ca
3.3. Генерируем ключ Диффи-Хэлмана (для сервера, только один раз):vars
build-dh
3.4. Генерируем приватный серверный сертификат:vars
build-key-server имя_сервера
3.5. Генерируем клиентский сертификат в PEM формате (для каждого клиента):vars
build-key имя_клиента
ИЛИ
Генерируем клиентский сертификат в PKCS#12 формате (для каждого клиента):vars
build-key-pkcs12 имя_клиента
3.6. Для отзыва TLS сертификата и генерации файла CRL:1. vars
2. revoke-full имя_клиента
3. проверяем последнюю строку вывода, подтверждающую отзыв
4. копируем файл отзыва сертификата (crl.pem) в директорию сервера и убеждаемся, что конфиг использует "crl-verify crl filename"
3.7. Генерируем ключ для аутентификации:openvpn --genkey --secret keys/имя_сервера-ta.key
4. Подготовка серверного и клиентского конфигов.
4.1. Серверный конфиг нужно разместить в C:Program FilesOpenVPNconfigserver.ovpn на сервере:
# Какой порт TCP/UDP должен прослушиваться OpenVPN?
# Если вы хотите запустить несколько экземпляров OpenVPN
# на той же машине используйте другой номер
# порта для каждого из них. Вам нужно будет
# открыть этот порт в брандмауэре.
port 1194
# TCP или UDP сервер?
;proto tcp
proto udp
# "dev tun" создаст маршрутизируемый IP-туннель,
# "dev tap" создаст туннель ethernet.
# Используйте "dev tap0", если вы соединяете ethernet
# и предварительно создали виртуальный интерфейс tap0
# и соединили его с вашим интерфейсом ethernet.
# Если вы хотите контролировать политику доступа
# через VPN необходимо создать правила
# брандмауэра для интерфейса TUN/TAP.
# В системах, отличных от Windows, вы можете дать
# явный номер единицы измерения, например tun0.
# В Windows для этого используйте "dev-node".
# В большинстве систем VPN не будет работать
# если вы не отключите брандмауэр полностью или частично
;dev tap
;dev tun
# Windows требуется имя адаптера TAP-Win32
# из панели Сетевые подключения если у вас
# есть больше, чем один. На XP SP2 или выше,
# возможно, вам придётся выборочно отключить
# брандмауэр для адаптера TAP.
# Системы, отличные от Windows, обычно не нуждаются в этом.
dev-node MyTap
# Корневой сертификат SSL/TLS (ca), сертификат
# (cert) и закрытый ключ (key). Каждый клиент
# и сервер должен иметь свой собственный сертификат и
# ключ. Сервер и все клиенты будут
# используйте один и тот же файл ca.
#
# Можно использовать любую систему управления ключами X509.
# OpenVPN также может использовать ключевой файл формата PKCS #12
ca ca.crt
cert server.crt
key server.key
# Параметры ключа Диффи-Хэлмана.
# Сгенерируйте свой ключ:
# openssl dhparam -out dh2048.pem 2048
dh dh2048.pem
# Топология сети
# Должна быть подсеть (адресация через IP)
# если клиенты Windows v2.0.9 и ниже должны
# поддерживаться (тогда net30, т.е. a /30 на клиента)
# По умолчанию net30 (не рекомендуется)
;topology subnet
# Настройка режима сервера и предоставление подсети VPN
# для OpenVPN, чтобы предоставить адреса клиентам.
# Сервер возьмёт 10.8.0.1 для себя,
# остальное будет предоставлено клиентам.
# Каждый клиент сможет связаться с сервером
# на 10.8.0.1. Закомментируйте эту строку, если у вас
# мост Ethernet.
server 10.8.0.0 255.255.255.0
# Ведение записи назначения виртуального IP-адреса клиента
# в этом файле. Если OpenVPN выходит из строя или
# перезапускается, можно назначить повторное подключение клиентов
# на тот же виртуальный IP-адрес из пула, который был
# ранее назначен.
ifconfig-pool-persist ipp.txt
# Настройка режима сервера для моста ethernet.
# Вы должны сначала использовать возможности моста вашей ОС
# для соединения интерфейса TAP с ethernet
# Интерфейс NIC. Затем вы должны вручную установить
# IP/netmask на интерфейсе моста, здесь мы
# предположим, что 10.8.0.4/255.255.255.0. Наконец, нам
# необходимо выделить диапазон IP-адресов в этой подсети
# (начало=10.8.0.50 конец=10.8.0.100)
# для подключения клиентов. Оставьте эту строку закомментированной,
# если вы не соединяете ethernet.
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
# Настройка режима сервера для моста ethernet
# через DHCP-прокси, где клиенты обращаются
# к серверу DHCP на стороне OpenVPN-сервера,
# чтобы получить распределение их IP-адресов
# и адресов DNS-серверов. Вы должны сначала использовать
# способность моста вашей ОС для моста TAP
# интерфейса с интерфейсом сетевого адаптера ethernet.
# Примечание: этот режим работает только на клиентах (таких как
# Windows), где на стороне клиента находится адаптер TAP,
# привязанный к DHCP-клиенту.
;server-bridge
# Push-маршруты к клиенту, чтобы разрешить
# добраться до других частных подсетей позади
# сервера. Помните, что эти
# частные подсети также потребуется
# знать для маршрута возвращения пула адресов OpenVPN-клиентов
# (10.8.0.0/255.255.255.0) обратно на OpenVPN-сервер.
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
# Чтобы назначить определенные IP-адреса определенным
# клиентам или если подключающийся клиент имеет свою
# подсеть, которая также должна иметь доступ к VPN,
# используйте подкаталог "ccd" с файлами конфигурации
# для конкретного клиента.
#
# НАПРИМЕР: Предположим, что клиент
# имеющий название сертификата "Телониус"
# также имеет небольшую подсеть за его подключенной
# машиной, например 192.168.40.128/255.255.255.248.
# Во-первых, раскомментируйте эти строки:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Затем создайте файл ccd/Thelonious с этой строкой:
# iroute 192.168.40.128 255.255.255.248
# Это разрешит частной подсети Телониуса
# доступ к VPN. Этот пример будет работать только
# если вы маршрутизируете, а не наводите мост, т. е. вы
# используете директивы "dev tun" и "server".
#
# НАПРИМЕР: Предположим, вы хотите выдать
# Телониусу фиксированный IP-адрес VPN 10.9.0.1.
# Сначала раскомментируйте эти строки:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Затем добавьте эту строку в ccd/Thelonious:
# ifconfig-push 10.9.0.1 10.9.0.2
# Предположим, что вы хотите включить разные
# политики доступа брандмауэра для различных групп
# клиентов. Существует два метода:
# (1) запуск нескольких демонов OpenVPN, по одному для каждой
# группы, и брандмауэр интерфейсов TUN/TAP
# для каждой группы/демона соответственно.
# (2) (продвинутый) создание скрипта для динамического
# изменения брандмауэра в ответ на доступ
# от разных клиентов.
;learn-address ./script
# Если включено, эта директива настроит
# всем клиентах перенаправление их сетевых шлюзов
# по умолчанию через VPN, повлёкший
# весь IP-трафик, такой как просмотр веб-страниц и
# и DNS-запросы, чтобы пройти через VPN
# (серверу OpenVPN может потребоваться NAT
# или мост интерфейса TUN/TAP с интернетом
# для того, чтобы это работало правильно).
;push "redirect-gateway def1 bypass-dhcp"
# Определенные параметры сети для Windows
# могут быть переданы клиентам, такие как DNS
# или адреса WINS-серверов. ПРЕДОСТЕРЕЖЕНИЕ:
# http://openvpn.net/faq.html#dhcpcaveats
# Адреса, приведенные ниже, относятся к публичным
# DNS-серверам, предоставляемые opendns.com.
;push "dhcp-option DNS 208.67.222.222"
;push "dhcp-option DNS 208.67.220.220"
# Раскомментируйте эту директиву, чтобы разрешить разным
# клиентам иметь возможность "видеть" друг друга.
# По умолчанию клиенты будут видеть только сервер.
# Чтобы заставить клиентов видеть только сервер, вам
# также необходимо будет соответствующим образом настроить брандмауэр
# интерфейса TUN/TAP сервера.
;client-to-client
# Раскомментируйте эту директиву, если несколько клиентов
# могут подключаться с одним и тем же сертификатом/ключом
# или общим именем. Это рекомендуется
# только в целях тестирования. Для использования в производстве,
# каждый клиент должен иметь свою собственную пару сертификата/ключа.
#
# ЕСЛИ ВЫ НЕ СОЗДАЛИ ИНДИВИДУАЛЬНОЙ
# ПАРЫ СЕРТИФИКАТ/КЛЮЧ ДЛЯ КАЖДОГО КЛИЕНТА,
# КАЖДЫЙ ИЗ НИХ ИМЕЕТ СВОЕ УНИКАЛЬНОЕ "ОБЩЕЕ ИМЯ",
# РАСКОММЕНТИРУЙТЕ ЭТУ СТРОКУ.
;duplicate-cn
# Директива keepalive вызывает ping-like
# сообщения, которые будут отправляться туда и обратно,
# чтобы каждая сторона знала, когда
# другая сторона перестала работать.
# Пингуем каждые 10 секунд; предполагается, что удалённый
# узел не работает, если нет пинга в течение
# 120 секунд.
keepalive 10 120
# Для дополнительной безопасности помимо этого предусмотрено
# с помощью SSL/TLS, создайте "брандмауэр HMAC"
# чтобы помочь блокировать DoS-атаки и флудинг UDP-портов.
#
# Сгенерировать с помощью:
# openvpn --genkey --secret ta.key
#
# Сервер и каждый клиент должны иметь
# копию этого ключа.
# Второй параметр должен быть "0"
# на сервере и '1' на клиентах.
tls-auth ta.key 0
# Выберите криптографический шифр.
# Этот пункт конфига должен также копироваться
# в файл конфигурации клиента.
# Обратите внимание, что клиент/сервер версии 2.4 будет автоматически
# согласовывать AES-256-GCM в режиме TLS.
cipher AES-256-CBC
# Включите сжатие на VPN-канале и передайте
# опцию клиенту (только v2. 4+, для более ранних
# версий см. ниже)
;compress lz4-v2
;push "compress lz4-v2"
# Для сжатия, совместимого со старыми клиентами, используйте comp-lzo
# Если вы включите его здесь, вы также должны
# включить его в файле конфигурации клиента.
;comp-lzo
# Максимальное количество одновременно подключенных
# клиентов, которое мы хотим разрешить.
;max-clients 100
# Параметры сохранения будут пытаться избежать
# доступа к определенным ресурсам при перезапуске,
# которые не могут быть больше доступны
# из-за понижения привилегий.
persist-key
persist-tun
# Выводит короткий файл состояния, показывающий
# текущие соединения, усеченные
# и перезаписанные каждую минуту.
status openvpn-status.log
# По умолчанию сообщения журнала будут отправляться в системный журнал (или
# в Windows, если они запущены как Служба, они будут отправлены в
# каталог "Program FilesOpenVPNlog").
# Используйте log или log-append, чтобы переопределить это значение по умолчанию.
# "log" будет усекать файл журнала при запуске OpenVPN,
# а "log-append" будет добавляться к нему. Используйте один
# или другой (но не оба).
;log openvpn.log
;log-append openvpn.log
# Установите соответствующий уровень детализации файла журнала.
#
# 0 молчит, за исключением фатальных ошибок
# 4 является разумным для общего использования
# 5 и 6 могут помочь отладить проблемы с подключением
# 9 очень подробно
verb 3
# Заглушить повторные сообщения. В журнал будет
# выведено не более 20 последовательных сообщений
# одной и той же категории.
;mute 20
# Уведомить клиента при перезапуске сервера,
# чтобы он мог автоматически повторно подключиться.
explicit-exit-notify 1
Итоговый пример серверного конфига может быть такой:
port 1194
proto udp
dev tun
dev-node MyTap
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
compress lz4-v2
push "compress lz4-v2"
max-clients 10
persist-key
persist-tun
status "C:\Program Files\OpenVPN\log\openvpn-status.log"
log "C:\Program Files\OpenVPN\log\openvpn.log"
verb 3
mute 20
explicit-exit-notify 1
4.2. Клиентский конфиг нужно разместить в C:Program FilesOpenVPNconfigclient.ovpn на машине клиента:
client
dev tun
dev-node MyTap
proto udp
remote openvpn-server-ip 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
mute 20
Для сервера:
сертификаты (ca.crt, server.crt, server.key, dh2048.pem, ta.key) положить в папку ssl например, конфиг (server.ovpn) положить в config.
Для клиента:
сертификаты (ca.crt, client.crt, client.key, ta.key) положить в папку ssl например, конфиг (client.ovpn) положить в config.