mirror of https://codeberg.org/CRXN/docs.git
Marek Küthe
parent
d5dc18d967
commit
564e007e4e
|
|
@ -0,0 +1,107 @@
|
|||
# CRXN / dn42 gateway documentation
|
||||
|
||||
CRXN mainly uses IGP protocols such as babel or ospf, while dn42 uses the EGP BGP. Since the protocols are based on different concepts, a direct connection is not possible.
|
||||
|
||||
## Routes into dn42
|
||||
If everyone who is a member of dn42 and CRXN would not filter the routes, this would result in announcing them in dn42 under their own AS number. However, according to the registry, you do not have permission to do this. Therefore the dummy ASN 4242423182 was registered in dn42. This is the origin of CRXN routes. So before exporting the routes to dn42, attach an AS path with AS4242423182 to it. So it looks from the outside that the CRXN routes come from AS4242423182. AS4242423182 has the permission to announce the CRXN routes.
|
||||
|
||||
## Routes into the CRXN
|
||||
CRXN uses IGP and therefore does not know the concept of AS numbers or originating systems. In CRXN it appears that everything comes from one system. Accordingly, you can export dn42 routes here without preparation.
|
||||
|
||||
## Notes
|
||||
|
||||
- If possible, try to export only CRXN routes to the dn42, which are also in the entitydb.
|
||||
- Only CRXN routes should be exported to dn42. When dn42 routes are exported from CRXN back to dn42, the BGP AS path attributes are lost. This would then make it look like all dn42 routes have their origin at the dummy AS, which is not correct. As a result, there would be many ROA fails and the dn42 network would become somewhat congested.
|
||||
|
||||
## Example configuration in bird
|
||||
|
||||
To create the BGP path artificially you can use the command `bgp_path.prepend`. This appends an AS number to the BGP path.
|
||||
```bird
|
||||
define CRXNAS = 4242423182;
|
||||
|
||||
function dn42_export_filter() {
|
||||
/* some filter */
|
||||
|
||||
if ( is_crxn_net() ) then {
|
||||
bgp_path.prepend(CRXNAS);
|
||||
}
|
||||
|
||||
/* some filter */
|
||||
|
||||
accept;
|
||||
}
|
||||
```
|
||||
|
||||
If you want to avoid so much traffic flowing through your gateway, you can repeat the command `bgp_path.prepend(CRXNAS);` once. By doing this, you intentionally make your gateway less attractive to others. (see Route Prepending)
|
||||
```bird
|
||||
if ( is_crxn_net() ) then {
|
||||
bgp_path.prepend(CRXNAS);
|
||||
bgp_path.prepend(CRXNAS);
|
||||
}
|
||||
```
|
||||
|
||||
## Registering the gateway
|
||||
|
||||
Currently, a list of gateway operators is maintained in [https://codeberg.org/crxn/dn42_gateways/](https://codeberg.org/crxn/dn42_gateways/). If you also want to operate a gateway, please submit a PR there.
|
||||
|
||||
## View current gateways
|
||||
|
||||
In case someone is running a gateway without permission or in case you want to check if your gateway is working, you can ask the [Global Route Collector (GRC)](https://wiki.dn42/services/Route-Collector) of dn42:
|
||||
```bash
|
||||
$ssh shell@collector.dn42
|
||||
------------------------------------
|
||||
* DN42 Global Route Collector *
|
||||
------------------------------------
|
||||
* https://collector.dn42/
|
||||
|
||||
This service provides a bird2 shell
|
||||
for querying the route collector
|
||||
|
||||
Be nice, access is logged and
|
||||
abuse will not be tolerated
|
||||
------------------------------------
|
||||
BIRD v2.0.9-11-g207ac485 ready.
|
||||
Access restricted
|
||||
bird> show route where bgp_path.last = 4242423182 all
|
||||
Table master6:
|
||||
fd14:57af:fe7a::/64 unreachable [DYN_00107 13:04:33.512 from fd89:35db:fc0::4] * (100) [AS4242423182i]
|
||||
Type: BGP univ
|
||||
BGP.origin: IGP
|
||||
BGP.as_path: 4242420604 4242422923 4242423182
|
||||
BGP.next_hop: fd89:35db:fc0::4
|
||||
BGP.local_pref: 100
|
||||
BGP.community: (64511,6) (64511,24) (64511,33)
|
||||
BGP.large_community: (65535, 70, 2) (210074, 0, 4242420591) (210074, 1, 1) (4242420604, 2, 13) (4242420604, 501, 4242423513) (4242420604, 502, 41) (4242420604, 504, 3)
|
||||
unreachable [DYN_00037 2022-12-04 from fd89:35db:fc0::3] (100) [AS4242423182i]
|
||||
Type: BGP univ
|
||||
BGP.origin: IGP
|
||||
BGP.as_path: 4242421271 4242422225 210074 4242422924 4242423182 4242423182
|
||||
BGP.next_hop: fd89:35db:fc0::3
|
||||
BGP.local_pref: 100
|
||||
BGP.community: (64511,6) (64511,24) (64511,33)
|
||||
BGP.large_community: (65535, 70, 2) (210074, 0, 4242420591) (210074, 1, 1) (4242420604, 2, 13) (4242420604, 501, 4242423513) (4242420604, 502, 41) (4242420604, 504, 3)
|
||||
unreachable [DYN_00139 00:37:09.086 from fd9e:5312:a3b3:100::11] (100) [AS4242423182i]
|
||||
Type: BGP univ
|
||||
BGP.origin: IGP
|
||||
BGP.as_path: 76190 4242420591 210074 4242422923 4242423182
|
||||
BGP.next_hop: fd9e:5312:a3b3:100::11
|
||||
BGP.local_pref: 100
|
||||
BGP.community: (64511,6) (64511,23) (64511,33)
|
||||
BGP.large_community: (65535, 70, 2) (210074, 0, 4242420591) (210074, 1, 1) (4242420604, 2, 13) (4242420604, 501, 4242423513) (4242420604, 502, 41) (4242420604, 504, 3)
|
||||
```
|
||||
(The data are only examples and not real)
|
||||
|
||||
```
|
||||
fd14:57af:fe7a::/64
|
||||
```
|
||||
This is the prefix that is passed through the gateway.
|
||||
|
||||
```
|
||||
BGP.as_path: 4242420604 4242422923 4242423182
|
||||
```
|
||||
This is the line which is interesting because you can see there who is currently running a gateway. At the very end is the dummy ASN 4242423182, preceded by either the dummy ASN or the operator's ASN. You can then look up the ASN number in the dn42 registry and know who is running the gateway.
|
||||
|
||||
Alternatively, you can filter out the AS numbers directly using standard tools:
|
||||
```bash
|
||||
ssh shell@collector.dn42 show route where bgp_path.last = 4242423182 all 2>/dev/null | grep -P "^\tBGP.as_path: " | grep -Po "(\d{5,10}) 4242423182" | awk '{ split($0,ary," "); print ary[1] }' | sort | uniq
|
||||
```
|
||||
|
|
@ -2,13 +2,17 @@
|
|||
|
||||
HINT: This is currently a work in progress by @mark22k
|
||||
|
||||
## Rekursiv
|
||||
## Recursive
|
||||
|
||||
| DNS | IP address |
|
||||
| --- | --- |
|
||||
| recur1.bandura.crxn | fd92:58b6:2b2::5353 |
|
||||
|
||||
## Authoritiv
|
||||
## Authoritative
|
||||
|
||||
| DNS | IP address |
|
||||
| --- | --- |
|
||||
| ns1.crxn | fd92:58b6:2b2::54 |
|
||||
|
||||
# Resolve CRXN domains only
|
||||
|
||||
|
|
@ -43,9 +47,9 @@ There are several software you can use for this.
|
|||
This guide is for Debian based systems.
|
||||
First you need to download Coredns. You can find the software at https://coredns.io/. As a download package you get a compressed file. Extract it and make the file `coredns` executable and copy it into the directory `/usr/local/bin`.
|
||||
```
|
||||
$tar xvf coredns_1.10.0_linux_amd64.tgz
|
||||
$chmod +x coredns
|
||||
$sudo cp coredns /usr/local/bin/
|
||||
$ tar xvf coredns_1.10.0_linux_amd64.tgz
|
||||
$ chmod +x coredns
|
||||
$ sudo cp coredns /usr/local/bin/
|
||||
```
|
||||
|
||||
To start Coredns automatically you can create a Systemd unit:
|
||||
|
|
@ -80,17 +84,17 @@ WantedBy=multi-user.target
|
|||
|
||||
After that reload systemd:
|
||||
```
|
||||
$sudo systemctl daemon-reload
|
||||
$ sudo systemctl daemon-reload
|
||||
```
|
||||
|
||||
To isolate Coredns, you create a new user:
|
||||
```
|
||||
$sudo adduser --home /etc/coredns/ --disabled-password --disabled-login coredns
|
||||
$ sudo adduser --home /etc/coredns/ --disabled-password --disabled-login coredns
|
||||
```
|
||||
|
||||
After that you can create and edit the Coredns configuration file `Corefile`:
|
||||
```
|
||||
editor /etc/coredns/Corefile
|
||||
$ editor /etc/coredns/Corefile
|
||||
```
|
||||
|
||||
Paste the following:
|
||||
|
|
@ -113,14 +117,23 @@ To resolve Clearnet domains, insert the following:
|
|||
tls_servername 1dot1dot1dot1.cloudflare-dns.com
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
To start Coredns you can use Systemd:
|
||||
```
|
||||
$ sudo systemctl start coredns
|
||||
```
|
||||
|
||||
To access the Coredns log you can use one of the following commands:
|
||||
```
|
||||
$ sudo systemctl status coredns
|
||||
```
|
||||
```
|
||||
$ sudo journalctl -r -u coredns
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
To start Coredns automatically, you can enable the unit with the following command:
|
||||
```
|
||||
$ sudo systemctl enable coredns
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -2,5 +2,5 @@
|
|||
# Additional
|
||||
|
||||
- [DNS](dns)
|
||||
- [DN42 interconnection](dn42_interconnection)
|
||||
- [OTG](otg)
|
||||
- [DN42 Interconnection](dn42-interconnection)
|
||||
- [ORG](otg/)
|
||||
|
|
|
|||
|
|
@ -8,11 +8,11 @@ Deavmi runs a Wireguard tunneling service for client-only (meaning you won't rou
|
|||
The service is made available over the following networks:
|
||||
|
||||
* Clearnet IPv6
|
||||
* This means you can connect your Wireguard endpoint to an IPV6 host (my server)
|
||||
* Endpoint address: `2a04:5b81:2010::65`
|
||||
* This means you can connect your Wireguard endpoint to an IPV6 host (my server)
|
||||
* Endpoint address: `2a04:5b81:2010::65`
|
||||
* Yggdrasil
|
||||
* This means you can run the [Yggdrasil software](http://yggdrasil-network.github.io) and use an Yggdrasil IPv6 address as the Wireguard endpoint
|
||||
* Endpoint address: `301:754:2ca2:57f8::1`
|
||||
* This means you can run the [Yggdrasil software](http://yggdrasil-network.github.io) and use an Yggdrasil IPv6 address as the Wireguard endpoint
|
||||
* Endpoint address: `301:754:2ca2:57f8::1`
|
||||
|
||||
## Setup procedure
|
||||
|
||||
|
|
@ -88,4 +88,4 @@ sudo systemctl restart systemd-networkd
|
|||
|
||||
---
|
||||
|
||||
I would like to thank zhoreeq for providing the configuration files above.
|
||||
I would like to thank zhoreeq for providing the configuration files above.
|
||||
|
|
|
|||
|
|
@ -11,22 +11,22 @@ practices and inner-workings and by the end you should have all the information
|
|||
and configuration details needed to get connected!
|
||||
|
||||
1. [Rules](rules)
|
||||
* We have **few** but **strict** rules nonetheless
|
||||
* Zero-tolerance for breaking them
|
||||
* We have **few** but **strict** rules nonetheless
|
||||
* Zero-tolerance for breaking them
|
||||
2. [Requirements](requirements)
|
||||
3. [Registration](registration)
|
||||
4. Setting up routing
|
||||
1. [Forwarding](../routing/forwarding)
|
||||
2. [Setting up Bird](../routing/bird)
|
||||
1. [Forwarding](../routing/forwarding)
|
||||
2. [Setting up Bird](../routing/bird)
|
||||
5. Tunneling
|
||||
* [Fastd tunneling](../tunneling/fastd)
|
||||
* [WireGuard tunneling](../tunneling/wireguard)
|
||||
* [Fastd tunneling](../tunneling/fastd)
|
||||
* [WireGuard tunneling](../tunneling/wireguard)
|
||||
6. Setting up your home network
|
||||
* Configuring your hosts
|
||||
1. Automatically with SLAAC and radv
|
||||
1. [Setting up radv (router)](../home_network/radv)
|
||||
2. [Setting up SLAAC (hosts)](../home_network/slaac)
|
||||
* [DNS](../home_network/dns)
|
||||
* Configuring your hosts
|
||||
1. Automatically with SLAAC and radv
|
||||
1. [Setting up radv (router)](../home-network/radv)
|
||||
2. [Setting up SLAAC (hosts)](../home-network/slaac)
|
||||
* [DNS](../home-network/dns)
|
||||
|
||||
## What's next?
|
||||
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@ Rules
|
|||
## The no's
|
||||
|
||||
* Nothing illegal in any of the countries our servers reside in
|
||||
* No child pornography (you fucking degenerate)
|
||||
* No conducting of illegal activities
|
||||
* If you don't get the point, don't do illegal stuff
|
||||
* No child pornography (you fucking degenerate)
|
||||
* No conducting of illegal activities
|
||||
* If you don't get the point, don't do illegal stuff
|
||||
|
||||
* No pornography
|
||||
|
||||
|
|
@ -17,8 +17,8 @@ Rules
|
|||
## The yes's
|
||||
|
||||
* Free speech
|
||||
* We all get offended from time to time but it's not worth stopping bad opinions
|
||||
* It's also, on the other hand, nice to not a be a dick though (social consequences are there still)
|
||||
* We all get offended from time to time but it's not worth stopping bad opinions
|
||||
* It's also, on the other hand, nice to not a be a dick though (social consequences are there still)
|
||||
|
||||
* If you see someone break the rules and have proof **speak up!** and notify us
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
# DNS
|
||||
|
||||
TODO: Add documentation @mark22k
|
||||
|
||||
You can take look at [Additional/DNS](../additional/dns) in the meantime.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
|
||||
# Setting up your home network
|
||||
|
||||
- [Setting up radv (router)](radv)
|
||||
- [Setting up SLAAC (hosts)](slaac)
|
||||
- [DNS](dns)
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
# Radv
|
||||
|
||||
This document is for setting up radv on Bird 2.0.
|
||||
|
||||
## General syntax
|
||||
|
||||
You will want to add one of these to one of your Bird configuration files:
|
||||
|
||||
```
|
||||
protocol radv
|
||||
{
|
||||
# Stuff goes here
|
||||
}
|
||||
```
|
||||
|
||||
## Advertising your prefix
|
||||
|
||||
If you would like to advertise your prefix to hosts on your LAN that have set their address acquisition for IPv6 to _'Automatic'_ such that they will assign themselves an address within that prefix then you will want to add a `prefix` block as so:
|
||||
|
||||
```
|
||||
protocol radv
|
||||
{
|
||||
# Advertise your prefix
|
||||
prefix fd40:ec65:5b4c::/64 {
|
||||
# TODO: Add anything that needs to be in here
|
||||
};
|
||||
|
||||
# Interfaces to run radv on
|
||||
interface "eth0";
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
In the above example I am advertising a `/64` within my `/48`/ULA (`fd40:ec65:5b4c::/48`), `fd40:ec65:5b4c::/64`, and only on interface `eth0` will radv run.
|
||||
|
||||
## Advertising route(s)
|
||||
|
||||
You can advertise a default route, to `fd00::/8` or simply all routes in your router's routing table, to your hosts using the following:
|
||||
|
||||
### Advertising a single `fd00::/8`
|
||||
|
||||
TODO: Add this as I normally don't do this even though one should as it means less memory consumption and advertisement updates
|
||||
|
||||
### Advertising all known routes
|
||||
|
||||
This will advertise all the routes your Bird router knows (those in the `crxn` table) such that your, laptop for example, will add all of them to its routing table.
|
||||
|
||||
```
|
||||
protocol radv
|
||||
{
|
||||
# Enable propagating of routes exported to us via radv to hosts
|
||||
propagate routes yes;
|
||||
|
||||
ipv6 {
|
||||
# Export all your routes into the radv advertisement
|
||||
export filter crxn6;
|
||||
table crxn;
|
||||
};
|
||||
|
||||
# Interface to run radv on - only eth0 (change to what you want)
|
||||
interface "eth0" {
|
||||
# Advertise your prefix
|
||||
prefix fd40:ec65:5b4c::/64 {
|
||||
# Defaults are fine
|
||||
};
|
||||
|
||||
# Prevent advertising of default route
|
||||
default lifetime 0;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
SLAAC
|
||||
=====
|
||||
|
||||
Configuring your hosts for automatic IP network and address assignment, DNS and routing is very easy.
|
||||
|
||||
**Note::** This tutorial is written for those who have setup Radv already.
|
||||
|
||||
## NetworkManager-based systems
|
||||
|
||||
For NetworkManager-based systems do the following. Open up `nm-connection-editor` and you should have a screen appear like this:
|
||||
|
||||
|
||||
|
||||
Then double click on the wifi or ethernet connection you have active of which connects you to the same LAN as your router and you should see a window like this popup:
|
||||
|
||||
|
||||
|
||||
Then go to the `IPv6` tab and you should see this:
|
||||
|
||||
|
||||
|
||||
Now make sure that this part is set to `Automatic`:
|
||||
|
||||
|
||||
|
||||
And then for the bottom two parts you can choose whatever option you want in these dropdowns:
|
||||
|
||||
|
||||
|
||||
Once you have configured that, then hit save and close all those windows:
|
||||
|
||||
|
||||
|
||||
What you want to do now is to open `nmtui` (in your terminal) and reactivate that connection, first go to _Activate a connection_:
|
||||
|
||||
|
||||
|
||||
Now reactivate the connection. You can do this by deactivating it and activating it again (unplugging and replugging won't reactivate it - it doesn't reload the profile).
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
And that is it, now you should be connected to CRXN on your laptop via your router.
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
<img src="./img/logo.png" class="crxn_logo" alt="CRXN logo">
|
||||
</div>
|
||||
|
||||
<div class="center mark22k_hide">
|
||||
<div class="center" id="home_crxn_tile">
|
||||
<h1>CRXN</h1>
|
||||
</div>
|
||||
|
||||
|
|
@ -31,40 +31,40 @@ networking with those that run networks already themselves.
|
|||
The network has a few goals that we always want to maintain as to not lose our allure:
|
||||
|
||||
1. Be a network for learning
|
||||
* We don't want to shun people away from using some new
|
||||
routing protocol as it might be cool and interesting to
|
||||
learn
|
||||
* We don't want to shun people away from using some new
|
||||
routing protocol as it might be cool and interesting to
|
||||
learn
|
||||
2. Be reliable
|
||||
* Of course when learning people should also make sure
|
||||
their routers don't just accept any route without making
|
||||
sure its valid - hence network operators should make sure
|
||||
their networks operate even when some are causing mayhem
|
||||
(malicious or learning by trial and error)
|
||||
* Also shouldn't be painfully slow
|
||||
* Of course when learning people should also make sure
|
||||
their routers don't just accept any route without making
|
||||
sure its valid - hence network operators should make sure
|
||||
their networks operate even when some are causing mayhem
|
||||
(malicious or learning by trial and error)
|
||||
* Also shouldn't be painfully slow
|
||||
3. Diverse routing
|
||||
* We want to try out protocols like **ospf**, **babel**, **bgp**
|
||||
and so on and so forth
|
||||
* We want to build a network out of a mix and match of these all
|
||||
working in harmony together
|
||||
* Monocultures suck!
|
||||
* We want to try out protocols like **ospf**, **babel**, **bgp**
|
||||
and so on and so forth
|
||||
* We want to build a network out of a mix and match of these all
|
||||
working in harmony together
|
||||
* Monocultures suck!
|
||||
4. Usable
|
||||
* We have DNS, we have voice chat servers and we have IRC (we
|
||||
even have gaming!) but we can always do with much **much more**!
|
||||
* We want the users, _you_, to make the network usable for your
|
||||
needs - who knows it might provide a service that helps out
|
||||
someone else
|
||||
* We have DNS, we have voice chat servers and we have IRC (we
|
||||
even have gaming!) but we can always do with much **much more**!
|
||||
* We want the users, _you_, to make the network usable for your
|
||||
needs - who knows it might provide a service that helps out
|
||||
someone else
|
||||
5. Peering
|
||||
* We want people to setup redundant links using whatever protocols
|
||||
they want, be it **wireguard**, **GRE**, **fastd** etc.
|
||||
* We want there to be interesting links and diversity
|
||||
* We want people to setup redundant links using whatever protocols
|
||||
they want, be it **wireguard**, **GRE**, **fastd** etc.
|
||||
* We want there to be interesting links and diversity
|
||||
6. _Chaos and Order_
|
||||
* The network should never stop experimenting
|
||||
* But it should have 99% uptime and safety fallbacks
|
||||
* If you want to experiment - then go ahead and try cause
|
||||
as little disruption as possible
|
||||
* If you run a node - make it secure - sign routes etc.
|
||||
to prevent others from experimenting from messing your
|
||||
network up
|
||||
* The network should never stop experimenting
|
||||
* But it should have 99% uptime and safety fallbacks
|
||||
* If you want to experiment - then go ahead and try cause
|
||||
as little disruption as possible
|
||||
* If you run a node - make it secure - sign routes etc.
|
||||
to prevent others from experimenting from messing your
|
||||
network up
|
||||
|
||||
We aim to create a more open Internet available to everyone and a place to learn about IP routing and networking in general.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,10 +6,6 @@ Get to know some familiar faces!
|
|||
|
||||
### Tristan B. Kildaire `~deavmi`
|
||||
|
||||
<!-- <img src="http://deavmi.assigned.network/profile_pic.jpg"> -->
|
||||
|
||||
<!-- <img src="people/deavmi.jpg"> -->
|
||||
|
||||
Creator of CRXN.
|
||||
|
||||
Roles: Documentation, Outreach, Network services, Scripting & Programming
|
||||
|
|
@ -23,7 +19,7 @@ Matrix: `deavmi@envs.net`
|
|||
Amazing German dude.
|
||||
|
||||
Roles: Network services, Routing
|
||||
BNET IRC: `chris2001` on `#crxn`
|
||||
BNET IRC: `chris2001`
|
||||
|
||||
### Ty3r0X `~ty3r0x`
|
||||
|
||||
|
|
@ -31,7 +27,7 @@ BNET IRC: `chris2001` on `#crxn`
|
|||
|
||||
Owner of Chaox, responsible for CRXNxDN42 interconnection
|
||||
|
||||
Roles: Network services, Routing, CRXNxDN42 inter-connect maintenance
|
||||
Roles: Network services, Routing, CRXNxDN42 interconnection maintenance
|
||||
|
||||
E-mail: `ty3r0x@chaox.ro`
|
||||
BNET IRC: `ty3r0x`
|
||||
|
|
@ -42,7 +38,7 @@ BNET IRC: `ty3r0x`
|
|||
|
||||
Owner of Bandura Communications, responsible for CRXNxDN42 interconnection, BGP master
|
||||
|
||||
Roles: Network services, Routing, CRXN DNS, CRXNxDN42 inter-connect maintenance, Scripting & Programming
|
||||
Roles: Network services, Routing, CRXN DNS, CRXNxDN42 interconnection maintenance, Scripting & Programming
|
||||
|
||||
Email: `crxn@mk16.de`
|
||||
Hackint IRC: `mark22k`
|
||||
|
|
|
|||
|
|
@ -9,19 +9,19 @@ This document assumes that you are using a Linux system (as one should) and a sy
|
|||
The following need to be installed:
|
||||
|
||||
1. `fastd`
|
||||
* This is the layer 2 tunnelling daemon we use to link up machines essentially providing a virtual ethernet network between the two nodes we want to link.
|
||||
* This is the layer 2 tunnelling daemon we use to link up machines essentially providing a virtual ethernet network between the two nodes we want to link.
|
||||
2. Optional: `yggdrasil`, `cjdns`
|
||||
* These are both overlay networks that can be used if clear-net access is not possible.
|
||||
* We recommend you still use them as they can run without internet access too and redundancy is a goal of CRXN and having a diverse peering setup
|
||||
* These are both overlay networks that can be used if clear-net access is not possible.
|
||||
* We recommend you still use them as they can run without internet access too and redundancy is a goal of CRXN and having a diverse peering setup
|
||||
|
||||
## Setting up a tunnel
|
||||
|
||||
The next step is to setup a tunnel. You will have to contact someone to get the following:
|
||||
|
||||
1. `ip:port` pairing details
|
||||
* The endpoint of their *fastd* instance
|
||||
* The endpoint of their *fastd* instance
|
||||
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)
|
||||
* 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)
|
||||
|
||||
Create a file with the template and instructions below in `/etc/fastd/crxn/fastd.conf`:
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ 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)
|
||||
* 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:
|
||||
|
||||
|
|
@ -78,21 +78,21 @@ fastd --generate-key
|
|||
Then save the *public key* and the *private key*. **Note:** You must give your peer your *public key*.
|
||||
|
||||
2. `"<secret key>"`
|
||||
* This must be the *private key* you generated earlier
|
||||
* 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>"`
|
||||
* Sets the interface name of the connection with the peer to crxn`<peerName>`
|
||||
* 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
|
||||
* Set this to either `ipv4` or `ipv6` depending of the address being used to connect to the remote peer
|
||||
3. `"<ip>"`
|
||||
* Set this to the remote peer's fastd address
|
||||
* Set this to the remote peer's fastd address
|
||||
4. `"port`
|
||||
* Set this to the remote peer's fastd port
|
||||
* Set this to the remote peer's fastd port
|
||||
5. `"<peer's public key>"`
|
||||
* Set this to your peer's public key
|
||||
* Set this to your peer's public key
|
||||
|
||||
The last thing to configure now is to rise the interface up when fastd starts (as it normally doesn't rise it for you), all occurences of `<interfaceName>` here should match the one in the `interface <interfaceName>;` declaration as shown earlier.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,127 @@
|
|||
# WireGuard
|
||||
|
||||
TODO: Add documentation
|
||||
## Configuration
|
||||
|
||||
For example, a sample WireGuard configuration looks like this:
|
||||
```
|
||||
[Interface]
|
||||
ListenPort = <listen port>
|
||||
PrivateKey = <privkey>
|
||||
|
||||
Address = <link local>/64
|
||||
Table = off
|
||||
|
||||
[Peer]
|
||||
PublicKey = <pubkey>
|
||||
PresharedKey = <psk>
|
||||
Endpoint = <endpoint>
|
||||
AllowedIPs = ::/0
|
||||
```
|
||||
|
||||
It is good practice to create a separate WireGuard tunnel for each peer. In this tutorial, `wg-quick` is used to manage the WireGaurd tunnels.
|
||||
|
||||
`<listen port>` is the local port to which the peer connects. This must be opened in the firewall using the UDP protocol. The only requirement for the port is that it is not already in use.
|
||||
|
||||
`<privkey>` is the private key. This should never be shared.
|
||||
|
||||
`<link local>` is link-local IPv6 address. It does not matter which one is used, because it is only valid for this interface. The only requirement is that the peer uses a different link-local IPv6 address.
|
||||
|
||||
`Table = off` prevents the creation of a default route for the `AllowedIPs`.
|
||||
|
||||
`<pubkey>` is the public key of the peer.
|
||||
|
||||
`<psk>` In addition to asymmetric keys, a symmetric pre-shared key can be used. This must be agreed in advance between the peers via a secure channel. A PSK is optional, but is recommended.
|
||||
|
||||
`<endpoint>` is the remote station, i.e. the peer. This is usually the host name or the IP address and the port. For example, `example.com:40006` or `peer1.crxn.de:20002`
|
||||
|
||||
`AllowedIPs` specifies the IP addresses that may be transported via the interface. `::/0` stands for any IPv6 address. If this is used, it is recommended to use firewall rules to avoid that peers can enter the clearnet via you.
|
||||
|
||||
## wg-quick
|
||||
|
||||
On Debian systems you store the configuration in `/etc/wireguard` with the file extension `.conf`. This may differ depending on the system. The name of the file also becomes the name of the interfaces. For example, you can save the file as `crxn_<peername>.conf`. The name of the interface then becomes `crxn_<peername>`.
|
||||
|
||||
The tunnel can be enabled with `wg-quick up <name>` and disabled with `wg-quick down <name>`. If can also control the tunnel with systemd:
|
||||
```
|
||||
$ sudo systemctl start wg-quick@<name>
|
||||
$ sudo systemctl stop wg-quick@<name>
|
||||
```
|
||||
Furthermore you can autostart the tunnel with systemd:
|
||||
```
|
||||
$ sudo systemctl enable wg-quick@<name>
|
||||
$ sudo systemctl disable wg-quick@<name>
|
||||
```
|
||||
|
||||
## Key generation
|
||||
|
||||
With the command `wg genkey` you can create a key:
|
||||
```
|
||||
$ wg genkey
|
||||
4HMlCI/Oz+sVmlM90c5YLpFR0/NaoMGv1uFT28qx1Gg=
|
||||
```
|
||||
|
||||
To calculate the public key that you share with your peer, you can use the `wg pubkey` command. For this you can type `wg pubkey`, insert the private key and press CTRL+D. Alternatively, you can pipe the private key.
|
||||
```
|
||||
$ wg pubkey
|
||||
4HMlCI/Oz+sVmlM90c5YLpFR0/NaoMGv1uFT28qx1Gg=
|
||||
RmK5OX34MLbEwJTRNl8i9ghrAS4SkKDsr24NIK2bWSY=
|
||||
```
|
||||
|
||||
```
|
||||
$ echo 4HMlCI/Oz+sVmlM90c5YLpFR0/NaoMGv1uFT28qx1Gg= | wg pubkey
|
||||
RmK5OX34MLbEwJTRNl8i9ghrAS4SkKDsr24NIK2bWSY=
|
||||
```
|
||||
(This method is not secure because it stores the private key in the command history).
|
||||
|
||||
## Tunnel status
|
||||
|
||||
The command `wg` shows all tunnels. The command `wg show <name>` shows only one specific tunnel.
|
||||
|
||||
```
|
||||
# wg show <name>
|
||||
interface: <name>
|
||||
public key: <my pubkey>
|
||||
private key: (hidden)
|
||||
listening port: <listen port>
|
||||
|
||||
peer: <pubkey>
|
||||
preshared key: (hidden)
|
||||
endpoint: <endpoint>
|
||||
allowed ips: ::/0
|
||||
latest handshake: 1 minute, 30 seconds ago
|
||||
transfer: 30.79 MiB received, 37.33 MiB sent
|
||||
```
|
||||
|
||||
A WireGuard tunnel only becomes active and performs a handshake when it is used. If a tunnel is not used, there will be no handshake. The tunnel can be activated with a ping on the peers inner tunnel address, for example. Whether the tunnel is working can be seen by `latest handshake`. If this line is present, the handshake was successful.
|
||||
|
||||
```
|
||||
$ ping fe80::2%<name>
|
||||
```
|
||||
|
||||
## Non-public peer
|
||||
|
||||
If only one peer has a public IP address and the other does not, for example because it is behind a NAT, WireGuard will also work. In this case, you do not specify an endpoint for the public peer. For the peer that is not public, omit the `ListenPort` and add an extra line. This causes the peer to send a kind of "ping" every `<sec>` seconds to maintain the tunnel.
|
||||
|
||||
```
|
||||
[Peer]
|
||||
... some config ...
|
||||
PersidentKeepalive = <sec>
|
||||
... some config ...
|
||||
```
|
||||
|
||||
The interval may be different depending on NAT and firewall. 20 to 60 seconds is recommended. Often used values are `20` or `25`.
|
||||
|
||||
## Dynamic IP addresses
|
||||
|
||||
It may happen that one peer has a dynamic IP address. Often a DNS name is then specified. However, WireGuard only resolves the DNS once at the start of the connection and therefore does not know of the new IP address. Therefore, you must manually tell WireGuard to resolve the new IP address:
|
||||
```
|
||||
wg set <name> peer "<pubkey>" endpoint "<endpoint>"
|
||||
```
|
||||
|
||||
This can then be executed as a cronjob every 30 minutes, for example:
|
||||
```
|
||||
*/30 * * * * /usr/bin/wg set <name> peer "<pubkey>" endpoint "<endpoint>"
|
||||
```
|
||||
|
||||
## Other documentation
|
||||
|
||||
The dn42 Wiki also has a guide to WireGuard: [in dn42](https://wiki.dn42/howto/wireguard) or [in clearnet](https://dn42.dev/howto/wireguard)
|
||||
|
|
|
|||
Loading…
Reference in New Issue