mirror of https://codeberg.org/CRXN/docs.git
Merge pull request 'update content' (#8) from mark22k/docs:master into master
Reviewed-on: https://codeberg.org/CRXN/docs/pulls/8
This commit is contained in:
Tristan B. Kildaire
commit
eee3b4a1e8
|
|
@ -11,6 +11,7 @@ CRXN uses IGP and therefore does not know the concept of AS numbers or originati
|
|||
## 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
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
|
|
@ -90,7 +94,7 @@ $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)
|
||||
- [OTG](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.
|
||||
|
|
@ -1,9 +1,8 @@
|
|||
Radv
|
||||
====
|
||||
# Radv
|
||||
|
||||
This document is for setting up radv on Bird 2.0.
|
||||
|
||||
# General syntax
|
||||
## General syntax
|
||||
|
||||
You will want to add one of these to one of your Bird configuration files:
|
||||
|
||||
|
|
@ -9,35 +9,35 @@ Configuring your hosts for automatic IP network and address assignment, DNS and
|
|||
|
||||
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).
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
# DNS
|
||||
|
||||
TODO: Add documentation @mark22k
|
||||
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ peer "<peerName>"
|
|||
{
|
||||
remote <type> "<ip>" port <port>;
|
||||
key "<peer's public key>";
|
||||
interface "<interface>";
|
||||
interface "$INTERFACE";
|
||||
float yes;
|
||||
}
|
||||
|
||||
|
|
@ -55,14 +55,14 @@ peer "<peerName>"
|
|||
If your system uses ifconfig append
|
||||
```
|
||||
# On interface rise run
|
||||
on up "ifconfig <interface> up";
|
||||
on down "ifconfig <interface> down";
|
||||
on up "ifconfig $INTERFACE up";
|
||||
on down "ifconfig $INTERFACE down";
|
||||
```
|
||||
|
||||
If your system uses ip append
|
||||
```
|
||||
on up "ip link set dev <interface> up";
|
||||
on down "ip link set dev <interface> down";
|
||||
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,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)
|
||||
|
|
|
|||
|
|
@ -22,9 +22,9 @@ nav:
|
|||
- Setting up your home network:
|
||||
- Configuring your hosts:
|
||||
- Automatically with SLAAC and radv:
|
||||
- Setting up radv (router): home_network/radv
|
||||
- Setting up SLAAC (hosts): home_network/slaac
|
||||
- DNS: home_network/dns
|
||||
- Setting up radv (router): home-network/radv
|
||||
- Setting up SLAAC (hosts): home-network/slaac
|
||||
- DNS: home-network/dns
|
||||
|
||||
- Additional:
|
||||
- DNS: additional/dns
|
||||
|
|
|
|||
Loading…
Reference in New Issue