]>
Commit | Line | Data |
---|---|---|
6fbf66fa | 1 | OpenVPN |
1800d77e | 2 | Copyright (C) 2002-2022 OpenVPN Inc <sales@openvpn.net> |
6fbf66fa JY |
3 | |
4 | OpenVPN has been written to try to avoid features | |
5 | that are not standardized well across different | |
6 | OSes, so porting OpenVPN itself will probably be | |
7 | straightforward if a tun or tap driver already exists. | |
8 | ||
9 | Where special OS features are used, they are usually | |
10 | bracketed with #ifdef HAVE_SOME_FUNCTION. | |
11 | ||
12 | PLATFORM STATUS: | |
13 | ||
14 | * Linux 2.2+ (supported) | |
15 | * Solaris (supported) | |
16 | * OpenBSD 3.0 (supported but pthreads are broken) | |
17 | * Max OS X Darwin | |
18 | * FreeBSD | |
19 | * NetBSD | |
20 | * Windows | |
21 | * 64 bit platforms -- I have heard reports that | |
22 | OpenVPN runs on Alpha Linux and FreeBSD. | |
23 | * ARM -- I have heard of at least one case | |
24 | where OpenVPN was successfully built and | |
25 | run on the ARM architecture. | |
26 | ||
27 | PORTING NOTES: | |
28 | ||
29 | * Make sure that OpenSSL will build on your | |
30 | platform. | |
31 | * Make sure that a tun or tap virtual device | |
32 | driver exists for your platform. See | |
33 | http://vtun.sourceforge.net/tun/ for examples | |
34 | of tun and tap drivers that have been written | |
35 | for Linux, Solaris, and FreeBSD. | |
36 | * Make sure you have autoconf 2.50+ and | |
37 | automake 1.6+. | |
38 | * Edit configure.ac, adding platform specific | |
39 | config code, and a TARGET_YOUROS define. | |
40 | * Add platform-specific includes to syshead.h. | |
41 | * Add an #ifdef TARGET_YOUROS to the do_ifconfig() | |
42 | function in tun.c to generate a correct "ifconfig" | |
43 | command for your platform. Note that OpenVPN | |
44 | determines the ifconfig path at ./configure time. | |
45 | * Add an ifconfig_order() variant for your OS so | |
46 | openvpn knows whether to call ifconfig before | |
47 | or after tun/tap dev open. | |
48 | * Add an #ifdef TARGET_YOUROS block in tun.c and define | |
49 | the open_tun, close_tun, read_tun, and write_tun | |
50 | functions. If your tun/tap virtual device is | |
51 | sufficiently generic, you may be able to use the | |
52 | default case. | |
53 | * Add appropriate code to route.c to handle | |
54 | the route command on your platform. This | |
55 | is necessary for the --route option to | |
56 | work correctly. | |
57 | * After you successfully build OpenVPN, run | |
58 | the loopback tests as described in INSTALL. | |
59 | * For the next test, confirm that the UDP socket | |
60 | functionality is working independently of the | |
61 | tun device, by doing something like: | |
62 | ./openvpn --remote localhost --verb 9 --ping 1 --dev null | |
63 | * Now try with --remote [a real host] | |
64 | * Now try with a real tun/tap device, you will | |
65 | need to figure out the appropriate ifconfig | |
66 | command to use once openvpn has opened the tun/tap | |
67 | device. | |
68 | * Once you have simple tests working on the tun device, | |
69 | try more complex tests such as using TLS mode. | |
70 | * Stress test the link by doing ping -f across it. | |
71 | * Make sure that packet fragmenting is happening | |
72 | correctly by doing a ping -s 2000 or higher. | |
73 | * Ensure that OpenVPN on your platform will talk | |
74 | to OpenVPN on other platforms such as Linux. | |
75 | Some tun/tap driver implementations will prepend | |
76 | unnecessary stuff onto the datagram that must be | |
77 | disabled with an explicit ioctl call if cross-platform | |
78 | compatibility is to be preserved. You can see some | |
79 | examples of this in tun.c. | |
80 | * If your system supports pthreads, try building | |
81 | with ./configure --enable-pthread and do a stress | |
82 | test in TLS mode. | |
83 | * Try the ultimate stress test which is --gremlin | |
84 | --reneg-sec 10 in TLS mode (preferably with pthreads | |
85 | enabled), then do a flood ping across the tunnel | |
86 | (ping -f remote-endpoint) in both directions and let | |
87 | it run overnight. --gremlin will induce massive | |
88 | corruption and packet loss, but you win if you | |
89 | wake up the next morning and both peers are still | |
90 | running and occasionally even succeeding in their | |
91 | attempted once-per-10-seconds TLS handshake. | |
92 | * When it's working, submit your patch to | |
93 | <openvpn-devel@lists.sourceforge.net> | |
94 | and rejoice :) |