PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,229
- Punkte für Reaktionen
- 1,726
- Punkte
- 113
Ich hatte AVM mal zu dem - meiner Meinung nach vorhandenen - Fehler im GUI-Assistenten kontaktiert und habe inzwischen begriffen, daß ich das am Ende ziemlich falsch verstanden hatte.
Es ist kein "lokaler" Port des entfernten Netzwerks, es ist ein weiteres - getrenntes - Netzwerk, ähnlich wie das isolierte "Gastnetz".
Die Bridge soll (der Assistent läßt aber entsprechende Prüfungen weg, daher auch mein Mißverständnis, das durch den Text auch nicht besser wurde) ein weiteres Netzwerk-Segment verwenden, das nichts mit dem lokal oder entfernt verwendeten Segment zu tun hat.
Damit wäre dann z.B. bei
lokal: 192.168.32.0/24
remote: 192.168.33.0/24
für "Netzwerk-Präfix" die Angabe von 192.168.32.0 oder 192.168.33.0 tabu, eine denkbare Adresse ist die 192.168.34.0 (mit Maske 255.255.255.0). Immer vorausgesetzt, ich habe es jetzt richtig interpretiert - zum Testen bin ich noch nicht wieder gekommen.
Das hat natürlich dann auch Auswirkungen auf die Konfiguration der VPN-Verbindung auf der Gegenseite. Dort ist dann als "Entferntes Netzwerk" eben nicht die 192.168.32.0, sondern genau diese zusätzliche 192.168.34.0/24 zu konfigurieren, sonst passen die IDs für Phase2 wieder nicht.
Vielleicht greift AVM ja die Anregung auf, das irgendwie mal zu dokumentieren.
Ich bin mir im Moment noch nicht einmal sicher, ob bei den DNS-Servern nun auch die Angabe eines lokalen Servers funktionieren würde (sollte ja eigentlich nicht sein, wenn ich das richtig verstehe). Wenn das nicht so ist, muß da ja fast zwingend der DNS-Server aus dem entfernten Netz eingetragen werden oder zumindest einer, der über das entfernte Netz auch erreicht werden kann.
Aber zumindest das eigentliche Ziel, allen Verkehr für dieses zusätzliche Segment über die entfernte Box laufen zu lassen, sollte sich damit immer noch umsetzen lassen ... nur für Dienste, die auf die lokale Broadcast-Domain beschränkt sind, sieht es dann schlecht aus.
Im Ergebnis würde dann für "normalen" VPN-Traffic (von den nicht reservierten Ports bzw. aus dem WLAN) zur entfernten FRITZ!Box noch eine weitere VPN-Verbindung notwendig sein.
Vielleicht hilft das ja dabei, die Audio-Probleme zu lokalisieren ... wenn die immer noch bestehen.
Warum das bei meinem eigenen Test dann alles halbwegs funktionierte, weiß ich im Nachhinein auch nicht mehr genau ... aber auch bei superfun funktionierte es ja offenbar in Ansätzen auch mit teilweise falschen Einstellungen (wenn da bei ihm tatsächlich das entfernte LAN bei Netzwerk-Präfix steht und meine geänderte Interpretation nun stimmen sollte).
Es ist kein "lokaler" Port des entfernten Netzwerks, es ist ein weiteres - getrenntes - Netzwerk, ähnlich wie das isolierte "Gastnetz".
Die Bridge soll (der Assistent läßt aber entsprechende Prüfungen weg, daher auch mein Mißverständnis, das durch den Text auch nicht besser wurde) ein weiteres Netzwerk-Segment verwenden, das nichts mit dem lokal oder entfernt verwendeten Segment zu tun hat.
Damit wäre dann z.B. bei
lokal: 192.168.32.0/24
remote: 192.168.33.0/24
für "Netzwerk-Präfix" die Angabe von 192.168.32.0 oder 192.168.33.0 tabu, eine denkbare Adresse ist die 192.168.34.0 (mit Maske 255.255.255.0). Immer vorausgesetzt, ich habe es jetzt richtig interpretiert - zum Testen bin ich noch nicht wieder gekommen.
Das hat natürlich dann auch Auswirkungen auf die Konfiguration der VPN-Verbindung auf der Gegenseite. Dort ist dann als "Entferntes Netzwerk" eben nicht die 192.168.32.0, sondern genau diese zusätzliche 192.168.34.0/24 zu konfigurieren, sonst passen die IDs für Phase2 wieder nicht.
Vielleicht greift AVM ja die Anregung auf, das irgendwie mal zu dokumentieren.
Ich bin mir im Moment noch nicht einmal sicher, ob bei den DNS-Servern nun auch die Angabe eines lokalen Servers funktionieren würde (sollte ja eigentlich nicht sein, wenn ich das richtig verstehe). Wenn das nicht so ist, muß da ja fast zwingend der DNS-Server aus dem entfernten Netz eingetragen werden oder zumindest einer, der über das entfernte Netz auch erreicht werden kann.
Aber zumindest das eigentliche Ziel, allen Verkehr für dieses zusätzliche Segment über die entfernte Box laufen zu lassen, sollte sich damit immer noch umsetzen lassen ... nur für Dienste, die auf die lokale Broadcast-Domain beschränkt sind, sieht es dann schlecht aus.
Im Ergebnis würde dann für "normalen" VPN-Traffic (von den nicht reservierten Ports bzw. aus dem WLAN) zur entfernten FRITZ!Box noch eine weitere VPN-Verbindung notwendig sein.
Vielleicht hilft das ja dabei, die Audio-Probleme zu lokalisieren ... wenn die immer noch bestehen.
Warum das bei meinem eigenen Test dann alles halbwegs funktionierte, weiß ich im Nachhinein auch nicht mehr genau ... aber auch bei superfun funktionierte es ja offenbar in Ansätzen auch mit teilweise falschen Einstellungen (wenn da bei ihm tatsächlich das entfernte LAN bei Netzwerk-Präfix steht und meine geänderte Interpretation nun stimmen sollte).
