Am Sun, 11 May 2014 16:32:48 +0200 schrieb Norbert Zawodsky
Am 10.05.2014 22:06, schrieb Carsten Neumann:
On 10/05/14 21:22, Norbert Zawodsky wrote:
Deine APs agieren wohl als WLAN<->Ethernet Bridges. Nein. Wieso glaubst Du ? Es ist 1 "physisches" LAN, wie ein Baum aufgebaut. Vom Server 1 Leitung zu einem switch. Von diesem switch je 1 Leitung in jedes Stockwerk wo wieder je 1 switch steht der es an die Endgeräte "verteilt". Eines der vielen "Endgeräte" pro Stockwerk ist ein AP (konkret D-Link DWL-2100AP)
Die Verkabelung ist in diesem Kontext weitgehend irrelevant. Deine Beschreibung schließt lediglich aus (zumindest solange keine VLAN im Spiel sind), dass der Server einen dedizierten Access zum AP hat und somit typischerweise dafür ein eigenes IP-Netzwerk verwendet. Das sagt nichts darüber aus, ob der AP "routet" oder "bridged". Die meisten SOHO-setups arbeiten mit einem AP als Bridge. Falls das bei Deinem AP nicht der Fall sein sollte, dann funktioniert nur ein AP-interner DHCP-service oder das Gerät muss sowas wie bootp-relay oder dhcp-helper können.
Nicht wirklich "Rechtevergabe". Es gibt nur 2 Möglichkeiten
* "bekannte" MAC Adresse: Client ist im 192.168.* Netz und hat Netzwerk-Zugriff "auf Alles" + Routing in die große weite Welt * "unbekannte" MAC Adresse: Client ist im 10.* Netz und hat nur routing hinaus. Das 192.* Netz ist für ihn "unsichtbar".
Wie strikt soll das getrennt sein? In einem Layer-2-Abschnitt können sich grundsätzlich alle sehen. Es liegt ja außerhalb Deines Einwirkungsbereichs, welche IP-Adresse sich die Clients (statisch) konfigurieren. Sicher funktioniert das nur mit VLAN und ob die von SOHO-Switches unterstützt werden und in der WLAN-Wolke noch getrennt funktionieren, darf bezweifelt werden.
Das interne LAN hängt am - nennen wir ihn "Zentralserver" - an eth1, konfiguriert mit 192.168.1.0/255.255.255.0 Wäre der richtige Weg, zb ein Alias eth1:1 anzulegen, mit z.B. 10.0.0.0/255.255.255.0 und der dhcp-server gibt "unbekannten" MACs Adressen aus einem 10er-pool ?
Grundsätzlich sollte das funktionieren, weil der DHCP-Server zu beiden IP-Netzadressen einen direkten Zugang hat.
Kann unsere suse-firewall mit netzwerk-aliasen umgehen? Ich bilde mir ein, da gabs mal irgend eine Einschränkung...
Da durchschaue ich (noch) nicht was das bewirken soll. Der Client könnte ja trotzdem z.B. ein "ssh 192.168.x.y." probieren, egal welcher domain er angehört.
Ja, genau wie er mit einer statisch konfigurierten IP-Adresse daher kommen könnte.
Ich hatte gehofft, ein AP verhielte sich ähnlich einem Layer 2 switch, der einfach nur Pakete weiterschickt. Ist aber scheinbar nicht so.
Meist ist das so.
Meine APs können auch "multi-SSID" und "VLAN" VLAN ist aber gänzlich Neuland für mich..
Wenn man mehreren VLAN jeweils eigene SSID zuweisen könnte, ließe sich die VLAN-Trennung auf diesem Wege in den Äther fortsetzen. Dann müssen nur noch die Switches VLAN separieren können, sonst wird doch wieder alles durchs gemeinsame Layer2-Segment geblasen.
zuordnet. Ich frage mich jetzt, was ich auf der Server Seite tun muss um mit VLANs zu arbeiten. Das Paket vlan aus den OSS REpo ist installiert. Allerdings steht im HOWTO "Whatever your previous netconf was, you should move everything to vlans." und das schreckt mich etwas ab...
Unter Beibehaltung der SuSEfirewall2 ist das sicher spannend. Bei manuellem iptables-Setup ist es eigentlich nur eine Datei, von der man dann beliebig (temporäre) Kopien erstellen kann. Mit mehreren VLAN an einem primären Interface mit je einem VLAN pro zusätzlichem IP-Alias hatte ich (zumindest unter Linux) allerdings noch nicht zu tun. -- Gruß, Tobias. no email, only xmpp: crefeld@xabber.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org