palo
/
tech-ingolf-wagner-de
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

nixos/tinc : update von der live-seite

master
Ingolf Wagner 2018-08-15 15:42:33 +02:00
parent 6fe56d37b5
commit b1c873fdea
1 changed files with 45 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
content/nixos/tinc.md
View File

@ -13,18 +13,19 @@ tinc-module.
I had to write my own,
because the standard `services.tinc` module
misses a lot of features,
for example maintaining sub-net and network wise activation and deactivation.
I designed it to be used with
for example forwarding to sub-networks and network wise activation and deactivation.
I designed it to work nicely with
[NixOps](https://nixos.org/nixops/).
You have to `enable` and `disable ` every network you define,
instead of `enable ` tinc and which enables all defined networks.
instead of `enable ` tinc which enables all defined networks.
This should make it easy to define all your networks
in one file (to keep track about everything).
in one file (to keep track about everything),
and micromanage in the computer specific definitions.
# How to use
# How to import
To use this module you can use `fetchgit` to import it.
You can use `fetchgit` to import it without downloading it yourself.
{{% note %}}
To find the newest `rev` and `sha256` just call `nix-shell -p nix-prefetch-git --run "nix-prefetch-git https://github.com/mrVanDalo/nixos-tinc.git"`
@ -60,43 +61,47 @@ $> nix-shell -p tinc_pre --run "tinc --config . generate-keys 4096"
After that is done we create the `hostfile` by
```
$> cat *.pub > hostfile
$> cat *.pub > hostfile ; rm *.pub
```
## Key-File-structure for these Examples
In the following examples we use the following file-structure
In the following examples I expect the following file-structure for keys and config files.
```
|-- configuration.nix
|-- public
| |-- Gibson
| | `-- hostfile
| |-- Hackbardt
| | `-- hostfile
| `-- HAL
| `-- hostfile
`-- secrets
|-- Gibson
| |-- ed25519_key.priv
| |-- hostfile
| `-- rsa_key.priv
|-- Hackbardt
| |-- ed25519_key.priv
| |-- hostfile
| `-- rsa_key.priv
`-- HAL
|-- ed25519_key.priv
|-- hostfile
`-- rsa_key.priv
```
# Using tinc to connect 3 computers
# Connect 3 computers
First we want to connect 3 computers in a private network of range ``10.1.1.0/24``.
We want to connect 3 computers in a private network of range ``10.1.1.0/24``.
One computer needs to be accessable from the internet,
it will be the computer that connects all the other computer.
You can have multiple computers which are reachable but for this example we only have one.
You can have multiple computers which are reachable from the internet
but for this example we only have one.
{{<figure src="/nixos/tinc/3computers.svg">}}
Here is the `configuration.nix`.
First we setup the whole infrastructure in the `default` and
than we `enable` and configure secret-keys
First we define the whole topolgy in `default` and
than we `enable` and configure secret-keys
for every computer in `Gibson`, `Hackbardt` and `HAL`
```
@ -124,7 +129,7 @@ default =
with lib;
services.custom.tinc =
let
publicHostFile = host: fileContent ./secrets/"${host}"/hostfile;
publicHostFile = host: fileContent ./public/"${host}"/hostfile;
in {
"private" = {
debugLevel = 0;
@ -196,9 +201,9 @@ includePrivateKeys "HAL" // {
}
```
If we deploy that and check the servers,
we can see tinc creates interfaces called `tinc.private`.
Observing the routes we see that tinc sets up everything so these computers can see each other.
If we deploy that and check the servers,
we can see that tinc creates interfaces called `tinc.private`.
Observing the routes we see that tinc sets up everything which is needed for proper routing.
```
$Gibson> ip addr show dev tinc.private
@ -229,12 +234,13 @@ PING HAL.private (10.1.1.3) 56(84) bytes of data.
**Awesome!** That was easy!
# Using tinc to connect 2 sub-nets
# Connect 2 sub-networks
So far so good,
So far so good,
but lets imagine we have some virtual machines running on 2 computers and want to make these virtual machines see each other.
This is a very common problem in [Kubernetes](https://kubernetes.io/).
It can be resolved by using the `tincSubnet` parameter.
It can be resolved by using the `tincSubnet` parameter,
to configure sub-network routing.
{{<figure src="/nixos/tinc/2subnets.svg">}}
@ -250,7 +256,7 @@ default =
with lib;
services.custom.tinc =
let
publicHostFile = name: fileContent ./secrets/"${name}"/hostfile;
publicHostFile = name: fileContent ./public/"${name}"/hostfile;
in {
"private" = {
debugLevel = 0;
@ -280,36 +286,31 @@ default =
...
```
After deployment we can see that `Gibson` has proper routing to the configured `tincSubnet`
ranges as well as to `10.1.1.0/24` to reach other the computers.
After deployment we can see that `Gibson` has proper routing to the configured `tincSubnet`
ranges as well as to `10.1.1.0/24` to reach the other network-nodes.
```
$> ip route show dev tinc.private
10.1.1.0/24 scope link
10.2.2.0/24 scope link
10.2.3.0/24 scope link
169.254.0.0/16 proto kernel scope link src 169.254.116.112 metric 203
$Gibson> ip route show dev tinc.private
10.1.1.0/24 scope link
10.2.2.0/24 scope link
10.2.3.0/24 scope link
169.254.0.0/16 proto kernel scope link src 169.254.116.112 metric 203
```
`Hackbardt` has routing to the network provided by `HAL`,
but has no routing (on the `tinc.private` interface) to the network it provides it self.
```
$> ip route show dev tinc.private
10.1.1.0/24 scope link
10.2.2.0/24 scope link
169.254.0.0/16 proto kernel scope link src 169.254.116.112 metric 203
$Hackbardt> ip route show dev tinc.private
10.1.1.0/24 scope link
10.2.2.0/24 scope link
169.254.0.0/16 proto kernel scope link src 169.254.116.112 metric 203
```
The module also sets the `sysctl` parameter
The module also sets the `sysctl` parameter
`net.ipv4.config.tinc/private.forwarding`
and
`net.ipv6.config.tinc/private.forwarding`
to
to
make sure the `tinc.private` interface forwards the traffic
to the configured sub-nets.
{{% note %}}
If that is not set to true, you have to turn it on yourself.
In the future this will also be managed by the `module`.
{{% /note %}}
to the configured sub-networks.