VPN

Package wgctrl enables control of WireGuard devices on multiple platforms. For more information on WireGuard, please see https://www.wireguard.com/. wgctrl can control multiple types of WireGuard devices, including: As new operating systems add support for in-kernel WireGuard implementations, this package should also be extended to support those native implementations. If you are aware of any efforts on this front, please file an issue: https://github.com/WireGuard/wgctrl-go/issues/new. This package implements WireGuard configuration protocol operations, enabling the configuration of existing WireGuard devices. Operations such as creating WireGuard devices, or applying IP addresses to those devices, are out of scope for this package.

Command tlstun implements basic VPN over TLS (both client and server). Client part is expected to be run locally and used by local services as a socks5 proxy. Client establishes TLS session to the server running on some remote host that performs outgoing requests on behalf of requests made to the client. Communication between client and server is multiplexed over a single TLS session thus reducing TLS handshake overhead. Client and server authenticate each other with certificates which can be created with openssl or https://github.com/artyom/gencert Generate server and client side certificates, they should be signed by the same CA and saved using PEM encoding into a single file with certificate followed by CA. Certificate keys should also be saved as a separate PEM-encoded files. With gencert tool from https://github.com/artyom/gencert this can be done as: This produces four files in the current directory: client certificate + key pair and another pair for the server. Note that my.domain.tld should point to the host you plan running server part of tlstun. Now configure tlstun to run on the server that could be reached at my.domain.tld like this: The client part is expected to be running locally (on a laptop/workstation, etc.): The presence of -remote flag configures tlstun to run in client mode. It is now listening on localhost port 1080 and local software can be configured to use this endpoint as a socks5 proxy. Note that -remote flag can be optionally set multiple times, then client probes all servers and picks the one that replied first. If connections multiplexing over a single TLS session is not needed (i.e. because of the head-of-line blocking effect), -nomux flag can be set, which disables multiplexing and uses one TLS session per connection. Note that use of this flag must be synchronized on client and server. You may force server side do all DNS lookups over Cloudflare's DNS over TLS on 1.1.1.1 and 1.0.0.1 with -cfdns flag.

Command tlstun implements basic VPN over TLS (both client and server). Client part is expected to be run locally and used by local services as a socks5 proxy. Client establishes TLS session to the server running on some remote host that performs outgoing requests on behalf of requests made to the client. Client and server authenticate each other with certificates which can be created with openssl or https://github.com/artyom/gencert Generate server and client side certificates, they can be signed by the same CA and saved using PEM encoding into a single file. Certificate keys should also be saved as a separate PEM-encoded files. With gencert tool from https://github.com/artyom/gencert this can be done as: This produces five files in the current directory: client certificate + key pair, another pair for the server and a certificate authority certificate. Note that my.domain.tld should point to the host you plan running server part of tlstun. Now configure tlstun to run on the server that could be reached at my.domain.tld like this: The client part is expected to be running locally (on a laptop/workstation, etc.): Client is now listening on localhost port 1080 and local software can be configured to use this endpoint as a socks5 proxy. Client may be configured to work with multiple servers: By default client will periodically evaluate all endpoints and prefer one which replies first. This check may be disabled with -no-check flag. Instead of listing endpoints directly, client may discover them from SRV DNS records. If -discover=domain.tld flag is set, client ignores any endpoints given on the command line and instead looks up SRV record _tlstun._tcp.domain.tld, which must follow standard format to specify host/port pairs. Server may be configured to automatically issue certificate from ACME provider (currently is's Let's Encrypt). For this to work, server must be exposed over port 443 and it also doubles as an https endpoint. By default it replies with 404 Not Found, but can optionally be configured to serve static files from file system directory: Server may also be run with -dns-tls flag, which enables resolving via DNS-over-TLS providers (currently Cloudflare, Quad9, LibreDNS).

Checks for any conflicting routes inserted by VPN that are required for WSL and overwrites them in order to have networking support for WSL available also when connected to VPN