L2TPv3 für LAN-Gastzugang
@tuxedonet:
Soso, die L2TP-Session ist mit dem jeweiligen lokalen Interface gebridged und die Ethernet-Pakete gehen damit direkt in das "virtuelle Kabel". Damit wäre in so einer Konstellation auch klar, warum eine Slave-Box nicht in jedem Falle selbst die IP-Adresse eines WLAN-Clients kennen muß, wenn sie nur das (W)LAN einer Master-Box per L2TPv3 repliziert (egal ob als Gastnetz oder als Repeater, das dürfte dort ähnlich aussehen). Die Pakete der Clients tauchen im Prinzip gar nicht "in der Box" auf, wenn man mal den (Code-)Teil mit dem Bridgen nicht als "in der Box" ansehen will.
Damit würde dann meine Annahme - daß es (per AVM-GUI) nur möglich sein/werden wird, wenn eine weitere Konfiguration im dsld/kdsld hinterlegt ist - unterstützt, denn diese möglichen "Standardkonfigurationen" nach der Umschaltung der Betriebsart sind wohl dort zur Compile-Time aufgeführt (soweit man das von außen sehen kann). Eine nachträgliche Sonderbehandlung/Änderung dieser "Vorlagen" - mit Berücksichtigung einzelner wahlfreier Ports - findet wohl für die Verwendung von "ipsecbr"-Interfaces ohnehin schon statt - ob man das ohne weiteres auf andere Punkte übertragen kann, ist mangels Quelltexten schlecht einzuschätzen.
Wer aber so eine Konfiguration verwenden möchte, sollte in der ar7.cfg diese Änderungen tatsächlich selbst vornehmen können (eth3 aus der "lan"-Bridge in die "guest"-Bridge verschieben) und solange man dann nicht die Betriebsart des Gerätes erneut umschaltet, sollte diese Änderung auch erhalten bleiben - zumindest war es bisher so, irgendwo habe ich mal eine funktionierene Konfiguration der 7490 mit zwei getrennten LAN-Bridges hier veröffentlicht, wofür auch die ar7.cfg geändert werden mußte.
Allerdings wird seitens des FRITZ!OS die IP-Einstellung für das "guest"-Interface auch bei diversen anderen Aktionen erneut geprüft (z.B. beim Ändern von lokalen Routen), so daß es bei diesem Interface etwas schwieriger werden könnte, diese Änderung aufrecht zu erhalten. Mir ist leider auch kein Kommando bekannt (neben der Umschaltung des "op_mode" über den ctlmgr, was dann zu den erwähnten "Standardkonfigurationen" führt, so weit ich weiß), mit dem man diese einzelne Einstellung in der ar7.cfg gezielt manipulieren könnte, ohne mit Editor und Neustart (von ctlmgr und dsld, ggf. sogar der gesamten Box) hantieren zu müssen - außer man macht es ebenfalls dynamisch. Dann muß man auf anderem Weg sicherstellen, daß der eth3-Port der Slave-Box nicht in die "lan"-Bridge eingebunden wird (auch nicht temporär, z.B. indem man ihn in eine "ipsecbrX"-Bridge stecken läßt in der "Standardkonfiguration") und dann kann man ihn wieder mit "brctl" an die "guest"-Bridge zuweisen, wenn er dort irgendwie abgehangen werden sollte, was man mit einem kleinen Skript mit Polling abfragen kann.
Wenn ich das richtig sehe, sollte sogar die Aktivierung von LAN4 als Gastzugang in der Master-Box ausreichend sein, damit der ganze Gastnetz- und L2TPv3-Mechanismus auf der Master-Box so eingerichtet wird, daß eine Slave-Box dieses Interface per L2TPv3 im (W)LAN nutzen könnte, dafür braucht es dort wohl gar kein eigenes aktiviertes Gast-WLAN - höchstens noch, wenn man irgendwelche Einstellungen zum Gast-WLAN von dort übernehmen will. Wie da die Authentifizierung aussieht (gibt es so etwas wie eine "Anmeldung" eines solchen Repeaters oder läuft das alles automatisch über UPnP und jeder beliebige LAN-Client kann so einen Tunnel-EP kreieren?), interessiert mich ja nun doch mal ... ich werde wohl den Aufbau auch mal selbst testen. Eine weitere 7490 als Testgerät ist für mich inzwischen praktisch unumgänglich (und bestellt), da habe ich ab deren Eintreffen dann wieder mehr Möglichkeiten - inzwischen entwickeln sich ja selbst die Labor-Zweige (hinter dem GUI) auseinander und mit den alten 7390 mag man nicht mehr testen, wenn man sich erst mal an die schnellen Möglichkeiten bei der 7490 gewöhnt hat, mal einen Teil der Firmware praktisch im Vorbeigehen und ohne aufwendige (dateibasierte) Updates zu ändern.
Oder hat schon jemand anderes die Angaben von tuxedonet auch für die reine Verwendung einer zweiten FRITZ!Box als WLAN-Repeater einer Master-Box? Die L2TPv3-Konfiguration müßte dort ja ähnlich aussehen, nur daß eben der Tunnel-Endpoint an einem anderen Interface endet ("guest" ist eben doch etwas spezieller). Die Frage hier wäre halt, welches das sein soll/wird ... darauf wollte ich in #14 auch hinaus. Wenn so ein Tunnel-EP (wo auf der anderen Seite ein WLAN-Repeater hängt) direkt in das "lan"-Interface eingebunden wird, landet sämtlicher (W)LAN-Traffic (geswitcht oder nicht), der auf der (Master-)FRITZ!Box vorbeirauscht, auch an diesem entfernten Tunnel-EP oder sehe ich das falsch (wenn ja, warum)? Das wäre dann ein kompletter "Sniffer" für das gesamte LAN einer solchen Master-Box und da sollte man ja nicht ganz so einfach drankommen können. Wenn der Tunnel-EP irgendwie anders gehandhabt wird (wie dann? vielleicht als zusätzliches lokales Interface a la TUN/TAP? irgendetwas muß AVM ja zum Einbau von TUN/TAP in den Kernel veranlaßt haben), mag das wieder anders aussehen ...
Während bei der Verwendung als WLAN-Repeater durch die Notwendigkeit der Angabe des WLAN-Schlüssels (oder WPS) noch eine gewisse Barriere gegen beliebige (auch unerwünschte) Repeater gegeben wäre (oder geht das etwa inzwischen auch "automatisch"?), sehe ich so etwas bei einer Möglichkeit, einen solchen L2TPv3-Tunnel auch über LAN-Kabel ohne irgendwelche "Kopplungen" oder Authentifizierungen (wie gesagt, habe ich noch nicht probiert, aber auch noch keine Stelle in der Firmware (bzw. im GUI) gesehen, wo so etwas stattfinden könnte) aufbauen zu können, als Problem an ... wenn ich nicht komplett daneben liege und die WLAN-Verschlüsselung bei so einem Repeater tatsächlich auch zwischen dem WLAN-Client und dem Master(-AP) läuft - was ich mir aber immer noch nur sehr schwer erklären könnte.
Als Problem sehe ich es weniger deshalb, weil er so ins Netz kommt (das ist eine Frage der physikalischen Zugangskontrolle) ... wenn er aber auf diesem Weg praktisch den gesamten Router-Traffic auf der LAN-Seite "auf dem Silbertablett" bekommt, ist das m.E. schon eine erhebliche Lücke (mit einigen Folgen), weil es andere Angriffstechniken auf L2 (wie z.B. ARP-Poisioning oder Port-Stealing) praktisch überflüssig machen würde. Gleiches würde dann auch für eine Schadsoftware auf einem (berechtigten) WLAN-Client gelten ... da jeder Bridge-Member seine eigene Kopie des Traffics erhält, kann das auch ziemlich unauffällig (abgesehen von evtl. auftretenden Performance-Problemen) ein weiterer L2TPv3-Tunnel von der Master-FRITZ!Box direkt zu einem WLAN-Client sein. Ich hoffe mal, daß ich hier etwas total falsch verstehe ... ansonsten wäre das (zumindest für mich) schon ein nicht zu unterschätzendes Loch.
Da würde ich dann so etwas wie eine "Kopplung" für den Aufbau eines Tunnels erwarten, meinetwegen mit einem "shared secret" und DHE für eine Authentifizierung, damit da nicht ein beliebiger Client über UPnP (selbst wenn er seinerseits eine FRITZ!Box "emulieren" müßte) die "lan"-Bridge eines solchen Masters abhören könnte. Solange es "nur" das "guest"-Interface ist, kann man das sicherlich in den Skat drücken (da muß man mit einem Lauscher rechnen und sich selbst um entsprechende zusätzliche Sicherheitsvorkehrungen kümmern) ... beim "lan"-Interface wäre das etwas anderes - meine persönliche Einschätzung und Meinung. Noch einmal deutlich betont ... ich weiß bisher noch nicht, wie so eine Einrichtung einer Tunnel-Session zwischen zwei FRITZ!Boxen wirklich aussieht, wenn es nicht um das "guest"-Interface geht - das ist alles nur theoretische Überlegung bis zu einem entsprechenden Test. Sollte ich mich irgendwo irren (außer an den Stellen, wo ich extra betont habe, daß ich es nicht genau weiß), lasse ich mich auch gerne auf die richtige Schiene setzen ...
EDIT: Ok, TUN/TAP wird natürlich schon für L2TPv3 generell benötigt ... da habe ich auf dem Schlauch gestanden.
