Авторизация  
zm1

> (FAQ) По командам OpenVPN в Windows

В теме 1 сообщение

Режимы работы 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-роутера

Для 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 для управления

 

Команды настройки маршрутизации

* 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-роутера

Для 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 и 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

 

Расширенная конфигурация туннеля L3 (IP-туннель, aka "routed")

 

 

В данном режиме OpenVPN-сервер эмулирует работу некоего многопортового виртуального маршрутизатора, к каждому порту которого подключен каждый клиент и сам серверный хост. При этом каждому виртуальному tun-интерфейсу хоста (и сервера в том числе) присваивается IP-адрес, также присваиваивается IP-адрес соответствующему порту этого виртуального маршрутизатора и выделяется подсеть, включающая эти 2 адреса + неожходимые 2 служебных, в итоге для каждого подключения выделяется подсеть /30 (255.255.255.252) из 4 адресов, назначение которых, например, для первой подсети 10.1.1.0/30 из OpenVPN-сети 10.1.1.0/24 таково:

10.1.1.0 - адрес подсети 10.1.1.0/30

10.1.1.1 - адрес tun-интерфейса сервера

10.1.1.2 - адрес интерфейса виртуального маршрутизатора

10.1.1.3 - адрес широковещания (broadcast)

Далее каждому подключающемуся клиенту выделяются подсеть и адрес именно блоками /30, то есть по 4 адреса.

Замечу, что к самим IP-адресам виртуального маршрутизатора непосредственно обратиться никак нельзя, оне НЕ ПИНГУЮТСЯ, и в tracert не отображаются.

 

Ключи

 

 

Все действия производятся в папке C:Program FilesOpenVPNeasy-rsa

Действия выполнять так, чтобы сохранялся контекст переменных, например, в командной строке без выхода из неё. Первой командой при каждой операции работы с ключами (кроме начальной инициализации) должна быть vars.bat.

 

Начальная инициализация, выполняется 1 раз

 

* init-config.bat - начальная инициализация, создаст файлы vars.bat и openssl.cnf

В файле vars.bat надо установить ВСЕ параметры

set HOME=%ProgramFiles%OpenVPNeasy-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 # очистка и инициализация папки ключей

 

Создание master Certificate Authority (CA) certificate & key, выполняется 1 раз

 

* vars.bat

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

 

Генерация сертификата и ключа для сервера, выполняется 1 раз

 

* 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)

 

Генерация Diffie Hellman parameters, выполняется 1 раз, нужно только для tls-server

 

* vars.bat

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

 

Генерация сертификатов и ключей клиентов, выполняется по необходимости

 

* vars.bat

* build-key client1

* build-key client2

* build-key client3

 

ВАЖНО!!! В вопросе "Common Name (eg, your name or your server's hostname) []:" нужно для каждого ключа указывать УНИКАЛЬНОЕ имя, например, client1, и т.д.

В результате будет создан ключ client1.key, сертификат client1.crt, запрос Certificate Signing Request (CSR) client1.csr, ?непонятный файл? 02.pem (копия client1.csr)

 

В итоге имеем:

ключи *.key # секретная информация, должны распространяться ТОЛЬКО ПО СЕКРЕТНЫМ КАНАЛАМ. Нужны только на соотв. хостах.

сертификаты *.crt # несекретная информация.

запросы серт. *.csr # Certificate Signing Request, нужны для распределённой генерации и сертификации ключей.

dh1024.pem # Diffie Hellman parameters

 

Вместо использования на клиентах 3-ёх раздельных файлов (ca, cert, key) можно использовать единый файл формата PKCS12. Для этого надо генерировать ключ клиента командой:

build-key-pkcs12 client1

Будет создан и обычный комплект файлов, и новый файл .p12 - это и есть этот комбинированный файл. Его можно использовать в конфиге клиента одной командой pkcs12 вместо трёх команд ca, cert, key.

Также при генерации этому файлу можно задать пароль для защиты секретного ключа, в таком случае каждый раз при установке соединения будет запрашиваться пароль для доступа к секретному ключу (Внимание! Так нельзя делать при запуске сервиса, т.к. он не сможет запросить пароль и не сможет установить соединение.). Следует также иметь ввиду, что пользователь имеет право самостоятельно изменить/удалить/установить пароль защиты секретного ключа.[/ list]

 

Отзыв сертификатов клиентов, выполняется по необходимости, например, при утере ключа или пароля, утечке или компрометации ключа клиента.

 

* vars.bat

* revoke-full client1

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

 

Конфигурация сервера - Server.ovpn

 

Здесь и далее, параметры указывающие на файлы можно (или даже желательно) указывать с полными путями. Для Windows символ "" указывается как "", пути с пробелами брать в кавычки, например: "C:Program FilesOpenVPNconfigca.crt". В примере это не указано чтобы не загромождать.

 

 

ca ca.crt # ca "C:Program FilesOpenVPNconfigca.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"

 

 

Конфигурация клиента - Client.ovpn

 

ca ca.crt # ca "C:Program FilesOpenVPNconfigca.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

 

Расширенная конфигурация туннеля L2 (Ethernet-туннель, aka "bridged")

 

В данном режиме тунелируются не IP-пакеты, а пакеты Ethernet, что позволяет использовать поверх такого OpenVPN-соединения:

 

* не только IP-протокол, но и, например, IPX (лично не проверено)

* приложения работающие только в пределах своей подсети

* приложения, работающие через broadcast (например, NetBIOS)

* иметь доступ к внутренним ресурсам, которые в силу разных причин не имеют настроенного шлюза

* без дополнительных настроек (например, настройка NAT на шлюзе для дополнительной OpenVPN-подсети) использовать перенаправление трафика командой redirect-gateway

 

В этой схеме на клиенте доступ к удалённой сети производится напрямую, то есть реально через ARP и т.п. Например, 192.168.1.191 - VPN-клиент, а 192.168.1.101 - хост в удалённой сети

 

Конфигурация сервера - Server.ovpn

 

ca ca.crt # ca "C:Program FilesOpenVPNconfigca.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"

 

Конфигурация клиента - Client.ovpn

 

ca ca.crt # ca "C:Program FilesOpenVPNconfigca.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

 

 

Некоторые распростанённые проблемы и методы решения

 

# После установки в ОС создаётся новый сетевой интерфейс с "адаптером" 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. На этом адаптере во избежание непонятных проблем желательно НЕ ВКЛЮЧАТЬ фаервол (брандмауэр), по крайней мере на начальном этапе установки, изучения и запуска.

 

# Не происходит добавление маршрута в таблицу маршрутизации, вероятно при включенной службе 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 секунд, на клиентах можно уменьшить до экспериментально вычисленного предела)

Поделиться сообщением


Ссылка на сообщение

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация