aboutsummaryrefslogtreecommitdiff
path: root/sample-keys/dh1024.pem
diff options
context:
space:
mode:
authorGert Doering <gert@greenie.muc.de>2010-08-08 21:24:30 +0200
committerDavid Sommerseth <dazo@users.sourceforge.net>2010-10-21 11:40:36 +0200
commit186f9a76fddfd7309fcb0e4a15e3498b37b16838 (patch)
tree6aa795d1c4fe151c391e928692f11ddfaf87871f /sample-keys/dh1024.pem
parentFixes openssl-1.0.0 compilation warning (diff)
downloadopenvpn-186f9a76fddfd7309fcb0e4a15e3498b37b16838.tar.xz
full "VPN client connect" test framework for OpenVPN
Run from "make check" if "t_client.rc" is found in workdir or srcdir (copy t_client.rc-sample, fill in specifics for your test server) How does it work? - you run "sudo make check" (needs root access to configure tun if!) - t_client.sh reads t_client.rc from current dir or ${srcdir} - t_client.rc defines a number of "test suffixes" to run (could be "1" "2" "3" or "p2m", "p2p", "special" or whatever you like), and for each suffix, there's config variables to specify - how to call OpenVPN - which hosts to ping for IPv4 and IPv6 when OpenVPN is up (and actually before starting OpenVPN - to make the test more meaningful, I have decided that the test hosts must not ping before the tests starts) - which addresses must show up in the output of "ifconfig" after OpenVPN has started - all variables except OPENVPN_CONF_<x> are optional (this should all be fairly obvious from looking at t_client.rc-sample) - the script wants to connect to a well-defined OpenVPN server that will assign well-known IPv4 (and IPv6) addresses, have well-defined pingable addresse, etc. - so you need to setup the test server before the script is useful for you. (Whether you use certificates or username/password is up to you, you could even mix and match - run one test with certs, and one with user/pass against different target ports... :-) ) [we *could* run a "reference server" somewhere and ship a sample t_client.rc + cert so that users could use this right away, but I do not currently have the resources to run such a public server] - whatever the script does is logged to a newly created directory below the current directory (openvpn output, ifconfig+route before starting OpenVPN, while running it, after ending it) - important: at least on NetBSD and OpenBSD, the script will print one failure, because the tun0 interface created is not destroyed after openvpn ends. For OpenBSD, I have changed close_tun() to do so ("ifconfig tun0 destroy"), for NetBSD I have not yet changed anything - but I strongly believe that the output of "ifconfig+route" should be reverted to exactly how it looked like before OpenVPN was started, so I consider this a bug in the NetBSD-specific bits of OpenVPN (and will look into this). - the test framework has been tested on Linux, NetBSD and OpenBSD. It *should* work fine on FreeBSD and Solaris. It works on MacOS X (but the output looks funny, because /bin/sh does not implement "echo -e" - need to add configure trickery) It will *not* work on Windows yet - I haven't looked into what's needed to make it work (background processes and signals in mingw bash?), maybe it's as easy as adding the necessary "ipconfig" and "netsh" commands to print interface + routing config... - I have only tested "connect via IPv4 transport, use IPv4+IPv6 payload", but the framework is generic enough that "connect via IPv6 transport" should work just fine (just setup OPENVPN_CONF_x accordingly in the t_client.rc). - this is neither finished nor pretty, but it helps me a *lot* in quickly testing whether I broke anything when fiddling system-dependent code (tun.c, route.c) across multiple build hosts - so I hope this is going to be fairly useful to Samuli and the buildbot :-) Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: David Sommerseth <dazo@users.sourceforge.net> Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
Diffstat (limited to 'sample-keys/dh1024.pem')
0 files changed, 0 insertions, 0 deletions