Bridging und Broadcasts (tinc, bcrelay, openvpn, subnet)

[DiscoBoy]

Hallo, ich habe eine generell Frage zu einem Network Setup auf dass ich bald wechseln möchte!

Status Quo:
Bisher hatte ich meine beiden Heimnetzwerke über OpenVPN (TUN-devices) verbunden, wobei jedes Netz ein eigenes Subnet hatte (z.b. 192.168.0.0 und 192.168.1.0). Damit die Netze miteinander kommunizieren können habe ich jeweils beim Verbindungsaufbau die entsprechenen Routen in OpenVPN gesetzt und Samba dazu veranlasst sich im anderen Subnet zu annoncieren sowie die beiden Bind/DNS Zonen gegenseitig aktualisieren lassen. Somit hat letzendlich, nach zugegebenermaßen einiger Frickelei auch ein Windows-Netzwerk zwischen den 2 Standorten relativ zuverlässig funktioniert (mit Netzwerkumgebung, etc.)

Plan
Für die Zukunft würde ich gerne OpenVPN (TAP-devices) oder alternativ tinc einsetzen und auf das Routing verzichten und Broadcasts ermöglichen (zwecks Vereinfachung der Windows Netzwerkumgebung, UPNP, Games, etc)! Nach einiger Grübelei denke ich es gibt hierfür folgende 2 Möglichkeiten - Für beide würde ich die VPN-devices mit dem jeweils lokalen Netwerk bridgen.

[Subnet A --BRIDGE-- VPN Device A] --INTERNET-- [VPN Device B --BRIDGE-- Subnet B]

Entweder würde ich also

Subnet A&B jeweils einen Teil eines Subnets zuteilen, von mir aus Subnet A ---> 1922.168.0.1-125 und Subnet B ---> 1922.168.0.125-254

oder ich würde

Subnet A -->1922.168.0.0/16 und Subnet B --> 1922.168.1.0/16

jeweils ein ganzes Subnetz zuweisen mit 255.255.0.0 Maske, wobei dass wohl die elegantere Methode wäre um in Zukunft evtl. einen dritten Standort Subnet C mit 192.168.3.0/16 anzubinden.

Frage/Verständnisproblem
Durch das Bridgen alleine sollte sich das Broadcast Problem lösen lassen. Macht es denn dann überhaupt noch Sinn die Standorte alle zu einem großen Subnet mit 255.255.0.0 Maske zusammenzuschliessen oder hat dass evtl. sogar negative Effekte??? Was ich verhindern möchte ist, dass mir am Ende nur noch Broadcasts zwischen den Standorten um die Ohren fliegen und so die DSL-Leitungen verstopfen. Eine Möglichkeit dies zu verhindern wären an den Gateways der einzelnen Standorte über eine iptables --recent Regel Broadcasts nur in gewissen Zeitabständen zuzulassen. Mich würde einfach eure Meinunng interessieren ob mein Netzwerksetup Sinn macht oder ob da irgendwelche denkfehler drin schlummern?

Vielen Dank!

[Blackbox]

Ich habe noch ein paar Nachfragen zu deiner Netzwerkkonfiguration.

Benutzt du die Bridges um die Broadcasts weiterzuleiten, denn jedes Subnet ist ja seine eigene Broadcastdomaine, da Broadcast ja nicht geroutet(d) werden.

Warum benutzt du eine 16er Notation, willst du mehr als 254 (Standardnotation 24) mögliche Hosts in ein Subnet packen und wenn nein, warum dann nicht eine angepasste Notation verwenden ?

Ich hoffe ich habe dein Ansinnen richtig verstanden, denn ganz sicher bin ich mir gerade nicht ?!

[DiscoBoy]

Also im Grunde werden es auf absehbare Zeit wohl 3 Standorte sein die miteinander verknüpft werden sollen!
Bisher hätte ich dafür 3 Subnetze mit Maske 255.255.255.0 vergeben, wofür ich dann an jedem Subnet-Gateway (A,B,C) das jeweilige Routing machen muss. Dies möchte ich umgehen, da das bei jedem weiteren Standort komplexer wird!

Soweit ich weiss brauche ich für Broadcasts zwischen den Netzten (ohne bcrelay) bei OpenVPN TAP-devices. Wobei ich dann auf jedem Gateway eth1 (intern) und tap0 zu br0 verbinden müsste. Ab jetzt wäre dann br0 mein internes Interface für das jeweilige LAN (A,B,C). Wenn ich das richtig verstehe würden jetzt alle ungerichteten LAN-internen Pakete (Broadcasts, etc) aus A automatisch auch über br0 via Internet an das LAN von z.B. Standort B und C gesendet.

Als einfache Lösung müsste dann br0 @ Standort A z.b.192.168.0.1-70 über DHCP vergeben, br0 @ Standort B bekäme dann den Bereich 192.168.0.71-142 und br0 @ Standort C den Bereich 192.168.0.143-213 fürs jeweilige LAN zugewiesen.

Damit ich nun diesen Adressenpool nicht bei jedem weiteren Standort weiter aufteilen muss (ähnlich unflexibel wie ständig auf allen Gateways neue Routen hinzufügen müssen) dachte ich die Lösung wäre ein größeres Netz mit Netzmaske 255.255.0.0 wobei wahrscheinlich auch 255.255.240.0 als Maske reichen würde.
Noch nicht ganz klar ist mir wie es denn dann bei dieser Lösung überhaupt mit dem Routing läuft - ich denke ich brauche dann ja gar keines, denn über die Bridges mit den TAP-Devices sollte es ja eigentlich so sein als würde ich ein physisches Kabel via Internet zum nächsten Standort legen. Es werden ja nicht nur wie bei TUN-devices IP-Pakete in ein anderes Subnetz geroutet sondern es wird ein Netz unterhalb von IP zwischen den Standorten etabliert - Hierbei habe ich nur Angst dass dann der Traffic für meine DSL Leitungen generell zu stark zunimmt.

Wahrscheinlicher ist aber, dass ich doch irgendwo noch einen kapitalen Denkfehler drin hab

[DynaBlaster]

Ich sehe jedenfalls keinen Denkfehler. Wenn du jeweils das tap-Device und die LAN-NIC zu einer Bridge zusammefasst, dann löst sich dein Routing- und Broadcast-Gefrickel in Luft auf - jeder erreicht jeden, völlig transparent wie im LAN auch - natürlich mit allen von dir beschriebenen Nachteilen.

Hast du schon mal daran gedacht, auf den VPN-Gateways was in Richtung Traffic-Shaping einzurichten. Damit könntest du die wichtigen Dienste priorisieren bzw. bestimmten Dienste gewisse Bandbreiten garantieren. Die Broadcasts fliegen dann automatisch in eine unpriviligierte Klasse ...

[DiscoBoy]

Danke! Freut mich wenn sich mein Plan nicht gleich ganz nach Unsinn anhört
Mit den Nachteilen meinst du wahrscheinlich auch den erhöhten Traffic der zwischen den Standorten über das VPN läuft. Mit hinzu kommt, dass ich wohl auch sicherstellen muss, dass die DHCP Server auf jedem Standort-Gateway eben nur Adressen an Clients im jeweiligen LAN vergeben. Ausserdem musss ich mich entscheiden welcher Samba Server der Domain Master und Local Master Browser wird (es gibt ja jetzt nur noch ein Netz, daher auch nur einen LMB) und mit WINS verhindern dass Windows Clients zuviel Broadcasten....Der Grund warum ich überhaupt auf jedem Gateway Samba, DHCP, DNS, CUPS, und LDAP einsetzte ist dass die Standorte auch bei ausgefallener DSL-Internetverbindung im LAN noch ihre Dienste anbieten können.

Deine Idee mit dem Traffic Shapen macht Sinn, ich werde mich mal genauer mit beschäftigen. Ausserdem hatte ich mir überlegt über itables und das RECENT-Modul nur eine gewisse Anzahl an Broadcasts pro Zeiteinheit zu erlauben, damit meine VPN Verbindung nicht damit geflooded wird. Ist es aber überhaupt noch möglich (um DHCP-Pakete über das VPN zu verhindern) iptables-Regeln nur auf das LAN-NIC (eth1) anzuwenden, dass ja nun zusammen mit dem VPN-Interface (tap0) zur Bridge (br0) zusammengesast wurde? ICh habe hier dieses Zitat in Erinnerung:

* (-) Firewalling von Brückenpaketen ist schwer möglich. (Unter Windows fällt mir keine Firewall ein die das könnte. Unter Linux geht das mit iptables und einem Bridging-Hack)
* (-) "Unschöne" Netzwerktopologie. Bei Diagnose von Netzwerkproblemen sind Netzwerkbrücken schwer als Ursache zu finden. Sie wirken wie schwarze Löcher, die unerwünscht Pakete verschlingen können. Können im schlimmsten Fall sogar Loops erzeugen, wo Pakete im Kreis laufen.

Bei welchen anderen Diensten muss man bei solch einem Netzwerk-Setup besonders aufpassen? Was sind denn Erfahrungswerte zum zusätzlichen Netzwerktraffic wenn ich TAP Devices verwende?