mirror of
https://github.com/OpenVPN/openvpn.git
synced 2024-09-19 19:42:30 +02:00
ccf9d57249
Manually excluded ovpn_dco_win.h because it is an imported file. ovpn_dco_linux.h is already excluded because it still says 2021. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com> Acked-by: Gert Doering <gert@greenie.muc.de> Message-Id: <20230110160531.81010-1-frank@lichtenheld.com> URL: https://patchwork.openvpn.net/project/openvpn2/patch/20230110160531.81010-1-frank@lichtenheld.com/ Signed-off-by: Gert Doering <gert@greenie.muc.de>
102 lines
3.8 KiB
Plaintext
102 lines
3.8 KiB
Plaintext
OpenVPN
|
|
Copyright (C) 2002-2023 OpenVPN Inc <sales@openvpn.net>
|
|
|
|
OpenVPN has been written to try to avoid features
|
|
that are not standardized well across different
|
|
OSes, so porting OpenVPN itself will probably be
|
|
straightforward if a tun or tap driver already exists.
|
|
|
|
Where special OS features are used, they are usually
|
|
bracketed with #ifdef HAVE_SOME_FUNCTION.
|
|
|
|
PLATFORM STATUS:
|
|
|
|
Tier 1 platforms - actively tested for every source commit, across
|
|
multiple operating system versions
|
|
|
|
* Windows 7 and newer
|
|
* Windows Server 2012 and newer
|
|
* Linux
|
|
* FreeBSD
|
|
* macOS
|
|
|
|
Tier 2 platforms - it worked at some point, but is not actively tested
|
|
on "latest OS, latest OS libraries" so might break if larger changes
|
|
are done on the platform side
|
|
|
|
* OpenBSD
|
|
* NetBSD
|
|
* DragonFly BSD
|
|
* Solaris
|
|
* AIX
|
|
|
|
For underlying CPU architecture, everything 32 bit or 64 bit (Intel, AMD,
|
|
ARM, PowerPC, SPARC*) should work fine. 16 bit Architectures are unlikely
|
|
to work.
|
|
|
|
|
|
PORTING GUIDELINE TO A NEW PLATFORM:
|
|
|
|
* Make sure that OpenSSL will build on your
|
|
platform.
|
|
* Make sure that a tun or tap virtual device
|
|
driver exists for your platform. See
|
|
http://vtun.sourceforge.net/tun/ for examples
|
|
of tun and tap drivers that have been written
|
|
for Linux, Solaris, and FreeBSD.
|
|
* Make sure you have autoconf 2.50+ and
|
|
automake 1.6+.
|
|
* Edit configure.ac, adding platform specific
|
|
config code, and a TARGET_YOUROS define.
|
|
* Add platform-specific includes to syshead.h.
|
|
* Add an #ifdef TARGET_YOUROS to the do_ifconfig()
|
|
function in tun.c to generate a correct "ifconfig"
|
|
command for your platform. Note that OpenVPN
|
|
determines the ifconfig path at ./configure time.
|
|
* Possibly add an ifconfig_order() variant for your OS so
|
|
openvpn knows whether to call ifconfig before
|
|
or after tun/tap dev open.
|
|
* Add an #ifdef TARGET_YOUROS block in tun.c and define
|
|
the open_tun, close_tun, read_tun, and write_tun
|
|
functions. If your tun/tap virtual device is
|
|
sufficiently generic, you may be able to use the
|
|
default case.
|
|
* Add appropriate code to route.c to handle
|
|
the route command on your platform. This
|
|
is necessary for the --route option to
|
|
work correctly.
|
|
* After you successfully build OpenVPN, run
|
|
the loopback tests as described in INSTALL.
|
|
* For the next test, confirm that the UDP socket
|
|
functionality is working independently of the
|
|
tun device, by doing something like:
|
|
./openvpn --remote localhost --verb 9 --ping 1 --dev null
|
|
* Now try with --remote [a real host]
|
|
* Now try with a real tun/tap device, you will
|
|
need to figure out the appropriate ifconfig
|
|
command to use once openvpn has opened the tun/tap
|
|
device.
|
|
* Once you have simple tests working on the tun device,
|
|
try more complex tests such as using TLS mode.
|
|
* Stress test the link by doing ping -f across it.
|
|
* Make sure that packet fragmenting is happening
|
|
correctly by doing a ping -s 2000 or higher.
|
|
* Ensure that OpenVPN on your platform will talk
|
|
to OpenVPN on other platforms such as Linux.
|
|
Some tun/tap driver implementations will prepend
|
|
unnecessary stuff onto the datagram that must be
|
|
disabled with an explicit ioctl call if cross-platform
|
|
compatibility is to be preserved. You can see some
|
|
examples of this in tun.c.
|
|
* Try the ultimate stress test which is --gremlin --reneg-sec 10
|
|
in TLS mode then do a flood ping across the tunnel
|
|
(ping -f remote-endpoint) in both directions and let
|
|
it run overnight. --gremlin will induce massive
|
|
corruption and packet loss, but you win if you
|
|
wake up the next morning and both peers are still
|
|
running and occasionally even succeeding in their
|
|
attempted once-per-10-seconds TLS handshake.
|
|
* When it's working, submit your patch to
|
|
<openvpn-devel@lists.sourceforge.net>
|
|
and rejoice :)
|