» OpenVPN

rain87

Цитата:

прописать отдельно маршруты для хостов, с которыми работает приложение (если их число достаточно мало).

не подходит.

Цитата:

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

костыль конечно, но тоже не вижу других вариантов (
спасибо, за вариант.

приветствую!
есть 2 роутера с подсетями 192.168.0.0 255.255.255.0
в одной из сетей поднята виртуалка на ubuntu, ей выдается фиксированный адрес 192.168.0.39, сама машина на WIFI. Отталкивался естественно от стандартного конфига. Вот конфиг клиентов и сервера
[more]

Цитата:

# Which local IP address should OpenVPN
# listen on? (optional)
local 192.168.0.39

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one. You will need to
# open up this port on your firewall.
port 1194

# TCP or UDP server?
;proto tcp
proto udp

# "dev tun" will create a routed IP tunnel,
# "dev tap" will create an ethernet tunnel.
# Use "dev tap0" if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use "dev-node" for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don't need this.
;dev-node MyTap

# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the "easy-rsa" directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see "pkcs12" directive in man page).
ca /etc/openvpn/ssl/ca.crt
cert /etc/openvpn/ssl/server.crt
key /etc/openvpn/ssl/server.key # This file should be kept secret

# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh1024.pem 1024
# Substitute 2048 for 1024 if you are using
# 2048 bit keys.
dh /etc/openvpn/ssl/dh1024.pem

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.8.0.0 255.255.255.0

# Maintain a record of client <-> virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist /etc/openvpn/ipp.txt

# Configure server mode for ethernet bridging.
# You must first use your OS's bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface. Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 10.8.0.4/255.255.255.0. Finally we
# must set aside an IP range in this subnet
# (start=10.8.0.50 end=10.8.0.100) to allocate
# to connecting clients. Leave this line commented
# out unless you are ethernet bridging.
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100

# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"

# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory "ccd" for client-specific
# configuration files (see man page for more info).

# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir /etc/openvpn/ccd
;route 192.168.0.1 255.255.255.0
# Then create a file ccd/Thelonious with this line:
# iroute 192.168.0.1 255.255.255.0
# This will allow Thelonious' private subnet to
# access the VPN. This example will only work
# if you are routing, not bridging, i.e. you are
# using "dev tun" and "server" directives.

client-config-dir /etc/openvpn/ccd
route 10.8.0.0 255.255.255.252

# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.8.0.21.
# First uncomment out these lines:
;client-config-dir /etc/openvpn/ccd
;route 10.8.0.21 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig-push 10.8.0.21 10.8.0.2

# Suppose that you want to enable different
# firewall access policies for different groups
# of clients. There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
# group, and firewall the TUN/TAP interface
# for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
# modify the firewall in response to access
# from different clients. See man
# page for more info on learn-address script.
;learn-address ./script

# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# the TUN/TAP interface to the internet in
# order for this to work properly).
# CAVEAT: May break client's network config if
# client's local DHCP server packets get routed
# through the tunnel. Solution: make sure
# client's local DHCP server is reachable via
# a more specific route than the default route
# of 0.0.0.0/0.0.0.0.
;push "redirect-gateway"

# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
;push "dhcp-option DNS 10.8.0.1"
;push "dhcp-option WINS 10.8.0.1"

# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.
client-to-client

# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names. This is recommended
# only for testing purposes. For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE "COMMON NAME",
# UNCOMMENT THIS LINE OUT.
;duplicate-cn

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 200 second time period.
keepalive 10 100

# For extra security beyond that provided
# by SSL/TLS, create an "HMAC firewall"
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn --genkey --secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
;tls-auth ta.key 0 # This file is secret

# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES

# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
comp-lzo

# The maximum number of concurrently connected
# clients we want to allow.
max-clients 100

# It's a good idea to reduce the OpenVPN
# daemon's privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
user nobody
group nogroup

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun

# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status /etc/openvpn/log/openvpn-status.log

# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it. Use one
# or the other (but not both).
log /etc/openvpn/log/openvpn.log
log-append /etc/openvpn/log/openvpn.log

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 6

# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
mute 20

[/more]
конфиги клиентов делались по принципу ccd файлов:

Цитата:

ifconfig-push 10.8.0.5 10.8.0.6

для 4адресовой сети, то есть выдавал мне адреса 10.8.0.5(клиент внутри первого роутера) 10.8.0.9(клиент внутри первого роутера, на машине, где стоит сам сервер openvpn) и 10.8.0.13 (удаленный клиент со своим роутером).
Сами конфиги клиентов выглядят примерно так:
[more]

Цитата:

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one. On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server? Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote 213.xxx.xxx.24x 1194
;remote 192.168.0.39 1194
;remote my-server-2 1194

# Choose a random host from the remote
# list for load-balancing. Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here. See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets. Set this flag
# to silence duplicate packet warnings.
mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description. It's best to use
# a separate .crt/.key file pair
# for each client. A single ca
# file can be used for all clients.
ca c:\\OpenVPNPortable\\data\\config\\ca.crt
cert c:\\OpenVPNPortable\\data\\config\\client2.crt
key c:\\OpenVPNPortable\\data\\config\\client2.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server". This is an
# important precaution to protect against
# a potential attack discussed here:
# http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server". The build-key-server
# script in the easy-rsa folder will do this.
;ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
mute 20
remote-cert-tls server

[/more]

Ситуация такая:
Коннект идет, адреса выдает, пинги со всех машин на 10.8.0.1 идут. А теперь чудеса.
С машины 10.8.0.9, на которой стоит виртуалка с сервером пингуется все
С машины внутри этой же серверной сети пингуется все, кроме 10.8.0.9
Соответственно //10.8.0.x не пашет.
1) Как добиться чтобы пинговало все, ведь по логике то должно
2) Есть ли какие-то существенные косяки в моих конфигах
3) Какие еще есть варианты.
ПС, нужно чтобы локал ресурсы по возможности были видны в сети, хотя бы на серверной машине.

makkonen
Вы когда-нибудь научитесь юзать тэг [more]?????!!!!!

Alukardd
поправил

Во первых могли и не отписываться...
Во вторых уберите комменты из конфигов! grep -v "^#" server.conf | uniq > server.conf.txt

makkonen
я бы советовал использовать tap режим. тебе, по сути, надо объеденить несколько точек в одну локальную сеть, которая будет работать внутри овпн. tap режим как раз для этого и работает - фактически, tap интерфейс с точки зрения ОС - полноценный ethernet интерфейс. tun режим больше предназначен для п2п связи клиент-сервер

ну а если честно, я просто плохо представляю себе, как работает tun никогда не использовал его. поэтому не могу сказать, в чём проблемы

Alukardd
можно не отписываться и вам было уж тогда, раз такая канитель
rain87
спасибо за совет, про это в курсе, вся проблема tap режима - настройки виртуалки. если просто поменять в конфиге - коннект есть, но пинга не идет.

makkonen
я-то как раз не мог не отписываться ибо не писал пустых сообщений.

а так могу вам сказать, что с моей стороны это не выпендрёж и придирки, а нормальная просьба к виду поста. Лично я не могу читать и искать пару нужных строк в простыне конфига, на 90% состоящего из комментариев. Таких как rain87, я знаю еще только 1-го на этом форуме - roma. И изредка ipmanyak.
Свои-то конфиги тяжело читать с комментами, а чужие...

makkonen
Цитата:

если просто поменять в конфиге - коннект есть, но пинга не идет.

просто поменять tun на tap, конечно, не спасёт ситуацию как минимум надо поменять ещё ccd для каждого клиента на такой макар -
ifconfig-push 10.8.0.5 255.255.255.0
и убрать из серверного конфига route 10.8.0.0 255.255.255.252

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

rain87, можно вопрос как человеку знающему тему?

Как и многим здесь мне нужно объединить 2 локалки. В принципе я это уже все сделал, но через tun и поэтому широковещательные запросы не действуют. И что-то опять недопонимаю, как поднять Бридж.

Описание локалок:[more]Первая локалка: 192.168.0.0 / 255.255.255.0
Сервак Имеет внутренний IP: 192.168.0.1

Вторая локалка: 192.168.2.0 / 255.255.255.0
Сервак Имеет внутренний IP: 192.168.2.1

Оба сервака построены на Server 2003 Ent SP2 En. На обоих поднят DHCP и NAT (ICS).
Сервак второй локалки коннектится к серваку Первой на его внешний IP: 192.168.1.4. (условно)[/more]

Вот конфиг OpenVPN сервера:[more]proto udp
port 64999
dev tun
comp-lzo
ping 30
verb 3
ifconfig 10.0.0.1 10.0.0.2
route 192.168.2.0 255.255.255.0 10.0.0.2
secret ..\\config\\static.key
tun-mtu 1500
cipher AES-256-CBC
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key[/more]

Вот конфиг OpenVPN клиента:[more]proto udp
port 64999
dev tun
comp-lzo
ping 30
verb 3
remote 192.168.1.4
ifconfig 10.0.0.2 10.0.0.1
route 192.168.0.0 255.255.255.0 10.0.0.1
secret ..\\config\\static.key
tun-mtu 1500
cipher AES-256-CBC
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key[/more]

Т.е. для получения нужного результата мне нужно:
1) В конфиге сервера вместо dev tun прописать dev tap?
2) В конфиге сервера убрать route 192.168.2.0 255.255.255.0 10.0.0.2 и прописать ifconfig-push 10.0.0.2 255.255.255.252?

Подскажи плиз, как надо сделать, а то реально устал экспериментировать.. уже во сне все эти пинги снятся.

ЗЫ:
А поднять это дело стандартным RRAS от Server 2003 SP2 - это вообще полная жопа. Несколько ночей потратил, пока читал тупые маны мелкософта и прочую писанину в нете. Может я еще пока не дорос, но не зря мне OpenVPN изначально рекомендовали.

Вот довольно-таки подробное руководство об оъединении сетей через tun

чтоб клиенты видели друг-друга в конфиг сервера : client-to-client

Чтоб сервер видел сеть за клиентом в файл ccd/имя_клиента:
iroute 192.168.76.0 255.255.255.0

где 192.168.76.0 - локальная подсеть за клиентом

Чтоб клиент видел сети за другими клиентами туда-же:

push "route 192.168.67.0 255.255.255.0"

где 192.168.67.0 - локальная подсеть за клиентом

PS Может взяться дружно перевести ман по OpenVPN ? Там еще столько интересных фич...(хотя сам пока осваивал OpenVPN по чужим конфигам).
Столько бы повторяющихся вопросов сразу же убавилось бы-))

timsky
да, во первых - tun поменять на tap
во вторых - в конфиге сервера
ifconfig 10.0.0.1 10.0.0.2 заменить на
ifconfig 10.0.0.1 255.255.255.252
и добавить
ifconfig-push 10.0.0.2 255.255.255.252
из конфига клиента удалить ifconfig 10.0.0.2 10.0.0.1

все route можно вполне оставить на месте. после этого, в принципе, можно делать бридж стандартными средствами винды

rain87
Сделал, но Сервер выдает ошибку:
Цитата:

Options error: option 'ifconfig-push' cannot be used in this context
Use --help for more information.

Пробовал добавить
Цитата:

mode server
server 10.0.0.0 255.255.255.0

вместе и по отдельности - выдает ту же ошибку

Конфиг сервера:[more]proto udp
port 64998
dev tap
comp-lzo
verb 3
ifconfig 10.0.0.1 255.255.255.252
ifconfig-push 10.0.0.2 255.255.255.252
route 192.168.2.0 255.255.255.0 10.0.0.2
secret ..\\config\\static.key
tun-mtu 1500
cipher AES-256-CBC
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key[/more]
Конфиг клиента:[more]proto udp
port 64998
dev tap
comp-lzo
verb 3
remote 192.168.1.4
route 192.168.0.0 255.255.255.0 10.0.0.1
secret ..\\config\\static.key
tun-mtu 1500
cipher AES-256-CBC
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key[/more]

Цитата:

после этого, в принципе, можно делать бридж стандартными средствами винды

Винда не позволяет, т.к. 2 из 3-х соединений у меня задействованы в ICS (NAT).
1 - Локалка
2 - Мир
3 - VPN

Помоги плиз разобраться

timsky
ifconfig-push видимо только в tls сервере может использоваться, хз. ну тогда убери ifconfig-push из серверного конфига, а в клиентский добавь ifconfig 10.0.0.2 255.255.255.252

Цитата:

Винда не позволяет, т.к. 2 из 3-х соединений у меня задействованы в ICS (NAT).

ну так а как тогда бридж делать? его по любому надо средствами ОС делать

Во че нашел!!!:
Ман OpenVPN по русски [more]1. Описание команд и основных опций (и их применимость на сервере и клиенте)

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


2. Простейшая конфигурация static-key - 1 сервер + 1 клиент одновременно:
2.1. Генерация статического ключа - ярлык в меню или "openvpn --genkey --secret static.key"
Этот общий ключ должен быть на обеих сторонах - и на сервере и на клиенте
2.2. Server.ovpn

код

dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key

.3. Client.ovpn

код

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


3. Расширенная конфигурация туннеля 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 адреса. В меру художественных способностей изобразил это на рисунке - http://forum.ixbt.com/post.cgi?id=attach:14:40906:38:1
Замечу, что к самим IP-адресам виртуального маршрутизатора непосредственно обратиться никак нельзя, оне НЕ ПИНГУЮТСЯ, и в tracert не отображаются.
Указанный выше вариант распределения IP-адресов сделан для совместимости с Windows. Однако, есть возможность использовать и выделение адресов/32, то есть без подсетей, см. команду ifconfig-pool-linear. Кроме того, в версии 2.1 (на момент июня 2007 это пока 2.1.rc4) в этом вопросе тоже есть нововведения.

3.1. Ключи
Все действия производятся в папке C:\Program Files\OpenVPN\easy-rsa
Действия выполнять так, чтобы сохранялся контекст переменных, например, в командной строке без выхода из неё. Первой командой при каждой операции работы с ключами (кроме начальной инициализации) должна быть vars.bat.

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

* 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 # очистка и инициализация папки ключей

Создание 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).

3.2.Конфигурация сервера - Server.ovpn
Здесь и далее, параметры указывающие на файлы можно (или даже желательно) указывать с полными путями. Для Windows символ "\" указывается как "\\", пути с пробелами брать в кавычки, например: "C:\\Program Files\\OpenVPN\\config\\ca.crt". В примере это не указано чтобы не загромождать.

код

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"

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

код

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


4. Расширенная конфигурация туннеля 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 - хост в удалённой сети:

код

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

4.1.Подготовительные операции
Если необходим доступ к локальной сети "за сервером" (в 95% случаев это необходимо), то надо объединить сетевой адаптер LAN сервера в мост с OpenVPN-tap-адаптером, при этом создаётся новый адаптер и уже ему назначаете IP, скорее всего тот который был до этого у LAN. В Win это можно сделать под XP или 2003 (2000 это не умеет). Если на сервере есть ПО, привязанное к интерфейсам, то, вероятно, потребуются соответствующие изменения настроек и этого ПО.

Генерация ключей не отличается от туннеля L3, поэтому см. п.3.1

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

код

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"

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

код

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


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

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]
После этого интерфейс будет "подниматься" и с правами пользователя.[/more]

Взято отсюда :http://forum.ixbt.com/topic.cgi?id=14:40906

rain87

Цитата:

ну тогда убери ifconfig-push из серверного конфига, а в клиентский добавь ifconfig 10.0.0.2 255.255.255.252

Уже сделал, tap работает, но пока также как и tun.


Цитата:

ну так а как тогда бридж делать?

Если бы я знал...
А может как-то можно завернуть эти запросы в тунель или еще как-то изъ**нуться?

timsky
а чего вообще ты хочешь добиться бриджем? какая конечная цель? чтоб бродкасты из одной сети ходили в другую?

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

rain87

Цитата:

а чего вообще ты хочешь добиться бриджем? какая конечная цель? чтоб бродкасты из одной сети ходили в другую?

Очень желательно чтобы компы были просто видны в Сетевом окружении. Т.е. чтобы обращаться к ним можно было не только по \\IP\шара.


Цитата:

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

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

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

Странно. Сделал бридж м/у Локалкой и OpenVPN соединением. Теперь даже при соединении OpenVPN на обоих серверах значок OpenVPN говорит о том, что сетевой кабель не подключен. А на Server значок OpenVPN GUI так и остается желтым. Вот его лог: [more]Wed Nov 24 15:48:55 2010 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Wed Nov 24 15:48:55 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Nov 24 15:48:55 2010 Static Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Nov 24 15:48:55 2010 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Nov 24 15:48:55 2010 Static Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Nov 24 15:48:55 2010 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Nov 24 15:48:55 2010 LZO compression initialized
Wed Nov 24 15:48:55 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Nov 24 15:48:55 2010 ROUTE default_gateway=192.168.1.1
Wed Nov 24 15:48:55 2010 TAP-WIN32 device [OpenVPN] opened: \\.\Global\{BB80C879-CA66-4134-A93D-EC7B42FA5AC9}.tap
Wed Nov 24 15:48:55 2010 NOTE: could not get adapter index for {BB80C879-CA66-4134-A93D-EC7B42FA5AC9}
Wed Nov 24 15:48:55 2010 TAP-Win32 Driver Version 9.7
Wed Nov 24 15:48:55 2010 TAP-Win32 MTU=1500
Wed Nov 24 15:48:55 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.0.0.1/255.255.255.252 on interface {BB80C879-CA66-4134-A93D-EC7B42FA5AC9} [DHCP-serv: 10.0.0.0, lease-time: 31536000]
Wed Nov 24 15:48:55 2010 Data Channel MTU parms [ L:1593 D:1450 EF:61 EB:135 ET:32 EL:0 AF:3/1 ]
Wed Nov 24 15:48:55 2010 Local Options hash (VER=V4): 'a6c49e9a'
Wed Nov 24 15:48:55 2010 Expected Remote Options hash (VER=V4): 'a6c49e9a'
Wed Nov 24 15:48:55 2010 UDPv4 link local (bound): [undef]:64998
Wed Nov 24 15:48:55 2010 UDPv4 link remote: [undef][/more]

Вот лог клиентской части: [more]Wed Nov 24 15:49:06 2010 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Wed Nov 24 15:49:06 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Nov 24 15:49:06 2010 Static Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Nov 24 15:49:06 2010 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Nov 24 15:49:06 2010 Static Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Nov 24 15:49:06 2010 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Nov 24 15:49:06 2010 LZO compression initialized
Wed Nov 24 15:49:06 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Nov 24 15:49:06 2010 ROUTE default_gateway=192.168.1.1
Wed Nov 24 15:49:06 2010 TAP-WIN32 device [OpenVPN] opened: \\.\Global\{D7D07FDE-AFB3-40BC-95FB-8E2F1A247CB4}.tap
Wed Nov 24 15:49:06 2010 NOTE: could not get adapter index for {D7D07FDE-AFB3-40BC-95FB-8E2F1A247CB4}
Wed Nov 24 15:49:06 2010 TAP-Win32 Driver Version 9.7
Wed Nov 24 15:49:06 2010 TAP-Win32 MTU=1500
Wed Nov 24 15:49:06 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.0.0.2/255.255.255.252 on interface {D7D07FDE-AFB3-40BC-95FB-8E2F1A247CB4} [DHCP-serv: 10.0.0.0, lease-time: 31536000]
Wed Nov 24 15:49:06 2010 Data Channel MTU parms [ L:1593 D:1450 EF:61 EB:135 ET:32 EL:0 AF:3/1 ]
Wed Nov 24 15:49:06 2010 Local Options hash (VER=V4): 'a6c49e9a'
Wed Nov 24 15:49:06 2010 Expected Remote Options hash (VER=V4): 'a6c49e9a'
Wed Nov 24 15:49:06 2010 UDPv4 link local (bound): [undef]:64998
Wed Nov 24 15:49:06 2010 UDPv4 link remote: 192.168.1.4:64998
Wed Nov 24 15:49:06 2010 Peer Connection Initiated with 192.168.1.4:64998
Wed Nov 24 15:49:12 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:12 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:16 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:16 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:17 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:17 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:19 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:19 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:20 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:20 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:21 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:21 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:22 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:22 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:23 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:23 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:24 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:24 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:25 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:25 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:26 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:26 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:27 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:27 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:28 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:28 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:29 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:29 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:30 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:30 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:31 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:31 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:32 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:32 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:33 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:33 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:34 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:34 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:35 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:35 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:36 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:36 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:37 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:37 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:38 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:38 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:39 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:39 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:40 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:40 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:41 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:41 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Nov 24 15:49:42 2010 TEST ROUTES: 0/1 succeeded len=1 ret=0 a=0 u/d=up
Wed Nov 24 15:49:42 2010 C:\WINDOWS\system32\route.exe ADD 192.168.0.0 MASK 255.255.255.0 10.0.0.1
Wed Nov 24 15:49:42 2010 Warning: route gateway is not reachable on any active network adapters: 10.0.0.1
Wed Nov 24 15:49:42 2010 Route addition via IPAPI failed [adaptive]
Wed Nov 24 15:49:42 2010 Route addition fallback to route.exe
The route addition failed: Either the interface index is wrong or the gateway does not lie on the same network as the interface. Check the IP Address Table for the machine.
SYSTEM ROUTING TABLE
0.0.0.0 0.0.0.0 192.168.1.1 p=0 i=65540 t=4 pr=3 a=833 h=0 m=10/-1/-1/-1/-1
127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=848 h=0 m=1/-1/-1/-1/-1
192.168.0.0 255.255.255.0 192.168.0.1 p=0 i=65539 t=3 pr=2 a=52 h=0 m=10/-1/-1/-1/-1
192.168.0.1 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=52 h=0 m=10/-1/-1/-1/-1
192.168.0.255 255.255.255.255 192.168.0.1 p=0 i=65539 t=3 pr=2 a=52 h=0 m=10/-1/-1/-1/-1
192.168.1.0 255.255.255.0 192.168.1.4 p=0 i=65540 t=3 pr=2 a=835 h=0 m=10/-1/-1/-1/-1
192.168.1.4 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=835 h=0 m=10/-1/-1/-1/-1
192.168.1.255 255.255.255.255 192.168.1.4 p=0 i=65540 t=3 pr=2 a=835 h=0 m=10/-1/-1/-1/-1
224.0.0.0 240.0.0.0 192.168.0.1 p=0 i=65539 t=3 pr=2 a=52 h=0 m=10/-1/-1/-1/-1
224.0.0.0 240.0.0.0 192.168.1.4 p=0 i=65540 t=3 pr=2 a=835 h=0 m=10/-1/-1/-1/-1
255.255.255.255 255.255.255.255 192.168.0.1 p=0 i=65539 t=3 pr=2 a=848 h=0 m=1/-1/-1/-1/-1
255.255.255.255 255.255.255.255 192.168.1.4 p=0 i=65540 t=3 pr=2 a=848 h=0 m=1/-1/-1/-1/-1
SYSTEM ADAPTER LIST
MAC Bridge Miniport
Index = 65539
GUID = {69EE820D-9D2D-47B0-BF91-59FE7CF47362}
IP = 192.168.0.1/255.255.255.0
MAC = 02:ff:d7:d0:7f:de
GATEWAY =
DNS SERV =
Intel(R) PRO/1000 MT Network Connection #2
Index = 65540
GUID = {64187949-53FB-423C-96FA-FC4546A3E9C1}
IP = 192.168.1.4/255.255.255.0
MAC = 00:0c:29:2e:35:67
GATEWAY = 192.168.1.1/0.0.0.0
DHCP SERV = 192.168.1.1
DHCP LEASE OBTAINED = Wed Nov 24 15:35:48 2010
DHCP LEASE EXPIRES = Thu Nov 25 15:35:48 2010
DNS SERV = 192.168.1.1
Wed Nov 24 15:49:42 2010 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )[/more]

И пинги уже не проходят ни с какой машины ни в какую противоположную сеть.


Цитата:

тогда надо всем выдавать ИП адреса из одной подсети

Можно. А это не помешает работе OpenVPN?

timsky
не, не помешает. скорее наоборот сделай в обеих сетях одну подсеть (192.168.0.0/24, например), и в обоих конфигах овпн укажи ifconfig 192.168.0.x 255.255.255.0 (в каждом конфиге, само собой, свой ИП, который не должен пересекаться ни с 1 из реальных машин). все route убери
ну и на обоих машинах, само собой, бридж подними

Цитата:

ну и на обоих машинах, само собой, бридж подними

Бридж я правильно поднимаю? Объединяю в Бридж Локалку и сетевой Интерфейс OpenVPN.

ну да, так

Кажись пашет! Спасибо огромное!

Цитата:

Здравствуйте,
подскажите плиз
Имеется удалённый компьютер, который подключается посредством OpenVPN к сети организации. У компьютера IP 172.16.8.2, у организации адресация 192.168.20.* Возникла необходимость, что бы данный компьютер посредством VPN-соединения через нашу сеть попадал в другую сеть с адресацией 192.168.0.* для работы по RDP. По идее, нужно прописать статический маршрут, но есть одно НО: адресация сети, через которую удалённый компьютер выходит в инет так же имеет адресацию 192.168.0.* Я правильно понимаю, что прописывание статического маршрута для доступа к сети 192.168.0.* посредством VPN в итоге отрубит компьютеру и инет, и VPN, который работает через этот инет, т.к. трафик локальной сети будет заворачиваться на VPN? Есть ли иное решение?

проблема актуальна.


Цитата:

надо перед прописыванием маршрута 192.168.0.* через впн явно прописать, через какой сетевой интерфейс доступен интернет шлюз

через route add? как должна выглядеть команда, опишите поподробнее пожалуйста!

Заранее благодарен.

BeerLinn

Цитата:

Я правильно понимаю, что прописывание статического маршрута для доступа к сети 192.168.0.* посредством VPN в итоге отрубит компьютеру и инет, и VPN, который работает через этот инет, т.к. трафик локальной сети будет заворачиваться на VPN?

да, так и будет
Цитата:

Есть ли иное решение?

можно прописывать маршрут не ко всей 192.168.0.* подсети, а только к конкретным машинам, которые нужны (если их немного). второе решение, как я говорил - прописать, через какой интерфейс доступен шлюз. но я не пойму, как это сделать под виндой. под линуксом всё просто и работает -
Код: root@rain87-laptop:~# route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
10.6.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.1.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0 vboxnet0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
1.0.0.0 10.6.1.4 255.0.0.0 UG 0 0 0 tap0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
root@rain87-laptop:~# route add -host 192.168.1.1 dev wlan0
root@rain87-laptop:~# route del -net 192.168.1.0/24 dev wlan0
root@rain87-laptop:~# route add -net 192.168.1.0/24 gw 10.6.1.4
root@rain87-laptop:~# route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 wlan0
10.6.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.1.0 10.6.1.4 255.255.255.0 UG 0 0 0 tap0
192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0 vboxnet0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
1.0.0.0 10.6.1.4 255.0.0.0 UG 0 0 0 tap0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

Доброго времени суток.
На сервере (Fedora 12) установлен OpenVPN 2.1.1
Клиенты под Win.
В сети за сервером есть как компьютера, так и видеорегистраторы, подключенные к сети.
Компьютера видны и отзываются. А вот видеорегистраторы молчат. Нету отзыва даже на пинги.

Файл настроек сервера:

Цитата:

client-config-dir /etc/openvpn/ccd/
mode server
tls-server
proto tcp-server
dev tap
port 1194
daemon
ifconfig 10.100.100.1 255.255.255.0
ifconfig-pool 10.100.100.20 10.100.100.250
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.9.0 255.255.255.0"
push "route-gateway 10.100.100.1"
duplicate-cn
cipher DES-EDE3-CBC
persist-key
persist-tun
comp-lzo

verb 3
log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
ifconfig-pool-persist /var/log/openvpn-ipp.txt

Файл настроек клиентов:

Цитата:

tls-client
proto tcp-client
remote ххх.ххх.ххх.ххх 1194
dev tap
port 1194
pull
tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 1
dh keys/dh1024.pem
ca "C:\\Program Files\\OpenVPN\\config\\CA.crt"
cert "C:\\Program Files\\OpenVPN\\config\\ххх.crt"
key "C:\\Program Files\\OpenVPN\\config\\ххх.key"
cipher DES-EDE3-CBC
comp-lzo

Какие могут быть рекомендации к лечению?

danilevskiy
а на видеорегистраторах прописан какой то шлюз? если нет, тогда на сервере надо NAT поднять. или на регистраторах прописать сервер шлюзом

Цитата:

а на видеорегистраторах прописан какой то шлюз?...

Прописан. Хотя толку от него? Я же в сети нахожусь, хоть и через VPN.


Цитата:

...тогда на сервере надо NAT поднять...

На сервере NAT поднят. Это инетовский шлюз.

Изменил tun на tap, все заработало как я хотел. Спасибо за советы.