On 04/09/13 18:43, Dmitry Melekhov wrote: > 04.09.2013 20:04, David Sommerseth пишет: >>> - post your server config - try replacing the 'client-connect' >>> script with something like >>> >>> #!/bin/bash exit 1 >>> >>> clients should no longer be able to connect - if they are, you know >>> the client-connect script is not called properly >> That's a good idea. >> >> In addition, other things to check: >> >> - - Do you have --script-security set at a proper level? >> - - Do you use chroot? Is the script/binary available inside the chroot, >> together with all needed dependencies? >> - - Can the user OpenVPN runs as access the script file? (including at >> least +x permissions an all parent directories) >> - - Does the script have execute permission set? (f.ex chmod 755) >> >>> - post your existing client-connect script. >> That's usually always a good idea to do. >> >> >> - -- > Hello! > > May be I'm not completely clear. > connect script usually works, but, as you can see from server log, in > case of connection failures due to low quality link it is just not > executed by server: > > I'll repeat interesting part of log: > > Sep 4 13:46:39 inetgw1 openvpn[2692]: 94.77.49.2:32770 [yuski] Peer > Connection Initiated with [AF_INET]94.77.49.2:32770 (via > [AF_INET]192.168.42.2%vlan2) > Sep 4 13:46:39 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 OPTIONS > IMPORT: reading client specific options from: ccd-udp/yuski > Sep 4 13:46:39 inetgw1 openvpn: yuski sudo route add -net 192.168.113.0 > netmask 255.255.255.0 gw 192.168.205.1 > > all is ok- connect script is executed > > > Sep 4 13:48:33 inetgw1 openvpn[2692]: yuski/94.77.49.2:32768 [UNDEF] > Inactivity timeout (--ping-restart), restarting > Sep 4 13:48:33 inetgw1 openvpn[2692]: yuski/94.77.49.2:32768 > SIGUSR1[soft,ping-restart] received, client-instance restarting > Sep 4 13:48:33 inetgw1 openvpn: yuski sudo route del -net 192.168.113.0 > netmask 255.255.255.0 gw 192.168.205.1 > > Server executed disconnect script. > > > Sep 4 14:46:39 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 TLS: soft > reset sec=0 bytes=1878484/0 pkts=6064/0 > Sep 4 14:46:40 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 CRL CHECK > OK: /C=RU/ST=Udm/L=Izhevsk/O=Belkam/CN=Belkam_CA/emailAddress=d...@belkam.com > Sep 4 14:46:40 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 VERIFY OK: > depth=1, > /C=RU/ST=Udm/L=Izhevsk/O=Belkam/CN=Belkam_CA/emailAddress=d...@belkam.com > Sep 4 14:46:40 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 CRL CHECK > OK: /C=RU/ST=Udm/L=Izhevsk/O=Belkam/CN=yuski/emailAddress=d...@belkam.com > Sep 4 14:46:40 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 VERIFY OK: > depth=0, > /C=RU/ST=Udm/L=Izhevsk/O=Belkam/CN=yuski/emailAddress=d...@belkam.com > Sep 4 14:46:40 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 Data > Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key > Sep 4 14:46:40 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 Data > Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication > Sep 4 14:46:40 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 Data > Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key > Sep 4 14:46:40 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 Data > Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication > Sep 4 14:46:40 inetgw1 openvpn[2692]: yuski/94.77.49.2:32770 Control > Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA > Sep 4 15:39:12 inetgw1 openvpn[2692]: MULTI: Learn: 192.168.113.1 -> > yuski/94.77.49.2:32770 > > As you see- no attempt to execute script. > Why? And how can I prevent this problem?
Ahh! I didn't quite catch that. Okay, --client-connect isn't designed to be called on re-establishments. Only on new connections. That is, a connection which has been through a complete disconnection phase. A complete disconnection can take some time, especially if you use UDP. However I'm puzzled that the --disconnect-client is triggered though, as that should indicate it's been through a complete disconnect. Which means --client-connect should really be called again. To confirm if this is a real bug, we need to see your both your server and client config files, so we can try to reproduce it. Then it's easier to see what's really going on. In the meantime I will recommend you to look at the --learn-address script hook and see if this works more as expected. This should be called each time OpenVPN (re-)learns the clients VPN address. -- kind regards, David Sommerseth
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
