 |
|
|
|
| Autor |
Nachricht |
cambies
Anmeldungsdatum: 06.04.2010
Beiträge: 9
|
 Verfasst am:
Di 20 Apr, 2010 16:59 |
  |
|
Hallo, ich bin mal wieder verzweifelt:
Wir haben zwei Subnets: 192.168.1.0/24 und 192.168.2.0/24 .
Wir arbeiten mit Novell Netware, und die Anmeldung am eDirectory erfolgt über Multicasts an 224.0.1.22 und 224.0.1.35. Nun befinden sich alle Directory-Agent-Server in 192.168.1.0er-Netz und und die User aus dem 2. Subnet können sich über SLP nicht anmelden, da as Multicast nicht vom 2 ins 1-Netz und wieder zurück geroutet wird.
Nun habe ich zusätzl. zwei Routen angelegt mit:
Ziel Mask Rtg.-Tag Router
224.0.0.0 224.0.0.0 1 192.168.1.254
224.0.0.0 224.0.0.0 2 192.168.2.254
224.0.0.0 224.0.0.0 0 0.0.0.0
Zum Zuteilen der Routen gibt es auch zwei Firewallregeln:
Von Nach Rtg.-Tag. Prio Aktion
192.168.1.0 224.0.0.0 1 2 allow
192.168.2.0 224.0.0.0 2 2 allow
Beliebig Beliebig 0 1 allow ALLOW-VPN-ROUTING
Beliebig Beliebig 0 0 deny cond. über Default-Route[DENY_ALL]
Nun mach ich ein trace + ip-r firewall und sehe folgendes:
| Code:
|
[Firewall] 2010/04/20 17:37:31,500
Packet matched rule ALLOW-VPN-ROUTING
DstIP: 224.0.1.22, SrcIP: 192.168.1.106, Len: 99, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 427, SrcPort: 427
[IP-Router] 2010/04/20 17:37:31,500
IP-Router Rx (LAN-1, BUERO-NETZ, RtgTag: 0):
DstIP: 224.0.1.22, SrcIP: 192.168.1.106, Len: 99, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 427, SrcPort: 427
Network unreachable (no route) => Discard
|
Nun wundert mich, warum die Firewall nicht gewillt ist, meinem schönen Multicast-Paket ein entsprechendes Routing-Tag zu verpassen, sondern die in diesem Fall "falsche" Regel ALLOW_VPN_ROUTING heranzieht.
Wenn ich die Prioritäten auf 1 setze, passiert das gleiche.
Nachdem ich 'zig IPTV-Posts durchgeackert habe, wo allerdings Multicast/IGMP zwischen LAN und WAN geroutet wird, bin ich eigentlich der meinung, die Konfig ist so okay, oder habe ich einen Denkste-Fehler?
Die ganze Sache ist ziemlich dringend und über jeden hilfreichen Hinweis wäre ich dankbar.
Schöne Grüsse, cambies |
Zuletzt bearbeitet von cambies am Mi 28 Apr, 2010 16:48, insgesamt einmal bearbeitet |
|
   |
|
Guest
|
| Verfasst am:
|
|
|
|
|
|
cambies
Anmeldungsdatum: 06.04.2010
Beiträge: 9
|
| Verfasst am:
Mi 28 Apr, 2010 16:46 |
|
|
Nicht mehr ganz so verzweifelt: Ich habs gelöst.
Der erste, zugegebenermaßen peinliche Grund war, dass ich bei Zuteilung des Routing-Tags über die FW-Regeln die Multicast-Adressen 224.0.0.0 mit der Subnetmask 255.0.0.0 gefiltert habe, währenddessen die Route in der Routing-Tabelle korrekt mit der Subnetmaske 240.0.0.0 versehen war. So konnte die FW-Regel nie zutreffen.
Ein zweiter Fehlergrund liegt in der Route selbst. Konfiguriert war
FW-Regeln:
--------------
Von 192.168.2.1 nach 224.0.0.0 -> Routing-Tag: 2
Von 192.168.1.1 nach 224.0.0.0 -> Routing-Tag: 1
Routing-Einträge:
---------------------
224.0.0.0 (RtgTag: 2) -> GW: 192.168.2.254
224.0.0.0 (RtgTag: 1) -> GW: 192.168.1.254
Entgegen dem herkömmlichen Routing, wo ich wie oben bei den "falschen" Routing-Einträgen als NEXT-HOPP das eigene Gateway angebe, muß jedoch das Gateway des Zielnetzes angegeben werden.
Die Routing-Einträge müssen also wie folgt lauten:
224.0.0.0 (RtgTag: 2) -> GW: 192.168.1.254
224.0.0.0 (RtgTag: 1) -> GW: 192.168.2.254
Was macht man jedoch bei 3 Subnetzen, was ja z.B. bei IGMP wahrscheinlich ist?
Für die NetWare-Problematik ist nun das letzte Hindernis nur noch die Windows-Firewall unter XP, die offensichtlich bei den Multicast-Paketen aus einem anderen Netzsegment zuschlägt.
Abschalten hilft  , kann aber nicht Sinn der Sache sein!
Gruß, cambies |
|
|
|
|
|
|
|
|
| |
|
|
