Add support for freebsd. You have to set `tun.dev` in your config. The second pass of this would be to remove the exec calls and use ioctl(2) and route(4) instead, but we can do that in a second PR.
Co-authored-by: Wade Simmons <wade@wades.im>
These settings make it possible to blacklist / whitelist IP addresses
that are used for remote connections.
`lighthouse.remoteAllowList` filters which remote IPs are allow when
fetching from the lighthouse (or, if you are the lighthouse, which IPs
you store and forward to querying hosts). By default, any remote IPs are
allowed. You can provide CIDRs here with `true` to allow and `false` to
deny. The most specific CIDR rule applies to each remote. If all rules
are "allow", the default will be "deny", and vice-versa. If both "allow"
and "deny" rules are present, then you MUST set a rule for "0.0.0.0/0"
as the default.
lighthouse:
remoteAllowList:
# Example to block IPs from this subnet from being used for remote IPs.
"172.16.0.0/12": false
# A more complicated example, allow public IPs but only private IPs from a specific subnet
"0.0.0.0/0": true
"10.0.0.0/8": false
"10.42.42.0/24": true
`lighthouse.localAllowList` has the same logic as above, but it applies
to the local addresses we advertise to the lighthouse. Additionally, you
can specify an `interfaces` map of regular expressions to match against
interface names. The regexp must match the entire name. All interface
rules must be either true or false (and the default rule will be the
inverse). CIDR rules are matched after interface name rules.
Default is all local IP addresses.
lighthouse:
localAllowList:
# Example to blacklist docker interfaces.
interfaces:
'docker.*': false
# Example to only advertise IPs in this subnet to the lighthouse.
"10.0.0.0/8": true
* Better config test
Previously, when using the config test option `-test`, we quit fairly
earlier in the process and would not catch a variety of additional
parsing errors (such as lighthouse IP addresses, local_range, the new
check to make sure static hosts are in the certificate's subnet, etc).
* run config test as part of smoke test
* don't need privileges for configtest
Co-authored-by: Nathan Brown <nate@slack-corp.com>
This change adds a new helper, `(*HostInfo).logger()`, that starts a new
logrus.Entry with `vpnIp` and `certName`. We don't use the helper inside
of handshake_ix though since the certificate has not been attached to
the HostInfo yet.
Fixes: #84
* add configurable punching delay because of race-condition-y conntracks
* add changelog
* fix tests
* only do one punch per query
* Coalesce punchy config
* It is not is not set
* Add tests
Co-authored-by: Nate Brown <nbrown.us@gmail.com>
A CIDRTree can be expensive to create, so only do it if we need
it. If the remote host only has one IP address and no subnets, just do
an exact IP match instead.
Fixes: #171
This PR does two things:
- Only run the tests when relevant files change.
- Cache the Go Modules directory between runs, so they don't have to redownload everything everytime (go.sum is the cache key). Pretty much straight from the examples: https://github.com/actions/cache/blob/master/examples.md#go---modules
Currently, we require that config file names end with `.yml` or `.yaml`.
This is because if the user points `-config` at a directory of files, we
only want to use the YAML files in that directory.
But this makes it more difficult to use the `-test -config` option
because config management tools might not have an extension on the file
when preparing a new config file. This change makes it so that if you
point `-config file` directly at a file, it uses it no matter what the
extension is.
This change exposes the current constants we have defined for the handshake
manager as configuration options. This will allow us to test and tweak
with different intervals and wait rotations.
# Handshake Manger Settings
handshakes:
# Total time to try a handshake = sequence of `try_interval * retries`
# With 100ms interval and 20 retries it is 23.5 seconds
try_interval: 100ms
retries: 20
# wait_rotation is the number of handshake attempts to do before starting to try non-local IP addresses
wait_rotation: 5
This change introduces logging.timestamp_format, which allows
configuration of the Logrus TimestampFormat setting. The primary purpose
of this change was to allow logging with millisecond precision. The
default for `text` and `json` formats remains the same for backwards
compatibility.
timestamp format is specified in Go time format, see:
- https://golang.org/pkg/time/#pkg-constants
Default when `format: json`: "2006-01-02T15:04:05Z07:00" (RFC3339)
Default when `format: text`:
when TTY attached: seconds since beginning of execution
otherwise: "2006-01-02T15:04:05Z07:00" (RFC3339)
As an example, to log as RFC3339 with millisecond precision, set to:
logging:
timestamp_format: "2006-01-02T15:04:05.000Z07:00"
Validate all lighthouse.hosts and static_host_map VPN IPs are in the
subnet defined in our cert. Exit with a fatal error if they are not in
our subnet, as this is an invalid configuration (we will not have the
proper routes set up to communicate with these hosts).
This error case could occur for the following invalid example:
nebula-cert sign -name "lighthouse" -ip "10.0.1.1/24"
nebula-cert sign -name "host" -ip "10.0.2.1/24"
config.yaml:
static_host_map:
"10.0.1.1": ["lighthouse.local:4242"]
lighthouse:
hosts:
- "10.0.1.1"
We will now return a fatal error for this config, since `10.0.1.1` is
not in the host cert's subnet of `10.0.2.1/24`
This is the initial creation of a CHANGELOG. When we are ready to cut
a release we can change the version at the top and update the links at
the bottom.
* fix: nebula-cert duration is optional, so reflect this is the cli help
nebula-cert sign defaults the duration flag to 1 second before the CA expires, so it is not required to be provided.
* tests: Fix test for duration flag help message
* nebula-cert: add duration default value hint
This restores `make bin-windows` and also adds `make
build/nebula-windows-amd64.zip` to build the zip file.
Co-authored-by: Ryan Huber <rhuber@gmail.com>
This script will be triggered by any tag starting with `v[0-9]+.[0-9]+.[0-9]+` (i.e.
v1.1.0). It will create all of the .tar.gz files (or .zip for windows). The amd64 binaries will be
compiled on their target systems, the rest of the Linux architecures
will be cross compiled from the Linux amd64 host.
A SHASUM256.txt will also be generated and attached to the release.
Simplify the makefile by using implicit rules. The new structure for the
build directory when using `make all` or `make release` is:
build/$GOOS-$GOARCH-$GOARM/nebula
(The GOARM part is optional, and only used for linux-arm-6)
So, releases end up like `nebula-linux-amd64.tar.gz` or
`nebula-linux-arm-6.tar.gz`
This change also adds `-trimpath` to the build, to make the pathnames
more generic in our releases.
Mateusz Kwiatkowski