MikroTik-Umstellung¶

Archivierter Stand

Diese Seite beschreibt einen früheren oder abgelösten Aufbau. Sie dient nur zur Nachvollziehbarkeit und darf nicht als aktuelle Wiederaufbauanleitung verwendet werden. Der produktive Stand steht unter Infrastruktur.

Dieses Dokument beschreibt die praktische Migration vom alten Fritzbox-Netz 192.168.178.0/24 in das neue MikroTik-Netz. Es dient als Checkliste, damit bei einem IP-Wechsel nicht nur die Adresse des Systems, sondern auch alle Abhängigkeiten, Firewalls und Vertrauensregeln angepasst werden.

Grundsatz für den Server-Umzug¶

Die Server und VMs bleiben zunächst vollständig im Management-VLAN 10. Proxmox benötigt deshalb vorerst keinen VLAN-Trunk und keine VLAN-Tags an den virtuellen Netzwerkkarten.

System	Neue Adresse
Proxmox	`10.10.10.10`
Home Assistant	`10.10.10.20`
OpenCCU	`10.10.10.21`
Cloudflare-LXC	`10.10.10.30`
ebusd Heizung	`10.10.10.31`
ebusd Lüftung	`10.10.10.32`
MCP-Server	`10.10.10.33`

Gateway und DNS im Management-Netz sind jeweils 10.10.10.1.

Sichere Migrationsreihenfolge¶

Proxmox-WLAN als Notzugang einrichten und testen.
Proxmox-LAN auf 10.10.10.10 umstellen.
Cloudflare-LXC umziehen.
MCP-Server umziehen.
Home Assistant umziehen.
OpenCCU umziehen.
ebusd-Container umziehen.
Alle alten IP-Verweise und temporären Hilfsadressen entfernen.
Wiki und Adressplan aktualisieren.

Proxmox¶

Netzwerkkonfiguration¶

Die Bridge vmbr0 verwendet:

auto vmbr0
iface vmbr0 inet static
    address 10.10.10.10/24
    gateway 10.10.10.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

Der MikroTik-Port ether3 ist ein ungetaggter Access-Port im VLAN 10. VLAN aware bleibt auf vmbr0 deaktiviert, solange alle Server im Management- VLAN liegen.

Hosts-Datei¶

In /etc/hosts muss die lokale Proxmox-Adresse ebenfalls angepasst werden:

127.0.0.1 localhost.localdomain localhost
10.10.10.10 pve.diebrocks.home pve

WLAN-Notzugang¶

Die WLAN-Karte dient nur als Rückfallebene für den Proxmox-Host:

SSID: Dev@DieBrocks.home
IP: 10.10.20.15/24
kein zweites Standard-Gateway
keine VMs oder Container über WLAN bridgen

Die WLAN-Anmeldung erfolgt über den interface-spezifischen wpa_supplicant-Dienst. Die Datei liegt unter:

/etc/wpa_supplicant/wpa_supplicant-wlp2s0.conf

Der Dienst wird mit folgendem Befehl dauerhaft aktiviert:

systemctl enable --now wpa_supplicant@wlp2s0.service

Notzugang:

https://10.10.20.15:8006

Cloudflare-LXC¶

Netzwerkkarte¶

LXC 102:

IPv4/CIDR: 10.10.10.30/24
Gateway: 10.10.10.1
Bridge: vmbr0
VLAN-Tag: keiner

Tunnelziele¶

In /etc/cloudflared/config.yml müssen alle internen Ziele auf die neuen Adressen geändert werden:

ingress:
  - hostname: ha.diebrocks.com
    service: http://10.10.10.20:8123

  - hostname: pve.diebrocks.com
    service: https://10.10.10.10:8006
    originRequest:
      noTLSVerify: true
      connectTimeout: 30s
      keepAliveTimeout: 1h

  - hostname: oc.diebrocks.com
    service: http://10.10.10.21

  - hostname: mcp.diebrocks.com
    path: ^/admin
    service: http://10.10.10.33:3001

  - hostname: mcp.diebrocks.com
    service: http://10.10.10.33:3000

  - service: http_status:404

Die spezielle /admin-Regel muss vor der allgemeinen MCP-Regel stehen.

Nach jeder Änderung:

cloudflared tunnel ingress validate
systemctl restart cloudflared
systemctl status cloudflared --no-pager

Home Assistant¶

IP-Adresse¶

Home Assistant OS kann für den ersten Zugriff kurz per DHCP gestartet werden. Danach wird die feste Adresse eingetragen:

IP: 10.10.10.20/24
Gateway: 10.10.10.1
DNS: 10.10.10.1

Die Schnittstelle heißt aktuell enp6s18.

Einzeiliger CLI-Befehl:

network update enp6s18 --ipv4-method static --ipv4-address 10.10.10.20/24 --ipv4-gateway 10.10.10.1 --ipv4-nameserver 10.10.10.1

Cloudflare als vertrauenswürdiger Proxy¶

Nach dem IP-Wechsel des Cloudflare-LXC muss in /config/configuration.yaml die neue Proxy-Adresse eingetragen werden:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 10.10.10.30

Die alte Adresse 192.168.178.16 entfernen. Ohne diese Änderung antwortet Home Assistant über den Tunnel mit 400 Bad Request.

OpenCCU-Integration¶

Nach dem Umzug der OpenCCU muss in der Integration Homematic(IP) Local for OpenCCU die CCU-Adresse auf 10.10.10.21 geändert werden.

OpenCCU¶

Temporärer Zugriff auf die alte Adresse¶

Wenn die OpenCCU nach dem Proxmox-Umzug noch auf 192.168.178.18 steht, kann dem Cloudflare-LXC temporär eine zweite Adresse im alten Netz gegeben werden:

ip addr add 192.168.178.250/24 dev eth0

Damit kann Cloudflare die alte CCU-Adresse weiterhin erreichen. Die Tunnelregel bleibt währenddessen temporär auf:

- hostname: oc.diebrocks.com
  service: http://192.168.178.18

Nach erfolgreichem Umzug wird die Hilfsadresse wieder entfernt:

ip addr del 192.168.178.250/24 dev eth0

Neue Netzwerkeinstellungen¶

IP-Adresse: 10.10.10.21
Netzmaske: 255.255.255.0
Gateway: 10.10.10.1
DNS: 10.10.10.1

Interne OpenCCU-Firewall¶

Die OpenCCU besitzt eine eigene Firewall. Ein reiner IP-Wechsel reicht daher nicht aus.

Pfad in der Weboberfläche:

Einstellungen -> Systemsteuerung -> Firewall konfigurieren

Empfohlene Einstellungen:

Firewall-Richtlinie: Ports blockiert
Homematic XML-RPC API: Eingeschraenkt
Remote Homematic-Script API: Eingeschraenkt
bei Bedarf Mediola-Zugriff: Eingeschraenkt
erlaubte IP-Adresse: 10.10.10.20

10.10.10.20 ist die Home-Assistant-Adresse. Alternativ kann gezielt ein notwendiger Adressbereich eingetragen werden, einzelne IPs sind jedoch restriktiver.

Wenn diese Freigabe fehlt, ist die Weboberfläche der CCU erreichbar, aber die Homematic-Ports wie 2001 oder 2010 werden für Home Assistant abgelehnt. Die Integration meldet dann beispielsweise Connection refused.

MCP-Server¶

LXC 108:

IPv4/CIDR: 10.10.10.33/24
Gateway: 10.10.10.1
Bridge: vmbr0
VLAN-Tag: keiner

Nach dem Umzug müssen alle internen Konfigurationen, SSH-Ziele und erlaubten Quelladressen von 192.168.178.7 auf 10.10.10.33 angepasst werden.

Der Cloudflare-Tunnel verwendet:

MCP/API: Port 3000
Admin-Oberfläche: Port 3001, Pfad ^/admin

MikroTik-Firewall¶

Home Assistant bleibt im Management-VLAN und erreicht IoT-Geräte per Routing. Eine zweite Netzwerkkarte in Home Assistant ist zunächst nicht erforderlich.

Wichtig für die Firewall-Reihenfolge:

established,related,untracked erlauben
notwendige explizite Verbindungen erlauben
erst danach IoT-Zugriffe auf interne Netze sperren

Die Antwortpakete von IoT-Geräten auf eine von Home Assistant gestartete Verbindung dürfen nicht vor der Established-Regel verworfen werden.

Für automatische Geräteerkennung über VLAN-Grenzen können später mDNS- Weiterleitung und gegebenenfalls eine SSDP-Lösung notwendig sein. Direkte Integrationen per IP funktionieren über normales Routing.

Abschlusskontrolle pro System¶

Nach jedem Umzug prüfen:

richtige IP und Netzmaske
Default-Gateway 10.10.10.1
DNS-Auflösung
lokale Weboberfläche
externe Cloudflare-Domain
interne Firewall des Dienstes
vertrauenswürdige Proxy- oder Quell-IP-Listen
Integrationen mit hart eingetragener alter IP
systemd-Dienste und offene Ports

Typische versteckte Stellen bei einem IP-Wechsel¶

System	Zusätzlich anzupassen
Proxmox	`/etc/hosts`, DNS, Cluster-/Storage-Ziele falls vorhanden
Cloudflare	alle `service:`-Ziele in `config.yml`
Home Assistant	`trusted_proxies`, Integrationen mit fester IP
OpenCCU	interne Firewall und erlaubte HA-IP
MCP	Cloudflare-Ziele, SSH-Hostziele, interne ACLs
MikroTik	Firewallregeln mit alten Quell- oder Zieladressen