Zum Inhalt wechseln


Foto

DHCP-Bereich nach MAC aufbauen?

Windows Server 2008 R2

  • Bitte melde dich an um zu Antworten
33 Antworten in diesem Thema

#16 zahni

zahni

    Expert Member

  • 16.497 Beiträge

 

Geschrieben 07. September 2017 - 14:14

Im Client-Bereich ist bei uns alles "Port-Based" in einem festen VLAN pro Etage.

Drucker bekommen feste IP-Adressen in einem festen Bereich, der im DHCP ausgeklammert ist.

 

VLAN-Tagging machen bei uns nur ein paar Server.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#17 cjmatsel

cjmatsel

    Senior Member

  • 417 Beiträge

 

Geschrieben 07. September 2017 - 14:27

Also machst Du VLAN in dem Fall nicht pro Gerätetyp sondern pro Etage... Und feste IPs für Drucker sind interessant wenn ein Dienstleister das Gerät tauschen muss, gelle...

#18 magheinz

magheinz

    Newbie

  • 1.417 Beiträge

 

Geschrieben 07. September 2017 - 14:30

einfach gleich 802.1x einführen und die VLANs per radius vergeben.

#19 zahni

zahni

    Expert Member

  • 16.497 Beiträge

 

Geschrieben 07. September 2017 - 14:31

Also machst Du VLAN in dem Fall nicht pro Gerätetyp sondern pro Etage... Und feste IPs für Drucker sind interessant wenn ein Dienstleister das Gerät tauschen muss, gelle...

Die IP-Adresse vergeben wir, wieso? 


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#20 cjmatsel

cjmatsel

    Senior Member

  • 417 Beiträge

 

Geschrieben 07. September 2017 - 14:59

einfach gleich 802.1x einführen und die VLANs per radius vergeben.

Hmm, wenn die Geräte selbst kein VLAN können?

#21 lefg

lefg

    Expert Member

  • 20.508 Beiträge

 

Geschrieben 07. September 2017 - 16:22

Moin

 

Ich habe den Thread begrifffen so: Es soll mehr Sicherheit erreicht werden im "LAN" erreicht werden. Ist das richtig so?

 

Ob das aber nur durch verschiedene IP-Bereiche auf der selben Leitung(quasi VLAN 1) erreichbar ist? Zwischen dem IP-Bereich Client und dem IP-Bereich Drucker müsste doch wohl ein Routing. Routing allein bringt aber kein mehr an Sicherheit. Dazu gehörte wohl eine Zugriffskontrolle auf einer Firewall: Nur authentifizierte Benutzer (Clients und User) bekommen Zugriff.

 

Auch ein Routing zwischen den Adressbereichen der VLANs reichte nicht für mehr Sicherheit, auch dort wird ein Access Control benötigt.

 

Ob das aber wirklich mehr Sicherheit brächte? Ein korrupter Client als authentfizierter Benutzer hatte doch Zugang zum Druckernetz.

 

Wir haben hier mal den Fall diskutiert, ob einem korrupter Drucker der Zugang nach draussen verwehrt wäre. Ich hab denn überlegt, ob ich das theoretische bei mir umsetzen könnte? Aber, unsere Drucker müsten aus dem Subnetz und VLAN raus ins "Hauptnetz" zum Erreichen der Remote Control Box des Herstellers und Vermieters, über diese Box die Bestellung des Druckmaterials abgewickelt. Ich hatte aber keine Möglichkeit auf der Box die zusätzlichen Routen für den Rückweg zum Antworten an die Drucker zu konfigurieren.

 

Auch kann auf den MFC-"Drucker" per GUI nur eine IP und nur ein Gateway konfiguriert werden, es kann auch kein VLAN. Das sei erst mit Geräten der nächsten Generation möglich, so der regionale Vertriebsleiter des Herstellers.

 

Eine Möglichkeit wäre gewesen, in den Drucker ein zweites Netzwerkinterfaces einzubauen, der Steckplatz dafür ist vorhanden. Der Servicetechniker konnte mir aber nicht mit Sicherheit sagen, ob das dann per GUI konfigurierbar wäre. Unser GF Zentrale Dienste hielt das Ganze dann für nicht notwendig, damit gestorben.

 

Ich, wir, meine Leute, Studenten und Studienleiter wollten aber gerne zumindest auf ein Gerät drucken aus verschiedenen Bereichen, verschiedene VLANs. Ich baute einen Printserver mit tagged VLANs und verband zwei USB-Ports mit denen des MFC. So konnten wir aus drei Netzen auf das Gerät drucken, das Gerät komnnte weiter die Remote Control Box erreichen und diese die Bestellungen weiterleiten.

 

Ergo: Es werden Geräte mit den geeigneten Eigenschaften benötigt, besonders für den Wunsch mehr Sicherheit. Ob diese aber so wirklich erreichbar ist? Und i.d.R. kostet sowas Geld. Mit Switche Layer 2+ allein wird das wohl nichts, denke ich jedenfalls.


Bearbeitet von lefg, 08. September 2017 - 05:57.

Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#22 magheinz

magheinz

    Newbie

  • 1.417 Beiträge

 

Geschrieben 07. September 2017 - 16:31

die thinclients und die pcs sollten das können. die besseren drucker auch. alle anderen kommen halt ins "gäste-netz". alternativ kommen die drucker dann halt an feste ports.

#23 cjmatsel

cjmatsel

    Senior Member

  • 417 Beiträge

 

Geschrieben 07. September 2017 - 20:11

Hi,

ursprünglich dachte ich tatsächlich nur ein reines logisches IP-Netz aufzubauen. Doch nach den selbst getesteten und hier geschriebenen Problemen wird es tatsächlich ein VLAN UND ein IP-Netz werden; natürlich mit Firewall davor (Da die Drucker nur zu sehr wenigen Servern über wenige Protokolle kommunizieren müssen halte ich das als Sicherheit für vertretbar). Leider bleibt das Problem: Weder meine IGEL-Clients noch meine Kyocera-Drucker sprechen VLAN... Einzig die Switche könnten VLAN nach Mac-Vendor fahren; aber immer nur Eines und eig. als Voice-VLAN vermarktet...
Bleibt tatsächlich: Entweder Geld in teure Switche investieren (und aktuell trotzdem raten wie das dort geht) oder jeden verdammten Switch-Port einzeln einstellen... :-/

#24 lefg

lefg

    Expert Member

  • 20.508 Beiträge

 

Geschrieben 07. September 2017 - 22:24

 

oder jeden verdammten Switch-Port einzeln einstellen.

 

Nun, ich hab so einige VLANs eingerichtet auf einigen Switches: HP 17xx, 18xx, 19xx, ...., die haben eine GUI und Menus, ich hatte die nötige Zeit und hab die Geduld, hatte doch Freude beim Gelingen. Das Zusammenspiel zwischen 17xx und 19xx war nicht so ganz einfach, ich musste erstmal lernen wie die ticken dabei.

Ich hatte auch ein gedankliches Konzept, für jeden Zweck ein VLAN, auch Reserve, jedes VLAN auf jedem Switch auf dem Campus, in jedem Gebäude, jeder Unterstation vorhanden, sozusagen eine Linie vom Hauptor bis zum Hinterausgang mit einigen Abzweigern. Ich musste dann an den Switches noch die Ports an die VLANs knüpfen.

 

Mit Software Defined Networking wäre sowas wohl schöner gewesen, ich musste aber mit dem vorhandenen Material auskommen, und das war eben ein Sammelsorium.

 

Ich hab da keine Trennung vorgenommen von Thick und Thin, das hätte keinen Sinn gemacht. Das VLAN 1 wurde Fallback zur Konfiguration, für den Fall, sollte ein Switch mal abschmieren, dann konnte ich den vielleicht noch erreichen. Eines war Verwaltung mit Verbindung zum Higher Echolon, ein weiteres für die Rechner in den Pools für die Studenten, dann eines für die Verbindung zwischen WLAN-Controller und APs. Andere und deren Zweck führe ich hier mal nicht auf.

 

Zum Monitoring gibt es Admin-Consolen mit PRTG.

 

Wie schon erwähnt, ich hab die Drucker nicht in einem extra VLAN, sie gehören zur Verwaltung, haben eine IP aus dem Bereich und können damit die Remote Control Box beim Higher Echolon erreichen. Die RCBox leitet die automatische Materialbestellung an den Service des Herstellers weiter, wir müssen uns nicht drum kümmern. Das Material kommt per Paketdienst, es ist aufgedruckt für welches Gerät an welchen Aufstellort es ist.


Bearbeitet von lefg, 07. September 2017 - 22:44.

Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#25 cjmatsel

cjmatsel

    Senior Member

  • 417 Beiträge

 

Geschrieben 19. September 2017 - 14:56

Hallo allerseits,

ich bin aktuell wieder ein kleines Stück weitergekommen: Ich habe Freeradius mit MAC-Authentifizierung eingerichtet und es funktioniert: Anhand der MAC-Adresse wird das richtige VLAN zugewiesen und das Gerät kann problemlos im entsprechenden Netz kommunizieren. Jetzt ein paar kleine Detailfragen:
- Kann man auch MAC-Vendors in Freeradius nutzen? Quasi als Gruppe? Das würde mir die Verwaltung erheblich vereinfachen: Ein client würde in die passende Gruppe geschubst und bekommt automatisch eine passende VLAN mit...
- Kann man ein Default-VLAN mitgeben für alle Geräte welche sich nicht authentifizieren können? Ein "Auth-Fail-VLAN" direkt auf dem HP-V1910-Switch scheint die Kommunikation vollständig zu blockieren, daher hatte ich hier an eine Einstellung im Freeradius gedacht... @lefg: Wäre das evtl. mit dem VLAN 1möglich, wenn man kein "Auth-Fail-VLAN" konfiguriert?
- Kann man unbekannte MACs sofort melden lassen? Quasi vom Freeradius zum Admin?

Lieben Dank für die ein oder andere Antwort...

#26 lefg

lefg

    Expert Member

  • 20.508 Beiträge

 

Geschrieben 19. September 2017 - 16:11

 

@lefg: Wäre das evtl. mit dem VLAN 1möglich, wenn man kein "Auth-Fail-VLAN" konfiguriert?

 

Moin

 

Leider kann ich das nicht beantworten, denn ich begreife nicht, was Du da machst.

 

Wo wurde denn Freeradius eingerichtet oder konfiguriert?


Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#27 cjmatsel

cjmatsel

    Senior Member

  • 417 Beiträge

 

Geschrieben 19. September 2017 - 16:56

@lefg: Jetzt verstehe ich Deine Frage nicht: was meinst du damit WO freeradius eingerichtet wurde? Auf einem normalen Server... außerdem ist das WO eigentlich unrelevant, das interessante ist die Frage WIE man ein AuthFail-Vlan (oder ähnliches) im konfigurieren und nutzen kann. Beim Switch kann man ja einfach bei AuthFail das vlan 1 vergeben; geht das auch bei einem Radius-Server?

#28 lefg

lefg

    Expert Member

  • 20.508 Beiträge

 

Geschrieben 19. September 2017 - 17:31

Ich gestehe, ich habe keine Ahnung. :)

 

Ich glaube zwar zu ahnen, was Du vorhast, aber ich habe so etwas nie gedacht, es bestand dafür einfach keine Notwendigkeit.


Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#29 magheinz

magheinz

    Newbie

  • 1.417 Beiträge

 

Geschrieben 19. September 2017 - 23:32

Du musst das nur am Switch konfigurieren. Authentifiziert sich ein Client nicht korrekt wird der Port ins GästeVLAN oder halt Authfaile-VLAN gesteckt. Der Radius muss da gar nichts machen.



#30 cjmatsel

cjmatsel

    Senior Member

  • 417 Beiträge

 

Geschrieben 20. September 2017 - 11:43

@magheinz: Das hatte ich mir schon gedacht; ich hatte gehofft diese Einstellung am Switch nicht nutzen zu müssen und stattdessen das global auf dem Radius lösen zu können...



Auch mit einem oder mehreren der folgenden Tags versehen: Windows Server 2008 R2