Custom configurations should be supplied in a `lixonet.conf` file in the `name=value` format, such as your subnet. Additionally, a tinc keypair is also be required.
WARNING: On some systems (i.e. Raspberry Pi) with integrated Ethernet, it seems promiscuous (PROMISC) mode is required on your `eth0` (see #1 next). Otherwise you won't see traffic getting passed to the tinc, wireguard, etc. containers from devices in your network.
1.`eth0` is the **LAN** or **WAN** interface supporting external routing, DNS, etc., and is the **bridged** interface to a router that will statically route the entire desired network subnet (i.e. x.x.0.0/21) through it. You may also have an `eth1` (and so on, so forth) that you statically configure for your entire, wide subnet (i.e. x.x.0.0/21) if you want to use two physical adapters. If you do have more than one interface, make sure that `internal_gateway` is set to the router IP address that can route your personal Lixonet subnets, and not your WAN gateway (unless they're the same).
2.`tun` and `tap` are in `/etc/modules` to load at boot (https://www.cyberciti.biz/faq/linux-how-to-load-a-kernel-module-automatically-at-boot-time/) and the system has been rebooted afterwards.
3. IPv4 forwarding is on: `sysctl -w net.ipv4.ip_forward=1`
8. Supply `/etc/lixonet/id_rsa` and `/etc/lixonet/(mesh)/id_rsa` for each mesh you'll be connected to (see: **Generating SSH keys**). Remember each id_rsa is unique!
3. Share the public keys (starting with something like `ssh-rsa`) with the repository owner(s) listed below so they can add a "Deploy key" to the repository for you.
Don't take my word for it, see: https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints
You only need to do this if you are setting `wg_enabled`=1, for example when you want to service VPN clients from a "master" node. See **Wireguard Options** for more information on how to do that.
See: https://www.wireguard.com/quickstart/
```
apk add -U wireguard-tools
wg genkey | tee privatekey | wg pubkey > publickey
A `lixonet.conf` file should be under each **network** directory you'd like to create. Create one directory for each mesh you'll be joining, under `/etc/lixonet`. If you want to join the `teamlixo` mesh for example, do this:
1. Create `/etc/lixonet/teamlixo/lixonet.conf` and specify at least all **required** options in this file.
2. Create or save `/etc/lixonet/teamlixo/tinc.key`
#### Available networks
Official networks:
| Name | Git clone URL(s) | Subnet | ASN format | Administsration |
*`git` - The Git clone repository URL, used for peer configurations.
*`tinc_peer_name` - The global neighbor name. Tinc and Bird use this to identify a peer in the network, and to exclude your own pre-packed config automagically from Tinc and BIRD dialing out so you don't connect to yourself over and over again.
*`tinc_peer_address` - The *router* address to use. This is your Lixonet routing layer address: 172.xxx.0.xxx
*`network_address` - The *network* address to use. This is your Lixonet routing layer address: 172.xxx.0.0 (especially take note of the last two 0's: `0.0` -- it _MUST_ end with zeros corresponding to the network size)
*`bgp_asn` - The BGP ASN to use. We usually follow the format `4206969XXX` where _XXX_ is the last octet of your `address`, zero-padded (i.e. 008 or 212)
*`internal_address` - The internal address to use. MUST be unique to this Lixonet EE instance; if the address of the host is 172.31.16.2, you should _NOT_ use that IP address, and instead pick another static address.
*`internal_gateway` - The internal gateway to use. This is the IP address, directly upstream from the Lixonet EE router, that can be used as a next hop to reach your own subnets.
*`internal_interface`: the interface to route your _OWN_ networks to. This should be the interface where your personal Lixonet subnets are reachable at, or in other words the interface at which the Lixonet EE router can send packets destined to networks you own. Defaults to `eth0`.
*`tinc_bind_address` - The address that Tinc should bind to to _listen_ for incoming public Internet connections (i.e. 10.0.0.1). This is _not_ the Lixonet router IP (i.e. 172.31.0.8). Use this if you have an `eth1` that you _don't_ want to use for binding tinc to, and would prefer to bind tinc exclusivley to `eth0` instead. Defaults to `internal_address`.
*`tinc_connect_to` - A comma-separated list of well-known/pre-defined hosts to connect to (i.e. `denco_mane_lixo`). If not supplied, this is automatically set to all core routers that aren't yourself (`name`).
*`bgp_rpki_retry`: If RPKI cache data cannot be obtained, the time period in seconds between a failed query the next attempt. Defaults to `90`.
*`bgp_rpki_refresh`: How long to wait in seconds before attempting to poll RPKI cache data after the last successful poll. Defaults to `900`.
*`bgp_rpki_expire`: How long to keep any records locally cached before they are deleted. Defaults to `172800` (2 days).
*`bgp_rpki_known_hosts`: The file path for the SSH key `known_hosts` file to use when validating remote RPKI hosts. Defaults to `/etc/bird/rpki/known_hosts` (provided by Lixonet; don't change this unless you need to!).
*`bind_forward_enable`: Enable BIND DNS forwarding when DNS queries are received from other nodes Lixonet for a domain that you control (i.e. lkwco.mane.lixo on that Lixonet box). `1`/enabled, `0`/disabled. Defaults to `1`.
*`bind_forward_address`: The overridden DNS server IP address to forward all requests for your own domain to. Defaults to the value of `internal_gateway`, which is proper in most if not all cases. Your BIND zone is automatically converted from your `tinc_peer_name` (i.e. `lkwco_mane_lixo` becomes `lkwco.mane.lixo`).
*`tld`: The network-wide TLD to use. Defaults to `lixo`.
Keep in mind that Wireguard is presently an auxilliary satellite connection point. Because of this, you shouldn't re-use any IP addresses related to WG. Consider planning a piece (/32, see `wg_prefix`) of your network (i.e. 172.31.1.z) where `z` is an unused address (or your ASN number, like 8, 16, so on) and setting that to `wg_address`. This is generally only desired on "master" or globally-reachable/hosted nodes to construct an overlay VPN. If a node is hosting WireGuard clients, they can send traffic into other nodes but likely won't receive any traffic back unless `wg_routes` is set so BIRD can export peer addresses into the BGP routing framework.
*`wg_routes`: A comma-delimited list of WireGuard route prefixes (CIDR) to advertise to other BGP peers. If not specified, no routes are propagated. If specified, only specific connected WireGuard peers added to the kernel routing table are advertised.
Enabling IPv6 allows you to be more easily/natively reached by IPv6 native clients such as mobile phones on LTE. Keep in mind this doesn't switch on IPv6 inside the VPN itself. This is typically something you want to do if you are using Wireguard and plan to allow mobile phones to reach you.
*`internal_mask6`: Required if `internal_address6` is set. Specify a static IPv6 subnet mask (i.e. `64` for a /64) that is associated to your `internal_interface`.
*`syslog_enabled`: Set to `1` to enable Syslog support. Defaults to `0`.
*`syslog_address`: Set to your preferred remote Syslog server, i.e. `udp://192.168.1.1:512`.
*`syslog_format`: Set to your preferred Syslog format. Defaults to `rfc5424micro`, the best option with highest precision, but may not be supported by all Syslog servers (see: https://docs.docker.com/config/containers/logging/syslog/).
*`syslog_facility`: Set to your preferred Syslog facility. Defaults to `news`, AKA 'Network News', a good category for network devices (see: https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.1).
