Jump to content
Калькуляторы

Помогите, пожалуйста, настроить OpenVPN не получается, уже почти всё перепробывал.

Доброго всем времени суток. Имеем машину с Ubuntu Server, на ней поднят Accel-PPP и силами форумчан (за что им низкий поклон) работает чуть более чем исправно. Однако попробовал поднять OpenVPN, однако сие чудо ни в какую не хочет передавать трафик дальше себя, хотя успешный коннект есть. Сразу оговорю, что пробовал менять tap на tun и наоборот, пробовал менять tcp на udp и наобопрот, пробовал ставить статический роут на клиенте (Win 7) вида 0.0.0.0 с метрикой 1. Route print на клиенте явно даёт понять, что маршрут автоматом добавился, но толку 0. Таки дела. Ниже приведу конфиги клиента и сервера на данный момент (ибо уж очень часто менялись в связи с попыткой хоть как-то настроить), а также логи сервера и клиента. Так же оговорюсь, что сертификаты сгенерированы правильно и коннект есть.

Конфиг сервера

port 1194
proto tcp
dev tap
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn//keys/dh1024.pem
server-bridge 10.10.11.0 255.255.255.0 10.10.11.2 10.10.11.10
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
cipher none
#user nobody
#group nogroup
persist-key
persist-tun
status openvpn-status.log
log log.log
log-append  openvpn.log
verb 4
mute 20
client-to-client
push "dhcp-option DNS 109.86.2.2"
push "dhcp-option DNS 109.86.2.21"
push "redirect-gateway"
push "route-gateway 10.10.11.1"

Конфиг клиента

client
dev tap
proto tcp
remote 109.87.158.138
port 1194
ca ca.crt
cert client1.crt
key client1.key
tls-client
cipher none
ns-cert-type server
comp-lzo
cipher none
persist-key
persist-tun
status openvpn-status.log
log /var/log/openvpn.log
verb 3
mute 20
redirect-gateway

Лог сервера

Tue Feb 19 16:00:54 2013 us=666032 Current Parameter Settings:
Tue Feb 19 16:00:54 2013 us=666074   config = '/etc/openvpn/server.conf'
Tue Feb 19 16:00:54 2013 us=666081   mode = 1
Tue Feb 19 16:00:54 2013 us=666086   persist_config = DISABLED
Tue Feb 19 16:00:54 2013 us=666092   persist_mode = 1
Tue Feb 19 16:00:54 2013 us=666096   show_ciphers = DISABLED
Tue Feb 19 16:00:54 2013 us=666101   show_digests = DISABLED
Tue Feb 19 16:00:54 2013 us=666106   show_engines = DISABLED
Tue Feb 19 16:00:54 2013 us=666111   genkey = DISABLED
Tue Feb 19 16:00:54 2013 us=666116   key_pass_file = '[uNDEF]'
Tue Feb 19 16:00:54 2013 us=666121   show_tls_ciphers = DISABLED
Tue Feb 19 16:00:54 2013 us=666126 Connection profiles [default]:
Tue Feb 19 16:00:54 2013 us=666132   proto = tcp-server
Tue Feb 19 16:00:54 2013 us=666136   local = '[uNDEF]'
Tue Feb 19 16:00:54 2013 us=666141   local_port = 1194
Tue Feb 19 16:00:54 2013 us=666146   remote = '[uNDEF]'
Tue Feb 19 16:00:54 2013 us=666151   remote_port = 1194
Tue Feb 19 16:00:54 2013 us=666155   remote_float = DISABLED
Tue Feb 19 16:00:54 2013 us=666160   bind_defined = DISABLED
Tue Feb 19 16:00:54 2013 us=666164   bind_local = ENABLED
Tue Feb 19 16:00:54 2013 us=666169 NOTE: --mute triggered...
Tue Feb 19 16:00:54 2013 us=666181 260 variation(s) on previous 20 message(s) suppressed by --mute
Tue Feb 19 16:00:54 2013 us=666188 OpenVPN 2.2.1 x86_64-linux-gnu [sSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [iPv6 payload 20110424-2 (2.2RC2)] built on Oct  8 2012
Tue Feb 19 16:00:54 2013 us=666245 NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is diff$
Tue Feb 19 16:00:54 2013 us=666305 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Feb 19 16:00:54 2013 us=667220 Diffie-Hellman initialized with 1024 bit key
Tue Feb 19 16:00:54 2013 us=667636 ******* WARNING *******: null cipher specified, no encryption will be used
Tue Feb 19 16:00:54 2013 us=667654 TLS-Auth MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Tue Feb 19 16:00:54 2013 us=667672 Socket Buffers: R=[87380->131072] S=[16384->131072]
Tue Feb 19 16:00:54 2013 us=667822 TUN/TAP device tap0 opened
Tue Feb 19 16:00:54 2013 us=667842 TUN/TAP TX queue length set to 100
Tue Feb 19 16:00:54 2013 us=667869 Data Channel MTU parms [ L:1560 D:1450 EF:28 EB:135 ET:32 EL:0 AF:14/28 ]
Tue Feb 19 16:00:54 2013 us=668135 Listening for incoming TCP connection on [undef]
Tue Feb 19 16:00:54 2013 us=668179 TCPv4_SERVER link local (bound): [undef]
Tue Feb 19 16:00:54 2013 us=668189 TCPv4_SERVER link remote: [undef]
Tue Feb 19 16:00:54 2013 us=668200 MULTI: multi_init called, r=256 v=256
Tue Feb 19 16:00:54 2013 us=668252 IFCONFIG POOL: base=10.10.11.2 size=9, ipv6=0
Tue Feb 19 16:00:54 2013 us=676586 ifconfig_pool_read(), in='client1,10.10.11.4', TODO: IPv6
Tue Feb 19 16:00:54 2013 us=676641 succeeded -> ifconfig_pool_set()
Tue Feb 19 16:00:54 2013 us=676657 IFCONFIG POOL LIST
Tue Feb 19 16:00:54 2013 us=676669 client1,10.10.11.4
Tue Feb 19 16:00:54 2013 us=676692 MULTI: TCP INIT maxclients=1024 maxevents=1028
Tue Feb 19 16:00:54 2013 us=676717 Initialization Sequence Completed
Tue Feb 19 19:38:11 2013 us=89658 MULTI: multi_create_instance called
Tue Feb 19 19:38:11 2013 us=89759 Re-using SSL/TLS context
Tue Feb 19 19:38:11 2013 us=89793 LZO compression initialized
Tue Feb 19 19:38:11 2013 us=90016 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Tue Feb 19 19:38:11 2013 us=90048 Data Channel MTU parms [ L:1560 D:1450 EF:28 EB:135 ET:32 EL:0 AF:14/28 ]
Tue Feb 19 19:38:11 2013 us=90082 Local Options String: 'V4,dev-type tap,link-mtu 1560,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,cipher [null-cipher],auth SHA1,keysize 0,key-meth$
Tue Feb 19 19:38:11 2013 us=90094 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1560,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,cipher [null-cipher],auth SHA1,keysize $
Tue Feb 19 19:38:11 2013 us=90130 Local Options hash (VER=V4): '3b1c829a'
Tue Feb 19 19:38:11 2013 us=90147 Expected Remote Options hash (VER=V4): '629dd956'
Tue Feb 19 19:38:11 2013 us=90180 TCP connection established with [AF_INET]109.87.158.51:49696
Tue Feb 19 19:38:11 2013 us=90194 TCPv4_SERVER link local: [undef]
Tue Feb 19 19:38:11 2013 us=90206 TCPv4_SERVER link remote: [AF_INET]109.87.158.51:49696
Tue Feb 19 19:38:11 2013 us=90380 109.87.158.51:49696 TLS: Initial packet from [AF_INET]109.87.158.51:49696, sid=90ae099f efd8cd96
Tue Feb 19 19:38:11 2013 us=230072 109.87.158.51:49696 VERIFY OK: depth=1, /C=UA/ST=CR/L=Simferopol/O=TNU/OU=server/CN=Server/name=server/emailAddress=123@mail.ru
Tue Feb 19 19:38:11 2013 us=230239 109.87.158.51:49696 VERIFY OK: depth=0, /C=UA/ST=CR/L=Simferopol/O=TNU/OU=server/CN=client1/name=server/emailAddress=123@mail.ru
Tue Feb 19 19:38:11 2013 us=434403 109.87.158.51:49696 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb 19 19:38:11 2013 us=434439 109.87.158.51:49696 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb 19 19:38:11 2013 us=681058 109.87.158.51:49696 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Feb 19 19:38:11 2013 us=681105 109.87.158.51:49696 [client1] Peer Connection Initiated with [AF_INET]109.87.158.51:49696
Tue Feb 19 19:38:11 2013 us=681148 client1/109.87.158.51:49696 MULTI_sva: pool returned IPv4=10.10.11.4, IPv6=1::1b00:0:427f:0
Tue Feb 19 19:38:12 2013 us=706878 client1/109.87.158.51:49696 PUSH: Received control message: 'PUSH_REQUEST'
Tue Feb 19 19:38:12 2013 us=706913 client1/109.87.158.51:49696 send_push_reply(): safe_cap=960
Tue Feb 19 19:38:12 2013 us=706950 client1/109.87.158.51:49696 SENT CONTROL [client1]: 'PUSH_REPLY,dhcp-option DNS 109.86.2.2,dhcp-option DNS 109.86.2.21,redirect-gateway,route-$
Tue Feb 19 19:38:12 2013 us=953159 client1/109.87.158.51:49696 MULTI: Learn: 00:ff:2c:cc:a3:45 -> client1/109.87.158.51:49696

Лог клиента

Tue Feb 19 19:38:10 2013 Warning: cannot open --log file: /var/log/openvpn.log: Системе не удается найти указанный путь.   (errno=3)
Tue Feb 19 19:38:10 2013 OpenVPN 2.0.9 Win32-MinGW [sSL] [LZO] built on Oct  1 2006
Tue Feb 19 19:38:10 2013 ******* WARNING *******: null cipher specified, no encryption will be used
Tue Feb 19 19:38:10 2013 LZO compression initialized
Tue Feb 19 19:38:10 2013 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Tue Feb 19 19:38:10 2013 Data Channel MTU parms [ L:1560 D:1450 EF:28 EB:135 ET:32 EL:0 AF:14/28 ]
Tue Feb 19 19:38:10 2013 Local Options hash (VER=V4): '629dd956'
Tue Feb 19 19:38:10 2013 Expected Remote Options hash (VER=V4): '3b1c829a'
Tue Feb 19 19:38:10 2013 Attempting to establish TCP connection with 109.87.158.138:1194
Tue Feb 19 19:38:11 2013 TCP connection established with 109.87.158.138:1194
Tue Feb 19 19:38:11 2013 TCPv4_CLIENT link local: [undef]
Tue Feb 19 19:38:11 2013 TCPv4_CLIENT link remote: 109.87.158.138:1194
Tue Feb 19 19:38:11 2013 TLS: Initial packet from 109.87.158.138:1194, sid=200faa9e 46e91083
Tue Feb 19 19:38:11 2013 VERIFY OK: depth=1, /C=UA/ST=CR/L=Simferopol/O=TNU/OU=server/CN=Server/name=server/emailAddress=123@mail.ru
Tue Feb 19 19:38:11 2013 VERIFY OK: nsCertType=SERVER
Tue Feb 19 19:38:11 2013 VERIFY OK: depth=0, /C=UA/ST=CR/L=Simferopol/O=TNU/OU=server/CN=server/name=server/emailAddress=123@mail.ru
Tue Feb 19 19:38:11 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb 19 19:38:11 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb 19 19:38:11 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Feb 19 19:38:11 2013 [server] Peer Connection Initiated with 109.87.158.138:1194
Tue Feb 19 19:38:12 2013 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Tue Feb 19 19:38:12 2013 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 109.86.2.2,dhcp-option DNS 109.86.2.21,redirect-gateway,route-gateway 10.10.11.1,route-gateway 10.10.11.0,ping 10,ping-restart 120,ifconfig 10.10.11.4 255.255.255.0'
Tue Feb 19 19:38:12 2013 OPTIONS IMPORT: timers and/or timeouts modified
Tue Feb 19 19:38:12 2013 OPTIONS IMPORT: --ifconfig/up options modified
Tue Feb 19 19:38:12 2013 OPTIONS IMPORT: route options modified
Tue Feb 19 19:38:12 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Feb 19 19:38:12 2013 TAP-WIN32 device [Подключение по локальной сети 2] opened: \\.\Global\{2CCCA345-C20A-4601-9254-D3B1A8087ADF}.tap
Tue Feb 19 19:38:12 2013 TAP-Win32 Driver Version 8.4 
Tue Feb 19 19:38:12 2013 TAP-Win32 MTU=1500
Tue Feb 19 19:38:12 2013 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.10.11.4/255.255.255.0 on interface {2CCCA345-C20A-4601-9254-D3B1A8087ADF} [DHCP-serv: 10.10.11.0, lease-time: 31536000]
Tue Feb 19 19:38:12 2013 Successful ARP Flush on interface [16] {2CCCA345-C20A-4601-9254-D3B1A8087ADF}
Tue Feb 19 19:38:12 2013 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Feb 19 19:38:12 2013 Route: Waiting for TUN/TAP interface to come up...
Tue Feb 19 19:38:13 2013 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Tue Feb 19 19:38:13 2013 route ADD 109.87.158.138 MASK 255.255.255.255 192.168.7.14
Tue Feb 19 19:38:13 2013 ROUTE: route addition failed using CreateIpForwardEntry: Неверны один или несколько аргументов.   [if_index=11]
Tue Feb 19 19:38:13 2013 Route addition via IPAPI failed
Tue Feb 19 19:38:13 2013 route DELETE 0.0.0.0 MASK 0.0.0.0 192.168.7.14
Tue Feb 19 19:38:13 2013 Route deletion via IPAPI succeeded
Tue Feb 19 19:38:13 2013 route ADD 0.0.0.0 MASK 0.0.0.0 10.10.11.0
Tue Feb 19 19:38:13 2013 ROUTE: route addition failed using CreateIpForwardEntry: Неверны один или несколько аргументов.   [if_index=16]
Tue Feb 19 19:38:13 2013 Route addition via IPAPI failed
Tue Feb 19 19:38:13 2013 Initialization Sequence Completed
Tue Feb 19 19:38:31 2013 write TCPv4_CLIENT: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Feb 19 19:38:31 2013 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Tue Feb 19 19:38:31 2013 Connection reset, restarting [-1]
Tue Feb 19 19:38:31 2013 TCP/UDP: Closing socket
Tue Feb 19 19:38:31 2013 SIGUSR1[soft,connection-reset] received, process restarting
Tue Feb 19 19:38:31 2013 Restart pause, 5 second(s)
Tue Feb 19 19:38:36 2013 Re-using SSL/TLS context
Tue Feb 19 19:38:36 2013 LZO compression initialized
Tue Feb 19 19:38:36 2013 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Tue Feb 19 19:38:36 2013 Data Channel MTU parms [ L:1560 D:1450 EF:28 EB:135 ET:32 EL:0 AF:14/28 ]
Tue Feb 19 19:38:36 2013 Local Options hash (VER=V4): '629dd956'
Tue Feb 19 19:38:36 2013 Expected Remote Options hash (VER=V4): '3b1c829a'
Tue Feb 19 19:38:36 2013 Attempting to establish TCP connection with 109.87.158.138:1194
Tue Feb 19 19:38:36 2013 TCP: connect to 109.87.158.138:1194 failed, will try again in 5 seconds
Tue Feb 19 19:38:41 2013 TCP/UDP: Closing socket
Tue Feb 19 19:38:41 2013 route DELETE 109.87.158.138 MASK 255.255.255.255 192.168.7.14
Tue Feb 19 19:38:41 2013 ROUTE: route deletion failed using DeleteIpForwardEntry: Элемент не найден.  
Tue Feb 19 19:38:41 2013 Route deletion via IPAPI failed
Tue Feb 19 19:38:41 2013 route DELETE 0.0.0.0 MASK 0.0.0.0 10.10.11.0
Tue Feb 19 19:38:41 2013 ROUTE: route deletion failed using DeleteIpForwardEntry: Элемент не найден.  
Tue Feb 19 19:38:41 2013 Route deletion via IPAPI failed
Tue Feb 19 19:38:41 2013 route ADD 0.0.0.0 MASK 0.0.0.0 192.168.7.14
Tue Feb 19 19:38:41 2013 ROUTE: route addition failed using CreateIpForwardEntry: Неверны один или несколько аргументов.   [if_index=11]
Tue Feb 19 19:38:41 2013 Route addition via IPAPI failed
Tue Feb 19 19:38:41 2013 Closing TUN/TAP interface
Tue Feb 19 19:38:41 2013 SIGTERM[hard,init_instance] received, process exiting

Заметил ещё такую особенность - добавление опции redirect-gateway def1 делает такую каку: шлюз по умолчанию сбивается и инет вообще не работает никак, разрыв коннекта с OpenVPN ничего не возращает на место, а приходится лишь вручную перезапускать интерфейс.

Очень прошу помощи форумчан.

P.S. из настроек принципиально лишь то, чтоб остался протокол TCP, т.к. клиент, ради которого вся операция делается, выходит в инет через проксю.

Share this post


Link to post
Share on other sites

как минимум неправильно в конфиге

server-bridge 10.10.11.0 255.255.255.0

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

Share this post


Link to post
Share on other sites

А вы вручную для начала route add сделайте

Спасибо за ответ. Делал я такую шляпу. На клиенте прописывал route add -p 0.0.0.0 mask 0.0.0.0 10.10.11.1 metric 1 (пробовал и без метрики) - тода вообще не работает интернет, т.е. видимо трафик пытается завернуться через новый шлюз, но не получается.

agr

Спасибо за ответ. В связи с этим возник вопрос - этим адресом должен быть ip OpneVPN-сервера? Если да, то какой - реальный внешний или же 10.10.11.1?

Share this post


Link to post
Share on other sites

В связи с этим возник вопрос - этим адресом должен быть ip OpneVPN-сервера? Если да, то какой - реальный внешний или же 10.10.11.1?

Если используете tap, то вы должны были настроить bridge на сервере, это адрес bridge интерфейса. Вы bridge настроили?

 

На клиенте прописывал route add -p 0.0.0.0 mask 0.0.0.0 10.10.11.1 metric 1 (пробовал и без метрики) - тода вообще не работает интернет, т.е. видимо трафик пытается завернуться через новый шлюз, но не получается.

нужен еще отдельный маршрут к самому vpn серверу через старый шлюз, иначе тунель не будет работать.

Share this post


Link to post
Share on other sites

agr

Спасибо за уже оказанную помощь.

Я решил отказаться от bridge (изменил в сервере эту строку на server 10.10.11.0 255.255.255.0). Когда по tap делаю, то просто трафик не идёт через новый шлюз (роут к vpn-серверу добавил), сам сервер по виртуальному адресу (10.10.11.1) не пингуется. Когда делаю через tun, то коннекта нет и лог на клиенте сыпет

Thu Feb 21 19:03:16 2013 TEST ROUTES: 0/3 succeeded len=2 ret=0 a=0 u/d=up
Thu Feb 21 19:03:16 2013 Route: Waiting for TUN/TAP interface to come up...

В чём дело и куда рыть?

Share this post


Link to post
Share on other sites

Читать мануалы.

http://forum.ixbt.com/topic.cgi?id=14:40906#1 очень доходчиво написано.

 

И так, для справки, а что у сервера время вдруг с 16:00 на 19:38 перескочило?

Share this post


Link to post
Share on other sites

Когда делаю через tun, то коннекта нет и лог на клиенте сыпет

а на клиенте то tap на tun поменяли?

Share this post


Link to post
Share on other sites

Добрый день. Спасибо огромное за ппомощь и наводку на роуты. Проблема решилась указанием "route-method exe". Теперь всё с полпинка.

Теперь второстепенный вопрос:

Имеем клиента за прокси, который после перезагрузки отлично коннектиться к моему серверу (tap по tcp на порт 443). Однако стОит лишь перевести машину в гибернацию, как по выходу из неё коннект пропадает и не восстанавливается никакими силами. Даже не пытается что-либо сделать, просто пишет "ошибка подключения к client" (т.е. к названию профиля). При этом весь системный журнал содержит лишь эти записи:

 

Mon Feb 25 11:39:25 2013 OpenVPN 2.3.0 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [iPv6] built on Feb 14 2013
Enter Management Password:
Mon Feb 25 11:39:25 2013 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Feb 25 11:39:25 2013 Need hold release from management interface, waiting...
Mon Feb 25 11:39:25 2013 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Feb 25 11:39:25 2013 MANAGEMENT: CMD 'state on'
Mon Feb 25 11:39:25 2013 MANAGEMENT: CMD 'log all on'
Mon Feb 25 11:39:25 2013 MANAGEMENT: CMD 'hold off'
Mon Feb 25 11:39:25 2013 MANAGEMENT: CMD 'hold release'
Mon Feb 25 11:39:46 2013 MANAGEMENT: Client disconnected
Mon Feb 25 12:02:21 2013 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340

 

Перезагрузка всё решает, однако простое включение/отключение tap-интерфейса не помогает.

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

Share this post


Link to post
Share on other sites

To serulya.

Пожалуйста определитесь с тем что вы хотите от openvpn и для чего он вам нужен. tun и tap тоннели принципиально разные и предназначены для разных целей.

Если Вы хотите просто ВПН сервер для доступа сотрудников к сети предприятия, то мануалов о том как это сделать более чем предостаточно.

Например:

http://snow-leo.blogspot.ru/2010/06/openvpn-tun.html

http://snow-leo.blogspot.ru/2013/01/openvpn-site-to-site.html

 

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

Share this post


Link to post
Share on other sites

sn0wle0

Хотелось бы предоставить человечку доступ в интернет, что уже реализовано и работает. Но выше описал проблему, возникующую при выходе из сна или гибернации.

Share this post


Link to post
Share on other sites

Если можно, помогите

Конфиг сервера

dev-node "ServerVPN"
mode server
port 55555
dev tap
proto tcp-server
tls-server
tls-auth C:\\OpenVPN\\config\\ta.key 0
duplicate-cn
auth MD5
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ca "C:\\OpenVPN\\config\\Server\\ca.crt"
cert "C:\\OpenVPN\\config\\Server\\ServerVPN.crt"
key "C:\\OpenVPN\\config\\Server\\ServerVPN.key"
dh "C:\\OpenVPN\\config\\Server\\dh2048.pem"
server 10.10.10.0 255.255.255.0
client-to-client
keepalive 10 120
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
verb 3
route-delay 10
route-method exe
route 10.10.10.0 255.255.255.0
route 192.168.0.0 255.255.255.0
route-gateway 10.10.10.1
push "route 192.168.2.0 255.255.255.0"

конфиг клиента

dev-node "ClientVPN"
remote 31.31.18.138
client
port 55555
dev tap
proto tcp-server
tls-client
tls-auth C:\\OpenVPN\\config\\ta.key 1
remote-cert-tls server
route-delay 2
auth MD5
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ca ca.crt
cert mike.crt
key mike.key
pull
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
verb 3
route-method exe
route-delay 3

лог сервера

Tue Jun 18 15:02:08 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Tue Jun 18 15:02:08 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Jun 18 15:02:08 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Enter Management Password:
Tue Jun 18 15:02:08 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Tue Jun 18 15:02:08 2019 Need hold release from management interface, waiting...
Tue Jun 18 15:02:08 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue Jun 18 15:02:08 2019 MANAGEMENT: CMD 'state on'
Tue Jun 18 15:02:08 2019 MANAGEMENT: CMD 'log all on'
Tue Jun 18 15:02:08 2019 MANAGEMENT: CMD 'echo all on'
Tue Jun 18 15:02:08 2019 MANAGEMENT: CMD 'bytecount 5'
Tue Jun 18 15:02:08 2019 MANAGEMENT: CMD 'hold off'
Tue Jun 18 15:02:08 2019 MANAGEMENT: CMD 'hold release'
Tue Jun 18 15:02:08 2019 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Tue Jun 18 15:02:08 2019 Diffie-Hellman initialized with 2048 bit key
Tue Jun 18 15:02:08 2019 Outgoing Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Tue Jun 18 15:02:08 2019 Incoming Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Tue Jun 18 15:02:08 2019 interactive service msg_channel=0
Tue Jun 18 15:02:08 2019 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=6 HWADDR=14:da:e9:01:1d:e2
Tue Jun 18 15:02:08 2019 open_tun
Tue Jun 18 15:02:08 2019 TAP-WIN32 device [ServerVPN] opened: \\.\Global\{203643F4-60F8-40F4-A281-94B5A6DE297A}.tap
Tue Jun 18 15:02:08 2019 TAP-Windows Driver Version 9.23 
Tue Jun 18 15:02:08 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.10.10.1/255.255.255.0 on interface {203643F4-60F8-40F4-A281-94B5A6DE297A} [DHCP-serv: 10.10.10.0, lease-time: 31536000]
Tue Jun 18 15:02:08 2019 Sleeping for 10 seconds...
Tue Jun 18 15:02:18 2019 Successful ARP Flush on interface [5] {203643F4-60F8-40F4-A281-94B5A6DE297A}
Tue Jun 18 15:02:18 2019 MANAGEMENT: >STATE:1560859338,ASSIGN_IP,,10.10.10.1,,,,
Tue Jun 18 15:02:18 2019 MANAGEMENT: >STATE:1560859338,ADD_ROUTES,,,,,,
Tue Jun 18 15:02:18 2019 C:\Windows\system32\route.exe ADD 10.10.10.0 MASK 255.255.255.0 10.10.10.1
Tue Jun 18 15:02:18 2019 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem
Tue Jun 18 15:02:18 2019 C:\Windows\system32\route.exe ADD 192.168.0.0 MASK 255.255.255.0 10.10.10.1
Tue Jun 18 15:02:18 2019 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem
Tue Jun 18 15:02:18 2019 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Tue Jun 18 15:02:18 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Tue Jun 18 15:02:18 2019 setsockopt(IPV6_V6ONLY=0)
Tue Jun 18 15:02:18 2019 Listening for incoming TCP connection on [AF_INET6][undef]:55555
Tue Jun 18 15:02:18 2019 TCPv6_SERVER link local (bound): [AF_INET6][undef]:55555
Tue Jun 18 15:02:18 2019 TCPv6_SERVER link remote: [AF_UNSPEC]
Tue Jun 18 15:02:18 2019 MULTI: multi_init called, r=256 v=256
Tue Jun 18 15:02:18 2019 IFCONFIG POOL: base=10.10.10.2 size=253, ipv6=0
Tue Jun 18 15:02:18 2019 MULTI: TCP INIT maxclients=60 maxevents=64
Tue Jun 18 15:02:18 2019 Initialization Sequence Completed
Tue Jun 18 15:02:18 2019 MANAGEMENT: >STATE:1560859338,CONNECTED,SUCCESS,10.10.10.1,,,,

Сервер подключается все в порядке! Внизу зеленым горит мониторчик.

 

лог клиента

Tue Jun 18 15:04:35 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Tue Jun 18 15:04:35 2019 Windows version 6.1 (Windows 7) 64bit
Tue Jun 18 15:04:35 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Enter Management Password:
Tue Jun 18 15:04:35 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Tue Jun 18 15:04:35 2019 Need hold release from management interface, waiting...
Tue Jun 18 15:04:36 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue Jun 18 15:04:36 2019 MANAGEMENT: CMD 'state on'
Tue Jun 18 15:04:36 2019 MANAGEMENT: CMD 'log all on'
Tue Jun 18 15:04:36 2019 MANAGEMENT: CMD 'echo all on'
Tue Jun 18 15:04:36 2019 MANAGEMENT: CMD 'bytecount 5'
Tue Jun 18 15:04:36 2019 MANAGEMENT: CMD 'hold off'
Tue Jun 18 15:04:36 2019 MANAGEMENT: CMD 'hold release'
Tue Jun 18 15:04:36 2019 Outgoing Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Tue Jun 18 15:04:36 2019 Incoming Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Tue Jun 18 15:04:36 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]31.31.18.138:55555
Tue Jun 18 15:04:36 2019 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Jun 18 15:04:36 2019 Listening for incoming TCP connection on [AF_INET6][undef]:55555

И все, больше ничего не происходит...

На клиенте мониторчик остается желтым...

 

Подскажите пожалуйста что это может быть за ошибка?

 

На стороне сервера на роутере, который подключается к оператору связи пробросил порт 55555. В Брандмауэре сделал исключение для программы openvpn.exe и на стороне сервера и на стороне клиента.

Share this post


Link to post
Share on other sites

проверьте, что брандмауэр Windows разрешает трафик, как на сервере, так и на клиенте. 

 

3 минуты назад, Mike84 сказал:

Listening for incoming TCP connection on [AF_INET6][undef]:55555

 

На клиенте выключите IPv6.

Share this post


Link to post
Share on other sites
8 минут назад, jffulcrum сказал:

проверьте, что брандмауэр Windows разрешает трафик, как на сервере, так и на клиенте.

как это правильно сделать?

 

8 минут назад, jffulcrum сказал:

На клиенте выключите IPv6.

Отключил, путем снятия галочки image.thumb.png.e364b2ffd52eecb79792441400e46c0d.png

Пока тоже самое...

Edited by Mike84

Share this post


Link to post
Share on other sites
1 минуту назад, Mike84 сказал:

как это правильно сделать?

Панель управления - Администрирование - Брандумаэр Windows в режиме повышенной безопасности - Входящие . Должно быть правило для OpenVPN, либо для программы, либо просто разрешающее определенные соединения (в вашем случае - TCP, порт 55555)

 

20 минут назад, Mike84 сказал:

конфиг клиента


dev-node "ClientVPN"
remote 31.31.18.138
client
port 55555
dev tap
proto tcp-server

Что-то мне подсказывает, что proto должно быть tcp-client или просто tcp

Share this post


Link to post
Share on other sites
8 минут назад, jffulcrum сказал:

Панель управления - Администрирование - Брандумаэр Windows в режиме повышенной безопасности - Входящие . Должно быть правило для OpenVPN, либо для программы, либо просто разрешающее определенные соединения (в вашем случае - TCP, порт 55555)

Такое правило я создал image.thumb.png.4febb7413fd175c6f21abf10f2b6b68c.pngimage.thumb.png.3b626e6510f0ccef72055b207ce50ffd.png.

 

11 минут назад, jffulcrum сказал:

Что-то мне подсказывает, что proto должно быть tcp-client или просто tcp

Спасибо, попробую!

 

Отлично!!! Сделал вот так! image.png.8aed0b0b89ee1e3f26eb7436722a6d92.png и Все подключилось!!! СПАСИБО!!!

Share this post


Link to post
Share on other sites

Т.е. получается у меня сам Сервер находится на компьютере с Windows 10, Клиент на компьютере с Windows 7. Теперь Хочу подключится со Смартфона с Android. Для этого отключаю Клиента на компьютере, потом копирую файлы mike.key; mike.crt; ca.crt; СlientVPN.ovpn; ta.key с клиентского компьютера на телефон. Устанавливаю на телефоне программу OpenVPN Connect. 

Дается на выбор: 1. Connect to VPNCloud. 2. Connect to VPN Server. 3. Connect with .ovpn file.

Я выбираю последнее (Connect with .ovpn file), ищу и указываю на файл в телефоне СlientVPN.ovpn. Но программа не подключается... Не знаю и почему...

Share this post


Link to post
Share on other sites

То есть вы в лоб скопировали конфиг с компа? Сильно. Снова цитируем:

 

22 часа назад, Mike84 сказал:

конфиг клиента


dev-node "ClientVPN"
remote 31.31.18.138
client
port 55555
dev tap

Может что-то и поменялось, но на НЕ-рутованном телефоне режим TAP у OpenVPN не работает. Работает режим TUN

Share this post


Link to post
Share on other sites
39 минут назад, jffulcrum сказал:

Может что-то и поменялось, но на НЕ-рутованном телефоне режим TAP у OpenVPN не работает. Работает режим TUN

Спасибо! изменил в обоих конфигах на tun и телефончик подключился!

Но сколько не читал, толком не могу понять...

1. Компьютер с клиентским VPN в режиме tun не видит сетевые папки компьютера-сервера... И также компьютер-клиент как был под одним внешним ip, и после подключения к vpn так под ним и сидит... Т.е получается, что у компьютера клиентского формируется два канала, тот, который и был до подключения и + vpn к компьютеру сервера. Т.е. клиент после подключения к vpn становится в локалке с компьютером-сервером? но почему тогда он не видит папки общего доступа?

Т.е. Что происходит с компьютером (какие возможности открываются), когда он подключается в режиме tun к сети vpn? или также, но в режиме tap?

2. Когда телефон подключается в режиме tun к сети vpn, какие возможности у него открываются?

 

Мне изначально нужно, чтобы все устройства, подключаемые к Серверу VPN находились в одной локальной сети и выходили в сеть только через машину-сервер. Но пока этого не получается, т.к. у клиента так и остался после подключения к сети vpb тот его старый внешний ip адрес.

 

Share this post


Link to post
Share on other sites

В режиме tun

ip компьютера-сервера 192.168.1.102, его ip в vpn сети 10.10.10.1

ip компьютера-клиента 192.168.0.254, его ip в vpn сети 10.10.10.6

 

с обоих сторон мониторчики зеленые горят, т.е. vpn вроде как поднялся.

 

Со стороны сервера 10.10.10.6 не пингуется и наоборот со стороны клиента сервер 10.10.10.1 тоже не пингуется...

---------------------------------------------------------------------------------------------------------------------------------------------

В режиме tap

ip компьютера-сервера 192.168.1.102, его ip в vpn сети 10.10.10.1

ip компьютера-клиента 192.168.0.254, его ip в vpn сети 10.10.10.2

 

с обоих сторон мониторчики зеленые горят, т.е. vpn вроде как поднялся.

 

Со стороны сервера клиент 10.10.10.2 пингуется и наоборот со стороны клиента сервер 10.10.10.1 тоже пингуется...

Edited by Mike84
забыл дописать

Share this post


Link to post
Share on other sites
2 часа назад, Mike84 сказал:

Мне изначально нужно, чтобы все устройства, подключаемые к Серверу VPN находились в одной локальной сети и выходили в сеть только через машину-сервер. Но пока этого не получается, т.к. у клиента так и остался после подключения к сети vpb тот его старый внешний ip адрес.

Для этого клиенту надо "скормить" шлюз по-умолчанию на стороне сервера. Например, через опцию сервера:

 

push "redirect-gateway def1"

 

При этом на сервере надо либо бриджевать, либо маршрутизировать на вышестоящий роутер, либо NAT`ить интерфейсы клиентов (через ICS, если у нас Windows). Конфигурации для каждого случая будут отличаться.

 

Для бриджа используется режим TAP. Для маршрутизации или NAT - TUN. Если без телефонов не обойтись, то надо смотреть, как у вас компьютер-сервер выходит в Интернет. Если телефонов нет, то проще бриджевать, см. https://openvpn.net/community-resources/ethernet-bridging/ . Конфиг сервера придется слегка переписать. Это также, возможно, решит проблему доступа к сетевым папкам сервера.

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this