std::strerror() doesn't claim to be thread-safe, so
add openvpn::strerror_str() which is thread-safe by
virtue of the fact that it backs to strerror_r().
Signed-off-by: James Yonan <james@openvpn.net>
A common AsioTimer usage pattern is:
expires_at(Time::now() + duration)
This is more succinctly and efficiently stated as:
expires_after(duration).
Signed-off-by: James Yonan <james@openvpn.net>
* Automatically overflow to dynamic allocation if function
object is too large.
* Added optional N and INTERN_ONLY parameters to fine-tune
internal allocation.
* Added default constructor.
* Added move assignment method.
* Added reset() methods.
* Added operator bool() method to test if functor has
been defined.
Signed-off-by: James Yonan <james@openvpn.net>
Created a lightweight abstraction layer so that another i/o
reactor can be dropped in place of asio.
The basic approach is to rename all references to asio::xxx
types to openvpn_io::xxx and then make openvpn_io a
preprocessor variable that points to the top-level namespace
of the i/o reactor implementation.
All of the source files that currently include <asio.hpp> now
include <openvpn/io/io.hpp> instead:
This gives us a lightweight abstraction layer that allows us
to define openvpn_io to be something other than asio.
Other changes:
* Inclusion of asio by scripts/build is now optional, and is
enabled by passing ASIO=1 or ASIO_DIR=<dir>.
* Refactored openvpn/common/socktypes.hpp to no longer
require asio.
* Refactored openvpn/log/logthread.hpp to no longer require
asio.
* Added openvpn::get_hostname() method as alternative to
calling asio directly.
* openvpn/openssl/util/init.hpp will now #error
if USE_ASIO is undefined.
Signed-off-by: James Yonan <james@openvpn.net>
user-defined service objects. This commit attempts
to work around that but requires a specially patched
version of Asio that includes the virtual
async_connect_post_open() method.
The asio::io_context::work class has been replaced by a new
class having somewhat different and more verbose
semantics.
We create our own class AsioWork based on the new class
asio::executor_work_guard<asio::io_context::executor_type>
that implements the semantics of the original
asio::io_context::work class.
mutable_buffers_1 -> mutable_buffer
const_buffers_1 -> const_buffer
This patch is a granularization of a patch by David Sommerseth
<davids@openvpn.net> where only the above renames are included.
construction even when user/group lookup fails.
Updated calls to std::strerror() to use a saved version
of errno.
Added chown(), gid(), and additional defined() methods.
Use uid_t as the return type for uid().
to HTTP CONNECT but implemented over the OpenVPN protocol.
1. Client connects to relay server as if it were connecting
to an ordinary OpenVPN server.
2. Client authenticates to relay server using its client
certificate.
3. Client sends a PUSH_REQUEST method to relay server which
then replies with a RELAY message instead of PUSH_REPLY.
4. On receiving the RELAY message, the client attempts to
reconnect using the existing transport socket. The
server will proxy this new connection (at the transport
layer) to a second server (chosen by the relay server)
that is the target of proxy.
5. The client must establish and authenticate a new session
from scratch with the target server, only reusing the
transport layer socket from the original connection to
the relay server.
6. The relay acts as a man-in-the-middle only at the
transport layer (like most proxies), i.e. it forwards
the encrypted session between client and target server
without decrypting or having the capability to decrypt
the session.
7. The client is designed to protect against potentially
untrusted or malicious relays:
(a) The client never transmits the target server
username/password credentials to the relay server.
(b) The relay forwards the encrypted OpenVPN session
between client and target server without having
access to the session keys.
(c) The client configuration has a special directive
for relay server CA (<relay-extra-ca>) and relay
server tls-auth key (<relay-tls-auth>) to allow
for separation of TLS/crypto configuration between
relay and target servers.
(d) The client will reject any PUSH_REPLY messages
from the relay itself to prevent the relay from
trying to establish a tunnel directly with the
client.
Example configuring a client for relay:
# remote addresses point to the relay server
remote ... 1194 udp
remote ... 443 tcp
# include all other directives for connecting
# to the target server
# enable relay mode
relay-mode
# constrain the relay server's cert type
relay-ns-cert-type server
# include extra CAs that validate the relay
# server cert (optional).
<relay-extra-ca>
-----BEGIN CERTIFICATE-----
. . .
-----END CERTIFICATE-----
</relay-extra-ca>
# specify the TLS auth key for the relay server
relay-key-direction 1
<relay-tls-auth>
-----BEGIN OpenVPN Static key V1-----
. . .
-----END OpenVPN Static key V1-----
</relay-tls-auth>
