Marek Küthe
Gitea
parent
36d659433a
commit
5c31d5f6a6
|
|
@ -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/)
|
||||
|
|
|
|||
|
|
@ -24,9 +24,9 @@ and configuration details needed to get connected!
|
|||
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)
|
||||
1. [Setting up radv (router)](../home-network/radv)
|
||||
2. [Setting up SLAAC (hosts)](../home-network/slaac)
|
||||
* [DNS](../home-network/dns)
|
||||
|
||||
## What's next?
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -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