Am 10.05.2014 22:06, schrieb Carsten Neumann:
On 10/05/14 21:22, Norbert Zawodsky wrote:
Hallo Günther, Carsten, Tobias, ich habe eine Frage die thematisch hier bestens dazupassen würde. Soll ich einen eigenen Thread aufmachen oder diesen hier kidnapen ??? Hmmm ;-) Wäre sinnvoll gewesen. :-( O.k., überzeugt, getan ...
Bei mir geht es darum:
Habe ein "internes LAN", 192.168.1.xxx (wie einfallslos ;-) ), ca. 30 hosts daran (nicht alles PCs. Erstaunich was heute alles schon eine IP Adresse hat). Und 3 WLAN-access points. (Keller, EG, 1. Stock, ...) Auf einer Maschine läuft ein DHCP server, firewall, router, usw... "Natürlich" 192.168.1.1. 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)
Verbindet sich nun ein "bekanntes" (= MAC-Adresse ist in dhcpd.conf eingetragen) Gerät mit unserem WLAN, bekommt es eine 192.168.1.xxx Adresse und alle sind glücklich.
Nun möchte ich aber "befreundeten" Geräten (Laptops, Handys von guten Freunden) ebenfalls gestatten, das WLAN zu benützen. Aber bei aller Freundschaft, sie sollten vom DHCP server eine Adresse bekommen, die NICHT im 192.168.1.xxx Netz liegt. Du willst die Rechte-Vergabe über die Netz-Adresse machen... 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 beomme ich das am besten hin?
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 ?
Kann unsere suse-firewall mit netzwerk-aliasen umgehen? Ich bilde mir ein, da gabs mal irgend eine Einschränkung... Nun ja, ich stell mir das nicht trivial vor. Können denn Deine WLAN-APs in mehreren Netzen gleichzeitig arbeiten? Die müssten ja - nach Deiner Vorstellung - zum einen die vertrauenswürdigen Hosts im 192.168... Netz als auch die aus den 10.... Netz bedienen können.
Mach lieber _ein_ WLAN-Netz und setze einen DNS-Server auf, der die Hosts in unterschiedliche Domains "schickt", ihnen also Namen nach dem Schema hostabc.trusted.mydomain bzw. hostxyz.friend.mydomain gibt. Dann wird einfach unterschieden, ob der sich Host in trusted.mydomain oder in friend.mydomain befindet.
Vielleicht fällt jemandem etwas besseres ein.
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. Ich hatte gehofft, ein AP verhielte sich ähnlich einem Layer 2 switch, der einfach nur Pakete weiterschickt. Ist aber scheinbar nicht so. Meine APs können auch "multi-SSID" und "VLAN" VLAN ist aber gänzlich Neuland für mich.. Ich kann im AP einstellen, dass er 2 verschiedene SSIDs ausschickt und eine Verbindung zu diesen SSIDs jeweil einem anderen VLAN 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... Norbert -- 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
On 11/05/14 16:32, Norbert Zawodsky wrote:
Am 10.05.2014 22:06, schrieb Carsten Neumann:
On 10/05/14 21:22, Norbert Zawodsky wrote:
Hallo Günther, Carsten, Tobias, ich habe eine Frage die thematisch hier bestens dazupassen würde. Soll ich einen eigenen Thread aufmachen oder diesen hier kidnapen ??? Hmmm ;-) Wäre sinnvoll gewesen. :-( O.k., überzeugt, getan ...
Bei mir geht es darum:
Habe ein "internes LAN", 192.168.1.xxx (wie einfallslos ;-) ), ca. 30 hosts daran (nicht alles PCs. Erstaunich was heute alles schon eine IP Adresse hat). Und 3 WLAN-access points. (Keller, EG, 1. Stock, ...) Auf einer Maschine läuft ein DHCP server, firewall, router, usw... "Natürlich" 192.168.1.1. 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)
Wenn es _keine_ Bridges sind, "spannen" die sowieso jeweils ein _eigenes_ Netz auf, dann liegen Deine WLAN-Hosts aber nicht in 192.168.1.0/24. Da Deine APs aber - nach Deiner Aussage - das LAN "einfach" ins drahtlose "erweitern", müssen's tatsächlich Bridges sein. Wie ich gesehen habe, kann man unter Linux LAN-WLAN Bridges einrichten. ;-) http://cartesianproduct.wordpress.com/2012/12/22/raspberry-pi-as-an-ethernet... Dabei dürfen die ethX und wlanY Schnittstelle, die gebrückt werden sollen _keine_ IP-Adresse bekommen. Der brZ kannst Du allerdings ruhig eine Adresse verpassen - bzw. musst Du sogar, wenn Du die zur Konfiguration und Wartung über's Netz erreichen möchtest. :-) Somit sollte es der Bridge prinzipiell egal sein, welche Netze über sie geroutet werden. Sie sollte sich somit wie ein Layer-2 Switch verhalten. Wie das nun bei Deinem D-Link Teil aussieht, kann ich nicht sagen. Vielleicht gibt es jemanden, der sowas bereits schonmal in einem ähnlichen Szenario verwendet hat.
Verbindet sich nun ein "bekanntes" (= MAC-Adresse ist in dhcpd.conf eingetragen) Gerät mit unserem WLAN, bekommt es eine 192.168.1.xxx Adresse und alle sind glücklich.
Nun möchte ich aber "befreundeten" Geräten (Laptops, Handys von guten Freunden) ebenfalls gestatten, das WLAN zu benützen. Aber bei aller Freundschaft, sie sollten vom DHCP server eine Adresse bekommen, die NICHT im 192.168.1.xxx Netz liegt. Du willst die Rechte-Vergabe über die Netz-Adresse machen...
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 beomme ich das am besten hin?
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 ?
Gibt's eigentlich einen Grund, dass Du dafür einen komplett anderen Adressbereich wählst? Ich hätte z.B. 192.168.0.0/24 oder 192.168.2.0/24 gewählt.
Kann unsere suse-firewall mit netzwerk-aliasen umgehen? Ich bilde mir ein, da gabs mal irgend eine Einschränkung...
Nun ja, ich stell mir das nicht trivial vor. Können denn Deine WLAN-APs in mehreren Netzen gleichzeitig arbeiten? Die müssten ja - nach Deiner Vorstellung - zum einen die vertrauenswürdigen Hosts im 192.168... Netz als auch die aus den 10.... Netz bedienen können.
Mach lieber _ein_ WLAN-Netz und setze einen DNS-Server auf, der die Hosts in unterschiedliche Domains "schickt", ihnen also Namen nach dem Schema hostabc.trusted.mydomain bzw. hostxyz.friend.mydomain gibt. Dann wird einfach unterschieden, ob der sich Host in trusted.mydomain oder in friend.mydomain befindet.
Vielleicht fällt jemandem etwas besseres ein.
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.
Wenn Du so etwas unbedingt generell verhindern möchtest, müsstest Du tatsächlich die Netze trennen und das Routing verhindern.
Ich hatte gehofft, ein AP verhielte sich ähnlich einem Layer 2 switch, der einfach nur Pakete weiterschickt. Ist aber scheinbar nicht so.
Nur, wenn er als Bridge fungiert, wozu aber Dein D-Link Teil prinzipiell in der Lage sein sollte. Probiers einfach aus. Lege Dir ein Ethernet Alias an, lass Deine DHCP-Server auf beiden Schnittstellen laufen - ich glaube für jedes Interface wird jeweils ein eigener Prozess gestartet - und schalte erstmal einfach nur die "martian source" Meldungen ab. Dann musst Du nur noch das Routing vom externen ins interne Netz verhindern. Ich stelle mir gerade die Frage, was passiert, wenn ein "Freund" die Vergabe per DHCP auslässt und sich eine Adresse aus Deinem internen Netz gibt.
Meine APs können auch "multi-SSID" und "VLAN" VLAN ist aber gänzlich Neuland für mich..
Ich kann im AP einstellen, dass er 2 verschiedene SSIDs ausschickt und eine Verbindung zu diesen SSIDs jeweil einem anderen VLAN 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...
Da ich selber noch keine VLANs eingerichtet habe, kann ich da leider nicht weiterhelfen. Stell ich mir das allerdings unter openSUSE mit yast nicht problematisch vor.
Norbert
C* -- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
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
participants (3)
-
Carsten Neumann -
Norbert Zawodsky -
Tobias Crefeld