]>
Commit | Line | Data |
---|---|---|
6fbf66fa | 1 | OpenVPN |
ccf9d572 | 2 | Copyright (C) 2002-2023 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 | ||
16d773eb GD |
14 | Tier 1 platforms - actively tested for every source commit, across |
15 | multiple operating system versions | |
16 | ||
17 | * Windows 7 and newer | |
18 | * Windows Server 2012 and newer | |
19 | * Linux | |
6fbf66fa | 20 | * FreeBSD |
16d773eb GD |
21 | * macOS |
22 | ||
23 | Tier 2 platforms - it worked at some point, but is not actively tested | |
24 | on "latest OS, latest OS libraries" so might break if larger changes | |
25 | are done on the platform side | |
26 | ||
27 | * OpenBSD | |
6fbf66fa | 28 | * NetBSD |
16d773eb GD |
29 | * DragonFly BSD |
30 | * Solaris | |
31 | * AIX | |
32 | ||
33 | For underlying CPU architecture, everything 32 bit or 64 bit (Intel, AMD, | |
34 | ARM, PowerPC, SPARC*) should work fine. 16 bit Architectures are unlikely | |
35 | to work. | |
36 | ||
6fbf66fa | 37 | |
16d773eb | 38 | PORTING GUIDELINE TO A NEW PLATFORM: |
6fbf66fa JY |
39 | |
40 | * Make sure that OpenSSL will build on your | |
41 | platform. | |
42 | * Make sure that a tun or tap virtual device | |
43 | driver exists for your platform. See | |
44 | http://vtun.sourceforge.net/tun/ for examples | |
45 | of tun and tap drivers that have been written | |
46 | for Linux, Solaris, and FreeBSD. | |
47 | * Make sure you have autoconf 2.50+ and | |
48 | automake 1.6+. | |
49 | * Edit configure.ac, adding platform specific | |
50 | config code, and a TARGET_YOUROS define. | |
51 | * Add platform-specific includes to syshead.h. | |
52 | * Add an #ifdef TARGET_YOUROS to the do_ifconfig() | |
53 | function in tun.c to generate a correct "ifconfig" | |
54 | command for your platform. Note that OpenVPN | |
55 | determines the ifconfig path at ./configure time. | |
16d773eb | 56 | * Possibly add an ifconfig_order() variant for your OS so |
6fbf66fa JY |
57 | openvpn knows whether to call ifconfig before |
58 | or after tun/tap dev open. | |
59 | * Add an #ifdef TARGET_YOUROS block in tun.c and define | |
60 | the open_tun, close_tun, read_tun, and write_tun | |
61 | functions. If your tun/tap virtual device is | |
62 | sufficiently generic, you may be able to use the | |
63 | default case. | |
64 | * Add appropriate code to route.c to handle | |
65 | the route command on your platform. This | |
66 | is necessary for the --route option to | |
67 | work correctly. | |
68 | * After you successfully build OpenVPN, run | |
69 | the loopback tests as described in INSTALL. | |
70 | * For the next test, confirm that the UDP socket | |
71 | functionality is working independently of the | |
72 | tun device, by doing something like: | |
73 | ./openvpn --remote localhost --verb 9 --ping 1 --dev null | |
74 | * Now try with --remote [a real host] | |
75 | * Now try with a real tun/tap device, you will | |
76 | need to figure out the appropriate ifconfig | |
77 | command to use once openvpn has opened the tun/tap | |
78 | device. | |
79 | * Once you have simple tests working on the tun device, | |
80 | try more complex tests such as using TLS mode. | |
81 | * Stress test the link by doing ping -f across it. | |
82 | * Make sure that packet fragmenting is happening | |
83 | correctly by doing a ping -s 2000 or higher. | |
84 | * Ensure that OpenVPN on your platform will talk | |
85 | to OpenVPN on other platforms such as Linux. | |
86 | Some tun/tap driver implementations will prepend | |
87 | unnecessary stuff onto the datagram that must be | |
88 | disabled with an explicit ioctl call if cross-platform | |
89 | compatibility is to be preserved. You can see some | |
90 | examples of this in tun.c. | |
16d773eb GD |
91 | * Try the ultimate stress test which is --gremlin --reneg-sec 10 |
92 | in TLS mode then do a flood ping across the tunnel | |
6fbf66fa JY |
93 | (ping -f remote-endpoint) in both directions and let |
94 | it run overnight. --gremlin will induce massive | |
95 | corruption and packet loss, but you win if you | |
96 | wake up the next morning and both peers are still | |
97 | running and occasionally even succeeding in their | |
98 | attempted once-per-10-seconds TLS handshake. | |
99 | * When it's working, submit your patch to | |
100 | <openvpn-devel@lists.sourceforge.net> | |
101 | and rejoice :) |