CRXN
/
docs
mirror of https://codeberg.org/CRXN/docs.git
1
0
Fork 0
Code Releases Activity

Update routing and tunneling instructions

This commit is contained in:
James Stone 2021-06-19 15:05:42 +01:00
parent 2f09fdc337
commit 29e85456fc
3 changed files with 71 additions and 85 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
docs/routing/bird/bird2.md
View File

@ -25,16 +25,21 @@ The configuration template is constructed out of the following files:
* Depending on what protocol you want to use this will contains
configurations for each
All of these will be included in a file saved at `/etc/crxn/bird.conf` like so:
All of these will be included in a file saved at `/etc/bird/bird.conf` like so:
```
router id <ipv4>;
include "/etc/crxn/networks.conf";
include "/etc/crxn/filters.conf";
include "/etc/crxn/tables.conf";
include "/etc/crxn/router.conf";
include "/etc/crxn/protocols.conf";
include "/etc/bird/crxn/tables.conf";
include "/etc/bird/crxn/filters.conf";
include "/etc/bird/crxn/router.conf";
include "/etc/bird/crxn/networks.conf";
```
Additionally, add the files for the route distribution protocol which we configure in the next steps.
```
include "/etc/bird/crxn/babel.conf"; # For babel routing
include "/etc/bird/crxn/ospfv3.conf"; # For OSPFv3 routing
```
Remember to set a unique router ID in `<ipv4>`, make it anything - it doesn't have to even be an address you own.
@ -46,40 +51,10 @@ filters that match to the specific prefix aggregates (regional subnets)
that CRXN uses.
```
# Given prefix `in` and `check` see whether or not
# the `in` is withint `check`
function rangeCheck (prefix inPrefix; prefix rangePrefix)
int ourNetworkLen;
ip ourNetworkID;
ip inPrefixMasked;
filter crxnFilter
{
# Get the length of our range
ourNetworkLen=rangePrefix.len;
# Get out network ID
ourNetworkID=rangePrefix.ip;
# Mask the inPrefix to that length
inPrefixMasked=inPrefix.ip.mask(ourNetworkLen);
# Check if the masks match
if(inPrefixMasked = ourNetworkID)
then
return true;
else
return false;
}
# CRXN Route filter based
filter crxn6
{
# CRXN v6 range
if (rangeCheck(net, fd00::/8) = true)
then
accept;
# No matches, reject
reject;
if (net ~ fd00::/8) then accept;
reject;
}
```
@ -111,33 +86,38 @@ doesn't even need those, it gets them from the interface.
# address and prefix. So instead of reading this from all routes with `proto kernel` this just
# yeets the routes off of the interface structure itself (even if you didn't have a route for your
# directly attached networks - i.e. nexthop = 0.0.0.0)
protocol direct crxnDirect {
ipv6
{
# Import from direct -> bird into bird's `crxn` table
import filter crxn6;
table crxn;
};
protocol direct crxnDirect
{
ipv6
{
table crxn;
import filter crxnFilter;
};
# Interfaces to find neighbours on
interface "eth*";
}
protocol device {
}
```
The second part is for syncing routes from Bird to the Linux kernels' routing
table such that you can forward traffic then absed on the routes learnt from
Bird.
The second part is for syncing routes from Bird to the Linux kernel's routing
table such that you can forward traffic based on the routes in Bird.
TODO: Check, defualt `learn` should larn non `kernel` and non-`bird` routes
TODO: Check, defualt `learn` should learn non `kernel` and non-`bird` routes
```
# CRXN Kernel protocol
# We import any routes from the kernel table other than `proto bird` and `proto kernel`,
# could be `proto static` for example. By default it will learn these.
# Of course we also then export all routes from our Bird tables into the kernel so you can actually forward packets
protocol kernel crxnKernel {
ipv6 {
# Export from bird -> kernel from bird's `crxn` table
export filter crxn6;
table crxn;
};
protocol kernel crxnKernel
{
ipv6 {
# bird's crxn table -> kernel
table crxn;
export filter crxnFilter;
};
}
```
@ -157,14 +137,3 @@ protocol static crxnStatic
}
}
```
#### `protocols.conf`
This file should look like this (as an example of running one `babel`
instance and one `ospf` instance):
```
# Import protocol instances
import "babel.conf";
import "ospf.conf";
```

8
docs/routing/bird/bird_babel.md
View File

@ -1,7 +1,7 @@
Bird Babel configuration
========================
In a file named `babel.conf` place the following template:
In `/etc/bird/crxn/babel.conf` place the following template:
```
# CRXN Babel protocol
@ -13,8 +13,8 @@ protocol babel crxnBabel
ipv6
{
import filter crxn6;
export filter crxn6;
import filter crxnFilter;
export filter crxnFilter;
table crxn;
};
}
@ -22,7 +22,7 @@ protocol babel crxnBabel
1. Set the `interface` list to a list of interfaces you wish the babel
protocol to run on
* It also supports regex in a string so you can do `"interface*"` for example
* It also supports regex in a string so you can do `"interface*"` for example
**Note:** For Bird 1.6 you will want to remove the `ipv6 {};`.

45
docs/tunneling/fastd.md
View File

@ -24,11 +24,12 @@ The next step is to setup a tunnel. You will have to contact someone to get the
2. `public key`
* You will need their public key which will be used to secure the connection to them such that traffic is encrypted (CRXN traffic and babeld router messages)
Once we have this information we can begin the setup with the below as the template:
Create a file with the template and instructions below in `/etc/fastd/crxn/fastd.conf`:
```
# The interface that will connect to the virtual ethernet network fastd connects us to
interface "<interfaceName>";
interface "crxn%n";
mode multitap;
# The encryption method (don't change this unless you need to)
method "salsa2012+umac";
@ -42,19 +43,28 @@ secret "<secret key>";
# Setup a peer to allow incoming connections from or initiate a connection too
peer "<peerName>"
{
remote <type> "<ip>" port <port>;
key "<peer's public key>";
remote <type> "<ip>" port <port>;
key "<peer's public key>";
}
# On interface rise run
on up "ifconfig <interfaceName> up";
```
So the above needs to have the following filled in:
If your system uses ifconfig append
```
# On interface rise run
on up "ifconfig $INTERFACE up";
on down "ifconfig $INTERFACE down";
```
1. `"<interfaceName>"`
* This is of your choosing and will need to be remembered for later steps
2. `<ip>` and `<port>`
If your system uses ip append
```
on up "ip link set dev $INTERFACE up";
on down "ip link set dev $INTERFACE down";
```
The template needs to have the following filled in:
1. `<ip>` and `<port>`
* The IP address and port to bind to and listen on for incoming connections from your peer's daemon (if his daemon initiates the connection first)
Now you must run the following:
@ -65,14 +75,14 @@ fastd --generate-key
Then save the *public key* and the *private key*. **Note:** You must give your peer your *public key*.
3. `"<secret key>"`
2. `"<secret key>"`
* This must be the *private key* you generated earlier
Now we need to fill in the peer details of the node you are connecting to:
1. `"<peerName>"`
* Set this to the name of the peer (can be anything really)
* Sets the interface name of the connection with the peer to crxn`<peerName>`
2. `<type>`
* Set this to either `ipv4` or `ipv6` depending of the address being used to connect to the remote peer
3. `"<ip>"`
@ -89,7 +99,14 @@ The last thing to configure now is to rise the interface up when fastd starts (a
You can then start the daemon as follows:
```
sudo fastd -c /etc/fastd/path/to/config.conf
sudo fastd -c /etc/fastd/crxn/fastd.conf
```
**TODO: Sosytemd-unit**
### Systemd unit
Fastd can also be set up with systemd units.
Run `systemctl start fastd@crxn` to bring up the tunnel
Run `systemctl stop fastd@crxn` to bring down the tunnel
To enable the systemd unit on startup run `systemctl enable fastd@crxn`