• Внешние файлы ключей, сертификатов и т.п.
  Примечание: Параметры указывающие на файлы можно (или даже желательно) указывать с полными путями. Для Windows символ "\" указывается как "\\", пути с пробелами брать в кавычки, например: "C:\\Program Files\\OpenVPN\\config\\ca.crt". Если путь не указан, то используется каталог ...\config
  • secret file_name - указание имени файла ключа для режима static-key. Допустим также параметр [direction], позволяющий асимметрично использовать ключи, например, "secret static.key 0" с одной стороны и "secret static.key 1" с другой, однако для этого ключи должны быть 2048-битовые, в версиях 2.* по умолчанию они именно такие.
  • Для расширенных режимов TLS надо указать или имена раздельных файлов ключей и сертификатов:
    • ca file_name (сервер, клиент) - сертификат СА (центра сертификации)
    • cert file_name (сервер, клиент) - сертификат данного узла, подписанный СА
    • key file_name (сервер, клиент) - ключ шифрования данного узла
    Или имя единого комбинированного файла:
  • pksc12 file_name - имя файла в формате PKCS #12, содержащего сертификат CA, ключ и сертификат клиента. Такой файл и команда заменяют сразу 3 соответствующих файла и команды - ca, cert, key.
  • dh file_name (сервер) - указание имени файла с Diffie-Hellman-параметрами, нужен только на сервере в режиме tls-server (заметим, что макрокомандой server включается именно этот режим)
  • tls-auth file_name (сервер, клиент) - ключ для аутентификации пакетов. В этом режиме ко всем отправляемым пакетам добавляется HMAC, который проверяется при приёме пакета - если не совпало, то пакет молча отбрасывается. И команда и сам файл-ключ должны быть одинаковыми и у клиента и у сервера. Ключ (в примере команды это ta.key) может быть или сгенерирован командой:
    openvpn --genkey --secret ta.key
    (в этом варианте допустим также параметр [direction], позволяющий асимметрично использовать ключи, например, на сервере "tls-auth ta.key 0" и на клиентах "tls-auth ta.key 1")
    или может быть файлом произвольного формата, тогда openvpn сам сделает из него ключ методом свёртки.
  • crl-verify file_name (сервер, клиент) - проверяет предъявленный сертификат по списку отозванных сертификатов, если он там обнаружен - соединение не устанавливается. Основное назначение - проверка на сервере отозванных сертификатов клиентов, хотя и клиент может проверять по этому списку сертификат сервера. См. http://openvpn.net/howto.html#revoke
  • auth-user-pass (клиент), auth-user-pass-verify script_name method (сервер) - дополнительная авторизация пользователя по логину и паролю. Детально см. http://openvpn.net/howto.html#auth. Пример и vbs-скрипт для Windows см. здесь - FAQ: OpenVPN (было - Помогите настроить OpenVPN) !, #302
• Режимы работы OpenVPN
  • dev [tun | tap] (сервер, клиент) - указание типа интерфейса и режима работы: tun = L3-туннель, tap = L2-туннель
  • dev-node TAP-interface-Name (сервер, клиент) - указание использование конкретного интерфейса, актуально если их в ситеме несколько и они по разному настроены в ОС (например, один tap и включён в мост, а второй - tun)
  • proto [tcp-server | tcp-client | udp] (сервер, клиент) - протокол, по умолчанию UDP
  • port 1194 (сервер, клиент) - номер порта, default=1194 (на клиенте для tcp-client игнорируется и используется динамический порт). См.также lport (указание локального порта) и rport (указание удалённого порта).
  • mode - задаёт режим работы сервера. По умолчанию OpenVPN работает в p2p-режиме, при указании mode server он работает в режиме сервера с многими клиентами.
  • tls-server, tls-client - использование режима TLS
  • ifconfig Local-IP Remote-IP/NetMask (сервер, клиент) - задаёт конфигурацию интерфейса.
    Для dev tun: ifconfig Local-IP Remote-IP - указывает IP-адрес локального интерфейса и адрес второй стороны туннеля. Важно, что в режиме клиент-сервер в отличие от режима static-key второй стороной туннеля является не адрес сервер и не адрес клиента, а адрес виртуального интерфейса виртуального OpenVPN-роутера, см. описание в п.3.
    Для dev tap: ifconfig Local-IP NetMask - указывает IP-адрес и маску локального интерфейса
    
• Команды настройки сервера
  • server network netmask (сервер) - макрокоманда конфигурации сервера. Задаёт сеть и маску для всей OpenVPN-сети. Первый адрес из этой сети назначается интерфейсу сервера, остальные выделяются клиентам. Не используйте эту макрокоманду для режима L2-моста, для этого есть server-bridge.
    Реально команда, например, server 10.8.0.0 255.255.255.0 раскрывается так (в скобках комментарии)
    Для режима dev tun:
    mode server
    tls-server
    ifconfig 10.8.0.1 10.8.0.2 (серверу назначается первый адрес из первой подсети /30)
    ifconfig-pool 10.8.0.4 10.8.0.251 (остальной блок адресов выделяется клиентам)
    route 10.8.0.0 255.255.255.0 (системе объявляется маршрут на всю OpenVPN-сеть)
    if client-to-client:
    push "route 10.8.0.0 255.255.255.0" (если включен режим client-to-client, то клиентам также передаётся маршрут на всю OpenVPN-сеть)
    else
    push "route 10.8.0.1" (иначе, если не включен режим client-to-client, клиентам передаётся только маршрут на сервер)
    
    Для режима dev tap:
    ifconfig 10.8.0.1 255.255.255.0 (серверу назначается первый адрес)
    ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0 (остальной блок адресов выделяется клиентам)
    push "route-gateway 10.8.0.1" (клиентам объявляется адрес шлюза, через который, при необходимости, они могут назначать маршруты)
    
  • server-bridge gateway netmask pool-start-IP pool-end-IP (сервер) - макрокоманда конфигурации сервера для режима L2-моста. Важно то, что в этом режиме IP-параметры мостового интерфейса настраиваются в системе! Здесь же параметр gateway может указывать или на этот же IP-адрес мостового интерфейса или на следующий шлюз в этой сети.
    Реально команда, например, server-bridge 10.8.0.4 255.255.255.0 10.8.0.128 10.8.0.254 раскрывается так (в скобках комментарии)
    mode server
    tls-server
    ifconfig-pool 10.8.0.128 10.8.0.254 255.255.255.0 (клиентам выделяется диапазон, указанный в макрокоманде)
    push "route-gateway 10.8.0.4" (параметр gateway передаётся клиентам как шлюз)
    
  • remote host (сервер) - в режиме tcp-server этот параметр на сервере работает как фильтр и принимает соединения ТОЛЬКО от указанного host.
  • client-to-client (сервер) - разрешает обмен трафиком между клиентами для режима dev tun
  • ifconfig-pool-persist File_Name [Time_in_seconds] (сервер) - задаёт файл, в котором на указанное время (по умолчанию 600 сек) кэшируются выданные адреса клиентам, что позволяет при переподключении выдать клиенту тот же адрес.
  • ifconfig-pool-linear (сервер) - задаёт для dev tun режим распределения адресов клиентам не подсетями /30, а "поштучно", то есть /32. Несовместим с Windows!
  • management localhost 8329 (сервер, клиент) - открыть порт 8329 на интерфейсе 127.0.0.1 для управления (см. http://openvpn.net/management.html)
    
• Команды настройки маршрутизации
  • route network/IP [netmask] [gateway] [metric] (сервер, клиент) - добавляет указанный маршрут в ОС после установления соединения. Значения параметров по умолчанию:
    netmask по умолчанию равно 255.255.255.255.
    gateway по умолчанию равно параметру, указанному в команде route-gateway или второму параметру команды ifconfig в режиме dev tun. То есть, по умолчанию исользуется шлюз в "OpenVPN-сеть". Если же нужно параметр указать (например, если нужно задать метрику), то это же значение можно указать ключевым словом vpn_gateway. Кроме того есть ещё ключевое слово net_gateway - это основной шлюз, который был в ОС до установления OpenVPN-соединения.
  • iroute network [netmask] - применяется в client-connect script или в client-config-dir файле, указывает OpenVPN-серверу, что данная сеть находится за соответствующим клиентом. Важно, что это только указание OpenVPN-серверу, для задания этого маршрута самой ОС надо указывать route или в конфиге сервера или вообще в самой ОС.
  • route-method exe (сервер, клиент) - указывает OpenVPN-у, что добавление маршрута надо делать не через API, а через route.exe. См. также в секции "Некоторые распростанённые проблемы и методы решения"
  • route-delay 10 (сервер, клиент) - см. в секции "Некоторые распростанённые проблемы и методы решения"
    
• Команды конфигурирования клиентов на стороне сервера
  • client-config-dir Dir_Name (сервер) - использовать из указанного каталога дополнительные индивидуальные файлы для конфигугации каждого клиента, файлы должны называться так же как и CN клиента (Common Name, то есть то что укзывается при конфигурации ключа клиента командой build-key, см.далее). Расширения у файла быть не должно, то есть, например, для клиента client1 файл так и должен называться - client1
  • push "команда" - указывает серверу передать "команду" клиенту. Например, команда в конфиге сервера push "ping 10" - это не команда ping 10 самому серверу, а указание серверу передать команду ping 10 клиенту. Описание самих команд для push даны отдельно. Это могут быть route, route-gateway, route-delay, redirect-gateway, ip-win32, dhcp-option, inactive, ping, ping-exit, ping-restart, setenv, persist-key, persist-tun, echo
  • push-reset (сервер, но в client-config-dir-файле) - указывает, что для данного клиента надо проигнорировать все глобальные команды push. Однако все push-команды из самого client-config-dir-файла будут исполнены.
  • ifconfig-push Local-IP Remote-IP/NetMask (сервер) - применяется в client-connect script или в client-config-dir файле, задаёт конфигурацию интерфейса соответствующего клиента.
    Для dev tun: ifconfig Local-IP Remote-IP - указывает IP-адрес локального интерфейса клиента и адрес второй стороны туннеля. Важно, что в режиме клиент-сервер второй стороной туннеля является не адрес сервер и не адрес клиента, а адрес виртуального интерфейса виртуального OpenVPN-роутера, см. описание в п.3.
    Для dev tap: ifconfig Local-IP NetMask - указывает IP-адрес и маску локального интерфейса
    
• Команды конфигурирования клиентов на стороне клиента
  • client - макрокоманда режима клиента, исполняется так:
    pull (указывает клиенту принимать от сервера команды, которые на сервере заданы как push)
    tls-client
  • nobind (клиент) - указание использовать динамический порт на клиенте, актуально только для udp, т.к. для tcp на клиенте всегда используется динамический порт.
  • remote host [port] (клиент) - указание второй стороны, host может быть как DNS-именем, так и IP-адресом. Клиент обязан иметь эту строку, причём она может быть не одна - это обеспечивает возможность подключения к разным интерфейсам сервера (отказоустойчивость) или распределение нагрузки.
  • remote-random (клиент) - использовать в случайном порядке одну из нескольких строк remote
  • resolv-retry infinite (клиент) - пытаться бесконечно определить адрес сервера (при указании его по имени), чтобы "обойти" проблему с завершением попытки установления соединения при отказе DNS или сбое внешних соединений
  • redirect-gateway [local] [def1] (клиент) - переключение шлюза на удалённый, есть 2 доп.параметра - local (см.manual) и def1 - изменяет маршрут не методом удаления старого маршрута 0.0.0.0/0 и назначением нового, а методом назначения двух более узких маршрутов 0.0.0.0/1 и 128.0.0.0/1
  • dhcp-option DNS 192.168.1.254 (клиент) - использование удалённого DNS
  • dhcp-option WINS 192.168.1.254 (клиент) - использование удалённого WINS
    
• Другие команды
  • comp-lzo (сервер, клиент) - сжатие трафика
  • status openvpn-status.log (сервер, клиент) - периодически сохранять информ. о текущем состоянии в указанный файл, это текстовый файл.
  • log openvpn.log или log-append openvpn.log (сервер, клиент) - сохранять или добавлять лог в указанный файл
  • keepalive 10 60 (сервер) - макрокоманда "пинговать" противоположную сторону туннеля с указанным периодом 10 сек, при отсутствии встречных пингов в течение 60 сек считать туннель упавшим и запускать пересоединение. Полезно также для поддержания статуса работающего udp-потока в транзитных NAT-шлюзах.
    Реально исполняется так (в скобках комментарии):
    Для mode server:
    ping 10 (сервер посылает OpenVPN-ping каждые 10 секунд. Не путать с ping в IP - здесь на OpenVPN-ping удалённая сторона не отвечает, поэтому эти пакеты надо отправлять с обеих сторон)
    ping-restart 120 (при отсутствии встречных пакетов, то есть от клиента, в течении 120 сек сервер перезапускает клиентскую сессию. Не путать, перезапускается НЕ ВЕСЬ OpenVPN-СЕРВЕР!)
    push "ping 10" (сообщить клиентам пинговать сервер каждые 10 секунд)
    push "ping-restart 60" (сообщить клиентам, что при отсутствии пингов от сервера в течение 60 секунд, клиент должен перезапустить свою сессию).
    Для mode p2p:
    ping 10
    ping-restart 60

код

---

dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key

---

код

---

remote server.ru
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key

---

• init-config.bat - начальная инициализация, создаст файлы vars.bat и openssl.cnf
  В файле vars.bat надо установить ВСЕ параметры
  set HOME=%ProgramFiles%\OpenVPN\easy-rsa
  set KEY_CONFIG=openssl.cnf
  set KEY_DIR=keys # путь к папке ключей относительно текущей (..\easy-rsa)
  set KEY_SIZE=1024
  set KEY_COUNTRY=ZZ
  set KEY_PROVINCE=ZZ
  set KEY_CITY=ZZZ
  set KEY_ORG=ZZZ
  set KEY_EMAIL=zz@zzz.zz
• vars.bat
• clean-all.bat # очистка и инициализация папки ключей

• vars.bat
• build-ca.bat # генерация сертификата и ключа - ca.crt, ca.key

• vars.bat
• build-key-server ServerName # ServerName - имя сервера. На некоторые доп вопросы можно ответить 2 раза "пусто", на 2 последних - "y":
  Sign the certificate? [y/n]:y
  1 out of 1 certificate requests certified, commit? [y/n]y
  В результате будет создан ключ ServerName.key, сертификат ServerName.crt, запрос Certificate Signing Request (CSR) ServerName.csr, ?непонятный файл? 01.pem (копия ServerName.csr)

• vars.bat
• build-dh # работает около минуты, грузит CPU под 100% , генерит файл dh1024.pem

• vars.bat
• build-key client1
• build-key client2
• build-key client3

• vars.bat
• revoke-full client1
  Будет сгенерирован файл crl.pem в каталоге keys, этот файл и должен быть параметром инструкции "crl-verify crl.pem". Этот файл несекретный, но от несанкционированных изменений должен быть защищён. После отзыва можно сгенерировать новый ключ с тем же CN-именем (Common Name).

код

---

ca ca.crt # ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert server.crt
key server.key # секретный файл
dh dh1024.pem
dev tun
server 10.8.0.0 255.255.255.0

---

код

---

push "route 192.168.10.0 255.255.255.0"

---

код

---

ca ca.crt # ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert client.crt
key client.key # секретный файл
dev tun
client
remote 1.1.1.1 1194

---

код

---

remote server.com 1194
remote-random
resolv-retry infinite

---

• не только IP-протокол, но и, например, IPX (лично не проверено)
• приложения работающие только в пределах своей подсети
• приложения, работающие через broadcast (например, NetBIOS)
• иметь доступ к внутренним ресурсам, которые в силу разных причин не имеют настроенного шлюза
• без дополнительных настроек (например, настройка NAT на шлюзе для дополнительной OpenVPN-подсети) использовать перенаправление трафика командой redirect-gateway

код

---

>arp -a
Интерфейс: 192.168.1.191 --- 0x2
 Адрес IP Физический адрес Тип
 192.168.1.101 02-ff-a2-cd-2c-07 динамический

---

код

---

ca ca.crt # ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert server.crt
key server.key # секретный файл
dh dh1024.pem
dev tap
server-bridge 192.168.1.254 255.255.255.0 192.168.1.190 192.168.1.199
# в предыд.команде 192.168.1.254 255.255.255.0 это шлюз из лок.сети во внеш.сети и маска,
# 192.168.1.190 192.168.1.199 - диапазон для VPN-хостов

---

код

---

# команды ниже могут назначить шлюзование всего трафика клиента через VPN
push "route-gateway 192.168.1.254"
push "dhcp-option DNS 192.168.1.254"
push "dhcp-option WINS 192.168.1.254"
push "redirect-gateway"

---

код

---

ca ca.crt # ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert client.crt
key client.key # секретный файл
dev tap
client
remote server.com 1194
remote 1.1.1.1 1194

---

код

---

ifconfig 192.168.1.190 255.255.255.0 # явное указание IP-адреса, назначаемого интерфейсу
dhcp-option DNS 192.168.1.254 # использование удалённого DNS
dhcp-option WINS 192.168.1.254 # использование удалённого WINS
redirect-gateway

---

1. После установки в ОС создаётся новый сетевой интерфейс с "адаптером" TAP-Win32 Adapter V8, отображаемый ОС как сетевой адаптер с неподключенным кабелем, он же может отбражаться в области значков. Это виртуальный адаптер OpenVPN. Его можно переименовать по желанию и это имя можно будет использовать в конфиг-файлах в команде dev-node TAP-interface-name
   1. Этот адаптер НЕ НУЖНО отключать (распространённое явление - не устанавливается OpenVPN-соединение т.к. отключен этот интерфейс)
   2. На этом адаптере в общем случае НЕ НУЖНО настраивать никакие параметры IP-протокола (кроме NetBIOS, см.ниже), включение и конфигурация этого интерфейса производятся автоматически при установке OpenVPN-соединения.
   3. Если не нужен NetBIOS, то во избежание проблем с NetBIOS-ом, свойственных multihomed-хостам РЕКОМЕНДУЕТСЯ отключить NetBIOS для данного интерфейса: сетевые подключения - свойства данного сетевого интерфейса – свойства протокола TCP/IP – дополнительно – WINS – Параметры NetBIOS = Отключить NetBIOS через TCP/IP.
   4. На этом адаптере во избежание непонятных проблем желательно НЕ ВКЛЮЧАТЬ фаервол (брандмауэр), по крайней мере на начальном этапе установки, изучения и запуска.
2. Не происходит добавление маршрута в таблицу маршрутизации, вероятно при включенной службе RRAS (чаще всего возникает на серверных ОС, например, Windows Server 2003, но встречал и на XP) - ошибка:
   "NOTE: FlushIpNetTable failed on interface [2] {427E6BDF-F41F-4E7A-B8C4-4F12B25A6C11} (status=1413) : Invalid index."
   Похоже дело в Win-довом глюке, по API-команде windows должна добавить маршрут, при этом если в конфиг OpenVPN вставить show-net-up, то OpenVPN запросит windows через API всю таблицу маршрутизации и выведет её в лог, там нужный маршрут будет. А если сделать "route print", то маршрута не будет...
   Решение: "route-method exe" в конфиг.файле - это указывает OpenVPN-у, что добавление маршрута надо делать не через API, а через route.exe. Кроме того, может потребоваться небольшая задержка перед добавлением маршрута через route.exe (встречалось, что без задержки route.exe ещё не видит только что появившийся интерфейс и не добавляет маршрут), это делается route-delay 10 (на серверах лично меня "не напрягает" задержка 10 секунд, на клиентах можно уменьшить до экспериментально вычисленного предела)
3. При запуске OpenVPN-соединения из учётной записи пользователя (без прав Администратора) возникает ошибка, связанная с недостатком прав для установки интерфейса. Варианты решения:
   1. Запускать OpenVPN как постоянный сервис (включить автозапуск сервиса OpenVPNservice). Кроме того, сервисом можно управлять и из OpenVPN-GUI, для этого надо в реестре устновить:
      [HKEY_LOCAL_MACHINE\SOFTWARE\OpenVPN-GUI]
      "allow_service"="1"
   2. Использовать «механизм» RunAs:
      runas /user:admin openvpn.exe .....
      runas /user:admin /savecred openvpn.exe .....
   3. Можно также использовать альтернативный продукт, например, http://www.robotronic.de/runasspcEn.html
      RunAsSpc.exe /program:"openvpn.exe" /domain:"localhost" /user:"admin" /password:"pass" /param:<programmoptions> /executein:<path to execute>
      Или более безопасно через создание Crypt-файла, см. приложенный к сообщению скриншот
   4. Более подробно см. также статью на английском - http://openvpn.se/files/howto/openvpn-howto_run_open…_as_nonadmin.html
   5. Использовать версию 2.1, в ней есть возможность 1 раз за сеанс (или до выгрузки драйвера) выполнить под администратором команду
      openvpn.exe --allow-nonadmin [TAP-adapter]
      После этого интерфейс будет "подниматься" и с правами пользователя.

• «OpenVPN, или кроссплатформенная частная сеть» (Журнал "Системный администратор", 2004-08, автор: Андрей Бешков) http://www.samag.ru/art/08.2004/08.2004_01.pdf
• "Организация единой сети при помощи виртуальных ethernet адаптеров (TAP) и программных мостов" (Roman Yerin (Kid)), http://kid.tomsk.ru/docs/linux_bridging.html