Howto: piVCCU Routing anstatt Bridging

[predi-ger-many]

Hallo,

unter https://github.com/alexreinert/piVCCU/b ... berrypi.md
und https://github.com/alexreinert/piVCCU/b ... up/wlan.md

befinden sich Anleitungen, wie man manuell das Setup unter Verwendung von Bridging macht.

Für LAN und WLAN unterscheiden sich die Anleitungen. Des Weiteren bekommt der PI immer ZWEI IPs,
was mir persönlich absolut gefällt. Des Weiteren halte ich nicht viel von Bridging mit physischen Adapter. In 20 Jahren als Linux Admin habe ich damit immer wieder schlechte Erfahrungen gemacht.

Daher habe ich mich mal aufgemacht und eine Anleitung erstellt, welche die Installation auf dem PI unter Verwendung von Routing anstatt Bridging beschreibt. Die Anleitung gilt für LAN und WLAN. Bei WLAN muss man nur das eth0 gegen wlan0 ersetzen.

Anmerkungen zum Dokument

Code: Alles auswählen

eth0
IP des PI: 192.168.1.51
Maske: 255.255.255.0
Gateway: 192.168.1.1
DNS 192.168.1.1

... über eth0 ist der PI aus dem Netzwerk erreichbar

br0
IP des PI: 192.168.255.254
Maske: 255.255.255.0
Gateway: NIX
DNS: NIX

... br0 wird mit piVCCU gebridged
... br0 wird nicht mit eth0 bebridged
... Verbindung mit eth0 erfolgt per Routing und NAT

vethpivccu
IP für die CCU2: 192.168.255.1
Maske: 255.255.255.0
Gateway: IP von br0
DNS: gleicher DNS wie eth0

... vethpivccu wird beim Start von piVCCU mit br0 gebridged

@Alex: Schau dir das Dokument mal bitte an. Vielleicht kannst du ja die Skripte auf Github verfügbar machen, so dass man sie mit nem einfachen wget downloaden kann. Basieren auf deinen Scripten Dann wird auch Routing für unbedarfte Anwender einfacher. Das Dokument sieht mehr aus als es ist. Es enthält zu jedem Punkt Prüfschritte, so dass man sieht, ob alles ok ist. Wenn man die weglässt, sind das max 3 Seiten

piVCCU - manuelles Setup mit statischer IP Routing und NAT.pdf

(642.17 KiB) 1300-mal heruntergeladen

Viele Grüße
Predi

[leonsio]

Hi

Routing Ansatz hat jedoch wesentliche Nachteile, vor allem wenn man weitere Anwendungen auf dem Pi laufen lassen hat, so muss man dann mit diversen Ports hantieren. (z.B ein apache auf dem host scheidet mit Port 80 aus)
Falls man gern alles unter einer IP aber diversen Ports haben möchte, sollte man lieber Docker verwenden. Hierzu gibt es auch eine Implementierung (jedoch mit OCCU)

LXC hat den Vorteil, dass man komplettes eigenständiges System hat und durch die Bridge mit LXC hat man quasi ein Virtualisierungslayer auf dem Host. man kann dann in einem weiteren LXC Container z.b openhab laufen lassen, was ebenfalls vollkommen isoliert wäre

ich hatte auch zuerst darüber nachgedacht die Bridge durch iptables zu ersetzen, jedoch aus oben genannten Gründen davon abstand genommen.

[predi-ger-many]

Routing Ansatz hat jedoch wesentliche Nachteile, vor allem wenn man weitere Anwendungen auf dem Pi laufen lassen hat, so muss man dann mit diversen Ports hantieren. (z.B ein apache auf dem host scheidet mit Port 80 aus)

Ähm. Auch wenn man Bridging nutzt kann man Port 80 nicht auf dem Pi nutzen. Denn der ist durch die gebridgte CCU im LXC belegt! Mit diversen Ports muss auch niemand hantieren. Die ist ein Script dabei, was alle Ports die die CCU benötigt 1:1 vom Pi zu CCU weiterreicht

Falls man gern alles unter einer IP aber diversen Ports haben möchte, sollte man lieber Docker verwenden. Hierzu gibt es auch eine Implementierung (jedoch mit OCCU)

Gerade, dass viCCU nicht auf OCCU aufsetzt, sondern das originale Firmware-Image nutzt, ist super.

LXC hat den Vorteil, dass man komplettes eigenständiges System hat und durch die Bridge mit LXC hat man quasi ein Virtualisierungslayer auf dem Host. man kann dann in einem weiteren LXC Container z.b openhab laufen lassen, was ebenfalls vollkommen isoliert wäre

Ähm. Die CCU läuft bei der Installation nach meinem Dokument auch in LXC. Da kann man genauso openhab in einem LXC laufen lassen.

ich hatte auch zuerst darüber nachgedacht die Bridge durch iptables zu ersetzen, jedoch aus oben genannten Gründen davon abstand genommen.

Also solltest du Bridging mit zwei LXC Container als Target versuchen... willkommen in der Bridge-Hölle!!! Gerade, wenn ich den Usecase betrachte, kommt nur noch Routing in Frage.

[deimos]

Hi,

Ähm. Auch wenn man Bridging nutzt kann man Port 80 nicht auf dem Pi nutzen. Denn der ist durch die gebridgte CCU im LXC belegt! Mit diversen Ports muss auch niemand hantieren.

Keine Ahnung, wie du darauf kommst, aber das geht einwandfrei. Sonst wäre das Konzept von virtuellen Rootservern eher nicht so weit verbreitet...

Die ist ein Script dabei, was alle Ports die die CCU benötigt 1:1 vom Pi zu CCU weiterreicht

Mind. mal ssh nicht. Und je nach AddOn fehlen die auch (z.B. mein check_mk Addon auf Port 6556)

Also solltest du Bridging mit zwei LXC Container als Target versuchen... willkommen in der Bridge-Hölle!!! Gerade, wenn ich den Usecase betrachte, kommt nur noch Routing in Frage.

Proxmox, Xen, oVirt setzen alle auf Bridging auf. Und auch ESXi benutzt Bridging, wenn auch nicht die Lknux Kernel Bridge. Und in entsprechenden virtuellen Umgebungen mit Routing und DNAT arbeiten ist jetzt nicht dein Ernst.

Viele Grüße
Alex

[predi-ger-many]

Also ich habe schon zig Root-Server gesehen. Da sehen die Netzwerkkonfigs mal richtig anders aus. Das ist eine ganz andere Liga. Der Vergleich hinkt massiv.

Ja, Port 22 ist durch den Host belegt. Das heißt aber nicht, dass man nicht per SSH auf die CCU kommt.

Deine Anleitung für WLAN verwendet übrigens auch NAT. Da muss man auch dann auch anpassen um check_mk zum laufen zu bekommen

[deimos]

Hi,

Also ich habe schon zig Root-Server gesehen. Da sehen die Netzwerkkonfigs mal richtig anders aus. Das ist eine ganz andere Liga. Der Vergleich hinkt massiv.

Was sieht bei denen groß anders aus? Gut, statt einer physikalischen Netzwerkkarte machst du idealerweise einen LACP Trunk aus mehreren Karten und ggf. kommen noch VLANs dazu, aber der Teil mit der Bridge ist identisch. Oder spielst du auf die andere Syntax z.B. bei Redhat an?
Und für den Schw...vergleich: Wie gesagt, ich bin keiner reinrassiger Linux-Admin. Aber als Dev-Op habe ich bis vor einem Jahr eine auf drei Datacenter (nein, nicht AWS und co.) verteilte Anwendung mit einer dreistelligen Anzahl an Server mitbetreut. Deutlich mehr aus Entwicklersicht, aber ich kann trotzdem von mir behaupten, dass ich mich bei dem Netzwerkkram recht gut auskenne.

Ja, Port 22 ist durch den Host belegt. Das heißt aber nicht, dass man nicht per SSH auf die CCU kommt.

Mit der von dir beschriebenen Anleitung nicht. Ist ja auch grundsätzlich erstmal kein Problem. Aber die Aussage von dir, dass alle Ports weitergereicht werden stimmt halt nur mit Einschränkungen.

Deine Anleitung für WLAN verwendet übrigens auch NAT. Da muss man auch dann auch anpassen um check_mk zum laufen zu bekommen

Stimmt. Aber ich behaupte auch nicht, dass diese Lösung ideal ist. Im Gegenteil, ich rate von WLAN an der Stelle sogar eher ab. Wenn ich gezwungen wäre, an der Stelle WLAN zu benutzen, dann würde ich es mit Routing ohne NAT einrichten. Nur richte das mal als Laie ein, teilweise können die Consumer Router ja nicht mal mehr statische Routen, die dafür ja zwingend notwendig wären.

Viele Grüße
Alex

[leonsio]

mich würde auch mal stark interessieren was du unter "richtig anders" verstehst?

Die Root Server, die du so von gängigen Anbietern vorfindest haben meist nur eine Netzwerkkarte. Somit hast du wahrscheinlich noch nie eine "richtig andere" Konfiguration mit NIC Teaming gesehen
Und VLANs sind bei den Root Servern unüblich.

Will man verschiedene VMs auf einem 0815 Root Server laufen lassen brauchst du in den meißten Fällen eine Bridge (z.B. KVM), außer du nimmst einen "richtigen" hypervisor (vmware/citrix), der einen eigenen Stack mitbringt. Im Inneren wird aber ebenfalls gebridgt.

Für Normalsterbliche ist es einfacher eine Bridge Konfiguration vorzunehmen, als mit iptables und NAT rumzuspielen.

Und falls du unbedingt eine drahtlose Übertragung bevorzugst, kannst es dir auch so einrichten: https://tools.ietf.org/html/rfc1149

[maschbaer]

Hallo predi-ger-many,

ich habe nach deiner Anleitung aus dem PDF erfolgreich eine piVCCU3 aufsetzen können. Mein Pi häng dabei über Wlan bei mir im Netzwerk.
Jetzt möchte ich die CCU über das Redmatic Homekit Plugin in mein Homekit integrieren. Das Aufsetzten hat soweit geklappt und ich sehe den QR-Code zum Scannen mit dem iPhone.

Leider findet Homekit die Bridge nicht.
Meine Vermutung ist, dass irgendwas mit der Portweiterleitung nicht stimmt. In diversen Anleitungen habe ich gelesen, dass man Port 5353 und 51826 braucht. Ich habe jetzt in

Code: Alles auswählen

/etc/network/if-up.d/pivccu

folgende Zeilen ergänzt:

Code: Alles auswählen

iptables -t nat -A PREROUTING -p tcp -i $IFACE --dport 51826 -j DNAT --to-destination $CCU_IP:51826
iptables -t nat -A PREROUTING -p tcp -i $IFACE --dport 5353 -j DNAT --to-destination $CCU_IP:5353

Leider bleibt RedMatic Homekit Bridge unerreichbar.

Hast du ggf. einen Tip für mich.

Jan

[linuxdep]

Das mit der Bridgeing Fünktion funktioniert und läuft doch prima... etwas hackelig am Anfang mit der Konfiguration gewesen, aber sonst...Routing ist doch Fehleranfälliger dagegen.

Habe da noch ein paar LXC mit kleineren Sachen laufen,, jeder hat seine eigene IP und alles ist gut. Ein VLAN Fähiger Switch ginge auch noch, aber das ist ein NERD Thema...

[Squelsh]

Vielen Dank an predi-ger-many für die geniale Anleitung!
Ich fand vor allem die Checks zu den einzelnen Schritten genial.

Habe zuerst ewig selber rumprobiert, das Bridging mit dem WLAN zum Laufen zu bekommen, bis ich gelesen hatte, das Linux kein Bridging mit WLAN NICs mag. Nun läuft es mit Routing. Bin happy