Здравствуйте!
Подскажите по OpenVPN
Есть 2 компа на Win 10 (Прости Господи!)
При попытке подключения с одного к другому вылетает такая ошибка:
VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=RU, ST=Moscow, L=Moscow, O=Organization, OU=*****.ddns.net, CN=KEYCN, name=KEYNAME, emailAddress=***@***.ru
Конфиг клиента:
client
dev tun
cipher AES-256-CBC
proto tcp
remote ddddd.ddns.net 41416
resolv-retry 30
verb 3
ca ca.crt
cert user1.crt
key user1.key Конфиг сервера:
proto tcp
port 41416
dev tun
dev-node "VPN Server"
dh "C:\Program Files\OpenVPN\ssl\dh1024.pem"
ca "C:\Program Files\OpenVPN\ssl\ca.crt"
cert "C:\Program Files\OpenVPN\ssl\cert.crt"
key "C:\Program Files\OpenVPN\ssl\cert.key"
server 192.168.5.0 255.255.255.0
max-clients 32
keepalive 10 120
client-to-client
mssfix 0
cipher AES-256-CBC
status "C:\Program Files\OpenVPN\log\status.log"
log "C:\Program Files\OpenVPN\log\openvpn.log"
verb 5
mute 5Лог на клиенте:
Sun Nov 26 19:22:05 2017 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Sun Nov 26 19:22:05 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Sun Nov 26 19:22:05 2017 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Enter Management Password:
Sun Nov 26 19:22:05 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun Nov 26 19:22:05 2017 Need hold release from management interface, waiting...
Sun Nov 26 19:22:06 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun Nov 26 19:22:06 2017 MANAGEMENT: CMD 'state on'
Sun Nov 26 19:22:06 2017 MANAGEMENT: CMD 'log all on'
Sun Nov 26 19:22:06 2017 MANAGEMENT: CMD 'echo all on'
Sun Nov 26 19:22:06 2017 MANAGEMENT: CMD 'hold off'
Sun Nov 26 19:22:06 2017 MANAGEMENT: CMD 'hold release'
Sun Nov 26 19:22:06 2017 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sun Nov 26 19:22:06 2017 MANAGEMENT: >STATE:1511713326,RESOLVE,,,,,,
Sun Nov 26 19:22:06 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]176.112.97.163:41416
Sun Nov 26 19:22:06 2017 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Nov 26 19:22:06 2017 Attempting to establish TCP connection with [AF_INET]176.112.97.163:41416 [nonblock]
Sun Nov 26 19:22:06 2017 MANAGEMENT: >STATE:1511713326,TCP_CONNECT,,,,,,
Sun Nov 26 19:22:07 2017 TCP connection established with [AF_INET]176.112.97.163:41416
Sun Nov 26 19:22:07 2017 TCP_CLIENT link local: (not bound)
Sun Nov 26 19:22:07 2017 TCP_CLIENT link remote: [AF_INET]176.112.97.163:41416
Sun Nov 26 19:22:07 2017 MANAGEMENT: >STATE:1511713327,WAIT,,,,,,
Sun Nov 26 19:22:07 2017 MANAGEMENT: >STATE:1511713327,AUTH,,,,,,
Sun Nov 26 19:22:07 2017 TLS: Initial packet from [AF_INET]176.112.97.163:41416, sid=770063ff 0f47046b
Sun Nov 26 19:22:07 2017 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=RU, ST=Moscow, L=Moscow, O=Organization, OU=*****.ddns.net, CN=KEYCN, name=KEYNAME, emailAddress=***@***.ru
Sun Nov 26 19:22:07 2017 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Sun Nov 26 19:22:07 2017 TLS_ERROR: BIO read tls_read_plaintext error
Sun Nov 26 19:22:07 2017 TLS Error: TLS object -> incoming plaintext read error
Sun Nov 26 19:22:07 2017 TLS Error: TLS handshake failed
Sun Nov 26 19:22:07 2017 Fatal TLS error (check_tls_errors_co), restarting
Sun Nov 26 19:22:07 2017 SIGUSR1[soft,tls-error] received, process restarting
Sun Nov 26 19:22:07 2017 MANAGEMENT: >STATE:1511713327,RECONNECTING,tls-error,,,,,
Sun Nov 26 19:22:07 2017 Restart pause, 5 second(s)
Sun Nov 26 19:22:09 2017 SIGTERM[hard,init_instance] received, process exiting
Sun Nov 26 19:22:09 2017 MANAGEMENT: >STATE:1511713329,EXITING,init_instance,,,,,
Лог на сервере:
Sun Nov 26 19:21:02 2017 us=793798 Current Parameter Settings:
Sun Nov 26 19:21:02 2017 us=793798 config = 'C:Program FilesOpenVPNconfigserver.ovpn'
Sun Nov 26 19:21:02 2017 us=793798 mode = 1
Sun Nov 26 19:21:02 2017 us=793798 show_ciphers = DISABLED
Sun Nov 26 19:21:02 2017 us=793798 show_digests = DISABLED
Sun Nov 26 19:21:02 2017 us=793798 NOTE: --mute triggered...
Sun Nov 26 19:21:02 2017 us=793798 291 variation(s) on previous 5 message(s) suppressed by --mute
Sun Nov 26 19:21:02 2017 us=793798 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Sun Nov 26 19:21:02 2017 us=793798 Windows version 6.2 (Windows 8 or greater) 64bit
Sun Nov 26 19:21:02 2017 us=793798 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Sun Nov 26 19:21:02 2017 us=793798 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.
Sun Nov 26 19:21:02 2017 us=887552 Diffie-Hellman initialized with 1024 bit key
Sun Nov 26 19:21:02 2017 us=903178 TLS-Auth MTU parms [ L:1623 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Sun Nov 26 19:21:02 2017 us=903178 interactive service msg_channel=0
Sun Nov 26 19:21:02 2017 us=903178 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 I=7 HWADDR=90:2b:34:15:fd:6c
Sun Nov 26 19:21:02 2017 us=903178 open_tun
Sun Nov 26 19:21:02 2017 us=903178 TAP-WIN32 device [VPN Server] opened: \.Global{D07C10C5-1417-4AEF-A456-7B1ACB4CE04F}.tap
Sun Nov 26 19:21:02 2017 us=903178 TAP-Windows Driver Version 9.21
Sun Nov 26 19:21:02 2017 us=903178 TAP-Windows MTU=1500
Sun Nov 26 19:21:02 2017 us=903178 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.5.1/255.255.255.252 on interface {D07C10C5-1417-4AEF-A456-7B1ACB4CE04F} [DHCP-serv: 192.168.5.2, lease-time: 31536000]
Sun Nov 26 19:21:02 2017 us=903178 Sleeping for 10 seconds...
Sun Nov 26 19:21:12 2017 us=912500 Successful ARP Flush on interface [9] {D07C10C5-1417-4AEF-A456-7B1ACB4CE04F}
Sun Nov 26 19:21:12 2017 us=912500 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Nov 26 19:21:12 2017 us=912500 C:WINDOWSsystem32route.exe ADD 192.168.5.0 MASK 255.255.255.0 192.168.5.2
Sun Nov 26 19:21:12 2017 us=912500 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Sun Nov 26 19:21:12 2017 us=912500 Route addition via IPAPI succeeded [adaptive]
Sun Nov 26 19:21:12 2017 us=912500 Data Channel MTU parms [ L:1623 D:1623 EF:123 EB:406 ET:0 EL:3 ]
Sun Nov 26 19:21:12 2017 us=912500 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Sun Nov 26 19:21:12 2017 us=912500 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Nov 26 19:21:12 2017 us=912500 setsockopt(IPV6_V6ONLY=0)
Sun Nov 26 19:21:12 2017 us=912500 Listening for incoming TCP connection on [AF_INET6][undef]:41416
Sun Nov 26 19:21:12 2017 us=912500 TCPv6_SERVER link local (bound): [AF_INET6][undef]:41416
Sun Nov 26 19:21:12 2017 us=912500 TCPv6_SERVER link remote: [AF_UNSPEC]
Sun Nov 26 19:21:12 2017 us=912500 MULTI: multi_init called, r=256 v=256
Sun Nov 26 19:21:12 2017 us=912500 IFCONFIG POOL: base=192.168.5.4 size=62, ipv6=0
Sun Nov 26 19:21:12 2017 us=912500 MULTI: TCP INIT maxclients=32 maxevents=36
Sun Nov 26 19:21:12 2017 us=912500 Initialization Sequence Completed
Sun Nov 26 19:22:07 2017 us=643519 MULTI: multi_create_instance called
Sun Nov 26 19:22:07 2017 us=643519 Re-using SSL/TLS context
Sun Nov 26 19:22:07 2017 us=643519 Control Channel MTU parms [ L:1623 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Sun Nov 26 19:22:07 2017 us=643519 Data Channel MTU parms [ L:1623 D:1623 EF:123 EB:406 ET:0 EL:3 ]
Sun Nov 26 19:22:07 2017 us=643519 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1559,tun-mtu 1500,proto TCPv4_SERVER,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Sun Nov 26 19:22:07 2017 us=643519 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1559,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Sun Nov 26 19:22:07 2017 us=643519 TCP connection established with [AF_INET6]::ffff:79.126.13.128:57395
Sun Nov 26 19:22:07 2017 us=643519 TCPv6_SERVER link local: (not bound)
Sun Nov 26 19:22:07 2017 us=643519 TCPv6_SERVER link remote: [AF_INET6]::ffff:79.126.13.128:57395
Sun Nov 26 19:22:08 2017 us=621530 79.126.13.128 TLS: Initial packet from [AF_INET6]::ffff:79.126.13.128:57395, sid=88d68a0a f9b71958
Sun Nov 26 19:22:08 2017 us=919980 79.126.13.128 Connection reset, restarting [0]
Sun Nov 26 19:22:08 2017 us=919980 79.126.13.128 SIGUSR1[soft,connection-reset] received, client-instance restarting
Sun Nov 26 19:22:08 2017 us=919980 TCP/UDP: Closing socket
Да и помогите свернуть код в спойлер, что-то не получилось «cut-/cut»
Here are the log files for both the client and the server.
SERVER
Code: Select all
2012-05-15 22:13:35 *Tunnelblick: OS X 10.7.3; Tunnelblick 3.2.6 (build 2891.3007)
2012-05-15 22:13:35 *Tunnelblick: Attempting connection with server; Set nameserver = 1; monitoring connection
2012-05-15 22:13:35 *Tunnelblick: /Applications/Tunnelblick.app/Contents/Resources/openvpnstart start server.ovpn 1338 1 0 0 0 49 -atDASNGWrdasngw
2012-05-15 22:13:35 *Tunnelblick: openvpnstart: /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.2.1/openvpn --cd /Users/michael/Library/Application Support/Tunnelblick/Configurations --daemon --management 127.0.0.1 1338 --config /Users/michael/Library/Application Support/Tunnelblick/Configurations/server.ovpn --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Smichael-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sserver.ovpn.1_0_0_0_49.1338.openvpn.log --management-query-passwords --management-hold --script-security 2 --up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -atDASNGWrdasngw --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -atDASNGWrdasngw --up-restart
2012-05-15 22:13:36 *Tunnelblick: openvpnstart message: Loading tun.kext
2012-05-15 22:13:36 us=35673 Current Parameter Settings:
2012-05-15 22:13:36 us=35900 config = '/Users/michael/Library/Application Support/Tunnelblick/Configurations/server.ovpn'
2012-05-15 22:13:36 us=35916 mode = 1
2012-05-15 22:13:36 us=35929 show_ciphers = DISABLED
2012-05-15 22:13:36 us=35942 show_digests = DISABLED
2012-05-15 22:13:36 us=35955 show_engines = DISABLED
2012-05-15 22:13:36 us=35968 genkey = DISABLED
2012-05-15 22:13:36 us=35985 key_pass_file = '[UNDEF]'
2012-05-15 22:13:36 us=35999 show_tls_ciphers = DISABLED
2012-05-15 22:13:36 us=36011 Connection profiles [default]:
2012-05-15 22:13:36 us=36024 proto = tcp-server
2012-05-15 22:13:36 us=36037 local = '[UNDEF]'
2012-05-15 22:13:36 us=36050 local_port = 1194
2012-05-15 22:13:36 us=36063 remote = '[UNDEF]'
2012-05-15 22:13:36 us=36076 remote_port = 1194
2012-05-15 22:13:36 us=36089 remote_float = DISABLED
2012-05-15 22:13:36 us=36102 bind_defined = DISABLED
2012-05-15 22:13:36 us=36115 bind_local = ENABLED
2012-05-15 22:13:36 us=36128 connect_retry_seconds = 5
2012-05-15 22:13:36 us=36141 connect_timeout = 10
2012-05-15 22:13:36 us=36154 connect_retry_max = 0
2012-05-15 22:13:36 us=36167 socks_proxy_server = '[UNDEF]'
2012-05-15 22:13:36 us=36180 socks_proxy_port = 0
2012-05-15 22:13:36 us=36192 socks_proxy_retry = DISABLED
2012-05-15 22:13:36 us=36205 Connection profiles END
2012-05-15 22:13:36 us=36218 remote_random = DISABLED
2012-05-15 22:13:36 us=36231 ipchange = '[UNDEF]'
2012-05-15 22:13:36 us=36243 dev = 'tun'
2012-05-15 22:13:36 us=36256 dev_type = '[UNDEF]'
2012-05-15 22:13:36 us=36269 dev_node = '[UNDEF]'
2012-05-15 22:13:36 us=36282 lladdr = '[UNDEF]'
2012-05-15 22:13:36 us=36295 topology = 1
2012-05-15 22:13:36 us=36308 tun_ipv6 = DISABLED
2012-05-15 22:13:36 us=36321 ifconfig_local = '10.10.46.1'
2012-05-15 22:13:36 us=36333 ifconfig_remote_netmask = '10.10.46.2'
2012-05-15 22:13:36 us=36346 ifconfig_noexec = DISABLED
2012-05-15 22:13:36 us=36359 ifconfig_nowarn = DISABLED
2012-05-15 22:13:36 us=36372 shaper = 0
2012-05-15 22:13:36 us=36385 tun_mtu = 1500
2012-05-15 22:13:36 us=36398 tun_mtu_defined = ENABLED
2012-05-15 22:13:36 us=36411 link_mtu = 1500
2012-05-15 22:13:36 us=36424 link_mtu_defined = DISABLED
2012-05-15 22:13:36 us=36436 tun_mtu_extra = 0
2012-05-15 22:13:36 us=36449 tun_mtu_extra_defined = DISABLED
2012-05-15 22:13:36 us=36462 fragment = 0
2012-05-15 22:13:36 us=36475 mtu_discover_type = -1
2012-05-15 22:13:36 us=36488 mtu_test = 0
2012-05-15 22:13:36 us=36501 mlock = DISABLED
2012-05-15 22:13:36 us=36514 keepalive_ping = 10
2012-05-15 22:13:36 us=36526 keepalive_timeout = 120
2012-05-15 22:13:36 us=36539 inactivity_timeout = 0
2012-05-15 22:13:36 us=36552 ping_send_timeout = 10
2012-05-15 22:13:36 us=36565 ping_rec_timeout = 240
2012-05-15 22:13:36 us=36578 ping_rec_timeout_action = 2
2012-05-15 22:13:36 us=36591 ping_timer_remote = DISABLED
2012-05-15 22:13:36 us=36603 remap_sigusr1 = 0
2012-05-15 22:13:36 us=36616 explicit_exit_notification = 0
2012-05-15 22:13:36 us=36629 persist_tun = ENABLED
2012-05-15 22:13:36 us=36642 persist_local_ip = DISABLED
2012-05-15 22:13:36 us=36655 persist_remote_ip = DISABLED
2012-05-15 22:13:36 us=36668 persist_key = ENABLED
2012-05-15 22:13:36 us=36681 mssfix = 1450
2012-05-15 22:13:36 us=36693 passtos = DISABLED
2012-05-15 22:13:36 us=36706 resolve_retry_seconds = 1000000000
2012-05-15 22:13:36 us=36719 username = '[UNDEF]'
2012-05-15 22:13:36 us=36735 groupname = '[UNDEF]'
2012-05-15 22:13:36 us=36748 chroot_dir = '[UNDEF]'
2012-05-15 22:13:36 us=36761 cd_dir = '/Users/michael/Library/Application Support/Tunnelblick/Configurations'
2012-05-15 22:13:36 us=36789 writepid = '[UNDEF]'
2012-05-15 22:13:36 us=36803 up_script = '/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -atDASNGWrdasngw'
2012-05-15 22:13:36 us=36817 down_script = '/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -atDASNGWrdasngw'
2012-05-15 22:13:36 us=36830 down_pre = DISABLED
2012-05-15 22:13:36 us=36842 up_restart = ENABLED
2012-05-15 22:13:36 us=36855 up_delay = DISABLED
2012-05-15 22:13:36 us=36871 daemon = ENABLED
2012-05-15 22:13:36 us=36889 inetd = 0
2012-05-15 22:13:36 us=36902 log = ENABLED
2012-05-15 22:13:36 us=36915 suppress_timestamps = DISABLED
2012-05-15 22:13:36 us=36928 nice = 0
2012-05-15 22:13:36 us=36944 verbosity = 4
2012-05-15 22:13:36 us=36958 mute = 0
2012-05-15 22:13:36 us=36970 gremlin = 0
2012-05-15 22:13:36 us=36983 status_file = 'openvpn-status.log'
2012-05-15 22:13:36 us=36996 status_file_version = 1
2012-05-15 22:13:36 us=37009 status_file_update_freq = 60
2012-05-15 22:13:36 us=37022 occ = ENABLED
2012-05-15 22:13:36 us=37035 rcvbuf = 65536
2012-05-15 22:13:36 us=37047 sndbuf = 65536
2012-05-15 22:13:36 us=37060 sockflags = 0
2012-05-15 22:13:36 us=37077 fast_io = DISABLED
2012-05-15 22:13:36 us=37091 lzo = 7
2012-05-15 22:13:36 us=37104 route_script = '[UNDEF]'
2012-05-15 22:13:36 us=37117 route_default_gateway = '[UNDEF]'
2012-05-15 22:13:36 us=37130 route_default_metric = 0
2012-05-15 22:13:36 us=37143 route_noexec = DISABLED
2012-05-15 22:13:36 us=37155 route_delay = 0
2012-05-15 22:13:36 us=37168 route_delay_window = 30
2012-05-15 22:13:36 us=37181 route_delay_defined = DISABLED
2012-05-15 22:13:36 us=37194 route_nopull = DISABLED
2012-05-15 22:13:36 us=37207 route_gateway_via_dhcp = DISABLED
2012-05-15 22:13:36 us=37220 max_routes = 100
2012-05-15 22:13:36 us=37233 allow_pull_fqdn = DISABLED
2012-05-15 22:13:36 us=37247 route 10.10.46.0/255.255.255.0/nil/nil
2012-05-15 22:13:36 us=37261 management_addr = '127.0.0.1'
2012-05-15 22:13:36 us=37274 management_port = 1338
2012-05-15 22:13:36 us=37287 management_user_pass = '[UNDEF]'
2012-05-15 22:13:36 us=37301 management_log_history_cache = 250
2012-05-15 22:13:36 us=37315 management_echo_buffer_size = 100
2012-05-15 22:13:36 us=37329 management_write_peer_info_file = '[UNDEF]'
2012-05-15 22:13:36 us=37342 management_client_user = '[UNDEF]'
2012-05-15 22:13:36 us=37356 management_client_group = '[UNDEF]'
2012-05-15 22:13:36 us=37369 management_flags = 6
2012-05-15 22:13:36 us=37382 shared_secret_file = '[UNDEF]'
2012-05-15 22:13:36 us=37396 key_direction = 0
2012-05-15 22:13:36 us=37409 ciphername_defined = ENABLED
2012-05-15 22:13:36 us=37422 ciphername = 'BF-CBC'
2012-05-15 22:13:36 us=37436 authname_defined = ENABLED
2012-05-15 22:13:36 us=37449 authname = 'SHA1'
2012-05-15 22:13:36 us=37462 prng_hash = 'SHA1'
2012-05-15 22:13:36 us=37476 prng_nonce_secret_len = 16
2012-05-15 22:13:36 us=37489 keysize = 0
2012-05-15 22:13:36 us=37502 engine = DISABLED
2012-05-15 22:13:36 us=37515 replay = ENABLED
2012-05-15 22:13:36 us=37529 mute_replay_warnings = DISABLED
2012-05-15 22:13:36 us=37542 replay_window = 64
2012-05-15 22:13:36 us=37555 replay_time = 15
2012-05-15 22:13:36 us=37568 packet_id_file = '[UNDEF]'
2012-05-15 22:13:36 us=37582 use_iv = ENABLED
2012-05-15 22:13:36 us=37595 test_crypto = DISABLED
2012-05-15 22:13:36 us=37608 tls_server = ENABLED
2012-05-15 22:13:36 us=37625 tls_client = DISABLED
2012-05-15 22:13:36 us=37638 key_method = 2
2012-05-15 22:13:36 us=37651 ca_file = 'ca.crt'
2012-05-15 22:13:36 us=37665 ca_path = '[UNDEF]'
2012-05-15 22:13:36 us=37678 dh_file = 'dh2048.pem'
2012-05-15 22:13:36 us=37705 cert_file = 'server.crt'
2012-05-15 22:13:36 us=37719 priv_key_file = 'server.key'
2012-05-15 22:13:36 us=37732 pkcs12_file = '[UNDEF]'
2012-05-15 22:13:36 us=37745 cipher_list = '[UNDEF]'
2012-05-15 22:13:36 us=37758 tls_verify = '[UNDEF]'
2012-05-15 22:13:36 us=37771 tls_export_cert = '[UNDEF]'
2012-05-15 22:13:36 us=37784 tls_remote = '[UNDEF]'
2012-05-15 22:13:36 us=37797 crl_file = '[UNDEF]'
2012-05-15 22:13:36 us=37811 ns_cert_type = 0
2012-05-15 22:13:36 us=37824 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37837 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37851 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37864 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37877 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37890 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37903 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37916 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37929 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37942 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37955 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37968 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37981 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=37995 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=38008 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=38021 remote_cert_ku[i] = 0
2012-05-15 22:13:36 us=38034 remote_cert_eku = '[UNDEF]'
2012-05-15 22:13:36 us=38047 tls_timeout = 2
2012-05-15 22:13:36 us=38060 renegotiate_bytes = 0
2012-05-15 22:13:36 us=38074 renegotiate_packets = 0
2012-05-15 22:13:36 us=38087 renegotiate_seconds = 3600
2012-05-15 22:13:36 us=38100 handshake_window = 60
2012-05-15 22:13:36 us=38114 transition_window = 3600
2012-05-15 22:13:36 us=38127 single_session = DISABLED
2012-05-15 22:13:36 us=38140 push_peer_info = DISABLED
2012-05-15 22:13:36 us=38153 tls_exit = DISABLED
2012-05-15 22:13:36 us=38167 tls_auth_file = '[UNDEF]'
2012-05-15 22:13:36 us=38180 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38194 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38207 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38221 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38234 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38248 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38261 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38275 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38288 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38302 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38315 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38329 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38342 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38356 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38369 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38383 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:36 us=38397 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38410 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38424 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38437 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38451 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38464 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38477 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38491 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38504 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38518 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38531 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38557 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38571 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38585 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38598 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38612 pkcs11_private_mode = 00000000
2012-05-15 22:13:36 us=38625 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38638 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38651 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38665 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38678 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38691 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38704 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38717 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38730 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38743 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38756 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38770 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38783 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38796 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38809 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38823 pkcs11_cert_private = DISABLED
2012-05-15 22:13:36 us=38836 pkcs11_pin_cache_period = -1
2012-05-15 22:13:36 us=38850 pkcs11_id = '[UNDEF]'
2012-05-15 22:13:36 us=38863 pkcs11_id_management = DISABLED
2012-05-15 22:13:36 us=38879 server_network = 10.10.46.0
2012-05-15 22:13:36 us=38894 server_netmask = 255.255.255.0
2012-05-15 22:13:36 us=38909 server_bridge_ip = 0.0.0.0
2012-05-15 22:13:36 us=38924 server_bridge_netmask = 0.0.0.0
2012-05-15 22:13:36 us=38939 server_bridge_pool_start = 0.0.0.0
2012-05-15 22:13:36 us=38954 server_bridge_pool_end = 0.0.0.0
2012-05-15 22:13:36 us=38968 push_entry = 'route 10.10.46.1'
2012-05-15 22:13:36 us=38981 push_entry = 'topology net30'
2012-05-15 22:13:36 us=38995 push_entry = 'ping 10'
2012-05-15 22:13:36 us=39008 push_entry = 'ping-restart 120'
2012-05-15 22:13:36 us=39022 ifconfig_pool_defined = ENABLED
2012-05-15 22:13:36 us=39037 ifconfig_pool_start = 10.10.46.4
2012-05-15 22:13:36 us=39052 ifconfig_pool_end = 10.10.46.251
2012-05-15 22:13:36 us=39067 ifconfig_pool_netmask = 0.0.0.0
2012-05-15 22:13:36 us=39081 ifconfig_pool_persist_filename = 'ipp.txt'
2012-05-15 22:13:36 us=39095 ifconfig_pool_persist_refresh_freq = 600
2012-05-15 22:13:36 us=39108 n_bcast_buf = 256
2012-05-15 22:13:36 us=39121 tcp_queue_limit = 64
2012-05-15 22:13:36 us=39134 real_hash_size = 256
2012-05-15 22:13:36 us=39147 virtual_hash_size = 256
2012-05-15 22:13:36 us=39161 client_connect_script = '[UNDEF]'
2012-05-15 22:13:36 us=39174 learn_address_script = '[UNDEF]'
2012-05-15 22:13:36 us=39188 client_disconnect_script = '[UNDEF]'
2012-05-15 22:13:36 us=39202 client_config_dir = '[UNDEF]'
2012-05-15 22:13:36 us=39215 ccd_exclusive = DISABLED
2012-05-15 22:13:36 us=39228 tmp_dir = '/var/folders/6k/r4rml09s5x50_t3s2lq90w2m0000gn/T/'
2012-05-15 22:13:36 us=39242 push_ifconfig_defined = DISABLED
2012-05-15 22:13:36 us=39257 push_ifconfig_local = 0.0.0.0
2012-05-15 22:13:36 us=39272 push_ifconfig_remote_netmask = 0.0.0.0
2012-05-15 22:13:36 us=39285 enable_c2c = DISABLED
2012-05-15 22:13:36 us=39298 duplicate_cn = DISABLED
2012-05-15 22:13:36 us=39311 cf_max = 0
2012-05-15 22:13:36 us=39325 cf_per = 0
2012-05-15 22:13:36 us=39338 max_clients = 1024
2012-05-15 22:13:36 us=39351 max_routes_per_client = 256
2012-05-15 22:13:36 us=39364 auth_user_pass_verify_script = '[UNDEF]'
2012-05-15 22:13:36 us=39378 auth_user_pass_verify_script_via_file = DISABLED
2012-05-15 22:13:36 us=39405 ssl_flags = 0
2012-05-15 22:13:36 us=39419 port_share_host = '[UNDEF]'
2012-05-15 22:13:36 us=39432 port_share_port = 0
2012-05-15 22:13:36 us=39445 client = DISABLED
2012-05-15 22:13:36 us=39458 pull = DISABLED
2012-05-15 22:13:36 us=39472 auth_user_pass_file = '[UNDEF]'
2012-05-15 22:13:36 us=39490 OpenVPN 2.2.1 i386-apple-darwin10.7.1 [SSL] [LZO2] [PKCS11] [eurephia] built on May 2 2012
2012-05-15 22:13:36 us=39629 MANAGEMENT: TCP Socket listening on 127.0.0.1:1338
2012-05-15 22:13:36 us=40211 Need hold release from management interface, waiting...
2012-05-15 22:13:36 us=151246 MANAGEMENT: Client connected from 127.0.0.1:1338
2012-05-15 22:13:36 us=186701 MANAGEMENT: CMD 'pid'
2012-05-15 22:13:36 us=187063 MANAGEMENT: CMD 'state on'
2012-05-15 22:13:36 us=187196 MANAGEMENT: CMD 'state'
2012-05-15 22:13:36 us=187363 MANAGEMENT: CMD 'hold release'
2012-05-15 22:13:36 us=187806 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2012-05-15 22:13:36 *Tunnelblick: Established communication with OpenVPN
2012-05-15 22:13:36 us=271213 Diffie-Hellman initialized with 2048 bit key
2012-05-15 22:13:36 us=273556 WARNING: file 'server.key' is group or others accessible
2012-05-15 22:13:36 us=274387 TLS-Auth MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
2012-05-15 22:13:36 us=274529 Socket Buffers: R=[262140->65536] S=[131070->65536]
2012-05-15 22:13:36 us=274805 ROUTE default_gateway=192.168.178.1
2012-05-15 22:13:36 us=275280 TUN/TAP device /dev/tun0 opened
2012-05-15 22:13:36 us=275392 MANAGEMENT: >STATE:1337112816,ASSIGN_IP,,10.10.46.1,
2012-05-15 22:13:36 us=275658 /sbin/ifconfig tun0 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2012-05-15 22:13:36 us=289372 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2012-05-15 22:13:36 us=289562 /sbin/ifconfig tun0 10.10.46.1 10.10.46.2 mtu 1500 netmask 255.255.255.255 up
2012-05-15 22:13:36 us=298344 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -atDASNGWrdasngw tun0 1500 1544 10.10.46.1 10.10.46.2 init
2012-05-15 22:13:38 *Tunnelblick client.up.tunnelblick.sh: No network configuration changes need to be made.
2012-05-15 22:13:38 *Tunnelblick client.up.tunnelblick.sh: Will NOT monitor for other network configuration changes.
2012-05-15 22:13:38 us=386030 MANAGEMENT: >STATE:1337112818,ADD_ROUTES,,,
2012-05-15 22:13:38 us=386347 /sbin/route add -net 10.10.46.0 10.10.46.2 255.255.255.0
add net 10.10.46.0: gateway 10.10.46.2
2012-05-15 22:13:38 us=389217 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
2012-05-15 22:13:38 us=389370 Listening for incoming TCP connection on [undef]:1194
2012-05-15 22:13:38 us=389470 TCPv4_SERVER link local (bound): [undef]:1194
2012-05-15 22:13:38 us=389548 TCPv4_SERVER link remote: [undef]
2012-05-15 22:13:38 us=389639 MULTI: multi_init called, r=256 v=256
2012-05-15 22:13:38 us=389760 IFCONFIG POOL: base=10.10.46.4 size=62
2012-05-15 22:13:38 us=389849 IFCONFIG POOL LIST
2012-05-15 22:13:38 us=389940 MULTI: TCP INIT maxclients=1020 maxevents=1024
2012-05-15 22:13:38 us=390088 Initialization Sequence Completed
2012-05-15 22:13:38 us=390376 MANAGEMENT: >STATE:1337112818,CONNECTED,SUCCESS,10.10.46.1,
2012-05-15 22:13:38 *Tunnelblick: Flushed the DNS cache
2012-05-15 22:13:43 us=31875 MULTI: multi_create_instance called
2012-05-15 22:13:43 us=32107 Re-using SSL/TLS context
2012-05-15 22:13:43 us=32252 LZO compression initialized
2012-05-15 22:13:43 us=32510 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
2012-05-15 22:13:43 us=32637 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
2012-05-15 22:13:43 us=32790 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-05-15 22:13:43 us=32890 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-05-15 22:13:43 us=33009 Local Options hash (VER=V4): 'c0103fa8'
2012-05-15 22:13:43 us=33112 Expected Remote Options hash (VER=V4): '69109d17'
2012-05-15 22:13:43 us=33948 TCP connection established with 192.168.178.18:57255
2012-05-15 22:13:43 us=34057 TCPv4_SERVER link local: [undef]
2012-05-15 22:13:43 us=34153 TCPv4_SERVER link remote: 192.168.178.18:57255
2012-05-15 22:13:44 us=34206 192.168.178.18:57255 TLS: Initial packet from 192.168.178.18:57255, sid=82a6f64e 02a662d0
2012-05-15 22:13:44 us=82525 192.168.178.18:57255 Connection reset, restarting [0]
2012-05-15 22:13:44 us=82701 192.168.178.18:57255 SIGUSR1[soft,connection-reset] received, client-instance restarting
2012-05-15 22:13:44 us=82879 TCP/UDP: Closing socket
2012-05-15 22:13:44 us=89585 MULTI: multi_create_instance called
2012-05-15 22:13:44 us=89750 Re-using SSL/TLS context
2012-05-15 22:13:44 us=89840 LZO compression initialized
2012-05-15 22:13:44 us=89992 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
2012-05-15 22:13:44 us=90083 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
2012-05-15 22:13:44 us=90195 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-05-15 22:13:44 us=90275 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-05-15 22:13:44 us=90365 Local Options hash (VER=V4): 'c0103fa8'
2012-05-15 22:13:44 us=90450 Expected Remote Options hash (VER=V4): '69109d17'
2012-05-15 22:13:44 us=90545 TCP connection established with 192.168.178.18:57256
2012-05-15 22:13:44 us=90630 TCPv4_SERVER link local: [undef]
2012-05-15 22:13:44 us=90711 TCPv4_SERVER link remote: 192.168.178.18:57256
2012-05-15 22:13:45 us=89924 192.168.178.18:57256 TLS: Initial packet from 192.168.178.18:57256, sid=17bf6baa 2d4a24f0
2012-05-15 22:13:45 us=135364 192.168.178.18:57256 Connection reset, restarting [0]
2012-05-15 22:13:45 us=135567 192.168.178.18:57256 SIGUSR1[soft,connection-reset] received, client-instance restarting
2012-05-15 22:13:45 us=135722 TCP/UDP: Closing socket
2012-05-15 22:13:45 us=162029 MULTI: multi_create_instance called
2012-05-15 22:13:45 us=162452 Re-using SSL/TLS context
2012-05-15 22:13:45 us=162556 LZO compression initialized
2012-05-15 22:13:45 us=162857 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
2012-05-15 22:13:45 us=162965 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
2012-05-15 22:13:45 us=163096 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-05-15 22:13:45 us=163176 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-05-15 22:13:45 us=163262 Local Options hash (VER=V4): 'c0103fa8'
2012-05-15 22:13:45 us=163347 Expected Remote Options hash (VER=V4): '69109d17'
2012-05-15 22:13:45 us=163442 TCP connection established with 192.168.178.18:57257
2012-05-15 22:13:45 us=163539 TCPv4_SERVER link local: [undef]
2012-05-15 22:13:45 us=163835 TCPv4_SERVER link remote: 192.168.178.18:57257
2012-05-15 22:13:46 us=162734 192.168.178.18:57257 TLS: Initial packet from 192.168.178.18:57257, sid=5a713988 0286f71c
2012-05-15 22:13:46 us=212099 192.168.178.18:57257 Connection reset, restarting [0]
2012-05-15 22:13:46 us=212542 192.168.178.18:57257 SIGUSR1[soft,connection-reset] received, client-instance restarting
2012-05-15 22:13:46 us=212731 TCP/UDP: Closing socket
2012-05-15 22:13:46 us=254158 MULTI: multi_create_instance called
2012-05-15 22:13:46 us=254583 Re-using SSL/TLS context
2012-05-15 22:13:46 us=254675 LZO compression initialized
2012-05-15 22:13:46 us=255324 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
2012-05-15 22:13:46 us=255453 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
2012-05-15 22:13:46 us=258114 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-05-15 22:13:46 us=258223 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-05-15 22:13:46 us=258385 Local Options hash (VER=V4): 'c0103fa8'
2012-05-15 22:13:46 us=258621 Expected Remote Options hash (VER=V4): '69109d17'
2012-05-15 22:13:46 us=258724 TCP connection established with 192.168.178.18:57258
2012-05-15 22:13:46 us=259359 TCPv4_SERVER link local: [undef]
2012-05-15 22:13:46 us=259447 TCPv4_SERVER link remote: 192.168.178.18:57258
2012-05-15 22:13:46 us=652441 192.168.178.18:57258 Connection reset, restarting [0]
2012-05-15 22:13:46 us=652631 192.168.178.18:57258 SIGUSR1[soft,connection-reset] received, client-instance restarting
2012-05-15 22:13:46 us=652817 TCP/UDP: Closing socket
2012-05-15 22:13:50 *Tunnelblick: Disconnecting; 'disconnect' button pressed
2012-05-15 22:13:50 us=369157 TCP/UDP: Closing socket
2012-05-15 22:13:50 us=369344 /sbin/route delete -net 10.10.46.0 10.10.46.2 255.255.255.0
delete net 10.10.46.0: gateway 10.10.46.2
2012-05-15 22:13:50 us=372743 Closing TUN/TAP interface
2012-05-15 22:13:50 us=373168 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -atDASNGWrdasngw tun0 1500 1544 10.10.46.1 10.10.46.2 init
2012-05-15 22:13:51 *Tunnelblick client.down.tunnelblick.sh: WARNING: No existing OpenVPN DNS configuration found; not tearing down anything; exiting.
2012-05-15 22:13:51 us=410242 SIGTERM[hard,] received, process exiting
2012-05-15 22:13:51 us=410409 MANAGEMENT: >STATE:1337112831,EXITING,SIGTERM,,
2012-05-15 22:13:51 *Tunnelblick: Flushed the DNS cache
CLIENT
Code: Select all
2012-05-15 22:13:42 *Tunnelblick: OS X 10.7.4; Tunnelblick 3.2.6 (build 2891.3007) Unsigned
2012-05-15 22:13:42 *Tunnelblick: Attempting connection with client1; Set nameserver = 1; monitoring connection
2012-05-15 22:13:42 *Tunnelblick: /Applications/Tunnelblick.app/Contents/Resources/openvpnstart start client1.ovpn 1338 1 0 0 0 49 -atDASNGWrdasngw
2012-05-15 22:13:42 us=899560 Current Parameter Settings:
2012-05-15 22:13:42 us=899722 config = '/Users/michael/Library/Application Support/Tunnelblick/Configurations/client1.ovpn'
2012-05-15 22:13:42 us=899733 mode = 0
2012-05-15 22:13:42 us=899742 show_ciphers = DISABLED
2012-05-15 22:13:42 us=899750 show_digests = DISABLED
2012-05-15 22:13:42 us=899759 show_engines = DISABLED
2012-05-15 22:13:42 us=899767 genkey = DISABLED
2012-05-15 22:13:42 us=899778 key_pass_file = '[UNDEF]'
2012-05-15 22:13:42 us=899787 show_tls_ciphers = DISABLED
2012-05-15 22:13:42 us=899796 Connection profiles [default]:
2012-05-15 22:13:42 us=899804 proto = tcp-client
2012-05-15 22:13:42 us=899813 local = '[UNDEF]'
2012-05-15 22:13:42 us=899822 local_port = 0
2012-05-15 22:13:42 us=899830 remote = '192.168.178.10'
2012-05-15 22:13:42 us=899839 remote_port = 1194
2012-05-15 22:13:42 us=899847 remote_float = DISABLED
2012-05-15 22:13:42 us=899855 bind_defined = DISABLED
2012-05-15 22:13:42 us=899864 bind_local = DISABLED
2012-05-15 22:13:42 us=899872 connect_retry_seconds = 5
2012-05-15 22:13:42 us=899881 connect_timeout = 10
2012-05-15 22:13:42 us=899890 connect_retry_max = 0
2012-05-15 22:13:42 us=899898 socks_proxy_server = '[UNDEF]'
2012-05-15 22:13:42 us=899907 socks_proxy_port = 0
2012-05-15 22:13:42 us=899915 socks_proxy_retry = DISABLED
2012-05-15 22:13:42 us=899924 Connection profiles END
2012-05-15 22:13:42 us=899932 remote_random = DISABLED
2012-05-15 22:13:42 us=899941 ipchange = '[UNDEF]'
2012-05-15 22:13:42 us=899949 dev = 'tun'
2012-05-15 22:13:42 us=899958 dev_type = '[UNDEF]'
2012-05-15 22:13:42 us=899966 dev_node = '[UNDEF]'
2012-05-15 22:13:42 us=899975 lladdr = '[UNDEF]'
2012-05-15 22:13:42 us=899983 topology = 1
2012-05-15 22:13:42 us=899991 tun_ipv6 = DISABLED
2012-05-15 22:13:42 us=900000 ifconfig_local = '[UNDEF]'
2012-05-15 22:13:42 us=900008 ifconfig_remote_netmask = '[UNDEF]'
2012-05-15 22:13:42 us=900017 ifconfig_noexec = DISABLED
2012-05-15 22:13:42 us=900025 ifconfig_nowarn = DISABLED
2012-05-15 22:13:42 us=900034 shaper = 0
2012-05-15 22:13:42 us=900042 tun_mtu = 1500
2012-05-15 22:13:42 us=900051 tun_mtu_defined = ENABLED
2012-05-15 22:13:42 us=900059 link_mtu = 1500
2012-05-15 22:13:42 us=900067 link_mtu_defined = DISABLED
2012-05-15 22:13:42 us=900076 tun_mtu_extra = 0
2012-05-15 22:13:42 us=900084 tun_mtu_extra_defined = DISABLED
2012-05-15 22:13:42 us=900093 fragment = 0
2012-05-15 22:13:42 us=900101 mtu_discover_type = -1
2012-05-15 22:13:42 us=900110 mtu_test = 0
2012-05-15 22:13:42 us=900122 mlock = DISABLED
2012-05-15 22:13:42 us=900131 keepalive_ping = 0
2012-05-15 22:13:42 us=900139 keepalive_timeout = 0
2012-05-15 22:13:42 us=900148 inactivity_timeout = 0
2012-05-15 22:13:42 us=900156 ping_send_timeout = 0
2012-05-15 22:13:42 us=900165 ping_rec_timeout = 0
2012-05-15 22:13:42 us=900173 ping_rec_timeout_action = 0
2012-05-15 22:13:42 us=900181 ping_timer_remote = DISABLED
2012-05-15 22:13:42 us=900190 remap_sigusr1 = 0
2012-05-15 22:13:42 us=900198 explicit_exit_notification = 0
2012-05-15 22:13:42 us=900207 persist_tun = ENABLED
2012-05-15 22:13:42 us=900215 persist_local_ip = DISABLED
2012-05-15 22:13:42 us=900224 persist_remote_ip = DISABLED
2012-05-15 22:13:42 us=900232 persist_key = ENABLED
2012-05-15 22:13:42 us=900241 mssfix = 1450
2012-05-15 22:13:42 us=900249 passtos = DISABLED
2012-05-15 22:13:42 us=900258 resolve_retry_seconds = 1000000000
2012-05-15 22:13:42 us=900266 username = '[UNDEF]'
2012-05-15 22:13:42 us=900275 groupname = '[UNDEF]'
2012-05-15 22:13:42 us=900283 chroot_dir = '[UNDEF]'
2012-05-15 22:13:42 us=900292 cd_dir = '/Users/michael/Library/Application Support/Tunnelblick/Configurations'
2012-05-15 22:13:42 us=900309 writepid = '[UNDEF]'
2012-05-15 22:13:42 us=900318 up_script = '/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -atDASNGWrdasngw'
2012-05-15 22:13:42 us=900327 down_script = '/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -atDASNGWrdasngw'
2012-05-15 22:13:42 us=900335 down_pre = DISABLED
2012-05-15 22:13:42 us=900344 up_restart = ENABLED
2012-05-15 22:13:42 us=900352 up_delay = DISABLED
2012-05-15 22:13:42 us=900363 daemon = ENABLED
2012-05-15 22:13:42 us=900372 inetd = 0
2012-05-15 22:13:42 us=900380 log = ENABLED
2012-05-15 22:13:42 us=900395 suppress_timestamps = DISABLED
2012-05-15 22:13:42 us=900404 nice = 0
2012-05-15 22:13:42 us=900415 verbosity = 4
2012-05-15 22:13:42 us=900424 mute = 0
2012-05-15 22:13:42 us=900433 gremlin = 0
2012-05-15 22:13:42 us=900441 status_file = '[UNDEF]'
2012-05-15 22:13:42 us=900450 status_file_version = 1
2012-05-15 22:13:42 us=900458 status_file_update_freq = 60
2012-05-15 22:13:42 us=900481 occ = ENABLED
2012-05-15 22:13:42 us=900490 rcvbuf = 65536
2012-05-15 22:13:42 us=900499 sndbuf = 65536
2012-05-15 22:13:42 us=900507 sockflags = 0
2012-05-15 22:13:42 us=900516 fast_io = DISABLED
2012-05-15 22:13:42 us=900524 lzo = 7
2012-05-15 22:13:42 us=900533 route_script = '[UNDEF]'
2012-05-15 22:13:42 us=900542 route_default_gateway = '[UNDEF]'
2012-05-15 22:13:42 us=900551 route_default_metric = 0
2012-05-15 22:13:42 us=900559 route_noexec = DISABLED
2012-05-15 22:13:42 us=900568 route_delay = 0
2012-05-15 22:13:42 us=900576 route_delay_window = 30
2012-05-15 22:13:42 us=900585 route_delay_defined = DISABLED
2012-05-15 22:13:42 us=900593 route_nopull = DISABLED
2012-05-15 22:13:42 us=900602 route_gateway_via_dhcp = DISABLED
2012-05-15 22:13:42 us=900611 max_routes = 100
2012-05-15 22:13:42 us=900620 allow_pull_fqdn = DISABLED
2012-05-15 22:13:42 us=900628 management_addr = '127.0.0.1'
2012-05-15 22:13:42 us=900637 management_port = 1338
2012-05-15 22:13:42 us=900646 management_user_pass = '[UNDEF]'
2012-05-15 22:13:42 us=900655 management_log_history_cache = 250
2012-05-15 22:13:42 us=900664 management_echo_buffer_size = 100
2012-05-15 22:13:42 us=900673 management_write_peer_info_file = '[UNDEF]'
2012-05-15 22:13:42 us=900682 management_client_user = '[UNDEF]'
2012-05-15 22:13:42 us=900691 management_client_group = '[UNDEF]'
2012-05-15 22:13:42 us=900700 management_flags = 6
2012-05-15 22:13:42 us=900709 shared_secret_file = '[UNDEF]'
2012-05-15 22:13:42 us=900718 key_direction = 0
2012-05-15 22:13:42 us=900727 ciphername_defined = ENABLED
2012-05-15 22:13:42 us=900736 ciphername = 'BF-CBC'
2012-05-15 22:13:42 us=900744 authname_defined = ENABLED
2012-05-15 22:13:42 us=900753 authname = 'SHA1'
2012-05-15 22:13:42 us=900762 prng_hash = 'SHA1'
2012-05-15 22:13:42 us=900771 prng_nonce_secret_len = 16
2012-05-15 22:13:42 us=900779 keysize = 0
2012-05-15 22:13:42 us=900788 engine = DISABLED
2012-05-15 22:13:42 us=900797 replay = ENABLED
2012-05-15 22:13:42 us=900806 mute_replay_warnings = DISABLED
2012-05-15 22:13:42 us=900814 replay_window = 64
2012-05-15 22:13:42 us=900823 replay_time = 15
2012-05-15 22:13:42 us=900832 packet_id_file = '[UNDEF]'
2012-05-15 22:13:42 us=900840 use_iv = ENABLED
2012-05-15 22:13:42 us=900849 test_crypto = DISABLED
2012-05-15 22:13:42 us=900858 tls_server = DISABLED
2012-05-15 22:13:42 us=900869 tls_client = ENABLED
2012-05-15 22:13:42 us=900878 key_method = 2
2012-05-15 22:13:42 us=900887 ca_file = 'ca.crt'
2012-05-15 22:13:42 us=900896 ca_path = '[UNDEF]'
2012-05-15 22:13:42 us=900913 dh_file = '[UNDEF]'
2012-05-15 22:13:42 us=900922 cert_file = 'client1.crt'
2012-05-15 22:13:42 us=900931 priv_key_file = 'client1.key'
2012-05-15 22:13:42 us=900939 pkcs12_file = '[UNDEF]'
2012-05-15 22:13:42 us=900948 cipher_list = '[UNDEF]'
2012-05-15 22:13:42 us=900957 tls_verify = '[UNDEF]'
2012-05-15 22:13:42 us=900965 tls_export_cert = '[UNDEF]'
2012-05-15 22:13:42 us=900974 tls_remote = '[UNDEF]'
2012-05-15 22:13:42 us=900983 crl_file = '[UNDEF]'
2012-05-15 22:13:42 us=900991 ns_cert_type = 0
2012-05-15 22:13:42 us=901000 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901009 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901018 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901026 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901035 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901044 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901052 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901061 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901070 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901078 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901087 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901096 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901104 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901113 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901122 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901130 remote_cert_ku[i] = 0
2012-05-15 22:13:42 us=901139 remote_cert_eku = '[UNDEF]'
2012-05-15 22:13:42 us=901148 tls_timeout = 2
2012-05-15 22:13:42 us=901156 renegotiate_bytes = 0
2012-05-15 22:13:42 us=901165 renegotiate_packets = 0
2012-05-15 22:13:42 us=901174 renegotiate_seconds = 3600
2012-05-15 22:13:42 us=901183 handshake_window = 60
2012-05-15 22:13:42 us=901192 transition_window = 3600
2012-05-15 22:13:42 us=901200 single_session = DISABLED
2012-05-15 22:13:42 us=901209 push_peer_info = DISABLED
2012-05-15 22:13:42 us=901218 tls_exit = DISABLED
2012-05-15 22:13:42 us=901227 tls_auth_file = '[UNDEF]'
2012-05-15 22:13:42 us=901236 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901245 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901254 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901263 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901271 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901280 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901289 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901298 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901307 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901316 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901325 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901333 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901342 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901351 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901360 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901369 pkcs11_protected_authentication = DISABLED
2012-05-15 22:13:42 us=901378 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901387 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901396 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901404 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901413 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901422 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901431 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901440 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901449 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901465 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901474 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901483 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901492 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901501 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901510 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901519 pkcs11_private_mode = 00000000
2012-05-15 22:13:42 us=901527 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901536 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901545 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901554 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901563 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901571 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901580 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901589 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901598 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901607 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901615 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901624 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901633 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901642 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901651 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901659 pkcs11_cert_private = DISABLED
2012-05-15 22:13:42 us=901668 pkcs11_pin_cache_period = -1
2012-05-15 22:13:42 us=901677 pkcs11_id = '[UNDEF]'
2012-05-15 22:13:42 us=901686 pkcs11_id_management = DISABLED
2012-05-15 22:13:42 us=901712 server_network = 0.0.0.0
2012-05-15 22:13:42 us=901723 server_netmask = 0.0.0.0
2012-05-15 22:13:42 us=901733 server_bridge_ip = 0.0.0.0
2012-05-15 22:13:42 us=901743 server_bridge_netmask = 0.0.0.0
2012-05-15 22:13:42 us=901753 server_bridge_pool_start = 0.0.0.0
2012-05-15 22:13:42 us=901763 server_bridge_pool_end = 0.0.0.0
2012-05-15 22:13:42 us=901772 ifconfig_pool_defined = DISABLED
2012-05-15 22:13:42 us=901781 ifconfig_pool_start = 0.0.0.0
2012-05-15 22:13:42 us=901791 ifconfig_pool_end = 0.0.0.0
2012-05-15 22:13:42 us=901801 ifconfig_pool_netmask = 0.0.0.0
2012-05-15 22:13:42 us=901810 ifconfig_pool_persist_filename = '[UNDEF]'
2012-05-15 22:13:42 us=901819 ifconfig_pool_persist_refresh_freq = 600
2012-05-15 22:13:42 us=901827 n_bcast_buf = 256
2012-05-15 22:13:42 us=901836 tcp_queue_limit = 64
2012-05-15 22:13:42 us=901845 real_hash_size = 256
2012-05-15 22:13:42 us=901854 virtual_hash_size = 256
2012-05-15 22:13:42 us=901863 client_connect_script = '[UNDEF]'
2012-05-15 22:13:42 us=901872 learn_address_script = '[UNDEF]'
2012-05-15 22:13:42 us=901881 client_disconnect_script = '[UNDEF]'
2012-05-15 22:13:42 us=901890 client_config_dir = '[UNDEF]'
2012-05-15 22:13:42 us=901899 ccd_exclusive = DISABLED
2012-05-15 22:13:42 us=901908 tmp_dir = '/var/folders/mn/1r1wj7k13nzdhpss1tb7y_j00000gn/T/'
2012-05-15 22:13:42 us=901917 push_ifconfig_defined = DISABLED
2012-05-15 22:13:42 us=901926 push_ifconfig_local = 0.0.0.0
2012-05-15 22:13:42 us=901936 push_ifconfig_remote_netmask = 0.0.0.0
2012-05-15 22:13:42 us=901945 enable_c2c = DISABLED
2012-05-15 22:13:42 us=901954 duplicate_cn = DISABLED
2012-05-15 22:13:42 us=901963 cf_max = 0
2012-05-15 22:13:42 us=901971 cf_per = 0
2012-05-15 22:13:42 us=901980 max_clients = 1024
2012-05-15 22:13:42 us=901989 max_routes_per_client = 256
2012-05-15 22:13:42 us=901997 auth_user_pass_verify_script = '[UNDEF]'
2012-05-15 22:13:42 us=902006 auth_user_pass_verify_script_via_file = DISABLED
2012-05-15 22:13:42 us=902015 ssl_flags = 0
2012-05-15 22:13:42 us=902024 port_share_host = '[UNDEF]'
2012-05-15 22:13:42 us=902041 port_share_port = 0
2012-05-15 22:13:42 us=902050 client = ENABLED
2012-05-15 22:13:42 us=902058 pull = ENABLED
2012-05-15 22:13:42 us=902067 auth_user_pass_file = '[UNDEF]'
2012-05-15 22:13:42 us=902080 OpenVPN 2.2.1 i386-apple-darwin10.7.1 [SSL] [LZO2] [PKCS11] [eurephia] built on May 2 2012
2012-05-15 22:13:42 us=902187 MANAGEMENT: TCP Socket listening on 127.0.0.1:1338
2012-05-15 22:13:42 us=902538 Need hold release from management interface, waiting...
2012-05-15 22:13:42 *Tunnelblick: openvpnstart: /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.2.1/openvpn --cd /Users/michael/Library/Application Support/Tunnelblick/Configurations --daemon --management 127.0.0.1 1338 --config /Users/michael/Library/Application Support/Tunnelblick/Configurations/client1.ovpn --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Smichael-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sclient1.ovpn.1_0_0_0_49.1338.openvpn.log --management-query-passwords --management-hold --script-security 2 --up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -atDASNGWrdasngw --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -atDASNGWrdasngw --up-restart
2012-05-15 22:13:43 *Tunnelblick: openvpnstart message: Loading tun.kext
2012-05-15 22:13:43 us=18950 MANAGEMENT: Client connected from 127.0.0.1:1338
2012-05-15 22:13:43 us=30339 MANAGEMENT: CMD 'pid'
2012-05-15 22:13:43 us=30587 MANAGEMENT: CMD 'state on'
2012-05-15 22:13:43 us=30683 MANAGEMENT: CMD 'state'
2012-05-15 22:13:43 us=30809 MANAGEMENT: CMD 'hold release'
2012-05-15 22:13:43 *Tunnelblick: Established communication with OpenVPN
2012-05-15 22:13:43 us=31127 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2012-05-15 22:13:43 us=31184 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2012-05-15 22:13:43 us=31998 WARNING: file 'client1.key' is group or others accessible
2012-05-15 22:13:43 us=32463 LZO compression initialized
2012-05-15 22:13:43 us=32592 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
2012-05-15 22:13:43 us=32689 Socket Buffers: R=[262140->65536] S=[131070->65536]
2012-05-15 22:13:43 us=32748 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
2012-05-15 22:13:43 us=32809 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-05-15 22:13:43 us=32861 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-05-15 22:13:43 us=34316 Local Options hash (VER=V4): '69109d17'
2012-05-15 22:13:43 us=34375 Expected Remote Options hash (VER=V4): 'c0103fa8'
2012-05-15 22:13:43 us=34439 Attempting to establish TCP connection with 192.168.178.10:1194 [nonblock]
2012-05-15 22:13:43 us=34504 MANAGEMENT: >STATE:1337112823,TCP_CONNECT,,,
2012-05-15 22:13:44 us=35675 TCP connection established with 192.168.178.10:1194
2012-05-15 22:13:44 us=35862 TCPv4_CLIENT link local: [undef]
2012-05-15 22:13:44 us=35969 TCPv4_CLIENT link remote: 192.168.178.10:1194
2012-05-15 22:13:44 us=36496 MANAGEMENT: >STATE:1337112824,WAIT,,,
2012-05-15 22:13:44 us=37637 MANAGEMENT: >STATE:1337112824,AUTH,,,
2012-05-15 22:13:44 us=37783 TLS: Initial packet from 192.168.178.10:1194, sid=b559972c beac9110
2012-05-15 22:13:44 us=84884 VERIFY ERROR: depth=0, error=self signed certificate: /C=NL/L=Amsterdam/O=domain/CN=vpn.domain.tld/emailAddress=client1@domain.tld
2012-05-15 22:13:44 us=85076 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2012-05-15 22:13:44 us=85132 TLS Error: TLS object -> incoming plaintext read error
2012-05-15 22:13:44 us=85183 TLS Error: TLS handshake failed
2012-05-15 22:13:44 us=85266 Fatal TLS error (check_tls_errors_co), restarting
2012-05-15 22:13:44 us=85338 TCP/UDP: Closing socket
2012-05-15 22:13:44 us=85411 SIGUSR1[soft,tls-error] received, process restarting
2012-05-15 22:13:44 us=85466 MANAGEMENT: >STATE:1337112824,RECONNECTING,tls-error,,
2012-05-15 22:13:44 us=89997 MANAGEMENT: CMD 'hold release'
2012-05-15 22:13:44 us=90147 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2012-05-15 22:13:44 us=90224 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2012-05-15 22:13:44 us=90287 Re-using SSL/TLS context
2012-05-15 22:13:44 us=90341 LZO compression initialized
2012-05-15 22:13:44 us=90453 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
2012-05-15 22:13:44 us=90527 Socket Buffers: R=[262140->65536] S=[131070->65536]
2012-05-15 22:13:44 us=90586 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
2012-05-15 22:13:44 us=90646 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-05-15 22:13:44 us=90697 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-05-15 22:13:44 us=90753 Local Options hash (VER=V4): '69109d17'
2012-05-15 22:13:44 us=90809 Expected Remote Options hash (VER=V4): 'c0103fa8'
2012-05-15 22:13:44 us=90865 Attempting to establish TCP connection with 192.168.178.10:1194 [nonblock]
2012-05-15 22:13:44 us=90917 MANAGEMENT: >STATE:1337112824,TCP_CONNECT,,,
2012-05-15 22:13:45 us=92063 TCP connection established with 192.168.178.10:1194
2012-05-15 22:13:45 us=92238 TCPv4_CLIENT link local: [undef]
2012-05-15 22:13:45 us=92343 TCPv4_CLIENT link remote: 192.168.178.10:1194
2012-05-15 22:13:45 us=92463 MANAGEMENT: >STATE:1337112825,WAIT,,,
2012-05-15 22:13:45 us=93409 MANAGEMENT: >STATE:1337112825,AUTH,,,
2012-05-15 22:13:45 us=93583 TLS: Initial packet from 192.168.178.10:1194, sid=6f6c0ff9 19cbcb52
2012-05-15 22:13:45 us=137799 VERIFY ERROR: depth=0, error=self signed certificate: /C=NL/L=Amsterdam/O=domain/CN=vpn.domain.tld/emailAddress=client1@domain.tld
2012-05-15 22:13:45 us=137967 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2012-05-15 22:13:45 us=138067 TLS Error: TLS object -> incoming plaintext read error
2012-05-15 22:13:45 us=138123 TLS Error: TLS handshake failed
2012-05-15 22:13:45 us=138199 Fatal TLS error (check_tls_errors_co), restarting
2012-05-15 22:13:45 us=138283 TCP/UDP: Closing socket
2012-05-15 22:13:45 us=138356 SIGUSR1[soft,tls-error] received, process restarting
2012-05-15 22:13:45 us=138420 MANAGEMENT: >STATE:1337112825,RECONNECTING,tls-error,,
2012-05-15 22:13:45 us=163849 MANAGEMENT: CMD 'hold release'
2012-05-15 22:13:45 us=163972 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2012-05-15 22:13:45 us=164027 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2012-05-15 22:13:45 us=164085 Re-using SSL/TLS context
2012-05-15 22:13:45 us=164140 LZO compression initialized
2012-05-15 22:13:45 us=164222 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
2012-05-15 22:13:45 us=164301 Socket Buffers: R=[262140->65536] S=[131070->65536]
2012-05-15 22:13:45 us=164360 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
2012-05-15 22:13:45 us=164422 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-05-15 22:13:45 us=164473 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-05-15 22:13:45 us=164530 Local Options hash (VER=V4): '69109d17'
2012-05-15 22:13:45 us=164585 Expected Remote Options hash (VER=V4): 'c0103fa8'
2012-05-15 22:13:45 us=164641 Attempting to establish TCP connection with 192.168.178.10:1194 [nonblock]
2012-05-15 22:13:45 us=164694 MANAGEMENT: >STATE:1337112825,TCP_CONNECT,,,
2012-05-15 22:13:46 us=164978 TCP connection established with 192.168.178.10:1194
2012-05-15 22:13:46 us=165158 TCPv4_CLIENT link local: [undef]
2012-05-15 22:13:46 us=165264 TCPv4_CLIENT link remote: 192.168.178.10:1194
2012-05-15 22:13:46 us=165383 MANAGEMENT: >STATE:1337112826,WAIT,,,
2012-05-15 22:13:46 us=166241 MANAGEMENT: >STATE:1337112826,AUTH,,,
2012-05-15 22:13:46 us=166390 TLS: Initial packet from 192.168.178.10:1194, sid=cba8be2d 8087b91c
2012-05-15 22:13:46 us=210753 VERIFY ERROR: depth=0, error=self signed certificate: /C=NL/L=Amsterdam/O=domain/CN=vpn.domain.tld/emailAddress=client1@domain.tld
2012-05-15 22:13:46 us=212739 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2012-05-15 22:13:46 us=214103 TLS Error: TLS object -> incoming plaintext read error
2012-05-15 22:13:46 us=214695 TLS Error: TLS handshake failed
2012-05-15 22:13:46 us=214881 Fatal TLS error (check_tls_errors_co), restarting
2012-05-15 22:13:46 us=214960 TCP/UDP: Closing socket
2012-05-15 22:13:46 us=215041 SIGUSR1[soft,tls-error] received, process restarting
2012-05-15 22:13:46 us=215096 MANAGEMENT: >STATE:1337112826,RECONNECTING,tls-error,,
2012-05-15 22:13:46 *Tunnelblick: Disconnecting; 'disconnect' button pressed
2012-05-15 22:13:46 *Tunnelblick: Flushed the DNS cache
2012-05-15 22:13:46 us=255591 MANAGEMENT: CMD 'hold release'
2012-05-15 22:13:46 us=255866 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2012-05-15 22:13:46 us=255923 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2012-05-15 22:13:46 us=256086 Re-using SSL/TLS context
2012-05-15 22:13:46 us=256190 LZO compression initialized
2012-05-15 22:13:46 us=256334 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
2012-05-15 22:13:46 us=256411 Socket Buffers: R=[262140->65536] S=[131070->65536]
2012-05-15 22:13:46 us=256470 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
2012-05-15 22:13:46 us=256532 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-05-15 22:13:46 us=256583 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-05-15 22:13:46 us=256640 Local Options hash (VER=V4): '69109d17'
2012-05-15 22:13:46 us=256694 Expected Remote Options hash (VER=V4): 'c0103fa8'
2012-05-15 22:13:46 us=256749 Attempting to establish TCP connection with 192.168.178.10:1194 [nonblock]
2012-05-15 22:13:46 us=256805 MANAGEMENT: >STATE:1337112826,TCP_CONNECT,,,
2012-05-15 22:13:46 us=654629 TCP/UDP: Closing socket
2012-05-15 22:13:46 us=655286 SIGTERM[hard,init_instance] received, process exiting
2012-05-15 22:13:46 us=655410 MANAGEMENT: >STATE:1337112826,EXITING,init_instance,,
I’ve also tried regenerating the certificates, also on another machine, Linux instead of Mac OS X.
Thank you for you help again!
Обычно довольно легко настроить VPN с использованием OpenVPN. Это одна из самых привлекательных функций OpenVPN по сравнению с другими решениями VPN. Однако иногда необходимо устранить неполадки в нерабочей настройке или настроить существующую настройку для повышения производительности.
Устранение неполадок и настройка OpenVPN часто игнорируются. Файлы журнала OpenVPN на стороне клиента и сервера предоставляют много информации, но вы должны знать как их читать. При настройке файлов конфигурации клиента и сервера также допускается довольно много ошибок. В этой главе вы узнаете, как интерпретировать файлы журнала OpenVPN и как обнаруживать и исправлять некоторые из этих распространенных ошибок.
Наконец, существует большая разница между рабочей установкой и установкой, которая работает хорошо. Возможно, ваша установка OpenVPN работает правильно, но пользователи все равно могут жаловаться на низкую производительность. Получение максимальной производительности от установки OpenVPN может показаться черной магией. В этой главе вы узнаете немного этой черной магии.
В этой главе будут рассмотрены следующие темы:
- Как читать файлы журнала
- Исправление распространенных ошибок конфигурации
- Устранение проблем с маршрутизацией
- Как оптимизировать производительность с помощью
pingиiperf - Анализ трафика OpenVPN с использованием
tcpdump
Как читать файлы журнала
Поначалу отладка нерабочих настроек может показаться сложной задачей. С чего начать? К счастью, OpenVPN предоставляет отличные средства ведения журналов и отладки. Однако с увеличением степени детализации журналов становится все труднее читать эти файлы журналов. Уровень детализации журнала OpenVPN по умолчанию равен 1, но рекомендуется установить степень детализации 3. Это часто дает администратору достаточно информации для обнаружения проблем с настройкой, в то же время сводя к минимуму потери производительности.
Установка детальности на 5 или выше рекомендуется только для целей отладки, так как это сильно повлияет на производительность.
Каждый пример в этой книге до сих пор включал устанку verb 3. Во-первых, мы рассмотрим файлы журнала клиента и сервера для рабочей настройки с такой детальностью. Важно понимать и, возможно, даже хранить файлы журналов работающего соединения. При попытке найти ошибку в нерабочей настройке, очень полезно сравнивать файлы журнала нерабочего случая с файлами рабочей настройки.
Запустите сервер, используя файл конфигурации по умолчанию basic-udp-server.conf:
[root@server]# openvpn --config basic-udp-server.conf
Пока не подключайтесь к клиенту. Файл журнала сервера теперь будет содержать следующее:
1 14:53:27 OpenVPN 2.3.6 x86_64-redhat-linux-gnu
[SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6]
built on Dec 2 2014
2 14:53:27 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013,
LZO2.03
3 14:53:27 Diffie-Hellman initialized with 2048 bit key
4 14:53:31 WARNING: this configuration may cache passwords in
memory -- use the auth-nocache option to prevent this
5 14:53:31 Control Channel Authentication: using
'/etc/openvpn/movpn/ta.key' as a OpenVPN static key
file
6 14:53:31 Outgoing Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
7 14:53:31 Incoming Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
8 14:53:31 Socket Buffers: R=[16777216->131072]
S=[16777216->131072]
9 14:53:31 TUN/TAP device tun0 opened
10 14:53:31 TUN/TAP TX queue length set to 100
11 14:53:31 do_ifconfig, tt->ipv6=0, tt-did_ifconfig_ipv6_setup=0
12 14:53:31 /sbin/ip link set dev tun0 up mtu 1500
13 14:53:31 /sbin/ip addr add dev tun0 10.200.0.1/24
broadcast 10.200.0.255
14 14:53:31 GID set to nobody
15 14:53:31 UID set to nobody
16 14:53:31 UDPv4 link local (bound): [undef]
17 14:53:31 UDPv4 link remote: [undef]
18 14:53:31 MULTI: multi_init called, r=256 v=256
19 14:53:31 IFCONFIG POOL: base=10.200.0.2 size=252, ipv6=0
20 14:53:31 Initialization Sequence Completed
Метки времени в начале каждой строки были сокращены для ясности.
Давайте посмотрим на этот файл журнала построчно:
- Строки 1 и 2 указывают версию и дату сборки самого OpenVPN, а также библиотеки, от которых зависит OpenVPN.
- Строка 3 говорит нам, что параметры Диффи-Хеллмана сервера были успешно инициализированы. Файл, указанный в строке конфигурации сервера
dh /etc/openvpn/movpn/dh2048.pemбыл использован для этого. - Строка 4 — это предупреждение, которое печатается почти всегда. Разработчики обсуждали, следует ли удалить эту строку или нет. В конце концов было решено, что по соображениям безопасности лучше всего распечатать это предупреждение. Если вы не слишком озабочены безопасностью, то можете игнорировать эту строку предупреждения.
- Строка 5 указывает, что канал управления защищен с использованием параметра конфигурации
tls-authи что OpenVPN смог успешно прочитать указанный файл. - Строки 6 и 7 сообщают нам, что два ключа SHA1 получены из файла
tls-authи теперь используются для подписи (хэширования) исходящего трафика и для проверки входящего трафика. - Строка 8 показывает размер буферов
Receive (R)иSend (S), которые использует OpenVPN. Эти параметры полезны только при доработке рабочей настройки, как мы увидим позже в этой главе. - Строки 9 и 10 показывают что OpenVPN смог успешно открыть устройство tun и установить глубину очереди пакетов для этого устройства равной
100. - Строки с 11 по 13 показывают настройки IPv4, которые используются для этой конфигурации сервера. Они также указывают что не были заданы параметры IPv6. Перечисленные здесь настройки являются переводом строки конфигурации сервера
server 10.200.0.0 255.255.255.0. - Строки 14 и 15 являются результатом указания
group nobodyиuser nobodyв файле конфигурации сервера соответственно. - Строки 16 и 17 показывают что OpenVPN прослушивает трафик UDP и привязан к неопределенному интерфейсу (0.0.0.0). Это результат указания
proto udpиbindв файле конфигурации сервера. - Строка 18 говорит нам, что это мультиклиентская установка с реальными и виртуальными размерами таблицы хешей
256. - В строке 19 указан диапазон адресов пула, доступных клиентам OpenVPN, которые могут подключаться к этому серверу. Это также часть перевода строки конфигурации сервера
server 10.200.0.0 255.255.255.0. - Строка 20 — это волшебная строка, которая сообщает нам, что сервер успешно запущен и инициализация завершена. Сервер теперь готов принимать соединения от входящих клиентов.
Далее мы запускаем клиент и смотрим файл журнала на стороне сервера:
[root@client]# openvpn --config basic-udp-client.conf
После этого мы также рассмотрим файл журнала на стороне клиента:
21 15:30:37 <CLIENT-IP>:39086 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:39086, sid=071ba589 7e9ff2a0
22 15:30:37 <CLIENT-IP>:39086 VERIFY OK: depth=1, C=ZA,
ST=Enlightenment, L=Overall, O=Mastering OpenVPN,
CN=Mastering OpenVPN, emailAddress=root@example.org
23 15:30:37 <CLIENT-IP>:39086 VERIFY OK: depth=0, C=ZA,
ST=Enlightenment, O=Mastering OpenVPN, CN=client3,
emailAddress=root@example.org
24 15:30:37 <CLIENT-IP>:39086 Data Channel Encrypt: Cipher
'BF-CBC' initialized with 128 bit key
25 15:30:37 <CLIENT-IP>:39086 Data Channel Encrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
26 15:30:37 <CLIENT-IP>:39086 Data Channel Decrypt: Cipher
'BF-CBC' initialized with 128 bit key
27 15:30:37 <CLIENT-IP>:39086 Data Channel Decrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
28 15:30:37 <CLIENT-IP>:39086 Control Channel: TLSv1, cipher
TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
29 15:30:37 <CLIENT-IP>:39086 [client3] Peer Connection Initiated
with [AF_INET]<CLIENT-IP>:39086
30 15:30:37 client3/<CLIENT-IP>:39086 MULTI_sva: pool returned
IPv4=10.200.0.2, IPv6=(Not enabled)
31 15:30:37 client3/<CLIENT-IP>:39086 MULTI: Learn: 10.200.0.2 →
client3/<CLIENT-IP>:39086
32 15:30:37 client3/<CLIENT-IP>:39086 MULTI: primary virtual IP
for client3/<CLIENT-IP>:39086: 10.200.0.2
33 15:30:39 client3/<CLIENT-IP>:39086 PUSH: Received control
message: 'PUSH_REQUEST'
34 15:30:39 client3/<CLIENT-IP>:39086 send_push_reply():
safe_cap=940
35 15:30:39 client3/<CLIENT-IP>:39086 SENT CONTROL [client3]:
'PUSH_REPLY,route-gateway 10.200.0.1,topology subnet,
ping 10,ping-restart 60,
ifconfig 10.200.0.2 255.255.255.0' (status=1)
Давайте пройдемся по новым записям журнала:
- Строка 21 указывает, что исходный пакет был получен от клиента с IP-адресом
<CLIENT-IP>. Обычно полный адрес IPv4 указан здесь. - Строки 22 и 23 показывают процесс проверки сертификата, предоставленного клиентом OpenVPN. Важной частью в этих строках журнала является
VERIFY-OK. - Строки с 24 по 27 перечисляют используемый шифр шифрования и дешифрования, а также хэши
SHA1, используемые для хеширования входящего и исходящего трафика в канале данных. BF-CBC (Blowfish Cipher Block Chaining) — текущий шифр по умолчанию для OpenVPN. - В строке 28 показан шифр TLS, используемый для защиты канала управления OpenVPN. Перечисленный здесь шифр очень похож на код шифрования, используемый защищенным веб-сервером.
- Строка 29 указывает, что клиент
client3с IP-адреса<CLIENT-IP>успешно прошел процесс аутентификации. - В строках с 30 по 32 указывается адрес пула, который будет назначен этому клиенту.
- Строки с 33 по 34 показывают что клиент запросил информацию о конфигурации (
PUSH REQUEST) и ответ от сервера — он отправляетpush_reply. - Строка 35 показывает содержимое сообщения
push_replyсо всей информацией о конфигурации для этого клиента. Эта строка чрезвычайно полезна при отладке установки OpenVPN, поскольку она показывает большую часть информации, которую сервер OpenVPN имеет для конкретного клиента, независимо от используемого файла конфигурации.
Аналогично, вот файл журнала клиента (запишите временные метки и сопоставьте их с временными метками из файла журнала сервера):
1 15:30:37 OpenVPN 2.3.6 x86_64-redhat-linux-gnu
[SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6]
built on Dec 2 2014
2 15:30:37 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013,
LZO 2.03
3 15:30:37 Control Channel Authentication: using
'/etc/openvpn/movpn/ta.key' as a OpenVPN static key
file
4 15:30:37 UDPv4 link local: [undef]
5 15:30:37 UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
6 15:30:37 [Mastering OpenVPN Server] Peer Connection Initiated
with [AF_INET]<SERVER-IP>:1194
7 15:30:39 TUN/TAP device tun0 opened
8 15:30:39 do_ifconfig, tt->ipv6=0, tt-did_ifconfig_ipv6_setup=0
9 15:30:39 /sbin/ip link set dev tun0 up mtu 1500
10 15:30:39 /sbi/nip addr add dev tun0 10.200.0.2/24
broadcast 10.200.0.255
11 15:30:39 Initialization Sequence Completed
Давайте пройдемся по новым записям журнала:
- Строки 1 и 2 очень похожи на строки из журнала сервера.
- Строка 3 указывает, что канал управления защищен с помощью параметра конфигурации
tls-authи OpenVPN смог успешно прочитать указанный файл. - Строки 4 и 5 говорят нам что клиент не связывался с локальным IP-адресом и было установлено соединение UDP с сервером по IP-адресу
<SERVER-IP>и порту1194. - В строке 6 указано, что соединение с сервером OpenVPN, идентифицирующим себя как
Mastering OpenVPN Server, было успешно установлено. Имя сервера извлекается из общего имени (common name) сертификата на стороне сервера. - Строка 7 говорит нам, что OpenVPN смог открыть TUN-устройство
tun0. - Строки с 8 по 10 перечисляют информацию IPv4, которую сервер передал к этому клиенту и показывают, что IP-адрес и маска сети задаются с помощью стандартной команды Linux
/sbin/ip. - Строка 11 снова является волшебной строкой, которая сообщает нам, что VPN-соединение было успешно установлено и теперь мы можем безопасно общаться с сервером OpenVPN. Однако, как мы увидим позже, сообщения об ошибках могут еще не появиться.
Обнаружение неработающей установки
Установка OpenVPN может не работать по многим причинам. В следующем разделе мы рассмотрим список распространенных сбоев. Во-первых, давайте посмотрим, что отображается в файлах журналов при неудачной попытке подключения. Сбои могут возникать очень рано при попытке подключения или даже после строки Initialization Sequence Completed.
Если мы используем неправильный файл tls-auth, соединение очень рано оборвется. Это как раз и является причиной использования файла tls-auth, поскольку минимизирует нагрузку на наш сервер OpenVPN, когда мошеннические клиенты пытаются получить доступ. Клиент, который пытается подключиться без указания файла tls-auth, будет отображаться в журналах сервера следующим образом:
16:40:31 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:40:31 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
16:40:33 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:40:33 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
16:40:37 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:40:37 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
16:40:45 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:40:45 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
16:41:01 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:41:01 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
Об этом клиенте больше ничего не сообщается, поскольку сервер OpenVPN немедленно отклоняет попытку подключения. Из временных меток в файле журнала мы видим, что клиент увеличивает время задержки между попытками соединения с каждым неудачным соединением. Если в течение 60 секунд соединение не может быть установлено, клиент прервет:
TLS Error: TLS key negotiation failed to occur within 60 seconds
(check your network connectivity)
TLS Error: TLS handshake failed
Второй сбой соединения станет очевидным только после того, как соединение будет успешно инициализировано. Для этого мы указываем использование другого кодирующего шифра на одной стороне, но забываем сделать это на другой. В файле журнала клиента теперь будет отображаться следующее:
16:56:20 /sbin/ip link set dev tun0 up mtu 1500
16:56:20 /sbin/ip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
16:56:20 Initialization Sequence Completed
16:56:30 Authenticate/Decrypt packet error: cipher final failed
16:56:40 Authenticate/Decrypt packet error: cipher final failed
Таким образом, сначала соединение, кажется, было успешно установлено (строки с 1 по 3), но через 10 секунд шифрование и дешифрование канала данных не удается.
Заметка
Если бы в этом случае использовался графический интерфейс Windows, значок графического интерфейса стал бы зеленым, но сама VPN не работала бы!
Во время инициализации будет сообщено о большинстве проблем конфигурации на стороне сервера или клиента. О проблемах маршрутизации, которые встречаются гораздо чаще, OpenVPN обычно не сообщает. Следовательно, требуются различные методы устранения неполадок.
Исправление распространенных ошибок конфигурации
При настройке конфигурации OpenVPN есть несколько распространенных ошибок, которые легко допустить. Эти ошибки конфигурации можно условно разделить на четыре категории:
- Сертификат (PKI) ошибки и несоответствия
- Несоответствие опций, таких как
tunпо сравнению сtap, шифрование и сжатие - Недостаточно прав для запуска OpenVPN
- Ошибки маршрутизации
В этом разделе мы рассмотрим первые три из этих категорий. Ошибки маршрутизации будут обсуждаться позже в этой главе.
Неправильный сертификат CA в конфигурации клиента
Файл конфигурации клиента почти всегда будет содержать три строки, подобные этой:
ca ca.crt
cert client.crt
key client.key
Эти файлы сертификатов и секретных ключей были созданы в главе 3, PKI и сертификаты и широко используются в последующих главах.
Файл CA, однако, не должен указывать центр сертификации, который использовался для подписи файла сертификата клиента. Это должен быть публичный сертификат центра сертификации, который использовался для подписи сертификата сервера. Если сертификат сервера был подписан другим центром сертификации, клиент откажется подключиться к серверу. Это можно увидеть в файле журнала на стороне клиента:
UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
VERIFY ERROR: depth=1, error=self signed certificate in certificate
chain: C=ZA, ST=Enlightenment, L=Overall, O=Mastering OpenVPN,
CN=Mastering OpenVPN, emailAddress=root@example.org
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
В этом случае ошибки не регистрируются на стороне сервера, так как сертификат клиента считается действительным на сервере.
Единственное, что зарегистрируется на сервере, это:
<CLIENT-IP>:42472 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:42472, sid=9a1e4a84 cdbb6926
<CLIENT-IP>:51441 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:51441, sid=17d3c89b 6999ae97
<CLIENT-IP>:43513 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:43513, sid=4609202f 4c91c23d
Это показывает последовательные попытки подключения, которые сделаны клиентом OpenVPN.
Как исправить
Убедитесь, что в файле конфигурации клиента указан правильный файл CA.
Сертификат клиента не распознан сервером
Если сертификат клиента не распознан сервером — сервер откажет в доступе к нему. Это может произойти, если используется неправильный (или мошеннический) клиентский сертификат или если клиентский сертификат был отозван, а опция crl-verify указана в файле конфигурации сервера.
Следующие записи будут отображаться в файле журнала сервера, если неизвестный клиент попытается подключиться к серверу OpenVPN:
<CLIENT-IP>:57072 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:57072, sid=a175f1be 6faed111
<CLIENT-IP>:57072 VERIFY ERROR: depth=0, error=unable to get
local issuer certificate: C=NL, O=Cookbook, CN=client1,
name=Cookbook Client, emailAddress=janjust@nikhef.nl
<CLIENT-IP>:57072 TLS_ERROR: BIO read tls_read_plaintext error:
error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:
no certificate returned
<CLIENT-IP>:57072 TLS Error: TLS object -> incoming plaintext
read error
<CLIENT-IP>:57072 TLS Error: TLS handshake failed
Сервер не может проверить сертификат клиента, так как он не распознает сертификат CA, который использовался для его подписи. Поэтому отказывается разрешить этому клиенту подключаться.
На стороне клиента никакие сообщения не печатаются в файле журнала в течение 60 секунд, после чего первоначальное рукопожатие прекращается и делается новая попытка подключения:
13:24:23 UDPv4 link local: [undef]
13:24:23 UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
13:25:23 TLS Error:
TLS key negotiation failed to occur within
60 seconds (check your network connectivity)
13:25:23 TLS Error: TLS handshake failed
13:25:23 SIGUSR1[soft,tls-error] received, process restarting
13:25:25 Control Channel Authentication: using
'/etc/openvpn/movpn/ta.key' as a OpenVPN static key file
13:25:25 UDPv4 link local: [undef]
13:25:25 UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
Как исправить
Убедитесь, что сертификат клиента распознается сервером. Это можно сделать либо указав соответствующий сертификат CA в файле конфигурации сервера, либо добавив сертификат CA в составленный файл сертификата CA в файле конфигурации сервера:
# cat CA1.crt CA2.crt > /etc/openvpn/movpn/ca-stack.pem
Далее используйте следующее в конфигурации сервера:
ca /etc/openvpn/movpn/ca-stack.pem
Таким образом, клиентские сертификаты, подписанные CA1.crt или CA2.crt будут приняты сервером.
Конечно, если это мошенник, пытающийся подключиться, то более подходящим решением может быть черный список IP-адресов, с которых клиент подключается.
Несоответствие сертификата клиента и приватного ключа
Если сертификат и закрытый ключ на клиенте не совпадают, то OpenVPN даже не будет пытаться подключиться к серверу. Вместо этого в файле журнала будет напечатана следующая ошибка:
Cannot load private key file /etc/openvpn/movpn/client1.key:
error:0B080074:x509 certificate routines:
X509_check_private_key:key values mismatch
Error: private key password verification failed
Exiting due to fatal error
Эта проблема может возникнуть, особенно, когда сертификат и закрытый ключ обновляются; Распространенной ошибкой является использование старого приватного ключа с новым сертификатом.
Как исправить
Убедитесь, что сертификат клиента и приватный ключ совпадают. Удивительно, но для этого не существует простого в использовании инструмента. Чтобы выяснить, принадлежат ли сертификат и закрытый ключ друг другу — мы можем использовать следующие команды и искать разделы modulus:
$ openssl x509 -text -noout -in client1.crt
[…]
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b2:17:bd:31:6d:56:d9:eb:c9:09:98:e2:c1:48:
c9:6a:e4:4a:6b:54:52:ea:1e:60:94:6b:cb:5e:d5:
a1:ef:83:05:f8:cf:a4:06:df:06:ee:d6:c8:75:65:
de:a7:96:68:a1:41:d1:9d:f0:2c:84:3f:ca:b9:d2:
e8:07:af:37:48:24:69:57:4e:09:70:66:47:6c:47:
36:4d:c9:29:13:eb:ed:c1:aa:cd:36:84:3c:55:18:
bc:ce:01:34:b5:89:04:dc:09:c5:ea:f2:57:9f:c2:
f5:c1:05:dd:66:4d:11:13:05:47:46:26:1a:55:18:
51:bd:89:65:ba:0d:89:bd:ea:03:58:5e:d3:d9:96:
a5:5e:2f:5f:b9:c8:88:fc:48:95:cb:4a:b2:12:3b:
b5:ed:4c:40:4c:50:8d:1d:eb:a5:c9:c0:e6:2c:ec:
01:0a:56:ac:db:9e:e7:56:f0:06:f7:ba:b6:ac:de:
41:d4:fb:b3:d6:f5:fe:13:b4:03:81:d9:f7:7c:2e:
60:2f:9c:5a:81:eb:2e:3a:e1:c4:8b:f8:b6:8d:2d:
f7:ec:7a:f6:2c:ff:af:1c:d2:7b:58:ca:9e:d1:f4:
ed:8a:7a:35:00:97:a3:35:dd:79:02:b4:79:9a:66:
3c:5e:c8:4d:87:eb:68:5d:45:29:73:70:7f:61:28:
67:b1
$ openssl rsa -text -noout -in client1.key
Private-Key: (2048 bit)
modulus:
00:b2:17:bd:31:6d:56:d9:eb:c9:09:98:e2:c1:48:
c9:6a:e4:4a:6b:54:52:ea:1e:60:94:6b:cb:5e:d5:
a1:ef:83:05:f8:cf:a4:06:df:06:ee:d6:c8:75:65:
de:a7:96:68:a1:41:d1:9d:f0:2c:84:3f:ca:b9:d2:
e8:07:af:37:48:24:69:57:4e:09:70:66:47:6c:47:
36:4d:c9:29:13:eb:ed:c1:aa:cd:36:84:3c:55:18:
bc:ce:01:34:b5:89:04:dc:09:c5:ea:f2:57:9f:c2:
f5:c1:05:dd:66:4d:11:13:05:47:46:26:1a:55:18:
51:bd:89:65:ba:0d:89:bd:ea:03:58:5e:d3:d9:96:
a5:5e:2f:5f:b9:c8:88:fc:48:95:cb:4a:b2:12:3b:
b5:ed:4c:40:4c:50:8d:1d:eb:a5:c9:c0:e6:2c:ec:
01:0a:56:ac:db:9e:e7:56:f0:06:f7:ba:b6:ac:de:
41:d4:fb:b3:d6:f5:fe:13:b4:03:81:d9:f7:7c:2e:
60:2f:9c:5a:81:eb:2e:3a:e1:c4:8b:f8:b6:8d:2d:
f7:ec:7a:f6:2c:ff:af:1c:d2:7b:58:ca:9e:d1:f4:
ed:8a:7a:35:00:97:a3:35:dd:79:02:b4:79:9a:66:
3c:5e:c8:4d:87:eb:68:5d:45:29:73:70:7f:61:28:
67:b1
[…]
Если мы посмотрим на модуль с открытого ключа (сертификата) и приватного ключа, то увидим что они одинаковы. Таким образом, этот сертификат и приватный ключ принадлежат друг другу.
Подсказка
При сравнении модулей часто достаточно сравнить первые несколько байтов, а затем последние несколько байтов.
Несоответствие ключей auth и tls-auth
Параметры auth и tls-auth используются для аутентификации пакетов канала управления и канала данных с использованием алгоритма подписи HMAC. Значением по умолчанию для алгоритма аутентификации HMAC является SHA1, в котором используются 160-битные ключи. Для опции tls-auth нет значения по умолчанию, так как оно не требуется. Однако этот вариант рекомендуется, поскольку он обеспечивает дополнительный уровень защиты от DDoS-атак.
Если алгоритм аутентификации, указанный в конфигурации клиента и сервера, не совпадает, то сервер не позволит клиенту начать квитирование безопасности TLS. Аналогичным образом, если файлы tls-auth на клиенте и сервере не совпадают или если с обеих сторон указан неверный параметр direction — сервер также не позволит клиенту начать квитирование безопасности TLS.
Обычно в файле конфигурации сервера указывается следующая опция:
tls-auth /etc/openvpn/movpn/ta.key 0
Соответственно, на клиенте у нас есть следующая опция:
tls-auth /etc/openvpn/movpn/ta.key 1
Здесь второй параметр определяет direction из tls-auth для используемых ключей. Этот параметр не обязателен, но он позволяет OpenVPN использовать разные ключи хеширования (или HMAC) для входящего и исходящего трафика. Ключ, используемый на клиенте для подписи исходящего трафика, должен совпадать с ключом, используемым на сервере для проверки входящего трафика, и наоборот.
Если используется неверный файл ключей tls-auth или если направление опущено или указано неверно, в журнале сервера появятся следующие записи:
Authenticate/Decrypt packet error: packet HMAC
authentication failed
TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:54377
В то же время, клиент просто попытается подключиться в течение 60 секунд, прежде чем произойдет тайм-аут.
Как исправить
Убедитесь, что используется один и тот же файл tls-auth в файлах конфигурации клиента и сервера. Также убедитесь, что параметр direction указан правильно на обоих концах (если используется вообще).
Если вы все еще не уверены, какие ключи HMAC используются для входящих и исходящих соединений, то можете увеличить детализацию файла журнала, чтобы увидеть фактические ключи, используемые как клиентом, так и сервером. Давайте добавим следующее в файлы конфигурации клиента и сервера:
Теперь обе стороны будут печатать большое количество информации о регистрации при запуске.
Строки для поиска в файле журнала на на стороне сервера:
Outgoing Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Outgoing Control Channel Authentication:
HMAC KEY: 4660a714 7f4d33f9 d2f7c61a 9f1d5743 4bf9411e
Outgoing Control Channel Authentication:
HMAC size=20 block_size=20
Incoming Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Incoming Control Channel Authentication:
HMAC KEY: cd1f6d9c 88db5ec7 d7977322 e01d14f1 26ee4e22
Incoming Control Channel Authentication:
HMAC size=20 block_size=20
Строка HMAC size = 20 соответствует тому, что используется 160-битовое хеширование с помощью SHA1, так как 160 соответстуют как 20 байт.
Если на стороне клиента используются правильный файл tls-auth и параметр direction, мы найдем следующее:
Outgoing Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Outgoing Control Channel Authentication:
HMAC KEY: cd1f6d9c 88db5ec7 d7977322 e01d14f1 26ee4e22
Outgoing Control Channel Authentication:
HMAC size=20 block_size=20
Incoming Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Incoming Control Channel Authentication:
HMAC KEY: 4660a714 7f4d33f9 d2f7c61a 9f1d5743 4bf9411e
Incoming Control Channel Authentication:
HMAC size=20 block_size=20
Ключи аутентификации входящего и исходящего каналов управления зеркально отображаются на клиенте и на сервере, обеспечивая надлежащую аутентификацию TLS.
Несоответствие размера MTU
OpenVPN использует два размера максимальной единицы передачи (MTU):
tun-mtu: указывает настройку MTU адаптераtunи указывает максимальный размер каждого пакета внутри VPN-туннеля.link-mtu: указывает максимальный размер каждого пакета вне туннеля. Он включает в себя все биты заполнения, шифрования и аутентификации, но это не фактический размер пакета при передаче по сети. Фактический размер пакета не может быть определен заранее, так как размер каждого пакета может отличаться из-за алгоритмов сжатия и шифрования.
Значение по умолчанию для параметра tun-mtu составляет 1500 байт, что также является размером MTU по умолчанию для адаптера Ethernet. При нормальных обстоятельствах мы можем использовать следующую формулу для вычисления размера link-mtu из размера tun-mtu:
link-mtu = tun-mtu + constant
Здесь constant зависит от используемых параметров конфигурации. Среди параметров конфигурации, которые влияют на эту константу, мы имеем следующие:
- Варианты сжатия, такие как
comp-lzoиcomp-noadapt - Размер вектора инициализации (IV) параметра шифрования опции
cipher - Опция
fragment, добавляющая дополнительный байт - Опция
no-replay, которая удаляет байт.
Если мы видим несоответствие предупреждений link-mtu — это обычно указывает на неправильную конфигурацию в других местах наших файлов конфигурации клиента и сервера. Как вы увидите в последующих примерах, несоответствие в link-mtu между клиентом и сервером может происходить довольно часто. Обычно VPN-соединение не будет работать правильно, если имеется несоответствие link-mtu.
Подсказка
Не поддавайтесь искушению исправить само предупреждение link-mtu явно установив его. Сначала исправьте другие предупреждения, которые могли вызвать появление предупреждения link-mtu.
Параметр link-mtu также имеет большое значение при настройке VPN-соединения.
Чтобы получить максимальную производительность от VPN-соединения — нам нужно убедиться, что пакеты не фрагментируются операционной системой, поскольку это сильно повлияет на производительность. В частности, для спутниковых каналов это может привести к снижению производительности почти до полной остановки.
Если на стороне сервера указан другой размер MTU по сравнению со стороной клиента, в файлах журнала появится следующее предупреждение:
WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1441', remote='link-mtu 1541'
WARNING: 'tun-mtu' is used inconsistently,
local='tun-mtu 1400', remote='tun-mtu 1500'
Это показывает, что для конфигурации default, издержки link-mtu на самом деле составляют 41 байт. Здесь мы добавили в файл конфигурации клиента:
На этом этапе VPN-соединение будет функционировать. Однако производительность будет ограничена, так как пакеты должны быть фрагментированы и повторно собраны. При такой настройке можно вызвать ошибку, отправив большие пакеты ICMP с установленным флагом not fragment . В Linux/FreeBSD это можно сделать с помощью следующей команды:
$ ping -M do -s 1450 10.200.0.2
В Windows мы используем следующее:
C:> ping -f -l 1450 10.200.0.2
Это приведет к 100-процентной потере пакета для команды ping, а также будет отображаться в файле журнала:
Authenticate/Decrypt packet error:
packet HMAC authentication failed
Это сообщение об ошибке может сначала показаться странным, но оно вызвано тем, что отправляющая сторона создала и подписала пакет, размер которого превышает 1400 байт. Клиент получает только первые 1400 байтов этого пакета и проверяет подпись, которая терпит неудачу. Затем он отклоняет пакет и распечатывает ошибку.
Как исправить
Убедитесь, что, если вы хотите использовать опцию tun-mtu — она указана в файлах конфигурации клиента и сервера.
Несоответствие шифра
Шифр кодирования, который используется для канала данных OpenVPN, можно указать, используя следующую опцию со значением по умолчанию BF-CBC:
Если в файле конфигурации клиента указан другой шифр, чем в файле конфигурации сервера, то в файлах журнала с обеих сторон будет напечатано предупреждающее сообщение, но VPN-соединение будет установлено. Однако, как только любой трафик проходит по нему, он не сможет расшифровать. Мы можем видеть это в следующем фрагменте из файла журнала на стороне клиента:
WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1557', remote='link-mtu 1541'
WARNING: 'cipher' is used inconsistently,
local='cipher AES-256-CBC', remote='cipher BF-CBC'
WARNING: 'keysize' is used inconsistently,
local='keysize 256', remote='keysize 128'
[Mastering OpenVPN Server] Peer Connection Initiated
with [AF_INET]<SERVER-IP>:1194
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
/sbi/nip link set dev tun0 up mtu 1500
/sbi/nip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
Initialization Sequence Completed
Authenticate/Decrypt packet error: cipher final failed
Три напечатанных предупреждения изначально показывают как другой тип, так и другой размер используемого шифра. Шифр Blowfish по умолчанию использует 128-битную стойкость, тогда как AES-256 — 256-битную стойкость, что приводит к немного большему зашифрованному пакету (link-mtu 1541 байт для Blowfish по сравнению с link-mtu 1557 байт для AES-256).
Как исправить
Убедитесь, что в файлах конфигурации клиента и сервера указан один и тот же шифр. Поскольку файлы журналов клиента и сервера выводят ожидаемый шифр, исправить эту ошибку довольно просто.
Заметка
В настоящее время невозможно передать шифр с сервера на клиент. Это в списке пожеланий разработчиков OpenVPN, но оно оказывает существенное влияние на код. Он не будет добавлено в OpenVPN до версии 2.4 или даже 2.5.
Несоответствие компрессии
OpenVPN имеет возможность сжимать весь VPN-трафик на лету. Для определенных типов трафика, таких как обычный веб-трафик, это может повысить производительность VPN, но добавляет дополнительные издержки к протоколу VPN. Для несжимаемого трафика эта опция фактически немного снижает производительность.
Параметр, используемый для указания сжатия в настоящее время, выглядит следующим образом:
comp-lzo [no|yes|adaptive]
Обратите внимание, что нам не нужно указывать второй параметр. Значение по умолчанию является адаптивным, если используется сжатие.
Как мы узнаем в Главе 10, Будущие направления , этот вариант будет заменен более общим вариантом compression, что позволит различные механизмы сжатия.
Можно передать опцию compression с сервера на клиент, но только если опция сжатия была указана в самом файле конфигурации клиента. Если файл конфигурации клиента не содержит такой опции, VPN-соединение не будет установлено. В файле журнала клиента будет показано следующее:
UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1541', remote='link-mtu 1542'
WARNING: 'comp-lzo' is present in remote config but
missing in local config, remote='comp-lzo'
[Mastering OpenVPN Server] Peer Connection Initiated with
[AF_INET]<SERVER-IP>:1194
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbinip link set dev tun0 up mtu 1500
sbinip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
Initialization Sequence Completed
write to TUN/TAP : Invalid argument (code=22)
Файл журнала сервера будет содержать те же сообщения WARNING, а также будет отображать предупреждения распаковки:
client3/<CLIENT-IP>:45113 Bad LZO decompression header byte: 42
Заметка
Странно, но верно: если мы будем ждать достаточно долго, клиент будет перезагружен из-за ошибок сжатия и попытается восстановить соединение. На этот раз, однако, соединение будет успешным, так как опция comp-lzo все еще находится в памяти.
Как исправить
Убедитесь, что, если вы хотите использовать сжатие, опция comp-lzo указана в файлах конфигурации клиента и сервера. С опцией comp-lzo в файле конфигурации на стороне клиента мы теперь можем контролировать тип сжатия, используемый на стороне сервера, используя опцию push. Используйте следующее:
comp-lzo no
push "comp-lzo no"
Это отключит сжатие, но, к сожалению, это не то же самое, что вообще не указывать какой-либо метод сжатия. Надеемся, что это будет решено в будущем выпуске.
Несоответствие фрагмента
Одним из наиболее часто используемых параметров настройки является опция fragment. Подробнее об этой опции вы узнаете в разделе Как оптимизировать производительность с помощью ping и iperf далее в этой главе.
Как и параметр comp-lzo, параметр fragment указывать не нужно ни с одной стороны. Однако мы не можем указать его только с одной стороны; он должен быть настроен на обоих. Если он указан только с одной стороны, то также должен быть указан и с другой. Технически говоря, даже нет необходимости использовать одно и то же значение для параметра fragment с обеих сторон, но это рекомендуется.
Если опция fragment не указана на стороне клиента, но используется на стороне сервера, то VPN-соединение не будет работать должным образом, как видно из журнала клиента:
WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1541', remote='link-mtu 1545'
WARNING: 'mtu-dynamic' is present in remote config but
missing in local config, remote='mtu-dynamic'
[Mastering OpenVPN Server] Peer Connection Initiated with
[AF_INET]194.171.96.101:1194
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbinip link set dev tun0 up mtu 1500
sbinip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
Initialization Sequence Completed
write to TUN/TAP : Invalid argument (code=22)
Опять же, это будет выглядеть так, как будто VPN подключился (Initialization sequence completed), но файл журнала заполнится сообщениями об ошибках с code=22 .
Обратите внимание, что в предупреждении фактически указан mtu-dynamic, который является устаревшим названием этой функции.
Как исправить
Убедитесь, что, если вы хотите использовать параметр fragment — он указывается в файлах конфигурации клиента и сервера.
Обратите внимание, что, в отличие от опции comp-lzo, эту функцию нельзя передать с сервера на клиент.
Несоответствие tun и tap
Наиболее распространенный вариант использования сети в стиле tap — это мостовая установка, как мы узнали из Главы 6 , Режим клиент /сервер с помощью tap-устройств. Однако не все устройства поддерживают сеть в стиле tap. В частности, все устройства Android и iOS не имеют этой возможности. Следовательно, если мы подключим такое устройство к серверу OpenVPN в стиле tap, в файле журнала сервера будут перечислены предупреждения от этих клиентов:
<CLIENT-IP>:39959 WARNING: 'dev-type' is used inconsistently,
local='dev-type tap', remote='dev-type tun'
<CLIENT-IP>:39959 WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1573', remote='link-mtu 1541'
<CLIENT-IP>:39959 WARNING: 'tun-mtu' is used inconsistently,
local='tun-mtu 1532', remote='tun-mtu 1500'
Помимо этих предупреждений сервер не обнаружит ничего о подключающихся клиентах. На клиенте аналогичные предупреждения будут перечислены вместе с этим:
WARNING: Since you are using --dev tun with a point-to-point
topology, the second argument to --ifconfig must be an IP address.
You are using something (255.255.255.0) that looks more like a
netmask. (silence this warning with --ifconfig-nowarn)
Так как мы не можем передать топологию подсети в настройке стиля tap, клиент возвращается к сети по умолчанию в стиле Net30. Этот тип сети по своей сути несовместим с сетью в стиле tap, но, кроме этого, клиент не выдает никаких предупреждений или ошибок.
Даже если бы мы (ошибочно) добавили topology subnet для подавления этого предупреждения на клиенте, VPN все равно не работал бы правильно.
Как исправить
Убедитесь, что с обеих сторон используется один и тот же тип сети (tun или tap). Если вам необходимо использовать устройства Android или iOS — вы должны настроить конфигурацию сервера в стиле tun, так как эти операционные системы не поддерживают сеть в стиле tap.
Проблемы с client-config-dir
В Главе 4, Режим клиент/сервер с TUN устройствами, мы узнали о CCD-файлах и их использование в разделе Специфичная для клиента конфигурация — файлы CCD. Файлы CCD обычно используются для подключения клиентской локальной сети к сети сервера с помощью оператора iroute.
Опыт работы со списками рассылки и форумами OpenVPN показал, что опция client-config-dir подвержена ошибкам и неправильной настройке. Вот три основные причины этого:
- Файл CCD или каталог, в котором он находится, не может быть прочитан OpenVPN после переключения на
safeпользователя, такого какnobody. - Опция
client-config-dirуказана без абсолютного пути. - Имя файла CCD указано неверно. Обычно имя файла CCD совпадает с именем из поля
/CN=сертификата клиента, без части/CN=и без какого-либо расширения!
При нормальном уровне журнала OpenVPN не жалуется, если не может найти или прочитать файл CCD. Он просто обрабатывает входящее соединение как стандартное соединение, и, таким образом, требуемый оператор iroute никогда не достигается.
Самый простой способ отладки — это временно добавить дополнительную опцию в конфигурацию сервера:
Перезагрузите сервер и клиент попытается восстановить соединение. Если сервер не может прочитать соответствующий файл CCD для подключающегося клиента — он откажет в доступе. Если это произойдет — мы знаем, что файл CCD не был прочитан. Если клиент может подключиться, то возникает другая проблема — скорее всего, проблема маршрутизации.
Другой способ увидеть что сервер OpenVPN делает с файлами CCD — это повысить уровень журнала до 4 и повторно подключить клиента, для которого указан файл CCD. Содержимое этого CCD-файла для клиента с сертификатом /CN=client1 выглядит следующим образом:
ifconfig-push 10.200.0.99 255.255.255.0
iroute 192.168.4.0 255.255.255.0
Это дает команду серверу OpenVPN назначить IP-адрес VPN 10.200.0.99 для этого клиента и для маршрутизации подсети 192.168.4.0./24 через него. Файл журнала сервера теперь содержит следующее:
<CLIENT-IP>:38876 [client1] Peer Connection Initiated with
[AF_INET]<CLIENT-IP>:38876
client1/<CLIENT-IP>:38876 OPTIONS IMPORT: reading client specific
options from: /etc/openvpn/movpn/clients/client1
client1/<CLIENT-IP>:38876 MULTI: Learn: 10.200.0.99 ->
client1/<CLIENT-IP>:38876
client1/<CLIENT-IP>:38876 MULTI: primary virtual IP for
client1/<CLIENT-IP>:38876: 10.200.0.99
client1/<CLIENT-IP>:38876 MULTI: internal route 192.168.4.0/24 ->
client1/<CLIENT-IP>:38876
client1/<CLIENT-IP>:38876 MULTI: Learn: 192.168.4.0/24 ->
client1/<CLIENT-IP>:38876
Если выделенная строка отсутствует, то файл CCD не читается. Также следующие строки, начинающиеся с MULTI: показывают как сервер OpenVPN интерпретирует строки, найденные в файле CCD. Это может быть важно для дальнейшей отладки любых вопросов iroute.
Как исправить
Если процесс сервера не может прочитать файл CCD — проверьте права доступа к полному пути к файлу, включая все подкаталоги, ведущие к нему. Убедитесь, что пользователь, указанный в параметре user, имеет разрешение на чтение всех каталогов и самого файла CCD.
Убедитесь, что в опции client-config-dir указан абсолютный путь вместо относительного. Кроме того, если мы используем опцию chroot (подробности см. в man), убедитесь, что директория client-config-dir видна внутри chroot-jail.
Используйте опцию ccd-exclusive чтобы быстро определить, может ли OpenVPN читать файл CCD. Если это возможно, то увеличьте уровень журнала на стороне сервера, чтобы увидеть, как OpenVPN интерпретирует операторы, найденные в файле CCD.
Нет доступа к устройству tun в Linux
Если OpenVPN запускается с недостаточными привилегиями или если OpenVPN настроен на удаление привилегий root и переключение на другой userid (например, nobody), то доступ к устройству tun может быть потерян. Это также может произойти, если OpenVPN используется в виртуализированной среде, такой как OpenVZ или Virtual Private Server (VPS).
Если OpenVPN запущен с недостаточными привилегиями — VPN-соединение вообще не будет установлено:
UDPv4 link local: [undef]
UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
[Mastering OpenVPN Server] Peer Connection Initiated with
[AF_INET]<SERVER-IP>:1194
ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted
(errno=1)
Exiting due to fatal error
Проверьте userid или используйте sudo для переключения на привилегированного пользователя перед запуском OpenVPN.
Наиболее распространенный сценарий, когда доступны недостаточные привилегии, происходит после автоматического перезапуска VPN-подключения. Рассмотрим следующий файл конфигурации клиента:
client
proto udp
remote openvpnserver.example.com
port 1194
dev tun
nobind
remote-cert-tls server
tls-auth /etc/openvpn/movpn/ta.key 1
ca /etc/openvpn/movpn/movpn-ca.crt
cert /etc/openvpn/movpn/client3.crt
key /etc/openvpn/movpn/client3.key
user nobody
group nobody
Это базовый файл конфигурации с двумя строками внизу. Когда мы запускаем VPN-соединение с помощью этого файла конфигурации, соединение устанавливается правильно, но выводится предупреждение:
WARNING: you are using user/group/chroot/setcon without persist-tun
-- this may cause restarts to fail
Действительно, после перезапуска VPN-соединения (например, из-за плохого сетевого соединения) перезапуск не удастся:
[Mastering OpenVPN Server] Inactivity timeout (--ping-restart), restarting
Mon Jun 1 16:51:50 2015 sbinip addr del dev tun0 10.200.0.2/24
RTNETLINK answers: Operation not permitted
Linux ip addr del failed: external program exited with error status: 2
SIGUSR1[soft,ping-restart] received, process restarting
WARNING: you are using user/group/chroot/setcon without persist-key -- this may cause restarts to fail
Error: private key password verification failed
Exiting due to fatal error
Здесь мы видим, что OpenVPN не удалось перезапустить, так как пользователю nobody не разрешили прочитать приватный ключ, который использовался для этого соединения. Если бы мы указали пользователя с правами доступа, мы бы увидели другую ошибку:
ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted
(errno=1)
Exiting due to fatal error
Обратите внимание, что во время перезапуска OpenVPN не может завершить работу существующего устройства tun или удалить любые системные маршруты. Это также будет иметь место, если используется persist-tun, но в этом случае он будет безвредным.
Как исправить
Добавьте следующие параметры в файл конфигурации клиента, если вы также используете параметры user и/или group:
Убедитесь, что вы запускаете OpenVPN с достаточными привилегиями.
Также убедитесь, что OpenVPN имеет правильный контекст безопасности SELinux, или попробуйте запустить OpenVPN с SELinux, установленным в разрешающий или отключенный режим:
# setenforcing permissive
Отсутствие повышенных привилегий в Windows
В некоторых старых версиях программы установки OpenVPN для Windows не были заданы правильные привилегии для приложения OpenVPN GUI.
В этом конкретном примере один сервер был передан с сервера OpenVPN всем клиентам:
push "route 192.168.122.0 255.255.255.0"
В Windows Vista и выше OpenVPN требуются повышенные привилегии чтобы иметь возможность добавлять или удалять системные маршруты. Если эти привилегии отсутствуют, VPN обычно инициализируется правильно, а значок GUI становится зеленым:
Мы даже можем пропинговать сервер OpenVPN по IP-адресу его VPN-сервера. Тем не менее, файл журнала в OpenVPN GUI покажет некоторые ошибки:
Первая строка на самом деле хитрая:
Warning: cannot open -log file: .....: Access is denied
Сложность в том, что как только мы нажимаем кнопку Disconnect — журнал исчезает, так как он не может быть записан на диск! Это вызвано тем, что каталог журналов по умолчанию C:\Program FilesOpenVPNlog доступен только пользователю с повышенными привилегиями.
Последние несколько строк в файле журнала говорят нам, что OpenVPN не удалось добавить маршрут, который был передан сервером. Опять же, это связано с тем, что программа OpenVPN была запущена с недостаточными привилегиями.
Как исправить
После перезапуска OpenVPN GUI с повышенными правами (включите Запуск от имени администратора) маршрут будет добавлен правильно. Это видно из таблицы маршрутизации:
Переданный маршрут — 192.168.122.0/24 , теперь присутствует в таблице маршрутизации, используя IP-адрес VPN сервера 10.200.0.1 в качестве шлюза.
Устранение проблем с маршрутизацией
Большинство вопросов, задаваемых в списках рассылки OpenVPN и форумах пользователей, на самом деле являются вопросами маршрутизации. Настройка VPN-соединения — это одно, а интеграция в существующую сеть — совсем другое. Для новичка трудная часть состоит в том, чтобы видеть, где заканчивается OpenVPN и где начинается маршрутизация. Этот раздел предназначен в качестве пошагового руководства по устранению неполадок маршрутизации в довольно простой настройке OpenVPN.
Рассмотрим следующий план сети:
- Сеть в главном офисе должна быть доступна для дополнительного офиса и для людей, работающих из дома
- Серверы в дополнительном офисе должны быть доступны для IT-отдела главного офиса
- Люди, работающие из дома, должны иметь доступ только к компьютерным ресурсам в главном офисе
Для этого в главном офисе устанавливается сервер OpenVPN, сотрудники которого подключаются как обычные клиенты VPN, а дополнительный офис подключается как специальный клиент, раскрывая свою собственную сеть.
Рисование детальной картины
Перед созданием файлов конфигурации для OpenVPN нарисуйте подробное изображение схемы сети, включая все подсети, IP-адреса, IP-адреса шлюза, имена интерфейсов и многое другое.
Используемые публичные IP-адреса не перечислены на этом рисунке, но это рекомендуется сделать. Кроме того, подключения от людей, работающих из дома, не включены, но они будут подключаться к общедоступному IP-адресу gateway1 на предыдущем рисунке.
На gateway1 добавлено правило переадресации портов, поэтому входящий и исходящий трафик UDP через порт 1194 перенаправляется на сервер OpenVPN в 172.31.1.2:1194.
Поскольку нам необходимо раскрыть сеть в дополнительном офисе, нам также потребуется использовать файл client-config-dir с соответствующим оператором iroute.
Файлы конфигурации сервера и клиента для этой настройки уже перечислены в Главе 4, Режим клиент/сервер с tun-устройствами, с некоторыми незначительными изменениями IP-адреса. Новый набор файлов конфигурации выглядит следующим образом:
proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
tls-auth /etc/openvpn/movpn/ta.key 0
dh /etc/openvpn/movpn/dh2048.pem
ca /etc/openvpn/movpn/movpn-ca.crt
cert /etc/openvpn/movpn/server.crt
key /etc/openvpn/movpn/server.key
persist-key
persist-tun
keepalive 10 60
topology subnet
user nobody
group nobody
verb 3
daemon
log-append /var/log/openvpn.log
push "route 172.31.1.0 255.255.255.0"
client-config-dir /etc/openvpn/movpn/clients
route 192.168.3.0 255.255.255.0 10.200.0.1
Этот файл сохраняется как movpn-09-01-server.conf. Для клиента OpenVPN в дополнительном офисе создается специальный сертификат с именем /CN=SecondaryOffice. Соответствующий файл CCD, следовательно, имеет имя /etc/openvpn/movpn/clients/SecondaryOffice. Его содержание таково:
ifconfig-push 10.200.0.200 255.255.255.0
iroute 192.168.3.0 255.255.255.0
Для всех клиентов может быть использован конфигурационный файл basic-udp-client.conf или basic-udp-client.ovpn. Это, кстати, показывает гибкость конфигурационных файлов OpenVPN. В большинстве случаев нет необходимости изменять файлы конфигурации клиента, даже если макет сети на стороне сервера был изменен или в VPN была добавлена вторичная сеть.
Затем мы запускаем сервер OpenVPN и клиент вторичного офиса и проверяем что файл CCD выбран. Клиент VPN на вторичном офисе может пинговать сервер OpenVPN на его VPN IP-адрес и поэтому может тест пользователь дома.
Заметка
На данный момент VPN работает, а маршрутизация — нет.
Начните с середины и двигайтесь наружу
Наиболее эффективный способ устранения неполадок в этой настройке состоит в том, чтобы рассматривать канал VPN как середину, а затем постепенно выполнять пошаговую работу до тех пор, пока все части сети не будут подключены. Во-первых, есть несколько тестов для выполнения на клиенте OpenVPN в дополнительном офисе. Почти для всех тестов достаточно простой команды ping.
Обратите внимание, что нет смысла переходить ко второму тесту, если первый не пройден, и, аналогично к третьему, если второй еще не работает:
-
Может ли клиент достичь IP-адреса VPN сервера?
Это должно функционировать; в противном случае существует проблема с нашим VPN. Это может быть очень ограниченная настройка брандмауэра/iptables на сервере. IP-адрес VPN-сервера должен быть приватным (как правило RFC1918) и, следовательно, не будет маршрутизируемым через общий Интернет. -
Может ли клиент получить доступ к IP-адресу сервера в локальной сети?
Если это не работает, то, скорее всего, существует правило брандмауэра или iptables, которое блокирует доступ. Проверьте входящие правила или попробуйте отключить правила брандмауэра для отладки. -
Может ли клиент достичь IP-адреса шлюза на стороне сервера?
Если нет, то проверьте ответы на следующие вопросы:
- На сервере включена переадресация IP?
- Существует ли правило брандмауэра/iptables, блокирующее перенаправление доступа к серверу с определенного диапазона IP-адресов?
- Существует ли на межсетевом шлюзе правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (Это было бы хорошей политикой безопасности.) Если это так, то ее необходимо настроить на разрешение трафика, поступающего с VPN IP 10.200.0.0/24.
- Есть ли обратный маршрут на шлюзе, куда должны возвращаться пакеты, исходящие из VPN? Пакеты с адресом назначения в диапазоне 10.200.0.0/24 следует пересылать на сервер OpenVPN по IP
172.31.1.2на маршрутизатореgateway1. Обратите внимание, что это обычно не так. Фактический синтаксис для добавления такого маршрута к шлюзу зависит от модели и встроенного программного обеспечения используемого маршрутизатора. - Может ли клиент связаться с другим сервером в локальной сети на стороне сервера?
Если нет, то проверьте ответы на следующие вопросы:
- Имеет ли этот сервер в локальной сети на стороне сервера правильный шлюз в качестве шлюза по умолчанию?
- Существует ли на сервере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)
Убедившись, что клиент может получить доступ ко всем машинам в локальной сети на стороне сервера — пришло время убедиться что обратное также верно. Убедитесь, что сервер OpenVPN может получить доступ ко всем машинам в локальной сети за вторичным клиентом. Тесты для выполнения очень похожи:
- Может ли сервер достичь IP-адреса VPN клиента?
Это должно функционировать; в противном случае существует проблема с нашим VPN. Это может быть очень ограниченная настройка брандмауэра/iptables на клиенте. Тем не менее, на данный момент это вряд ли будет проблемой. Но лучше перестраховаться, чем потом жалеть, так что давайте проверим это.
- Может ли сервер получить доступ к IP-адресу локальной сети клиента?
Если это не работает, то, скорее всего, существует правило брандмауэра/iptables, которое блокирует доступ. Проверьте входящие правила.
- Может ли сервер достичь IP-адреса шлюза на стороне клиента?
Если нет, то проверьте ответы на следующие вопросы:
- Включена ли переадресация IP на клиенте вторичного офиса?
Существует ли правило брандмауэра/iptables, блокирующее перенаправление доступа на клиенте из определенного диапазона IP-адресов? - Есть ли на клиентском шлюзе правило брандмауэра, блокирующее доступ с IP-адресов не из локальной сети? (Это было бы хорошей политикой безопасности.) Если это так, то ее необходимо отрегулировать так, чтобы трафик приходил с VPN IP
10.200.0.1. -
Есть ли обратный маршрут на шлюзе во вторичном офисе, чтобы сообщить ему, куда должны возвращаться пакеты, исходящие из VPN? Пакеты с адресом источника
10.200.0.1должны быть перенаправлены клиенту OpenVPN по IP192.168.3.17на маршрутизатореgateway2. Обратите внимание, что это обычно не так. Фактический синтаксис для добавления такого маршрута к шлюзу зависит от модели и встроенного программного обеспечения используемого маршрутизатора. Также обратите внимание, что мы разрешаем проходить только пакетам с самого сервера OpenVPN, так как все остальные клиенты не требуют доступа к его сети. - Может ли сервер OpenVPN подключиться к другому компьютеру в локальной сети на стороне клиента?
Если нет, то проверьте ответы на следующие вопросы:
- Имеет ли этот сервер в локальной сети на стороне клиента надлежащий шлюз в качестве шлюза по умолчанию?
- Существует ли на сервере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)
На этом этапе клиент OpenVPN в дополнительном офисе должен иметь доступ ко всем машинам в локальной сети на стороне сервера, а сервер OpenVPN в главном офисе должен иметь доступ ко всем машинам в локальной сети на стороне клиента. Есть только еще один шаг: убедитесь, что серверы в локальной сети на стороне сервера могут обращаться к серверам в локальной сети на стороне клиента и наоборот. Опять же, нужно выполнить четыре теста, начиная с компьютера в локальной сети на стороне сервера:
- Может ли эта машина достичь IP-адреса VPN клиента OpenVPN?
Это должно сработать, так как клиент может добраться до этой машины в результате четвертого теста. Однако лучше перестраховаться, чем сожалеть, так что давайте проверим это.
- Может ли эта машина получить доступ к IP-адресу локальной сети клиента?
Если это не работает, то, скорее всего, существует правило брандмауэра или iptables, которое блокирует доступ. Проверьте входящие правила на клиенте OpenVPN. Может ли сервер локальной сети достичь IP-адреса шлюза на стороне клиента?
Если нет, то проверьте ответы на следующие вопросы:
- Включена ли переадресация IP на клиенте вторичного офиса? Существует ли правило брандмауэра/iptables, блокирующее перенаправление доступа на клиенте для определенного диапазона IP-адресов? Обратите внимание, что пакеты, поступающие с компьютера в локальной сети на стороне сервера, будут иметь адрес источника (
172.31.1.X), отличный от адреса самого сервера OpenVPN (10.200.0.1). - Есть ли на клиентском шлюзе правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (Это было бы хорошей политикой безопасности.) Если это так, то ее необходимо настроить, чтобы разрешить трафик, поступающий из диапазона IP-адресов локальной сети
172.31.1.0/24. Точно так же может потребоваться добавить правило брандмауэра на шлюзе на стороне сервера, чтобы разрешить трафик, поступающий из диапазона IP-адресов локальной сети192.168.3.0/24на стороне клиента. -
Есть ли обратный маршрут на шлюзе во вторичном офисе, для сообщения ему куда должны возвращаться пакеты, исходящие из VPN? Пакеты с адресом источника
172.31.1.0/24должен быть перенаправлен клиенту OpenVPN по IP192.168.3.17на маршрутизатореgateway2. Обратите внимание, что это обычно не так. - Может ли сервер на стороне сервера подключиться к другому компьютеру на стороне клиента?
Если нет, то проверьте ответы на следующие вопросы:
- Имеет ли сервер в локальной сети на стороне клиента надлежащий шлюз в качестве шлюза по умолчанию?
- Существует ли на клиентском компьютере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)
Методично прорабатывая все эти шаги, мы можем решить практически все проблемы маршрутизации. В некоторых случаях могут потребоваться более продвинутые методы отладки. Это может потребовать от нас временно отключить правила брандмауэра, поэтому перед попыткой сделать это следует соблюдать особую осторожность.
Найдите время, чтобы временно отключить брандмауэр
В списках рассылки OpenVPN было слишком много случаев, когда люди не могли заставить маршрутизацию работать, и это оказалось слишком ограничительным правилом брандмауэра или iptables. Нет необходимости отключать все правила брандмауэра, но если вы застряли на одном из двенадцати шагов, перечисленных ранее, то попробуйте отключить брандмауэр, связанный с устройством, которое вы не можете достичь или с которого вы отправляете трафик.
Заметка
Если вам нужно использовать настройку NATted, убедитесь, что вы не отключаете правила NATting.
Если ничего не помогает, используйте tcpdump
Низкоуровневый сетевой инструмент tcpdump — отличный инструмент для проверки подключения. Для устранения проблем с маршрутизацией мы можем использовать tcpdump, чтобы увидеть, поступает ли какой-либо трафик в конкретный сетевой интерфейс или покидает его, и мы можем проверить адреса источника и назначения этого трафика. На клиенте или сервере Windows может быть проще запустить Wireshark (http://www.wireshark.org), который предоставляет аналогичные функции, включая графический интерфейс.
В двенадцати шагах, перечисленных ранее, могут помочь следующие операторы tcpdump:
- Запустите
tcpdump -nnel -i tun0на сервере, чтобы увидеть, поступает ли вообще какой-либо трафик через VPN. - Запустите
tcpdump -nnel -i eth0на сервере (гдеeth0— интерфейс локальной сети используемого сервера), чтобы увидеть, поступает ли вообще какой-либо трафик на интерфейс локальной сети. Если нет, то, скорее всего, правило брандмауэра отбрасывает входящий трафик на туннельном интерфейсе. - Запустите
tcpdump -nnel -i eth0на сервере, чтобы проверить, покидает ли трафик интерфейс LAN с помощью следующего:
source address = 10.200.0.200
destination address = 172.31.1.254
Также проверьте, видим ли мы обратный трафик от серверного шлюза с обратными адресами отправителя и получателя.
- Снова запустите
tcpdump -nnel -i eth0на сервере, чтобы проверить, покидает ли трафик интерфейс локальной сети со следующими заголовками пакетов:
source address = 10.200.0.200
destination address = 172.31.1.XXX
Здесь 172.31.1.XXX — это IP-адрес компьютера, к которому мы пытаемся подключиться в локальной сети на стороне сервера. Есть ли обратный трафик?
И так далее и так далее для оставшихся шагов!
Как оптимизировать производительность с помощью ping и iperf
Получить максимальную производительность из установки OpenVPN может быть сложно. В чистой сети Ethernet стандартные настройки OpenVPN довольно хороши. Однако в гигабитных сетях требуется некоторая настройка.
Когда используется ADSL или кабельное модемное соединение, производительность также обычно довольно хорошая. Однако при определенных обстоятельствах производительность нашего туннеля OpenVPN может значительно отставать от производительности обычной сети. Эти обстоятельства почти всегда зависят от интернет-провайдера, но, тем не менее, стоит изучить как повысить производительность.
Ключом к оптимизации производительности является наличие хороших инструментов для измерения производительности. Два основных, но бесценных инструмента для измерения производительности сети — это ping и iperf. Инструмент iperf легко доступен в Linux, FreeBSD и Mac OS. Есть порты, доступные для Windows и даже Android.
Использование ping
Используя ping мы можем определить оптимальный размер MTU для нашей сети. Большинство сетевых операторов сейчас предоставляют своим клиентам MTU для Ethernet размером 1500 байт. Это приводит к полезной нагрузке пакета в 1472 байта. Остальные 28 байтов являются издержками TCP/IP для таких вещей, как адрес источника и назначения.
Однако если между клиентом и сервером существует сеть с более низким MTU, то это может значительно повысить производительность, уменьшив размер пакетов OpenVPN чуть ниже этого размера. Чтобы определить максимальный размер передачи для нашей сети, мы используем следующее:
$ ping -M do -s 1472 www.example.org
В Windows мы используем следующее:
C:> ping -f -l 1472 www.example.org
Она будет отправлять ICMP-пакеты на удаленный сервер по нашему выбору с установленным флагом not fragment, инструктируя сетевые маршрутизаторы не разбивать этот пакет на более мелкие биты. Если между клиентом и сервером есть сеть с меньшим MTU, то команда ping завершится неудачно:
$ ping -M do -s 1472 www.example.org
PING www.example.org (IP) 1472(1500) bytes of data.
ping: local error: Message too long, mtu=1480
Это говорит нам о том, что производительность будет, скорее всего, лучше, если мы используем либо фрагмент размером 1480, либо размер MTU 1480 байт вместо значения по умолчанию 1500. Обратите внимание, что это не является гарантией — только измерив фактическую производительность VPN, мы узнаем, каково влияние на самом деле.
Использование iperf
Используя iperf мы можем измерить производительность сети как внутри, так и вне VPN-туннеля. Это даст нам ценную информацию о том, сколько пропускной способности мы тратим, используя VPN-туннель.
Прежде чем измерять производительность самого VPN-туннеля, всегда пытайтесь измерить производительность нормальной сети. Будет довольно сложно заставить VPN работать лучше чем базовая сеть.
Сначала запустите iperf на сервере с помощью следующей команды:
Затем запустите iperf на клиенте с помощью следующей команды:
$ iperf -c openvpn.example.org
В кабельной сети, которая использовалась для тестирования, результат выглядит следующим образом:
Это на самом деле скорость загрузки используемого кабельного соединения. Теперь мы можем проверить производительность VPN-туннеля в той же сети:
[ 3] 0.0-10.8 sec 5.25 MBytes 4.09 Mbits/sec
Повторение измерения дает очень похожие цифры, поэтому справедливо утверждать, что производительность VPN-туннеля на несколько процентов ниже производительности базовой сети. Это на самом деле имеет смысл, так как использование VPN действительно создает некоторые накладные расходы для инкапсуляции, шифрования и аутентификации (подписи) исходных данных. Это будет трудно для дальнейшей оптимизации этой сети.
Аналогично, для скорости загрузки используемого кабельного соединения мы обнаруживаем, что производительность VPN-туннеля на несколько процентов ниже:
Производительность базовой сети показана следующим образом:
[ 4] 0.0-10.6 sec 51.6 MBytes 40.7 Mbits/sec
Теперь сравните это с VPN-туннелем:
[ 4] 0.0-10.7 sec 49.5 MBytes 39.0 Mbits/sec
Опять же, мы видим снижение производительности на 4,5 процента.
Теперь мы можем использовать параметры fragment и mssfix, чтобы посмотреть сможем ли мы повысить производительность. Там будет немного проб и ошибок для поиска подходящего места для конкретной установки. Неизвестно, какое именно место будет заранее, но метод его определения всегда один и тот же. Теперь добавьте параметры в файлы конфигурации клиента и сервера:
Делая это и изменяя X, мы получаем следующие результаты:
| X (bytes) | Download (Mbps) | Upload (Mbps) |
|---|---|---|
| 1200 | 37.9 | 3.94 |
| 1300 | 38.1 | 4.01 |
| 1400 | 38.4 | 4.04 |
| 1472 | 38.8 | 4.06 |
| 1500 | 37.6 | 3.98 |
| 39.0 | 4.09 |
Мы можем заключить, что настройки OpenVPN по умолчанию — самое приятное место для этой сети. Мы могли бы повторить это упражнение, изменив параметр tun-mtu но мы получили бы тот же результат. Однако рекомендуется сначала настроить производительность с помощью параметра fragment, поскольку этот параметр меньше влияет на пересылку пакетов.
Гигабитная сеть
Теперь мы выполним ту же процедуру в неиспользуемой сети Gigabit Ethernet. Производительность iperf базовой сети составляет 950 Мбит/с вверх и вниз.
Когда мы запускаем сервер OpenVPN с помощью конфигурации basic-udp-server.conf и подключаем к нему клиента с помощью файла конфигурации basic-udp-client.conf, мы достигаем следующей производительности iperf:
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 193 MBytes 161 Mbits/sec
[ 4] 0.0-10.0 sec 242 MBytes 203 Mbits/sec
Сейчас наблюдается явное падение производительности. К сожалению, снижение параметра fragment нам здесь не поможет. С fragment 1200 мы достигаем 149 Мбит/с и 115 Мбит/с соответственно.
В высокоскоростных сетях также имеет смысл поэкспериментировать с шифром кодирования. Оба сервера, используемые в этом примере, способны выполнять быстрые инструкции AES благодаря расширению AES-NI, которое присутствует в процессорах (Xeon E5 2620 с тактовой частотой 2 ГГц и Xeon E5 2643 с тактовой частотой 3,5 ГГц, соответственно). Давайте добавим следующее:
Теперь мы получаем следующий результат:
[ 5] 0.0-10.0 sec 316 MBytes 265 Mbits/sec
[ 4] 0.0-10.0 sec 266 MBytes 223 Mbits/sec
На способном процессоре шифр оказывает большое влияние на производительность. Поскольку OpenVPN является монолитной программой — большое количество ядер не помогает вообще. Тактовая частота процессора является доминирующим фактором. Подключив ноутбук Core i7 с тактовой частотой 3,8 ГГц к серверу Xeon E5-2643 с частотой 3,5 ГГц, мы получаем гораздо более высокую пропускную способность, используя точно такую же конфигурацию:
[ 5] 0.0-10.0 sec 707 MBytes 593 Mbits/sec
[ 4] 0.0-10.0 sec 529 MBytes 443 Mbits/sec
Таким образом, если вы хотите настроить туннель OpenVPN через высокоскоростную сеть, то лучший совет — использовать высокопроизводительные ЦП, которые поддерживают набор инструкций AES-NI. С такой настройкой можно достичь скорости сети более 500 Мбит/с в обоих направлениях.
Анализ трафика OpenVPN с помощью tcpdump
Низкоуровневый сетевой инструмент tcpdump или его аналог Wireshark с графическим интерфейсом является последним средством для устранения неполадок и производительности сети. В этом разделе мы рассмотрим процесс захвата и анализа зашифрованного сетевого трафика, создаваемого OpenVPN.
Сначала мы настраиваем нашу стандартную сеть OpenVPN, используя конфигурационные файлы basic-udp. На клиенте также работает веб-сервер. Мы будем использовать команду wget на стороне сервера, чтобы извлечь файл с веб-сервера, чтобы мы могли посмотреть на полученный сетевой трафик.
Мы запускаем tcpdump на интерфейсе Ethernet и собираем сетевой трафик, выполняя wget вне туннеля:
wget -O /dev/null https://CLIENT-IP/test1
Результирующий вывод tcpdump выглядит следующим образом (для ясности изменен):
Как мы видим, существует 13 пакетов для передачи текстового файла размером 5 КБ. Большинство из этих пакетов были использованы для установки и разрыва соединения, но есть четыре больших пакета, которые были использованы для фактической передачи данных. Первые три из четырех пакетов имеют размер 1514 байт, что является максимальным размером пакета Ethernet.
Далее мы запускаем ту же команду wget внутри туннеля. Теперь мы наблюдаем зашифрованный трафик на адаптере Ethernet:
Здесь мы видим 22 захваченных пакета. Первый и последний два пакета являются heartbeat пакетами OpenVPN и могут игнорироваться. Оставшиеся 18 пакетов являются зашифрованным эквивалентом пакетов, показанных в первом выводе tcpdump. Как мы видим здесь, длина пакета немного меньше, и особенно payload каждого пакета немного меньше: самый большой пакет payload UDP составляет 1445 байтов. Эти 1445 байт содержат зашифрованные и подписанные данные из команды wget. В нашей настройке мы не указали параметр fragment — это означает, что OpenVPN 2.3 по умолчанию будет иметь внутреннюю фрагментацию 1450 байт.
Общий размер каждого пакета никогда не превышает 1487 байтов, что довольно близко к оптимальному: обычно пакеты не должны превышать размер MTU, который составляет 1500 байтов.
Этот дамп экрана tcpdump также показывает что фрагментации не происходит, кроме как внутри OpenVPN. Это хорошо, поскольку мы хотим избежать фрагментации пакетов операционной системой или сетью для максимальной производительности. Если бы мы видели здесь фрагментацию пакетов, то это было бы отличным признаком того, что нам нужно было добавить дополнительную фрагментацию в нашу конфигурацию OpenVPN.
Давайте посмотрим, что произойдет, если мы добавим fragment 1400 в нашу настройку. Мы перезапускаем сервер и клиент и снова запускаем команду wget:
С добавленным в нашу настройку fragment 1400 мы можем видеть в выводе tcpdump что полезная нагрузка пакета теперь составляет 1397 байт, что очень близко к пределу 1400. Мы также видим, что теперь требуется больше пакетов для передачи текстового файла размером 5 КБ по туннелю, что означает снижение производительности. Из этого снимка экрана мы можем сделать вывод, что нам следует снова удалить параметр.
Из предыдущего скриншота и предыдущего мы также можем сделать вывод, что каждый пакет OpenVPN несет 42-байтовые издержки. Эти издержки частично способствуют накладным расходам, возникающим при использовании любого решения VPN. Он включает в себя всю служебную информацию, поскольку все сетевые пакеты должны содержать служебную информацию об адресе источника, адресе назначения, типе пакета, контрольные суммы, флаги и многое другое.
Наконец, давайте посмотрим на содержимое реального зашифрованного пакета OpenVPN. Для этого удобно использовать инструмент Wireshark (http://www.wireshark.org). Wireshark в основном предоставляет графический интерфейс поверх низкоуровневого инструмента tcpdump. Он может декодировать содержимое большинства типов сетевого трафика, как мы можем видеть на следующем снимке экрана (снимок экрана был анонимным по соображениям конфиденциальности):
Этот скриншот говорит нам следующее:
- Фактический размер пакета составляет 1487 байт.
- Он содержит заголовки Ethernet и IPv4, как и любой сетевой пакет в сети Ethernet.
- Это пакет OpenVPN с исходным портом 35400 и портом назначения 1194 — это означает, что он перемещается от клиента к серверу. На самом деле это один из зашифрованных пакетов при передаче файла размером 5 КБ с клиента на сервер.
- Полезной нагрузкой пакета является пакет данных OpenVPN (формат версии 1) с размером полезной нагрузки 1487 байт. Обратите внимание, что tcpdump сообщил о 1488 байтах ранее, но Wireshark может декодировать полезную нагрузку и увидеть, что первый байт является кодом операции OpenVPN.
Этот пакет будет получен OpenVPN, проверен на аутентификацию, расшифрован и распакован (если мы указали). Полученный незашифрованный пакет затем перенаправляется в таблицы маршрутизации операционной системы, которые решают, куда направить пакет. В нашем случае пакет останется на сервере и будет передан процессу wget.
Резюме
В этой главе вы познакомились с некоторыми основными приемами устранения неполадок и настройки OpenVPN. Вы также получили представление о чтении файлов журналов клиента и сервера. Вы узнали как обнаружить и исправить некоторые из наиболее часто совершаемых ошибок. Большинство вопросов в списке рассылки OpenVPN касаются проблем маршрутизации — поэтому мы обсудили обнаружение и устранение проблем маршрутизации. Наконец, существует большая разница между работающей установкой и хорошо работающей установкой, поэтому мы рассмотрели примеры того, как обнаруживать и решать проблемы с производительностью.
Конечно, OpenVPN не идеален и поэтому ваша нерабочая настройка также может быть вызвана ошибкой в самом OpenVPN. Существует несколько каналов для сообщения об ошибках, включая список электронной почты (openvpn-users@lists.sourceforge.net), канал IRC (#openvpn на freenode.net IRC) и веб-сайт форума (https://forums.openvpn.net). Вы также можете отправлять запросы на функции или списки пожеланий на эти каналы, некоторые из которых могут появиться в будущей версии OpenVPN.
В следующей главе вы узнаете, что нового можно ожидать в следующих выпусках OpenVPN. Вы также узнаете, какие в настоящее время известны проблемы с базой кодов OpenVPN, и узнаете о планах по устранению этих проблем.