Step 1:
Launch the msi installer for openvpn and click next:
Step 2:
Read and click I Agree to indicate your agreement:
Step 3:
Choose the location to install the program files for the Desktop Client and click Install to begin:
Step 4:
You are now ready to install the Desktop Client, ensure TAP Virtual Eth Adapter and OpenVPN GUI are checked:
Step 5:
Please wait while the Desktop Client Installs, click Next when complete:
Step 6:
You may see a warning asking you to install the Desktop Clients TAP Adapter, check the box that says «Always trust software from «OpenVPN Technologies, Inc.» and click Install:
Step 7:
The Desktop Client is now installed, click Finish to complete the installation:
TAP-Windows driver (NDIS 6)
This is an NDIS 6.20/6.30 implementation of the TAP-Windows driver, used by
OpenVPN and other apps. NDIS 6.20 drivers can run on Windows 7 or higher except
on ARM64 desktop systems where, since the platform relies on next-gen power
management in its drivers, NDIS 6.30 is required.
Build
The prerequisites for building are:
- Python 2.7
-
- Microsoft Windows 10 EWDK (Enterprise Windows Driver Kit)
-
- Visual Studio+Windows Driver Kit works too. Make sure to work from a «Command Prompt for Visual Studio» and to call buildtap.py with «—sdk=wdk».
-
- The devcon source code directory (setup/devcon) from Windows-driver-samples (optional)
-
- If you use the repo from upstream remember to include our patch to devcon.vcxproj to ensure that devcon.exe is statically linked.
- Windows code signing certificate
- Git (not strictly required, but useful for running commands using bundled bash shell)
- MakeNSIS (optional)
- Prebuilt tapinstall.exe binaries (optional)
- Visual Studio 2019 and WiX Toolset for MSM packaging (optional)
Make sure you add Python’s install directory (usually c:\python27) to the PATH
environment variable.
Tap-windows6 has been successfully build on Windows 10 and Windows Server 2016 using
CMD.exe, Powershell and Git Bash.
View build script options:
$ python buildtap.py
Usage: buildtap.py [options]
Options:
-h, --help show this help message and exit
-s SRC, --src=SRC TAP-Windows top-level directory, default=<CWD>
--ti=TAPINSTALL tapinstall (i.e. devcon) directory (optional)
-d, --debug enable debug build
--hlk build for HLK tests (test sign, no debug)
-c, --clean do an nmake clean before build
-b, --build build TAP-Windows and possibly tapinstall (add -c to
clean before build)
--sdk=SDK SDK to use for building: ewdk or wdk, default=ewdk
--sign sign the driver files
-p, --package generate an NSIS installer from the compiled files
-m, --package-msm generate a MSM installer from the compiled files
--cert=CERT Common name of code signing certificate,
default=openvpn
--certfile=CERTFILE Path to the code signing certificate
--certpw=CERTPW Password for the code signing certificate/key
(optional)
--crosscert=CERT The cross-certificate file to use, default=MSCV-
VSClass3.cer
--timestamp=URL Timestamp URL to use, default=http://timestamp.verisign
.com/scripts/timstamp.dll
--versionoverride=FILE
Path to the version override file
Edit version.m4 and paths.py as necessary then build:
$ python buildtap.py -b
On successful completion, all build products will be placed in the «dist»
directory as well as tap6.tar.gz. The NSIS installer package will be placed to
the build root directory.
Building tapinstall (optional)
The easiest way to build tapinstall is to clone the Microsoft driver samples
and copy the source for devcon.exe into the tap-windows6 tree. Using PowerShell:
$ git clone https://github.com/OpenVPN/Windows-driver-samples.git $ Copy-Item -Recurse Windows-driver-samples/setup/devcon tap-windows6 $ cd tap-windows6 $ python.exe buildtap.py -b --ti=devcon
The build system also supports reuse of pre-built tapinstall.exe executables.
To make sure the buildsystem finds the executables, create the following
directory structure under tap-windows6 directory:
devcon
├── Release
│ └── devcon.exe
├── x64
│ └── Release
│ └── devcon.exe
└── ARM64
└── Release
└── devcon.exe
This structure is equal to what building tapinstall would create. Then call
buildtap.py with «—ti=devcon». Replace «Release» with your build configuration;
for example, when using —Hlk you’d use «Hlk».
Please note that the NSIS packaging (-p) step will fail if you don’t have
tapinstall.exe available. Also don’t use the «-c» flag or the above directories
will get wiped before MakeNSIS is able to find them.
Developer Mode: Installing, Removing and Replacing the Driver
The driver can be installed using a command-line tool, tapinstall.exe, which is
bundled with OpenVPN and tap-windows installers. Note that in some versions of
OpenVPN tapinstall.exe is called devcon.exe. To install, update or remove the
tap-windows NDIS 6 driver follow these steps:
- place tapinstall.exe/devcon.exe to your PATH
- open an Administrator shell
- cd to dist
- cd to amd64, i386, or arm64 depending on your system’s processor architecture.
If you are actively developing the driver (e.g.: Edit, Compile, Debug, Loop…), you may not be signing your driver each time, thus you need to be aware of the following additional items.
Disable Secure Boot:
Unsigned drivers require disabling secure boot.
- Secure Boot: Varies depending on PC Maker and/or the BIOS setting on your test machine.
- https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/disabling-secure-boot
- VMWare (one example): https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-898217D4-689D-4EB5-866C-888353FE241C.html
- Virtual Box: SecureBoot is not supported on Virtual Box
- Parallels (MacOS) https://kb.parallels.com/en/124242 [With Parallels 15, it is enabled by default, use 0 to disable]
Enable Windows Test Mode:
Test mode is also required.
- Enable Windows Test Mode via BCEDIT
- For details: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcdedit-command-line-options
- Specifically,
bcdedit /set testsigning offorbcdedit /set testsigning on - The result should be
Test Modein the bottom right corner of the windows screen.
Driver Installation:
Notes
- The command
tapinstall install OemVista.inf TAP0901installs the driver - Because your driver is not signed, the
tapinstall installstep will pop up the «Big Scary Unsigned Driver Warning», you’ll need to click OK. - As a result, the driver will be copied into the Windows Driver Store
Updating the Driver, and the Windows Driver Store:
At some point, you will build a shinny new driver and need to test it.
- The command
tapinstall remove TAP0901— removes the driver - However, the previously approved driver is still in the Windows Driver Store
- Typing
tapinstall install ...now, only re-installs the old driver that was copied into the driver store.
Key step: The driver needs to be removed from the driver store also.
- Details: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc730875(v=ws.11)
There is a script to do this, but it only works if you have not changed the text strings in your driver package
- Script Location: https://github.com/mattock/tap-windows-scripts
The manual steps are:
- Step 1 — Obtain a list of Installed drivers via the command:
pnputil -e, this will list all of theoemNUMBER.inffiles that are in the driver store. - Step 2 — Find your driver in that list, it will be some
oem<NUMBER>.inffile - Step 3 — To delete, use
pnputil.exe /d oemNUMBER.inf
Finally use tapinstall install OemVista.inf TAP0901 to install your driver
Important:
If you do not see the Big Scary Unsigned Driver Warning — Windows will use the old (not new) driver.
Troubleshooting:
Examining the SetupAPI log file helps, see C:\Windows\INF\setupapi.dev.log.
Build for HLK tests
A test-signed version of tap-windows6 driver should be used for the HLK tests.
The recommended procedure is to use pre-built, cross-signed devcon.exe and use
the WDK-generated key for signing the driver.
First setup the directory with prebuilt devcon as described above.
Then run the build with the —hlk option:
$ python.exe buildtap.py -c -b --ti=devcon-prebuilt --hlk
Release process and signing
Microsoft’s driver signing requirements have tightened considerably over the
last several years. Because of this this buildsystem no longer attempts to sign
files by default. If you want to sign the files at build time use the —sign
option. The «sign» directory contains several Powershell scripts that help
produce release-signed tap-windows6 packages:
- Cross-Sign: cross-sign tap-windows6 driver files and tapinstall.exe
- Create-DriverSubmission: create architecture-specific attestation signing submission cabinet files
- Extract-DriverSubmission: extract attestation-signed zip files
- Sign-File: sign files (e.g. tap-windows6 installer or driver submission cabinet files)
- Sign-tap6.conf.ps1: configuration file for all the scripts above
- Prepare-Msm.ps1: take Win7- and Win10-signed «dist» directories and produce a «dist» directory that MSM packaging can consume
Most of these scripts operate directly on the «dist» directory that
tap-windows6 build system produces. Below it is assumed that building and
signing is done on the same computer.
First produce cross-signed drivers for (Windows 7/8/8.1/Server 2012r2):
$ python.exe buildtap.py -c -b --ti=devcon $ sign\Cross-Sign.ps1 -SourceDir dist -Force
Note that the «-Force» option for Cross-Sign.ps1 is required except in the
unlikely case that you’re appending a signature.
Next produce a driver submission cabinet files for attestation signing:
$ sign\Create-DriverSubmission.ps1 $ Get-ChildItem -Path disk1|sign\Sign-File.ps1
Three architecture-specific (i386, amd64, arm64) cabinet files are created.
Submit these to Windows Dev Center for attestation signing. Note that unsigned
cabinet files will be automatically rejected.
When submitting the drivers to Microsoft take care to only request signatures
applicable for each architecture.
At this point move the cross-signed «dist» directory away:
$ Move-Item dist dist.win7
Download the attestation-signed drivers as zip files put them into a temporary
directory (e.g. tap-windows6tempdir). Then run Extract-DriverSubmission.ps1:
$ Get-ChildItem -Path tempdir -Filter "*.zip"|sign\Extract-DriverSubmission.ps1
This extracts the drivers into the «dist» directory. Move that directory to dist.win10:
$ Move-Item dist dist.win10
After this you can start creating the installers and/or MSM packages.
If you’re creating NSIS packages do:
$ Move-Item dist.win7 dist $ python.exe buildtap.py -p --ti=devcon $ Move-Item dist dist.win7
Followed by:
$ Move-Item dist.win10 dist $ python.exe buildtap.py -p --ti=devcon $ Move-Item dist dist.win10
Finally sign both installers:
$ Get-Item tap-windows*.exe|sign\Sign-File.ps1
On the other hand if you’re creating MSM packages do:
$ sign\Prepare-Msm.ps1 $ python buildtap.py -m --sdk=wdk $ Get-Item tap-windows*.msm|sign\Sign-File.ps1
For additional instructions and background information please refer to
this article on OpenVPN community wiki.
Overriding setting defined in version.m4
It is possible to override one or more of the settings in version.m4 file with
the —versionoverride <file> option. Any settings given in the override file
have precedence over those in version.m4.
This is useful when building several tap-windows6 drivers with different
component ids for example.
Notes on proxies
It is possible to build tap-windows6 without connectivity to the Internet but
any attempt to timestamp the driver will fail. For this reason configure your
outbound proxy server before starting the build. Note that the command prompt
also needs to be restarted to make use of new proxy settings.
MSM packaging
In order to build the MSM packages build and sign the driver first:
- Build the TAP driver with buildtap.py and «-b» flag.
- EV-sign the drivers
- WHQL/Attestation-sign the drivers
Place the signed drivers in a directory structure under tap-windows6
directory. Each platform directory should contain the EV-signed driver with a
«win10» subdirectory containing WHQL/Attestation signed driver for that
platform:
dist
├── amd64
│ ├── win10
│ │ ├── OemVista.inf
│ │ ├── tap0901.cat
│ │ └── tap0901.sys
│ ├── OemVista.inf
│ ├── tap0901.cat
│ └── tap0901.sys
├── arm64
│ ├── win10
│ │ ├── OemVista.inf
│ │ ├── tap0901.cat
│ │ └── tap0901.sys
│ └── (Note: EV-signed driver for arm64 is not used.)
├── include
│ └── tap-windows.h
└── i386
├── win10
│ ├── OemVista.inf
│ ├── tap0901.cat
│ └── tap0901.sys
├── OemVista.inf
├── tap0901.cat
└── tap0901.sys
Building MSM packages requires Visual Studio 2019 (EWDK is not sufficient) and
the WiX Toolset installed. In a Developer Command Prompt for Visual Studio
2019, run:
$ python buildtap.py -m --sdk=wdk
This will compile the installer.dll file with embedded drivers and package it
as a platform-dependent tap-windows-<version>-<platform>.msm files.
As the WiX Toolset does not support the arm64 platform yet, only amd64 and
i386 MSM files are built.
Optional: Consider EV-signing the MSM packages before deploying them. Thou,
MSM signature is ignored when merging MSM into MSI package, users get a choice
to validate the integrity of the downloaded MSM packages manually.
License
See the file COPYING.
OpenVPN – это набор open source программ, который заслуженно является одним из самых популярных и легких решений для реализации защищенной VPN сети. OpenVPN позволяет объединить в единую сеть сервер и клиентов (даже находящиеся за NAT или файерволами), или объединить сети удаленных офисов. Серверную часть OpenVPN можно развернуть практически на всех доступных операционных системах (пример настройки OpenVPN на Linux). Вы можете установить OpenVPN сервер даже на обычный компьютер с десктопной редакцией Windows 10.
В этой статье, мы покажем, как установить OpenVPN сервер на компьютер с Windows 10, настроить OpenVPN клиент на другом Windows хосте и установить защищенное VPN подключение.
Содержание:
- Установка службы OpenVPN сервера в Windows
- Создаем ключи шифрования и сертификаты для OpenVPN
- Конфигурационный файл OpenVPN сервера в Windows
- Настройка OpenVPN клиента в Windows
Установка службы OpenVPN сервера в Windows
Скачайте MSI установщик OpenVPN для вашей версии Windows с официального сайта (https://openvpn.net/community-downloads/). В нашем случае это OpenVPN-2.5.5-I602-amd64.msi (https://swupdate.openvpn.org/community/releases/OpenVPN-2.5.5-I602-amd64.msi).
Запустите установку.
Если вы планируете, OpenVPN сервер работал в автоматическом режиме, можно не устанавливать OpenVPN GUI. Обязательно установите OpenVPN Services.
Начиная с версии OpenVPN 2.5, поддерживается драйвер WinTun от разработчиков WireGuard. Считается, что этот драйвер работает быстрее чем классический OpenVPN драйвер TAP. Установите драйвер Wintun, откажитесь от установки TAP-Windows6.
Установите OpenSSL утилиту EasyRSA Certificate Management Scripts.
Запустите установку.
По умолчанию OpenVPN устаналивается в каталог C:\Program Files\OpenVPN.
После окончания установки появится новый сетевой адаптер типа Wintun Userspace Tunnel. Этот адаптер отключен, если служба OpenVPN не запущена.
Создаем ключи шифрования и сертификаты для OpenVPN
OpenVPN основан на шифровании OpenSSL. Это означает, что для обмена трафиком между клиентом и серверов VPN нужно сгенерировать ключи и сертификаты с использованием RSA3.
Откройте командную строку и перейдите в каталог easy-rsa:
cd C:\Program Files\OpenVPN\easy-rsa
Создайте копию файла:
copy vars.example vars
Откройте файл vars с помощью любого текстового редактора. Проверьте пути к рабочим директориям.
Обязательно поправьте переменную EASYRSA_TEMP_DIR следующим образом:
set_var EASYRSA_TEMP_DIR "$EASYRSA_PKI/temp"
Можете заполнить поля для сертификатов (опционально)
set_var EASYRSA_REQ_COUNTRY "RU" set_var EASYRSA_REQ_PROVINCE "MSK" set_var EASYRSA_REQ_CITY "MSK" set_var EASYRSA_REQ_ORG "IT-Company" set_var EASYRSA_REQ_EMAIL " [email protected] " set_var EASYRSA_REQ_OU " IT department "
Срок действия сертификатов задается с помощью:
#set_var EASYRSA_CA_EXPIRE 3650 #set_var EASYRSA_CERT_EXPIRE 825
Сохраните файл и выполните команду:
EasyRSA-Start.bat
Следующие команды выполняются в среде EasyRSA Shell:
Инициализация PKI:
./easyrsa init-pki
Должна появится надпись:
init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: C:/Program Files/OpenVPN/easy-rsa/pki
Теперь нужно сгенерировать корневой CA:
./easyrsa build-ca
Задайте дважды пароль для CA:
CA creation complete and you may now import and sign cert requests.
Данная команда сформировала:
- Корневой сертификат центра сертификации: «C:\Program Files\OpenVPN\easy-rsa\pki\ca.crt»
- Ключ центра сертификации «C:\Program Files\OpenVPN\easy-rsa\pki\private\ca.key»
Теперь нужно сгенерировать запрос сертификата и ключ для вашего сервера OpenVPN:
./easyrsa gen-req server nopass
Утилита сгенерирует два файла:
req: C:/Program Files/OpenVPN/easy-rsa/pki/reqs/server.req key: C:/Program Files/OpenVPN/easy-rsa/pki/private/server.key
Подпишем запрос на выпуск сертификата сервера с помощью нашего CA:
./easyrsa sign-req server server
Подтвердите правильность данных, набрав yes.
Затем введите пароль CA от корневого CA.
В каталоге issued появится сертификат сервера («C:\Program Files\OpenVPN\easy-rsa\pki\issued\server.crt»)
Теперь можно создать ключи Диффи-Хеллмана (займет длительное время):
./easyrsa gen-dh
Для дополнительной защиты VPN сервера желательно включить tls-auth. Данная технология позволяет использовать подписи HMAC к handshake-пакетам SSL/TLS, инициируя дополнительную проверку целостности. Пакеты без такой подписи будут отбрасываться VPN сервером. Это защитит вас от сканирования порта VPN сервера, DoS атак, переполнения буфера SSL/TLS.
Сгенерируйте ключ tls-auth:
cd C:\Program Files\OpenVPN\bin
openvpn --genkey secret ta.key
Должен появиться файл «C:\Program Files\OpenVPN\bin\ta.key». Переместите его в каталог C:\Program Files\OpenVPN\easy-rsa\pki
Теперь можно сформировать ключи для клиентов OpenVPN. Для каждого клиента, который будет подключаться к вашему серверу нужно создать собственные ключи.
Есть несколько способов генерации ключей и передачи их клиентам. В следующем примере, мы создадим на сервере ключ клиента и защитим его паролем:
./easyrsa gen-req kbuldogov
./easyrsa sign-req client kbuldogov
Данный ключ («C:\Program Files\OpenVPN\easy-rsa\pki\private\kbuldogov.key») нужно передать клиенту и сообщить пароль. Клиент может снять защиту паролем для ключа:
openssl rsa -in "C:\Program Files\OpenVPN\easy-rsa\pki\private\kbuldogov.key"-out "C:\Program Files\OpenVPN\easy-rsa\pki\private\kbuldogov_use.key"
Если вы хотите сгенерировать ключ, не защищенный паролем, нужно выполнить команду:
./easyrsa gen-req имяклиента nopass
На сервере с OpenVPN вы можете создать неограниченное количество ключей и сертификатов для пользователей. Аналогичным образом сформируйте ключи и сертфикаты для других клиентов.
Вы можете отохвать скомпрометированные сертификаты клиентов:
cd C:\Program Files\OpenVPN\easy-rsa
EasyRSA-Start.bat
./easyrsa revoke kbuldogov
Итак, мы сгенерировали набор ключей и сертификатов для OpenVPN сервера. Теперь можно настроить и запустить службу OpenVPN.
Конфигурационный файл OpenVPN сервера в Windows
Скопируйте типовой конфигурационный файл OpenVPN сервера:
copy "C:\Program Files\OpenVPN\sample-config\server.ovpn" "C:\Program Files\OpenVPN\config-auto\server.ovpn"
Откройте файл server.ovpn в любом текстовом редакторе и внесите свои настройки. Я использую следующий конфиг для OpenVPN:
# Указываем порт, протокол и устройство port 1194 proto udp dev tun # Указываем пути к сертификатам сервера ca "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\ca.crt" cert "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\issued\\server.crt" key "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\private\\server.key" dh "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\dh.pem" # Указываем настройки IP сети, адреса из которой будет будут получать VPN клиенты server 10.24.1.0 255.255.255.0 #если нужно разрешить клиентам подключаться под одним ключом, нужвно включить опцию duplicate-cn (не рекомендуется) #duplicate-cn # TLS защита tls-auth "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\ta.key" 0 cipher AES-256-GCM # Другая параметры keepalive 20 60 persist-key persist-tun status "C:\\Program Files\\OpenVPN\\log\\status.log" log "C:\\Program Files\\OpenVPN\\log\\openvpn.log" verb 3 mute 20 windows-driver wintun
Сохраните файл.
OpenVPN позволяет использовать как TCP, так и UDP для подключения. В этом примере я запустил OpenVPN на 1194 UDP. Рекомендуется использовать протокол UDP, это оптимально как с точки зрения производительности, так и безопасности.
Не забудьте открыть на файерволе порты для указанного вами порта OpenVPN на клиенте и на сервере. Можно открыть порты в Windows Defender с помощью PowerShell.
Правило для сервера:
New-NetFirewallRule -DisplayName "AllowOpenVPN-In" -Direction Inbound -Protocol UDP –LocalPort 1194 -Action Allow
Правило для клиента:
New-NetFirewallRule -DisplayName "AllowOpenVPN-Out" -Direction Outbound -Protocol UDP –LocalPort 1194 -Action Allow
Теперь нужно запустить службу OpenVPN и изменить тип ее запуска на автоматический. Воспользуйтесь таким командами PowerShell, чтобы включить службу:
Set-Service OpenVPNService –startuptype automatic –passthru
Get-Service OpenVPNService| Start-Service
Откройте панель управления, и убедитесь, что виртуальный сетевой адаптер OpenVPN Wintun теперь активен. Если нет, смотрите лог «C:\Program Files\OpenVPN\log\server.log»
Если при запуске OpenVPN вы видите в логе ошибку:
Options error: In C:\Program Files\OpenVPN\config-auto\server.ovpn:1: Maximum option line length (256) exceeded, line starts with..
Смените в файле server.ovpn символы переноса строки на Windows CRLF (в notepad++ нужно выбрать Edit -> EOL Conversion -> Windows CR LF). Сохраните файл, перезапустите службу OpevVPNService.
Данный конфиг позволит удаленным клиентам получить доступ только к серверу, но другие компьютеры и сервисы в локальной сети сервера для них недоступны. Чтобы разрешить клиентам OpenVPN получить доступ к внутренней сети нужно:
Включить опцию IPEnableRouter в реестре (включает IP маршрутизацию в Windows, в том числе включает маршрутизацию меду сетями Hyper-V): reg add «HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters» /v IPEnableRouter /t REG_DWORD /d 1 /f
Добавьте в конфгурационный файл сервера OpenVPN маршруты до внутренней IP сети:
push "route 10.24.1.0 255.255.255.0" push "route 192.168.100.0 255.255.255.0"
Если нужно, назначьте клиенту адреса DNS серверов:
push "dhcp-option DNS 192.168.100.11" push "dhcp-option DNS 192.168.100.12"
Если нужно завернуть все запросы клиента (в том числе Интернет трафик) на ваш OpenVPN сервер, добавьте опцию:
push "redirect-gateway def1"
Настройка OpenVPN клиента в Windows
Создайте на сервере шаблонный конфигурационный файла для клиента VPN (на базе iшаблона client.ovpn) со следующими параметрами (имя файла kbuldovov.ovpn)
client dev tun proto udp remote your_vpn_server_address 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert kbuldogov.crt key kbuldogov.key remote-cert-tls server tls-auth ta.key 1 cipher AES-256-GCM connect-retry-max 25 verb 3
В директиве remote указывается публичный IP адрес или DNS имя вашего сервера OpenVPN.
Скачайте и установите клиент OpenVPN Connect для Windows (https://openvpn.net/downloads/openvpn-connect-v3-windows.msi).
Теперь на компьютер с клиентом OpenVPN нужно с сервера скопировать файлы:
- ca.crt
- kbuldogov.crt
- kbuldogov.key
- dh.pem
- ta.key
- kbuldogov.ovpn
Теперь импортируйте файл с профилем *.ovpn и попробуйте подключиться к вашему VPN серверу.
Если все настроено правильно, появится такая картинка.
Проверьте теперь лог OpenVPN на клиенте «C:\Program Files\OpenVPN Connect\agent.log»
Mon Dec 27 08:09:30 2021 proxy_auto_config_url
Mon Dec 27 08:09:31 2021 TUN SETUP
TAP ADAPTERS:
guid='{25EE4A55-BE90-45A0-88A1-8FA8FEF24C42}' index=22 name='Local Area Connection'
Open TAP device "Local Area Connection" PATH="\\.\Global\{25EE4A55-BE90-45A0-88A1-8FA8FEF24C42}.tap" SUCCEEDED
TAP-Windows Driver Version 9.24
ActionDeleteAllRoutesOnInterface iface_index=22
netsh interface ip set interface 22 metric=1
Ok.
netsh interface ip set address 22 static 10.24.1.6 255.255.255.252 gateway=10.24.1.5 store=active
IPHelper: add route 10.24.1.1/32 22 10.24.1.5 metric=-1
Клиент успешно подключится к OpenVPN серверу и получил IP адрес 10.24.1.6.
Проверьте теперь лог на сервере («C:\Program Files\OpenVPN\log\openvpn.log»). Здесь также видно, что клиент с сертификатом kbuldogov успешно подключится к вашему серверу.
2021-12-27 08:09:35 192.168.13.202:55648 [kbuldogov] Peer Connection Initiated with [AF_INET6]::ffff:192.168.13.202:55648 2021-12-27 08:09:35 kbuldogov/192.168.13.202:55648 MULTI_sva: pool returned IPv4=10.24.1.6, IPv6=(Not enabled) 2021-12-27 08:09:35 kbuldogov/192.168.13.202:55648 MULTI: Learn: 10.24.1.6 -> kbuldogov/192.168.13.202:55648 2021-12-27 08:09:35 kbuldogov/192.168.13.202:55648 MULTI: primary virtual IP for kbuldogov/192.168.13.202:55648: 10.24.1.6
Другая модель развертывания для 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 Files\OpenVPN\config).
Заметка
Файл конфигурации сервера для версии OpenVPN для Windows аналогичен файлу конфигурации для Linux. Основными отличиями являются полные пути к файлам сертификатов и ключей, а также способ указания адаптера TAP-WIN с помощью ключевых слов dev и dev-node. Также обратите внимание, что параметры user/group и daemon/logging были удалены.
- Запустите сервер OpenVPN (с повышенными привилегиями):
C:> cd \program files\openvpn\config
C:> ..\bin\openvpn --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.
OS: MS Windows 2000/XP/2003/Vista/2008/Seven/2012.
Application: Windows client OpenVPN v.2.3.
В операционной системе «MS Windows» встроенная поддержка протокола OpenVPN отсутствует, очевидно потому следуем на сайт разработчиков и загружаем необходимое клиентское программное обеспечение:
Важно! Для того, чтобы клиент OpenVPN мог средствами операционной системы изменять сетевую конфигурацию интерфейсов — включаем встроенного клиента DHCP, если он был выключен ранее.
Запускаем установку, везде соглашаясь с замыслом разработчиков, одобряя все опции, кроме двух необязательных: «OpenSSL Utilites» и «OpenVPN RSA Certificate Management»:
OpenVPN-client for MS Windows: выбираем компоненты для установки.
Инсталлятор OpenVPN озаботится поддержкой системой псевдо-устройства «tun» (в процессе установки драйверов будет создано новое устройство — виртуальный сетевой TUN/TAP интерфейс), наша задача состоит в том, чтобы не помешать ему в этом (предоставив по требованию привилегии суперпользователя системы). Мы будем использовать технологию «Layer 3 based IP» туннеля для пропускания IP-трафика между клиентом и окружением сервера VPN (OpenVPN поддерживает и «Layer 2 based Ethernet», но в нашем решении пропуск трафика уровня Ethernet не требуется):
OpenVPN-client for MS Windows: соглашаемся с установкой драйверов виртуальных сетевых устройств TUN/TAP.
Прежде всего, если мы желаем инициировать VPN-соединения вручную, с помощью графического интерфейса, следует подправить условия запуска GUI, указав работать ему от имени суперпользователя системы — иначе клиент OpenVPN не сможет создать виртуальный сетевой интерфейс и применить полученные с сервера маршруты следования трафика (если планируется использовать только фоновый сервис, то в модификации условий запуска клиента OpenVPN нет необходимости):
OpenVPN-client for MS Windows: переходим к редактированию свойств ярлыка запуска клиента OpenVPN.
OpenVPN-client for MS Windows: предписываем запускать клиента OpenVPN с привилегиями суперпользователя операционной системы.
Очень важно! Прежде чем производить дальнейшие работы с конфигурационными файлами, необходимо отключить маскировку расширений файлов в названиях таковых, заставив операционную систему «MS Windows» позволять явно указывать тип файла с помощью вручную задаваемых расширений. В нашем случае мы в процессе настройки создаём обычный текстовый файл (plain text), изменяя после его расширение с принятого в системе «.txt» на зарезервированный для OpenVPN «.ovpn». Так вот, если позволить системе «скрывать расширения для зарегистрированных типов файлов», то у нас получится не желаемое «client.name.ovpn», а «client.name.ovpn.txt» — только оконечивающего имя файла реального расширения «.txt» мы не увидим, потому как оно скрыто, а настраиваемый OpenVPN-клиент не примет конфигурации, потому что ожидает её хоть и в текстовом файле, но с расширением «.ovpn».
Снимаем «галочку» с пункта «скрывать расширения для зарегистрированных типов файлов» в наборе опций «Параметры папок» «Панели управления» системы:
OpenVPN-client for MS Windows: Снимаем «галочку» с пункта «скрывать расширения для зарегистрированных типов файлов» в наборе опций «Параметры папок».
Приложение не предоставляет никаких средств «интуитивно понятной» настройки. Единственный предусмотренный способ — создание конфигурационного файла VPN-соединения вручную в соответствующей предопределённой директории:
OpenVPN-client for MS Windows: переходим в предопределённую разработчиками директорию конфигураций VPN-туннелей.
Конфигураций может быть несколько — они различаются по именам файлов и могут быть использованы как все вместе одновременно, так и по отдельности. Для простоты разместим файлы конфигурации и сертификатов, используемые нашим пока единственным VPN-соединением в одном месте. В дальнейшем, в случае необходимости использования множественных соединений, не составит труда распределить файлы по выделенным директориям. А пока, копируем полученные от администратора VPN-сервера сертификаты и ключи в директорию «C:\Program Files\OpenVPN\config\» и там же создаём конфигурационный файл «сlient.name.ovpn» следующего содержания:
# Режим работы соединения: begin
# включаем режим работы в качестве клиента VPN
client
# ничего не прослушиваем, работаем только в качестве клиента
nobind
# включаем Layer 3 based IP туннель
dev tun
# используемый транспортный протокол
proto tcp
# Режим работы соединения: end
# IP или доменное имя сервера VPN и прослушиваемый сервером порт
remote vpn.example.net 443
# Сертификаты, шифрование и сжатие: begin
ca ca.crt
cert сlient.name.crt
key сlient.name.key
; tls-auth ta.key 1
# включаем сжатие трафика между сервером и клиентом
comp-lzo
# включаем шифрование повышенного уровня относительно стандартного
cipher AES-256-CBC
# Сертификаты, шифрование и сжатие: end
# Журналирование событий
verb 3
# Запрос дополнительной проверки подлинности по логину
; auth-user-pass
Естественно, в вышеприведённой конфигурации адрес сервера удалённого доступа «vpn.example.net» заменяем на предоставленный администратором. Так же, вместо «ca.crt», «сlient.name.crt», «сlient.name.key» и «ta.key» подставляем имена файлов сертификатов и ключей созданных для обеспечения вашего VPN-подключения администратором (эти файлы вы уже должны были разместить рядом с «конфигом»).
Конфигурационные файлы OpenVPN имеют единый формат для всех поддерживаемых версий операционных систем (Linux, Mac, Windows). Применительно к MS Windows отличие лишь в указании двойных «бэкслешей» в пути к файлам ключей и сертификатов и заключение полных путей к файлам в двойные кавычки.
Подключатся к удалённой сетевой инфраструктуре можно двумя способами: запуская клиента OpenVPN в качестве фоновой задачи при старте операционной системы в автоматическом режиме или вручную, через контекстное меню индикатора графического интерфейса «OpenVPN GUI for Windows», размещающегося в «трее»:
OpenVPN-client for MS Windows: пример содержимого директории VPN-конфигураций и контекстного меню интерфейса клиента OpenVPN.
С установлением VPN-соединения индикатор клиента в «трее» приобретёт зеленоватую окраску. С этого момента доступ к удалённой сетевой инфраструктуре можно считать успешно осуществлённым. Ради интереса можете удостоверится в появлении дополнительно к основному интернет-подключению ещё одной ограниченной сетевой конфигурации VPN:
OpenVPN-client for MS Windows: перечень активных сетевых соединений, включающий VPN-туннель.
Я упоминал ранее, что для полноценной работы OpenVPN-клиента требуются права суперпользователя. В частности, высокий уровень доступа необходим для применения полученных от VPN-сервера маршрутов на частные сети удалённой инфраструктуры. Для расширения кругозора после первого подключения можно проверить, действительно ли маршруты приняты операционной системой в работу (в командной строке ввести и исполнить «route print»):
OpenVPN-client for MS Windows: таблица маршрутизации, включающая ссылки за шлюзы VPN-туннеля.
По умолчанию сразу после установки возможность автоматического запуска фонового сервиса OpenVPN неактивна — единожды исправляем это и больше не возвращаемся к подключению до истечения срока действия сертификатов:
OpenVPN-client for MS Windows: инициирование автоматического запуска фонового сервиса OpenVPN.
Если подключение используется эпизодически и в автоматизации процесса нет необходимости, то в качестве минимальной оптимизации можно настроить автозапуск графического интерфейса, индикатор которого будет размещён в «трее» и предоставит возможность инициировать VPN-туннель одним кликом мыши в контекстном меню:
OpenVPN-client for MS Windows: внесение в список автозапуска утилиты графического интерфейса клиента OpenVPN.
Если конфигураций VPN-туннелей несколько, то, в случае автоматического запуска фонового сервиса, все они будут инициированы одна за другой, последовательно. Естественно, что вручную можно запускать VPN-соединения в произвольном порядке, выбирая подпункты контекстного меню графического интерфейса «OpenVPN GUI for Windows» в «трее».