User Tools

Site Tools


infrastructure:servers:chaosknoten

Chaosknoten

hostname:
chaosknoten
location:
IRZ42
maintainer:
Infra-Team
netbox:
https://netbox.hamburg.ccc.de/dcim/devices/40/

Hardware

  • Dell PowerEdge R730
  • 2x Xeon E5-2640 v4 (10c 20t)
  • 512GB RAM (32x 16GB)

Zweck

Öffentliche Dienste des CCCHH und von Freunden

Gast-VMs

Die VMs sind in Netbox dokumentiert: Virtual Machines Cluster=chaosknoten

Firewall-Freischaltung

Der Zugriff auf das Proxmox-Webinterface ist nur von ausgewählten IP-Adressen aus möglich:

  • CCCHH-Z9: 185.161.129.132 und 2a07:c480:103:2::2
  • stb: 213.240.180.39 und 2a01:170:118b::1
  • haegar: 136.243.3.21, 136.243.3.60, 2a01:4f8:211:1c94::2, 82.66.166.90

Netzwerkanbindung

Chaosknoten hat vier physikalische Interfaces (plus IPMI):

  • eno1: SFP+-Slot, dz. nicht benutzt
  • eno2: SFP+-Slot, dz. nicht benutzt
  • eno3:
    • 1G Kupfer
    • verbunden mit IRZ42-Netz VLAN 48 (aber bei uns ungetaggt)
    • von hinten gesehen linker Port
    • grünes Patchkabel zu Switchport 15
  • eno4:
    • 1G Kupfer
    • verbunden mit IRZ42-Netz VLAN 512 (aber bei uns ungetaggt)
    • von hinten gesehen rechter Port
    • rotes Patchkabel zu Switchport 18

eno3 und eno4 sind jeweils auf vmbr3 und vmbr4 gebridged.

vmbr4 hat die Adresse 212.12.48.126/24 für SSH und Management-Webinterface von Proxmox.

Die VMs haben Adressen aus verschiedenen Netzen. Siehe Netbox Prefixes IRZ42

IPMI-iDRAC-Interface

  • 1G Kupfer
  • verbunden mit ipmi-vpn.zs64.net, ein EdgeRouter X mit OpenWrt, der 6 HE höher hängt (hinter lokschuppen und jachthafen)
  • Wireguard-Config liegt in Pass unter noc/server/chaosknoten-ipmi/wireguard
  • Zugang zum Router liegt in Pass unter noc/server/zs64-ipmi/root
  • Hostname chaosknoten-ipmi.hamburg.ccc.de / 44.128.124.4

Network Design

Currently only some traffic is going through the old router VM (turing) and other VMs are routed by Wieske. We intend to move over to a setup where all traffic is going through a new router VM (router.hamburg.ccc.de).

There are requirements for 3 main networks:

  • v4-NAT: VMs without public IPv4 address behind the public reverse proxy
  • public: VMs with public IPv4 address
  • VMs without public interface at all, e.g. CI runners

Internal networks are all running on one linux bridge interface vmbr0 using VLANs to separate them. See NetBox VLANs IRZ42 for available VLAN IDs and NetBox router net0 for those assigned to vmbr0/net0 of the router VM.

Internal IPv4 addresses shall use 10.32.0.0/16 (NetBox-Link). Each VLAN shall use it's own /24-network with the third byte matching the VLAN ID, if private IPs are needed.

The router will have additional network interfaces for the uplink bridge devices vmbr3 (net1) and vmbr4 (net2) which match the physical interfaces.

How to add VMs

To add a new VM:

  • Generate new public IPv6 and add to Netbox, e.g. in v4-NAT network
  • Add records to DNS server
    • AAAA record on $hostname.hosts.hamburg.ccc.de
    • A and AAAA records for $service.hamburg.ccc.de as needed, e.g. via public-reverse-proxy
  • Create VM in Proxmox and note MAC address
  • Add VM in NetBox
    • Create interface in net0 with the MAC address from Proxmox and the suitable VLAN
    • Configure the chosen IPv6 address in cloud-init, IPv4 shall be DHCP
  • Setup firewall in Proxmox as needed
  • When in v4-NAT network: Re-deploy public-reverse-proxy

Legacy IPv4 Networks

Public IPv4s

We have the following public IPv4 subnets/ranges available:

Private IPv4s

We use the following private IPv4 ranges:

Legacy IPv6 Networks

The new prefix for IPv6 connectivity is 2a00:14b0:42:100::/56 (NetBox-Link). It is routed through our new router VM (which shall have 2a00:14b0:4200:3500::130:2/112) and the uplink router on 2a00:14b0:4200:3500::130:1. Please see the NetBox which sub-prefixes are used for what!

Legacy: We have 2 IPv6-64-Prefixes, which map to corresponding IPv4-Prefixes/-Ranges.

2a00:14b0:4200:3000::/64

2a00:14b0:4200:3000::/64 (NetBox-Link)
This subnet corresponds to the following IPv4-Subnets:

To generate an IPv6 corresponding to an IPv4, we use the following convention: Take the last octet of the IPv4-address in decimal and use it for the first two bytes of the localpart, but with the digits as hex.
So e.g.: 212.12.48.1252a00:14b0:4200:3000:125::1

2a00:14b0:f000:23::/64

2a00:14b0:f000:23::/64 (NetBox-Link)
This subnet corresponds to the following IPv4-Subnets:

To generate an IPv6 corresponding to an IPv4 from either 212.12.50.208/29 or 212.12.51.128/28, we use the following convention: Take the 3rd octet of the IPv4-address in decimal and use it for the first two bytes of the localpart, but with the digits in hex. Then take the last octet of the IPv4-address in decimal and use it for the third and fourth bytes of the localpart, but with the digits as hex.
So e.g.:

  • 212.12.50.2122a00:14b0:f000:23:50:212:0:1
  • 212.12.51.1332a00:14b0:f000:23:51:133:0:1

To generate an IPv6 corresponding to an IPv4 from 172.31.17.0/25, we use the following convention: Take the last octet of the IPv4-address in decimal and use it for the last two bytes of the localpart, but with the digits in hex.
So e.g.:

  • 172.31.17.532a00:14b0:f000:23::53

Konfiguration

Zugriff auf VMs

SSH auf alten VMs läuft auf nicht-Standard-Ports, normalerweise 42666.

VMs sollten per IPv6 direkt erreichbar sein. Falls Zugriff aus einem Netz ohne IPv6 erforderlich ist, kann die Router-VM als Jumphost verwendet werden.

Alte VMs, die eine RFC1918-Adresse haben, können über turing-router oder turing-main als Jumphost erreicht werden. Als Beispiel hier ein Snippet für .ssh/config.

Host ccchh-router
    User chaos
    Hostname router.hamburg.ccc.de

Host *.host.hamburg.ccc.de
    User chaos
    ProxyJump ccchh-router


## legacy
Host ccchh-jumphost
    User chaos
    Hostname public-reverse-proxy.hamburg.ccc.de

Host *-intern.hamburg.ccc.de
    User chaos
    ProxyJump ccchh-jumphost

Host turing
    HostName turing.hamburg.ccc.de
    Port 4222
    User chaos

Host turing-main
    HostName turing.hamburg.ccc.de
    Port 42666
    User chaos

HOWTO Chaosknoten-Reboot

Vor dem Reboot

VMs hibernaten

Eine Reihe von VMs brauchen beim Booten ein Secret über die Konsole, z. B. für LUKS. Wenn man das nicht machen will, kann mann die betreffenden VMs in den Winterschlaf schicken. Wir haben alle VMs, für die das notwendig ist, mit dem Tag “luks” markiert.

# ./suspend-luks-vms.sh

Nach dem Reboot

Was nach einem reboot alles passieren muss, damit alle services wieder hochkommen.

ZFS encrypted Dataset entsperren

Key liegt im pass unter noc/server/chaosknoten/zfs/rust0-encrypted-passphrase

zfs load-key rust0/encrypted

Assigned Services

infrastructure/servers/chaosknoten.txt · Last modified: by jtbx

Except where otherwise noted, content on this wiki is licensed under the following license: CC0 1.0 Universal
CC0 1.0 Universal Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki