WIP: new z9 ccchh router #98

Draft
bitwhisker wants to merge 3 commits from new_ccchh_router into main
Owner

Linux router with systemd_networkd, nftables, unbound and kea_dhcp

new IP Ranges (10.89.208.0/20):

  • 10.89.208.0/22 Clients
  • 10.89.212.0/24 IoT
  • 10.89.213.0/24 Management/Services
  • 185.161.130.65/28 Public

creates roles:

  • unbound
  • kea_dhcp

Potentially missing:

  • changing IPs in all other configs

do we maybe want to split physical and virtual hosts?

Linux router with systemd_networkd, nftables, unbound and kea_dhcp new IP Ranges (10.89.208.0/20): - 10.89.208.0/22 Clients - 10.89.212.0/24 IoT - 10.89.213.0/24 Management/Services - 185.161.130.65/28 Public creates roles: - unbound - kea_dhcp Potentially missing: - changing IPs in all other configs do we maybe want to split physical and virtual hosts?
rt1(z9 host) unbound(role) kea_dhcp(role): create unbound and kea_dhcp role for rt1
Some checks failed
/ Ansible Lint (push) Failing after 2m30s
/ Ansible Lint (pull_request) Failing after 2m27s
/ build (pull_request) Failing after 2m39s
866005c055
- create unbound role
- create kea_dhcp role
- configure unbound and keadhcp on rt1(z9 host)
ansible lint: brackets are annoying
Some checks failed
/ Ansible Lint (push) Successful in 2m36s
/ Ansible Lint (pull_request) Successful in 2m36s
/ build (pull_request) Failing after 2m40s
28150818a7
june requested review from june 2026-05-24 04:43:53 +02:00
june left a comment

Core configuration looks good, tho I left some comments. Left some more comments on the roles as well.
The kea_dhcp role also is still missing a README, see the following READMEs for good references:

Core configuration looks good, tho I left some comments. Left some more comments on the roles as well. The `kea_dhcp` role also is still missing a README, see the following READMEs for good references: - https://git.hamburg.ccc.de/CCCHH/ansible-infra/src/commit/7832978ff732208f2f29f04ef446c7c51076c6d1/roles/secrets - https://git.hamburg.ccc.de/CCCHH/ansible-infra/src/commit/7832978ff732208f2f29f04ef446c7c51076c6d1/roles/deploy_systemd_resolved_config
@ -1,6 +1,7 @@
skip_list:
- "yaml[line-length]"
- "name[casing]"
- "yaml[brackets]"
Owner

That's not what linting is for.
Either just fix the brackets (you can also run ansible-lint locally to check for the errors) or ignore a specific file, if it doesn't make sense to lint.

That's not what linting is for. Either just fix the brackets (you can also run ansible-lint locally to check for the errors) or ignore a specific file, if it doesn't make sense to lint.
@ -14,6 +14,9 @@ all:
yate:
ansible_host: yate.ccchh.net
ansible_user: chaos
rt1:
Owner

It's fine, just feel like rt1 is one of those obscure names again, which gives more trouble than benefit.

It's fine, just feel like `rt1` is one of those obscure names again, which gives more trouble than benefit.
Author
Owner

do you have an idea/a proposal for a better name?
maybe z9-router or something like that?
I would say it would not be a good idea to name it just router,
because of the indirect name collision with the chaosknoten router.

do you have an idea/a proposal for a better name? maybe z9-router or something like that? I would say it would not be a good idea to name it just router, because of the indirect name collision with the chaosknoten router.
Owner

Oh, that totally makes sense. I'm fine with the name, if others really like it, but personally I would prefer something like z9-router indeed.

Oh, that totally makes sense. I'm fine with the name, if others really like it, but personally I would prefer something like `z9-router` indeed.
@ -53,3 +69,4 @@
dooris:
rt1:
ansible_pull_hosts:
hosts:
Owner

If we configure ansible-pull variables above, the host should also be added to the relevant host group. (However an ansible-pull age private key is still missing.)

If we configure ansible-pull variables above, the host should also be added to the relevant host group. (However an ansible-pull age private key is still missing.)
@ -0,0 +49,4 @@
ct state invalid drop
ct state established,related accept
ip protocol icmp accept
Owner

This seems to be using tabs for some reason, probably best to replace with spaces.
We might want to start using .editorconfig files in the future.

This seems to be using tabs for some reason, probably best to replace with spaces. We might want to start using `.editorconfig` files in the future.
@ -0,0 +75,4 @@
udp dport 51820 accept comment "allow WireGuard access"
# Allow DHCP server access.
iifname { $lan_ifs } udp dport 67 accept comment "allow dhcp server access"
Owner

Same indentation problem here.

Same indentation problem here.
@ -0,0 +102,4 @@
ct state established,related accept
# Allow internet access.
iifname { $lan_ifs, $if_wg55_management } oifname $wan_ifs accept comment "allow internet access"
Owner

Same indentation problem here.

Same indentation problem here.
@ -0,0 +108,4 @@
meta nfproto ipv4 oifname $v4_exposed_ifs accept comment "allow v4 exposed network access"
meta nfproto ipv6 oifname $v6_exposed_ifs accept comment "allow v6 exposed network access"
# Allow clients and managment to most
Owner

"managment" -> "management"
Also "Allow clients and management to lan interfaces." might be a better comment for this rule.

"managment" -> "management" Also "Allow clients and management to lan interfaces." might be a better comment for this rule.
@ -0,0 +5,4 @@
[WireGuard]
ListenPort=51820
PrivateKeyFile=/etc/ansible_secrets/wireguard_wg55_privat_key
Owner

wireguard_wg55_privat_key -> wireguard_wg55_private_key

`wireguard_wg55_privat_key` -> `wireguard_wg55_private_key`
@ -0,0 +75,4 @@
[WireGuardPeer]
# friendly_name = lilly-lillysLaptop
AllowedIPs = 10.89.214.16/32 #,2a07:c481:1:37::/128
Owner

IPv6 is missing the most significant bits. And is generally commented out weirdly?
#,2a07:c481:1:37::/128 -> ,2a07:c481:1:37::16/128

IPv6 is missing the most significant bits. And is generally commented out weirdly? ` #,2a07:c481:1:37::/128` -> `,2a07:c481:1:37::16/128`
Author
Owner

took that directly from the opnsense config and just converted it to networkd format
and to not produce unexpected behavior I commented the ipv6 out,
because it did not have the important part

took that directly from the opnsense config and just converted it to networkd format and to not produce unexpected behavior I commented the ipv6 out, because it did not have the important part
Owner

Ah, ye, makes sense! Would just assign an IP then as that doesn't hurt and Lilly can choose to use it or not.

Ah, ye, makes sense! Would just assign an IP then as that doesn't hurt and Lilly can choose to use it or not.
@ -0,0 +80,4 @@
[WireGuardPeer]
# friendly_name = bitwhisker
AllowedIPs = 10.89.214.17/32,2a07:c481:1:37::a/128
Owner

If we want to count the v6 up in hex (which I think is reasonable as we do the same for the VLAN ID in the prefix), then it should also be done properly.

dec -> hex
-----------
...
15  ->  f # langoor_home
16  -> 10 # lilly-lillysLaptop
17  -> 11 # bitwhisker
18  -> 10 # forestcat
If we want to count the v6 up in hex (which I think is reasonable as we do the same for the VLAN ID in the prefix), then it should also be done properly. ``` dec -> hex ----------- ... 15 -> f # langoor_home 16 -> 10 # lilly-lillysLaptop 17 -> 11 # bitwhisker 18 -> 10 # forestcat ```
Author
Owner

took that directly from the opnsense config and just converted it to networkd format

was considering it, but my reason for not doing that, was because I did not want to change the last part of the IPs that are already in use

took that directly from the opnsense config and just converted it to networkd format was considering it, but my reason for not doing that, was because I did not want to change the last part of the IPs that are already in use
Owner

Ah, I see, yeah, okay. We would have the option now, as we change things anyway, to clean up that configuration, but I'm also fine with keeping it as is for legacy reasons.
Just something to consider.

Ah, I see, yeah, okay. We would have the option now, as we change things anyway, to clean up that configuration, but I'm also fine with keeping it as is for legacy reasons. Just something to consider.
@ -0,0 +17,4 @@
[IPv6SendRA]
UplinkInterface=netwan.400
EmitDomains=true
Domains=ccchh.net
Owner

The search domain would be z9.ccchh.net. Unless it got decided to drop that now.

The search domain would be `z9.ccchh.net`. Unless it got decided to drop that now.
Author
Owner

yes, we said yesterday, that we want to get rid of z9.ccchh.net. and z9. (tld)

yes, we said yesterday, that we want to get rid of z9.ccchh.net. and z9. (tld)
june marked this conversation as resolved
@ -0,0 +4,4 @@
ansible.builtin.systemd_service:
daemon_reload: true
- name: Kea_dhcp4.reloaded
Owner

Called "reloaded" even tho the action is restarted. One of them needs to be adjusted.

Called "reloaded" even tho the action is `restarted`. One of them needs to be adjusted.
@ -0,0 +10,4 @@
state: restarted
enabled: true
- name: Kea_dhcp6.reloaded
Owner

Same restarted/reloaded comment as above.

Same restarted/reloaded comment as above.
@ -0,0 +16,4 @@
state: restarted
enabled: true
- name: Kea_ctrl.reloaded
Owner

Same restarted/reloaded comment as above.

Same restarted/reloaded comment as above.
@ -0,0 +1,8 @@
---
- name: Install Kea on Archlinux
Owner

We don't have any Arch Linux infrastructure, so we don't need this.

We don't have any Arch Linux infrastructure, so we don't need this.
@ -0,0 +5,4 @@
when: ansible_facts['distribution'] == "Debian"
ansible.builtin.deb822_repository:
name: "isc-{{ kea_dhcp__version_repo }}"
uris: "https://dl.cloudsmith.io/public/isc/{{ kea_dhcp__version_repo }}/deb/debian"
Owner

Do we have a requirement for the more up-to-date version present in the upstream repository or is the one in the Debian repos sufficient?

Do we have a requirement for the more up-to-date version present in the upstream repository or is the one in the Debian repos sufficient?
Author
Owner

chris wrote this, I don't know why they thought this would be necessary

@c6ristian

chris wrote this, I don't know why they thought this would be necessary @c6ristian
Owner

For Club this properly doesn't matter. This was because the compatibility between different version has history been often Subject to Change. As long as there are no plan to do HA its probably fine.

For Club this properly doesn't matter. This was because the compatibility between different version has history been often Subject to Change. As long as there are no plan to do HA its probably fine.
Owner

Alright, gotcha. Then just using the Debian-packaged version nicely saves us adding a repo.

Alright, gotcha. Then just using the Debian-packaged version nicely saves us adding a repo.
@ -0,0 +16,4 @@
ansible.builtin.apt:
name:
- isc-kea-dhcp4
- isc-kea-dhcp6
Owner

Since we got granular control over whether to use dhcpv4, v6 or the agent, would it make sense to then also granularly install the relevant packages?
I would think Debian would also automatically start the services, which wouldn't make sense, if no sensible v6 config is present.

Since we got granular control over whether to use dhcpv4, v6 or the agent, would it make sense to then also granularly install the relevant packages? I would think Debian would also automatically start the services, which wouldn't make sense, if no sensible v6 config is present.
@ -0,0 +1,51 @@
---
- name: Include config vars
tags: [ kea, include_vars ]
Owner

I would rather just stick to only having tags at the playbook level. I don't think this kind granular control for the role is really needed as it the config files also shouldn't trigger a reload, if not changed.

I would rather just stick to only having tags at the playbook level. I don't think this kind granular control for the role is really needed as it the config files also shouldn't trigger a reload, if not changed.
Author
Owner

this was just copied from the fux noc ansible, but I can remove it

this was just copied from the fux noc ansible, but I can remove it
@ -0,0 +3,4 @@
tags: [kea, dhcp]
block:
- name: Install Kea on Archlinux
when: ansible_facts['distribution'] == "Archlinux"
Owner

Again, getting rid of the Arch Linux logic also greatly simplifies this file.

Again, getting rid of the Arch Linux logic also greatly simplifies this file.
Author
Owner

this was just copied from the fux noc ansible, but I can remove it

this was just copied from the fux noc ansible, but I can remove it
@ -0,0 +18,4 @@
- name: Install stork-agent with aur_pkg_install
ansible.builtin.include_role:
name: aur_pkg_install
Owner

We don't even have this role present in our repo, so just getting rid of the Arch Linux logic probably makes sense.

We don't even have this role present in our repo, so just getting rid of the Arch Linux logic probably makes sense.
@ -0,0 +12,4 @@
{% for subnet in kea_dhcp__dhcp6.subnets %}
{
"id": {{ subnet.id }},
"subnet": "{{ subnet.subnet }}",
Owner

Just a nit-pick, but having the indentation be consistent across the dhcp4 and dhcp6 config would be nice.

Just a nit-pick, but having the indentation be consistent across the dhcp4 and dhcp6 config would be nice.
@ -0,0 +1,44 @@
### the IP or hostname to listen on for incoming Stork server connections
# STORK_AGENT_HOST=
Owner

Most of the variables here are commented out, so we can just massively simplify this file.
If they are included for documentation purposes, I would rather include a link in the README.

Most of the variables here are commented out, so we can just massively simplify this file. If they are included for documentation purposes, I would rather include a link in the README.
@ -0,0 +1 @@
nameserver 127.0.0.1
Owner

Same comment as below: We already have a role for managing the resolv.conf, so rather include that.
See: 7832978ff7/roles/deploy_systemd_resolved_config

Same comment as below: We already have a role for managing the `resolv.conf`, so rather include that. See: https://git.hamburg.ccc.de/CCCHH/ansible-infra/src/commit/7832978ff732208f2f29f04ef446c7c51076c6d1/roles/deploy_systemd_resolved_config
@ -0,0 +1,27 @@
- name: unbound.restarted
tags: [ unbound, dns, dns_resolver ]
Owner

Again, same comment as in the kea role, I don't think it makes sense to have granular tags in the role itself.

Again, same comment as in the kea role, I don't think it makes sense to have granular tags in the role itself.
@ -0,0 +10,4 @@
- name: install extra dns tooling
become: true
ansible.builtin.package:
name: [ bind ] # the bind package includes tools like dig in archlinux
Owner

There is no bind package on Debian and we already install dig in the base_config role:

There is no `bind` package on Debian and we already install `dig` in the `base_config` role: https://git.hamburg.ccc.de/CCCHH/ansible-infra/src/commit/7832978ff732208f2f29f04ef446c7c51076c6d1/roles/base_config/tasks/main.yaml#L30
@ -0,0 +39,4 @@
state: started
enabled: true
- name: disable systemd-resolved
Owner

We have a nice role for managing systemd-resolved already, so no need to duplicate functionality here.
See: 7832978ff7/roles/deploy_systemd_resolved_config

We have a nice role for managing systemd-resolved already, so no need to duplicate functionality here. See: https://git.hamburg.ccc.de/CCCHH/ansible-infra/src/commit/7832978ff732208f2f29f04ef446c7c51076c6d1/roles/deploy_systemd_resolved_config
@ -0,0 +1,17 @@
---
- name: install unbound prometheus exporter
become: true
ansible.builtin.package:
Owner

There's no unbound-prometheus-exporter package on Debian.

There's no `unbound-prometheus-exporter` package on Debian.
@ -0,0 +3,4 @@
become: true
ansible.builtin.package:
name: prometheus-unbound-exporter
notify: prometheus-unbound-exporter.enabled
Owner

I would rather move the enable and start logic into the file itself, since that's not really the job of a handler. See the main unbound setup tasks for reference.

I would rather move the enable and start logic into the file itself, since that's not really the job of a handler. See the main unbound setup tasks for reference.
@ -0,0 +3,4 @@
server:
{% if unbound_enable_dnssec -%}
# disable chroot because unbound is the only thing running on the VM
# and because it has issues with how archlinux configures the systemd units write protection regarding the anchor file
Owner

Is this still relevant on Debian? Again, we don't use Arch Linux in our infra.

Is this still relevant on Debian? Again, we don't use Arch Linux in our infra.
@ -0,0 +12,4 @@
{% endif -%}
# use all CPUs
num-threads: 2
Owner

Are those all the CPUs we use? Might it make sense to have this configurable or at least change the comment?

Are those all the CPUs we use? Might it make sense to have this configurable or at least change the comment?
Some checks failed
/ Ansible Lint (push) Successful in 2m36s
/ Ansible Lint (pull_request) Successful in 2m36s
/ build (pull_request) Failing after 2m40s
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin new_ccchh_router:new_ccchh_router
git switch new_ccchh_router

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff new_ccchh_router
git switch new_ccchh_router
git rebase main
git switch main
git merge --ff-only new_ccchh_router
git switch new_ccchh_router
git rebase main
git switch main
git merge --no-ff new_ccchh_router
git switch main
git merge --squash new_ccchh_router
git switch main
git merge --ff-only new_ccchh_router
git switch main
git merge new_ccchh_router
git push origin main
Sign in to join this conversation.
No description provided.