Routing von Broadcasts

[DiscoBoy]

Mein Ziel ist es, Broadcasts über ein VPN zu routen. Ich benutze OpenVPN P2P mit tun Devices, um getrennte Subnetzte zusammenzuführen. Nach einigem hin und her funktioniert der Datanaustausch zwischen den Netzen, auch Windows/Samba Browsing. Was ich bisher noch nicht hinbekommen habe, ist es Broadcasts zwischen den Netzen auszutauschen, z.B. bei Online Games, etc.

Je ein Debian Etch Server bildet einen Endpunkt des VPNs mit tun0 Interface. BCRELAY leitet auch erfolgreich Broadcasts von eth1 (angeschlossenes Subnet) ins VPN weiter. Am anderen Server kommen die Broadcasts schliesslich auch auf tun0 an. Von dort müssten sie aber weiter geleitet werden in das dortige Subnet (wiederum eth1).

Die Relay-Kette für die Broadcasts sieht also so aus:

Broadcast -> Subnet A -> eth1 -> tun0 <-> tun0 -> eth1 -> Subenet B -> Broadcast

Da BCRELAY die Broadcasts nicht ein zweites Mal weiterleiten kann wollte ich die zweite Weiterleitung über IPTABLES realisieren. Alle Broadcasts, die auf tun0 ankommen, sollen über "-j ROUTE --oif eth1" ins Subnet B weitergeleitet werden. Aber Debian Etch bringt keine Unterstützung für die ROUTE Erweiterung, zumindest der Kernel, da /lib/iptables/libipt_ROUTE.so auf den Servern vorhanden ist.

Damit ist mein Latein am Ende! Ich möchte keinen eigenen Kernel kompilieren, da ich sonst alle parr Wochen wegen Updates neue Kernel kompilieren darf. BCRELAY führt mich auch nicht weiter, da es weitergeleitete Broadcasts mit einer TTL=1 versieht und solche Broadcasts dann nicht nochmal weiterleitet.

Fällt euch eine Alternative ein? Oder habt ihr Erfahrungen mit der ROUTE Erweiterung, oder iproute2?

Bin für alle Ideen dankbar - bitte nur kein Vorschlag gleiche Subnetzte zu verwenden und diese zu bridgen!

[swuing]

hi

und wenn man die TTL mit iptables erhöht?
auszug aus der iptables-manpage:

Code: Alles auswählen

TTL
This is used to modify the IPv4 TTL header field. The TTL field determines how many hops (routers) a packet can traverse until it's time to live is exceeded.

Setting or incrementing the TTL field can potentially be very dangerous,
    so it should be avoided at any cost. 
Don't ever set or increment the value on packets that leave your local network!
    mangle table. 
--ttl-set value
    Set the TTL value to `value'. 
--ttl-dec value
    Decrement the TTL value `value' times. 


--ttl-inc value
    Increment the TTL value `value' times. 

kenne mich damit nicht so aus...trotzdem...
der bridging modus von openvpn hilft dir nicht weiter?

[DiscoBoy]

Stimmt, ein guter Gedanke! Muss mal daheim nachsehen ob das klappt. TTL ist ja auch eine Erweiterung oder wird das vom Standard Kernel/Iptables unterstützt?

Bridging Modus von OpenVPN? Funktioniert das mit zwei verschiedenen Subnets? Irgendetwas war da, was mich davon abgehalten hat TAP Devices zu verwenden....Ich glaub ich hab damals auch nicht hinbekommen, dass da Traffic drüber läuft.

Momentan hab ich eben zwei Subnets A,B getrennt vom dritten Subnet V(pn) und pushe mit OpenVPN die richtigen Routen um jeweils Rechner im anderen Subnet anzusprechen.

Danke aber schonmal....

[compaqt]

Ein tun Interface ist Layer 3, also eine Grenze für Broadcasts. Mit einem tap Interface sollte es funktionieren, da es auf Layer 2 läuft und die Broadcasts werden im ganzen VPN verteilt. Natürlich braucht es ein wenig geschraube an der Konfiguration von OpenVPN.

[daFreak]

Vielleicht hilft dir das weiter
http://www.debianforum.de/forum/viewtop ... highlight=

[DiscoBoy]

Voraussetzungen:

* Im Normalfall muss auf beiden Seiten das selbe Subnet (z.B. 192.168.1.0) verwendet werden, damit die Computer sich später erreichen können.
* Eine IP Adresse im LAN 1 darf nicht bereits im LAN 2 vergeben sein, und umgekehrt. (= eindeutige IP Adressen)
* Nur eine Netzwerkbrücke/OpenVPN pro physikalisches Netzwerk.

Vor- und Nachteile:


* (+) Jedes Protokoll, das auf Ethernet läuft, läuft auch durch den Tunnel.
* (+) Broadcasts werden auch getunnelt. (z.B. für diverse LAN-Spiele)
* (+) In den meisten Fällen einfacher zu Konfigurieren als Routing, da keine Änderungen an Routingtabellen notwendig sind.

* (-) 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.

tja, ich wusste doch warum ich mich für tun device entschieden habe... Ich möchte zwei getrennte Subnets weiterhin erhalten. Andere frage: wäre es möglich das tap device so zu verwenden:

SERVER 1 | Server 2
(Subnet A) eth1<-bridge-> tap0 ==|== tap0 <-bridge-> eth1 (Subent B)

Sprich: Ich mache auf jedem Server eine Bridge mit eth1, so dass das tap0 device beide Subnets verbindet.
Bleibt mir beim Einsatz von tap immer noch die Möglichkeiten Routen zu pushen, da sich sonst die Clients in beiden Subnets nicht finden können? Aber was trag ich dann als Gateway ein? Die Bridge?
Ausserdem hab ich damit natürlich mehr Netzwerklast über das VPN wegen Layer2

Naja, immerhin habt ihr mich schon auf ein paar gute Ideen gebracht. Ich versuch jetzt mal das Heraufsetzen von TTL bei den relayten Broadcasts...

[DynaBlaster]

SERVER 1 | Server 2
(Subnet A) eth1<-bridge-> tap0 ==|== tap0 <-bridge-> eth1 (Subent B)

Sprich: Ich mache auf jedem Server eine Bridge mit eth1, so dass das tap0 device beide Subnets verbindet.
Bleibt mir beim Einsatz von tap immer noch die Möglichkeiten Routen zu pushen, da sich sonst die Clients in beiden Subnets nicht finden können? Aber was trag ich dann als Gateway ein? Die Bridge?

Ich glaube nicht, dass das so funktionieren wird. Nehmen wir an, Server 1 in Subnet A hat die IP 192.168.0.1 für sein Bridge-Device. Server 2 entsprechend 192.168.1.1. Wie sollen denn die beiden mittereinander kommmunizieren, wenn sie nicht im gleichen Subnet sind?

Wie wäre es, wenn du in einen der beiden Server eine weitere Netzwerkkarte einbaust. eth1 wird weiterhin mit dem tap-Device gebridget und liegt im gleichen Subnet wie die Bridege auf dem anderen Server. Die "neue" Netzwerkkarte zeigt in das andere Subnet. Dann hast du die Netze getrennt und kannst mittels BCRELAY die Broadcasts weiterleiten - jedenfalls theoretisch

[DiscoBoy]

hi

und wenn man die TTL mit iptables erhöht?

So, ich hab mich gerade daran versucht, und dann folgendes festegestellt:

To avoid a UDP broadcast loop, bcrelay changes the IP TTL and the
// UDP checksum (to 1 and 0 respectively) of the UDP broadcasts it relays.
// No relaying will be done for UDP broadcasts with IP TTL=1 and UDP
// checksum=0. Could also (mis)use IP identification for this, but IP TTL
// and UDP chksum combination is expected to work fine.

Also müsste ich ebenfalls noch die UDP Checksum verändern...Allerdings kommt trotz TTL Manipulation auf der anderen Seite (tun0 Subnet B) immer noch TTL=1 Packete an...obwohl die Firewall diese ja abgeändert haben soll. Ich überprüf das momentan mit tcpdump -i tun0 port 27960 -vvvne.

Dabei kommt das raus:

Code: Alles auswählen

tcpdump: listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
17:44:44.540280  In ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl   1, id 37594, offset 0, flags [none], proto: UDP (17), length: 43) 192.168.10.200.27960 > 255.255.255.255.27960: [no cksum] UDP, length 15
17:44:44.559549  In ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl   1, id 37595, offset 0, flags [none], proto: UDP (17), length: 43) 192.168.10.200.27960 > 255.255.255.255.27961: [no cksum] UDP, length 15

...

und mit iptables lass mich mir das ausgeben: $IPTABLES -A INPUT -i tun0 -s 192.168.10.0/24 -d 255.255.255.255 -j LOG --log-level 6 --log-prefix "VPN BROADCAST IP "

In der Log finde ich dann:

Code: Alles auswählen

Jan  5 17:41:49 slave1 kernel: VPN BROADCAST IP IN=tun0 OUT= MAC= SRC=192.168.10.200 DST=255.255.255.255 LEN=43 TOS=0x00 PREC=0x00 TTL=125 ID=36336 PROTO=UDP SPT=27960 DPT=27960 LEN=23
Jan  5 17:41:49 slave1 kernel: VPN BROADCAST IP IN=tun0 OUT= MAC= SRC=192.168.10.200 DST=255.255.255.255 LEN=43 TOS=0x00 PREC=0x00 TTL=125 ID=36337 PROTO=UDP SPT=27960 DPT=27961 LEN=23
Jan  5 17:41:49 slave1 kernel: VPN BROADCAST IP IN=tun0 OUT= MAC= SRC=192.168.10.200 DST=255.255.255.255 LEN=43 TOS=0x00 PREC=0x00 TTL=125 ID=36338 PROTO=UDP SPT=27960 DPT=27962 LEN=23
Jan  5 17:41:49 slave1 kernel: VPN BROADCAST IP IN=tun0 OUT= MAC= SRC=192.168.10.200 DST=255.255.255.255 LEN=43 TOS=0x00 PREC=0x00 TTL=125 ID=36339 PROTO=UDP SPT=27960 DPT=27963 LEN=23

...

Irgendas stimmt da also noch nicht! Nur was? ...

[swuing]

wie schaut denn die iptables-regel aus welche die TTL hochsetzt?

aber seh ich das richtig, das iptables-log und tcpdump geben vom angeblich gleichen datenstream unterschiedliche
TTL-werte aus?

vielleicht gehts wenn du die iptables-regel in eine andere chain setzt

[DiscoBoy]

Auf Subnetz A, da wo die Broadcasts herkommen schaun die iptables-regeln so aus:

Code: Alles auswählen

$IPTABLES -t mangle -A INPUT  -i tun0  -s 192.168.10.0/24  -d 255.255.255.255  -j TTL --ttl-set 36 
$IPTABLES -t mangle -A OUTPUT  -o tun0  -s 192.168.10.0/24  -d 255.255.255.255  -j TTL --ttl-set 36 
$IPTABLES -t mangle -A FORWARD  -o tun0  -s 192.168.10.0/24  -d 255.255.255.255  -j TTL --ttl-set 36 
$IPTABLES -t mangle -A POSTROUTING  -o tun0  -s 192.168.10.0/24  -d 255.255.255.255  -j TTL --ttl-set 36 

bei Subnet B, da wo ich mit TCPDUMP schaue, was auf tun0 ankommt sehen sie eigentlich genauso aus.

Code: Alles auswählen

$IPTABLES -t mangle -A INPUT  -i tun0  -s 192.168.11.0/24  -d 255.255.255.255  -j TTL --ttl-set 125 
$IPTABLES -t mangle -A OUTPUT  -o tun0  -s 192.168.11.0/24  -d 255.255.255.255  -j TTL --ttl-set 125 
$IPTABLES -t mangle -A FORWARD  -o tun0  -s 192.168.11.0/24  -d 255.255.255.255  -j TTL --ttl-set 125 
$IPTABLES -t mangle -A POSTROUTING  -o tun0  -s 192.168.11.0/24  -d 255.255.255.255  -j TTL --ttl-set 125

Nur die TTL wird hier auf 125 gesetzt. Eigentlich sollten die Broadcasts ja schon beim Verlassen von Subnet A über das dortige tun0 auf eine TTL von 36 gesetzt werden....
TCPDUMP (Subnet B) zeigt mir aber trotzdem eine TTL=1 an, obwohl die TTL ja erst auf 36 und anschliessend auf 125 gesetzt werden sollte (36 und 125 sind nur verschieden gewählt, damit ich sie unterscheiden kann).
Der Firewall-LOG zeigt dies zumindest richtig an....[/code]

[swuing]

ich denke das bcrelay nach den iptables-regeln eingreift und wieder alles auf TTL 1 setzt.

und wenn du in den regeln tun0 durch eth1 ersetzt?

wobei mich wundert das man die packete einfach so verändern kann, ist ja immerhin ein vpn.

[DiscoBoy]

ich denke das bcrelay nach den iptables-regeln eingreift und wieder alles auf TTL 1 setzt.

und wenn du in den regeln tun0 durch eth1 ersetzt?

wobei mich wundert das man die packete einfach so verändern kann, ist ja immerhin ein vpn.

Daran hab ich auch schon gedacht. Momentan wird die TTL ja aber auf beiden Seiten verändert, einmal auf 125, einmal auf 36. Wenn also BCRELAY erst eingreift, nachdem das Packet schon iptables auf dem Server in Subnet A verlässt, dann müsste es im Subnet B schon vor iptables eingreifen, da diese die TTL ja auch erhöhen würde....

Denke es wird Zeit dem Author von BCRELAY mal ne Mail zu schreiben....

Danke für eure Gedankenansätze!

[habakug]

Hallo!

Ich empfehle dir diese [1] Lektüre. So wollen es die Gamer haben.

Gruß, habakug

[1] http://de.gentoo-wiki.com/OpenVPN_mit_% ... werkkarten