| | 59 | |
| | 60 | = OpenVPN 3.0: Design and implementation = |
| | 61 | |
| | 62 | OpenVPN 3.0 architecture would look something like this. This picture and following description may not match James' original ideas 100%, so this page will be updated as necessary. |
| | 63 | |
| | 64 | {{{ |
| | 65 | (TCP/UDP port) |
| | 66 | /\ |
| | 67 | || "Plug-ins" or modules |
| | 68 | || |
| | 69 | \/ |
| | 70 | +-------------+ |
| | 71 | | OpenVPN 3.0 | +------------+ |
| | 72 | | core engine |<-->| SSL module | |
| | 73 | | | +------------+ |
| | 74 | | | |
| | 75 | | | +----------------+ |
| | 76 | | |<-->| Authentication | |
| | 77 | | | +----------------+ |
| | 78 | | | |
| | 79 | | | +---------+ |
| | 80 | | |<-->| Logging | |
| | 81 | | | +---------+ |
| | 82 | | | |
| | 83 | | | +----------------------------+ |
| | 84 | | |<-->| Network protocol & routing | |
| | 85 | | | +----------------------------+ |
| | 86 | | | |
| | 87 | | | +------+ |
| | 88 | | |<-->| ??? | |
| | 89 | | | +------+ |
| | 90 | +-------------+ |
| | 91 | /\ |
| | 92 | || |
| | 93 | || |
| | 94 | \/ |
| | 95 | [TUN/TAP device] |
| | 96 | }}} |
| | 97 | |
| | 98 | |
| | 99 | Openvpn configuration file would define which modules to use. |
| | 100 | |
| | 101 | The SSL module could f.ex. be an OpenSSL, NSS or GNUTLS module, which handles everything which is related to certificates and encryption. |
| | 102 | |
| | 103 | The authentication module would somehow co-operate with the SSL module, but still being able to be used without SSL, but then enabling other types of authentication methods. |
| | 104 | |
| | 105 | A Network protocol and routing module would look at the decrypted packets and do the proper protocol processing of the packets between the TUN/TAP device and the internal OpenVPN "network". This is where the IPv4 and IPv6 stuff would go in. |
| | 106 | |
| | 107 | The logging module can log to file, syslog, a network socket, database connection - depending on the module. If not enabled, no logging whatsoever happens. |
| | 108 | |
| | 109 | If OpenVPN is designed like this, the "OpenVPN core" needs to be completely written from scratch before we can really begin to see something happening. This is also the part where libevent would be implemented. This core becomes an "internal bus" where the traffic is passed between the user-space UDP/TCP socket and the kernel-space TUN/TAP device. The rest of the work happens in the modules. |
| | 110 | |
| | 111 | Something which strikes me here, is that this then could also give a possibility for Linux to write parts of this core as a kernel module (similar to NFS), where this kernel module makes use of a user-space tool for the user-space modules. *BSD and Solaris might have similar possibilities - but where not suitable, a plain user-space daemon will |
| | 112 | also be able to do the task. |
| | 113 | |
| | 114 | Provided this we choose to design OpenVPN as above, we'd need to do the following: |
| | 115 | |
| | 116 | * Define which types of modules OpenVPN core should support. This means modules like, encryption, authentication, networking, routing, logging, etc, etc. Based on the task the module would have. |
| | 117 | * Define/draft the API for the core functions of each module type, and document which modules are chain-able and which are not. |
| | 118 | * Define/draft the core's internal messaging bus for passing data between each of the modules. |
| | 119 | * Implement the core from scratch |
| | 120 | * Rewrite the current OpenVPN 2.x parts which are interesting to pull |
| | 121 | into OpenVPN 3.x, to use the new module API. Then make OpenVPN 2.x |
| | 122 | make use of this API internally - without loading the code as modules. |
