WLAN mit EAP-MSCHAPv2 funktioniert hervorragend nach dem neusten Update. Ich kann mich mit Benutzernamen anmelden, das Zertifikat wird akzeptiert.
Warum klappt das über LAN nicht so einfach? Ich habe den Dienst gestartet, MAC Adresse der LAN Schnittstelle ist in der Benutzerliste eingetragen. Im Lancom sehe ich keinen Authentifizierungsversuch.
Gibts eine Anleitung was ich zumindest auf der Seite des Lancom einstellen muss? Die Einstellungen in WIN7 sind doch die gleichen wie bei WLAN, oder?
EAPoL auf dem 321agn
Moderator: Lancom-Systems Moderatoren
Moin,
das kann nicht funktionieren, weil's nicht implementiert ist. LCOS enthält keinen 802.1x-
Authenticator für die Ethernet-Schnittstelle, auch wenn die Port-Einstellungen unter
Setup->IEEE802.1x etwas anderes suggerieren...
Gruß Alfred
das kann nicht funktionieren, weil's nicht implementiert ist. LCOS enthält keinen 802.1x-
Authenticator für die Ethernet-Schnittstelle, auch wenn die Port-Einstellungen unter
Setup->IEEE802.1x etwas anderes suggerieren...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Muss ich mich aus Neugierde mal einklinken..
Sind das die Einstellungen welche in LANconfig unter Wireless-LAN/802.1x/Interfaces stecken?
Oder für was sind die dann gut?
Also so ein 802.1x-Authenticator für Ethernet wäre an sich schon ganz cool. Wobei das meistens eher am Switch Sinn macht.
Jaja ich weiß ich weiß.. ich will viel^^
MfG
1711+
Sind das die Einstellungen welche in LANconfig unter Wireless-LAN/802.1x/Interfaces stecken?
Oder für was sind die dann gut?
Also so ein 802.1x-Authenticator für Ethernet wäre an sich schon ganz cool. Wobei das meistens eher am Switch Sinn macht.
Jaja ich weiß ich weiß.. ich will viel^^
MfG
1711+
Moin,
die Tabelle aufgenommen. Die Authenticator-Statemachine könnte genausogut mit LAN wie
WLAN arbeiten, aber es fehlt im Datenpfad des Ethernet die 'Weiche', die Pakete von frei-
gegebenen MAC-Adressen ausfiltert. Und auf Punkt-zu-Punkt-Strecken kann das LCOS im Moment
ja genausowenig 802.1x...ist also in erster Linie ein Stachel, der einen daran erinnert, daß da noch
etwas fehlt.
So unnütze Menüpunkte gab es auch an anderen Stellen im LCOS, z.B. die Client-EAP-Methode
in den WLAN-Verschlüsselungseinstellungen. Im Client-Betrieb wurden früher immer nur
die Einstellungen der ersten SSID genutzt, also hatte man pro WLAN-Interface sieben Menüpunkte
ohne Sinn und Zweck...bis dann in der 7.8x die Unterstützung für mehrere Profile im Client-Modus
kam, da ergab das auf einmal Sinn. Unser Leiter der Entwicklung muß irgendwie hellseherische
Fähigkeiten gehabt haben, als er das damals in dieser Tabelle haben wollte (ich wollte's eben
deswegen in den Client-Einstellungen haben...)
das also schon reizvoll, und Du bist nicht der erste, der sich da wünscht. Das schließt einen PM
bei LANCOM ein, ich habe irgendwie das Gefühl, daß das nicht mehr lange dauern wird. Einen
1x-Supplicant auf dem Ethernet haben einige Geräte ja schon länger. Von daher werde ich die
überflüssigen Zeilen wohl nicht (mehr) herausnehmen.
Man sollte bei der Sache aber im Auge behalten, daß eine 1x-Authentisierung auf dem Ethernet
nicht so wertvoll ist wie im WLAN, denn sie ist nicht mit dynamisch ausgehandelten Schlüsseln
verbunden - ein 'Schmarotzer' kann also mittels MAC-Spoofing sehr leicht auf einer vorhandenen
Authentisierung 'mitreiten'. Abhilfe ist erst mittels 802.1AE (MACSEC) in Sicht, aber die dafür
erforderlichen Erweiterungen in 802.1X sind noch im Draft-Status.
Gruß Alfred
Ja, die meinte ich.Sind das die Einstellungen welche in LANconfig unter Wireless-LAN/802.1x/Interfaces stecken?
Naja, da hat jemand damals einfach alle Interfaces, die die LAN-Bridge kennt, inOder für was sind die dann gut? Very Happy
die Tabelle aufgenommen. Die Authenticator-Statemachine könnte genausogut mit LAN wie
WLAN arbeiten, aber es fehlt im Datenpfad des Ethernet die 'Weiche', die Pakete von frei-
gegebenen MAC-Adressen ausfiltert. Und auf Punkt-zu-Punkt-Strecken kann das LCOS im Moment
ja genausowenig 802.1x...ist also in erster Linie ein Stachel, der einen daran erinnert, daß da noch
etwas fehlt.
So unnütze Menüpunkte gab es auch an anderen Stellen im LCOS, z.B. die Client-EAP-Methode
in den WLAN-Verschlüsselungseinstellungen. Im Client-Betrieb wurden früher immer nur
die Einstellungen der ersten SSID genutzt, also hatte man pro WLAN-Interface sieben Menüpunkte
ohne Sinn und Zweck...bis dann in der 7.8x die Unterstützung für mehrere Profile im Client-Modus
kam, da ergab das auf einmal Sinn. Unser Leiter der Entwicklung muß irgendwie hellseherische
Fähigkeiten gehabt haben, als er das damals in dieser Tabelle haben wollte (ich wollte's eben
deswegen in den Client-Einstellungen haben...)
Je nach LANCOM hat man ja einen (kleinen) Switch eingebaut, für das kleine Büroszenario wäreAlso so ein 802.1x-Authenticator für Ethernet wäre an sich schon ganz cool. Wobei das meistens eher am Switch Sinn macht.
das also schon reizvoll, und Du bist nicht der erste, der sich da wünscht. Das schließt einen PM
bei LANCOM ein, ich habe irgendwie das Gefühl, daß das nicht mehr lange dauern wird. Einen
1x-Supplicant auf dem Ethernet haben einige Geräte ja schon länger. Von daher werde ich die
überflüssigen Zeilen wohl nicht (mehr) herausnehmen.
Man sollte bei der Sache aber im Auge behalten, daß eine 1x-Authentisierung auf dem Ethernet
nicht so wertvoll ist wie im WLAN, denn sie ist nicht mit dynamisch ausgehandelten Schlüsseln
verbunden - ein 'Schmarotzer' kann also mittels MAC-Spoofing sehr leicht auf einer vorhandenen
Authentisierung 'mitreiten'. Abhilfe ist erst mittels 802.1AE (MACSEC) in Sicht, aber die dafür
erforderlichen Erweiterungen in 802.1X sind noch im Draft-Status.
Gruß Alfred
Aah cool, danke für die ausführliche Erklärung! Immer wieder mal recht interessant was da wo wie und weshalb steckt
Eine Frage hätte ich da noch welche mir schon lange Bauchschmerzen bereitet:
Wie muss ich den RADIUS konfigurieren wenn ich beispielsweise nur EAP-TTLS zulassen will? Oder nur PEAP? Oder nur TTLS und PEAP.. oder nur TLS.. etc.. lol
Auf gut Deutsch, ich kapiere die Einstellmöglichkeiten unter RADIUS/EAP beim besten Willen samt Hilfe nicht
Kannst du mir da evtl. etwas Licht ins Dunkel bringen?
Steht Default Methode jetzt dafür was überhaupt geht oder was Standard Methode ist. Sprich kann ich da eingrenzen?
Was bewirken die TTLS/PEAP-Default Einstellungen genau und für was steht da "keine". Ist mit "keine" TTLS/PEAP dann deaktiviert?
Danke!
1711+
Edit:
Was unter RADIUS/Benutzerkonten die Auswahl bei Dienst-Typ und bei Protokollen EAP bedeutet wäre auch noch interessant. EAP passt ja nicht ganz in eine Reihe mit mschapv2 und chap oder?^^
Eine Frage hätte ich da noch welche mir schon lange Bauchschmerzen bereitet:
Wie muss ich den RADIUS konfigurieren wenn ich beispielsweise nur EAP-TTLS zulassen will? Oder nur PEAP? Oder nur TTLS und PEAP.. oder nur TLS.. etc.. lol
Auf gut Deutsch, ich kapiere die Einstellmöglichkeiten unter RADIUS/EAP beim besten Willen samt Hilfe nicht
Kannst du mir da evtl. etwas Licht ins Dunkel bringen?
Steht Default Methode jetzt dafür was überhaupt geht oder was Standard Methode ist. Sprich kann ich da eingrenzen?
Was bewirken die TTLS/PEAP-Default Einstellungen genau und für was steht da "keine". Ist mit "keine" TTLS/PEAP dann deaktiviert?
Danke!
1711+
Edit:
Was unter RADIUS/Benutzerkonten die Auswahl bei Dienst-Typ und bei Protokollen EAP bedeutet wäre auch noch interessant. EAP passt ja nicht ganz in eine Reihe mit mschapv2 und chap oder?^^
Zuletzt geändert von 1711+ am 24 Okt 2010, 20:34, insgesamt 1-mal geändert.
Moin,
Methode vor, aber der Client kann per NAK eine andere Methode fordern. Einschränken ist
nicht ganz einfach, weil EAP zum Teil geschachtelt läuft, man in der 'äußeren' EAP-Verhandlung
den realen Benutzernamen nicht immer erfährt, und der RADIUS-Server nicht immer sicher
feststellen kann, ob es jetzt die äußere oder innere EAP-Methode ist.
verstanden zu haben. EAP(OL) funktioniert grob so:
- Der Authenticator (also der AP) schickt einen Identity Request zum Client
- Der Supplicant (WLAN-Client) antwortet mit einem Identity Response, den leitet
der Authenticator als RADIUS-Request an den RADIUS-Server weiter. Ab jetzt
arbeitet der AP nur noch als Relaisstation zwischen Supplicant und RADIUS-Server.
- Der RADIUS-Server schickt einen Request mit der Methode, die im LCOS in den
RADIUS-EAP-Einstellungen als 'Default-Methode' hinterlegt ist - also z.B. (EAP-)MD5.
- Dem (WLAN-)Client gefällt das z.B. nicht und er schickt als Antwort ein NAK mit dem
Hinweis, daß er gerne PEAP machen möchte
- der RADIUS-Server akzeptiert das und schickt ein PEAP-Start
- Jetzt läuft zwischen RADIUS-Server und Supplicant ein TLS-Handshake (PEAP baut
auf EAP/TLS auf!), in deren Verlauf der Server sich gegenüber dem Supplicant mit
seinem Zertifikat authentifiziert.
- Jetzt kommt der Witz: der zwischen RADIUS-Server und Supplicant aufgebaute TLS-
Tunnel wird genutzt, um *eine weitere' EAP-Verhandlung zu führen, in der sich der
Client authentisiert. Falls die innere EAP-Verhandlung auch auf dem LCOS-RADIUS-
Server läuft (also der Eintrag für den Tunnel-Server leer ist), dann schlägt der LCOS-
RADIUS-Server diesmal als Default die 'PEAP-Default-Tunnel-Methode' vor. Micro$oft
sei Dank ist EAP-MSCHAPv2 praktisch immer richtig, deshalb geht's diesmal ohne NAK
ab.
- In der inneren Authentisierung authentisiert sich jetzt der Client per MSCHAPv2. Dies
ist als Challenge/Response-Verfahren prinzipiell anfällig gegen Wörterbuchattacken,
aber da diese innere EAP-Verhandlung verschlüsselt durch den TLS-Tunnel läuft, der
in der ersten Phase aufgebaut wurde, kann niemand mitlesen.
- Am Ende gibt's einen 'Success' in der MSCHAPv2-Verhandlung. der wird durchgereicht
an die äußere EAP-Authentisierung (die quasi die ganze Zeit mitläuft) und der AP erhält
mit dem RADIUS-Accept die Session-Keys, mit denen AP und Client dann einen WPA-
Handshake machen.
Wer mal live sehen will, was während so einer PEAP-Authentisierung passiert, mache
einfach mal einen RADIUS-Server-Trace an - dort kann man sehen, wie das Gerät in der
zweiten Phase mit sich selber über die 127.0.0.1 spricht...
Die restlichen Parameter in den RADIUS-EAP-Einstellungen? Die Reauthentisierung ist die
Zeitperiode, alle wieviel Sekunden während des Betriebs die 1x-Authentisierung zwecks
Rekeying wiederholt werden soll. Dazu muß Reauthentisierung auf dem AP aber auch
eingeschaltet sein. VORSICHT! Das tut unter Win7 aus unerfindlichen Gründen nicht mehr!
Der Retransmit-Timeout sagt dem AP, nach wieviel Sekunden er eine Anfrage an den Client
wiederholen soll, wenn keine Antwort kommt. Wenn man dort eine Null stehen läßt, benutzt
der AP seinen eingebauten Default (30 Sekunden).
Die MTU gibt die maximala Paketgröße der EAP-Request vor, die der RADIUS-Server in Richtung
Supplicant herausgibt. Daran muß man eher selten drehen, in Zukunft werden LANCOM-APs
dem RADIUS-Server selber einen sinnvollen Wert für die EAPOL-MTU vorschlagen.
'sich selber' keine Default-Methode vorschlagen. Das ist aber eher ungeschickt, denn dann
würde die innere EAP-Verhandlung auch erstmal mit dem Default der äußeren Methode
vorlegen. PEAP innerhalb von PEAP ist zwar nicht unmöglich, aber wenig sinnvoll...
Zusammenhang mit PPP (siehe die Methodenauswahl im PPP-Setup). Wenn bei einem
RADIUS-Request oder einer PPP-Einwahl z.B. schlicht Benutzername und Paßwort übermittelt
werden, dann nennt man das PAP. Anstelle dessen kann der Einwahlserver aber auch einen
Challenge an den Client schicken, und Challenge und Client-Antwort an den RADIUS-Server
schicken. Damit geht das Paßwort niemals über die Leitung. Je nach Variante nennt man das
dann CHAP, MS-CHAP, oder MS-CHAPv2. Aber auch über PPP kann man wieder EAP als
Authentisierungsmethode verwenden (dazu ist es ursprünglich sogar mal entwickelt worden!),
deshalb steht an dieser Stelle EAP neben PAP, CHAP usw. Für die Einschränkung der EAP-
Methoden müßte man einen eine weitere Auswahlliste danebenstellen, das hat aber so seine
Probleme:
(1) Bei TTLS erfährt man in der ersten Phase gar nicht den echten Benutzernamen, man könnte
TTLS also gar nicht benutzerspezifisch zulassen
(2) Wie geschrieben, hat man bei TTLS und PEAP eine innere und eine äußere EAP-Verhandlung,
die jede für sich über RADIUS läuft. Es ist für den Server gar nicht so einfach festzustellen, ob
das jetzt die innere oder äußere Verhandlung ist, insbesondere bei einem einzelnen AP, wo
das Gerät ja in beiden Fällen über die 127.0.0.1 mit sich redet.
(3) Die Auswahl ist eigentlich auch noch vom Medium abhängig. 'Reines' MD5 (also ohne ein
TTLS außenrum) ist für 802.1x auf Ethernet durchaus gängig, auf dem WLAN, wo jeder
mithören kann, ist es aber so unbrauchbar.
Ufff...ich hoffe, ich habe damit mehr Fragen beantwortet als aufgeworfen...
Gruß Alfred
Das kann man im Augenblick nicht einschränken. Der RADIUS-Server schlägt eine Default-Wie muss ich den RADIUS konfigurieren wenn ich beispielsweise nur EAP-TTLS zulassen will? Oder nur PEAP? Oder nur TTLS und PEAP.. oder nur TLS.. etc.. lol
Methode vor, aber der Client kann per NAK eine andere Methode fordern. Einschränken ist
nicht ganz einfach, weil EAP zum Teil geschachtelt läuft, man in der 'äußeren' EAP-Verhandlung
den realen Benutzernamen nicht immer erfährt, und der RADIUS-Server nicht immer sicher
feststellen kann, ob es jetzt die äußere oder innere EAP-Methode ist.
Wenn man EAP verstehen will, ist es hilfreich, das Prinzip der bewußten russischen PüppchenAuf gut Deutsch, ich kapiere die Einstellmöglichkeiten unter RADIUS/EAP beim besten Willen samt Hilfe nicht
verstanden zu haben. EAP(OL) funktioniert grob so:
- Der Authenticator (also der AP) schickt einen Identity Request zum Client
- Der Supplicant (WLAN-Client) antwortet mit einem Identity Response, den leitet
der Authenticator als RADIUS-Request an den RADIUS-Server weiter. Ab jetzt
arbeitet der AP nur noch als Relaisstation zwischen Supplicant und RADIUS-Server.
- Der RADIUS-Server schickt einen Request mit der Methode, die im LCOS in den
RADIUS-EAP-Einstellungen als 'Default-Methode' hinterlegt ist - also z.B. (EAP-)MD5.
- Dem (WLAN-)Client gefällt das z.B. nicht und er schickt als Antwort ein NAK mit dem
Hinweis, daß er gerne PEAP machen möchte
- der RADIUS-Server akzeptiert das und schickt ein PEAP-Start
- Jetzt läuft zwischen RADIUS-Server und Supplicant ein TLS-Handshake (PEAP baut
auf EAP/TLS auf!), in deren Verlauf der Server sich gegenüber dem Supplicant mit
seinem Zertifikat authentifiziert.
- Jetzt kommt der Witz: der zwischen RADIUS-Server und Supplicant aufgebaute TLS-
Tunnel wird genutzt, um *eine weitere' EAP-Verhandlung zu führen, in der sich der
Client authentisiert. Falls die innere EAP-Verhandlung auch auf dem LCOS-RADIUS-
Server läuft (also der Eintrag für den Tunnel-Server leer ist), dann schlägt der LCOS-
RADIUS-Server diesmal als Default die 'PEAP-Default-Tunnel-Methode' vor. Micro$oft
sei Dank ist EAP-MSCHAPv2 praktisch immer richtig, deshalb geht's diesmal ohne NAK
ab.
- In der inneren Authentisierung authentisiert sich jetzt der Client per MSCHAPv2. Dies
ist als Challenge/Response-Verfahren prinzipiell anfällig gegen Wörterbuchattacken,
aber da diese innere EAP-Verhandlung verschlüsselt durch den TLS-Tunnel läuft, der
in der ersten Phase aufgebaut wurde, kann niemand mitlesen.
- Am Ende gibt's einen 'Success' in der MSCHAPv2-Verhandlung. der wird durchgereicht
an die äußere EAP-Authentisierung (die quasi die ganze Zeit mitläuft) und der AP erhält
mit dem RADIUS-Accept die Session-Keys, mit denen AP und Client dann einen WPA-
Handshake machen.
Wer mal live sehen will, was während so einer PEAP-Authentisierung passiert, mache
einfach mal einen RADIUS-Server-Trace an - dort kann man sehen, wie das Gerät in der
zweiten Phase mit sich selber über die 127.0.0.1 spricht...
Die restlichen Parameter in den RADIUS-EAP-Einstellungen? Die Reauthentisierung ist die
Zeitperiode, alle wieviel Sekunden während des Betriebs die 1x-Authentisierung zwecks
Rekeying wiederholt werden soll. Dazu muß Reauthentisierung auf dem AP aber auch
eingeschaltet sein. VORSICHT! Das tut unter Win7 aus unerfindlichen Gründen nicht mehr!
Der Retransmit-Timeout sagt dem AP, nach wieviel Sekunden er eine Anfrage an den Client
wiederholen soll, wenn keine Antwort kommt. Wenn man dort eine Null stehen läßt, benutzt
der AP seinen eingebauten Default (30 Sekunden).
Die MTU gibt die maximala Paketgröße der EAP-Request vor, die der RADIUS-Server in Richtung
Supplicant herausgibt. Daran muß man eher selten drehen, in Zukunft werden LANCOM-APs
dem RADIUS-Server selber einen sinnvollen Wert für die EAPOL-MTU vorschlagen.
Wenn man 'keine' einstellt, dann würde der RADIUS Server bei der getunnelten VerhandlungWas bewirken die TTLS/PEAP-Default Einstellungen genau und für was steht da "keine". Ist mit "keine" TTLS/PEAP dann deaktiviert?
'sich selber' keine Default-Methode vorschlagen. Das ist aber eher ungeschickt, denn dann
würde die innere EAP-Verhandlung auch erstmal mit dem Default der äußeren Methode
vorlegen. PEAP innerhalb von PEAP ist zwar nicht unmöglich, aber wenig sinnvoll...
Vorsicht Falle: MSCHAPv2 gibt es nicht nur als EAP-Methode, sondern auch ohne EAP, z.B. imWas unter RADIUS/Benutzerkonten die Auswahl bei Dienst-Typ und bei Protokollen EAP bedeutet wäre auch noch interessant. EAP passt ja nicht ganz in eine Reihe mit mschapv2 und chap oder?^^
Zusammenhang mit PPP (siehe die Methodenauswahl im PPP-Setup). Wenn bei einem
RADIUS-Request oder einer PPP-Einwahl z.B. schlicht Benutzername und Paßwort übermittelt
werden, dann nennt man das PAP. Anstelle dessen kann der Einwahlserver aber auch einen
Challenge an den Client schicken, und Challenge und Client-Antwort an den RADIUS-Server
schicken. Damit geht das Paßwort niemals über die Leitung. Je nach Variante nennt man das
dann CHAP, MS-CHAP, oder MS-CHAPv2. Aber auch über PPP kann man wieder EAP als
Authentisierungsmethode verwenden (dazu ist es ursprünglich sogar mal entwickelt worden!),
deshalb steht an dieser Stelle EAP neben PAP, CHAP usw. Für die Einschränkung der EAP-
Methoden müßte man einen eine weitere Auswahlliste danebenstellen, das hat aber so seine
Probleme:
(1) Bei TTLS erfährt man in der ersten Phase gar nicht den echten Benutzernamen, man könnte
TTLS also gar nicht benutzerspezifisch zulassen
(2) Wie geschrieben, hat man bei TTLS und PEAP eine innere und eine äußere EAP-Verhandlung,
die jede für sich über RADIUS läuft. Es ist für den Server gar nicht so einfach festzustellen, ob
das jetzt die innere oder äußere Verhandlung ist, insbesondere bei einem einzelnen AP, wo
das Gerät ja in beiden Fällen über die 127.0.0.1 mit sich redet.
(3) Die Auswahl ist eigentlich auch noch vom Medium abhängig. 'Reines' MD5 (also ohne ein
TTLS außenrum) ist für 802.1x auf Ethernet durchaus gängig, auf dem WLAN, wo jeder
mithören kann, ist es aber so unbrauchbar.
Ufff...ich hoffe, ich habe damit mehr Fragen beantwortet als aufgeworfen...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Moin,
als 'sicherer' angesehen, weil man sich physischen Zugang zum Netz verschaffen muß - bei einem
Heimanwender wäre das ja nur ein Einbrecher...in einem Firmennetz sieht das schon anders aus,
deshalb wird 802.1x auf den Switches da auch öfters eingesetzt.
Gruß Alfred
Etwas zum WLAN Vergleichbares kann ich da nicht anbieten. Allgemein wird Ethernet in dem SinneSo, wie mache ich denn nun das LAN sicher, damit keiner einfach so ins Netz (LAN) kommt?
als 'sicherer' angesehen, weil man sich physischen Zugang zum Netz verschaffen muß - bei einem
Heimanwender wäre das ja nur ein Einbrecher...in einem Firmennetz sieht das schon anders aus,
deshalb wird 802.1x auf den Switches da auch öfters eingesetzt.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
@ alf29
Du hast alle Fragen 100%ig geklärt! Danke dass du dir die Zeit genommen hast das so ausführlich zu erklären.
Kanns sein dass die Hilfe dann bei den beiden Punkten Reauth-Periode und Retransmit Timeout unter LANconfig verdreht ist? Weil da stehts genau andersrum wie du erklärst.
Schönen Abend!
1711+
Du hast alle Fragen 100%ig geklärt! Danke dass du dir die Zeit genommen hast das so ausführlich zu erklären.
Kanns sein dass die Hilfe dann bei den beiden Punkten Reauth-Periode und Retransmit Timeout unter LANconfig verdreht ist? Weil da stehts genau andersrum wie du erklärst.
Schönen Abend!
1711+
Die Switche machen das dann aber auch nur portbasiert oder auch nutzerbasiert? Haste mal nen Beispiel als kleinen Switch, also kein CatalystEtwas zum WLAN Vergleichbares kann ich da nicht anbieten. Allgemein wird Ethernet in dem Sinne
als 'sicherer' angesehen, weil man sich physischen Zugang zum Netz verschaffen muß - bei einem
Heimanwender wäre das ja nur ein Einbrecher...in einem Firmennetz sieht das schon anders aus,
deshalb wird 802.1x auf den Switches da auch öfters eingesetzt.
Danke
Moin,
das kommt jetzt darauf an, was Du als 'klein' bezeichnest. Ein nicht-managebarer Switch
tut's für diese Aufgabe natürlich nicht, aber wenn ich's richtig im Kopf habe, müßte man
schon so größenordnungsmäßig bei Switches für 150..200 fündig werden. Da solche
Switches für den Einsatz im Serverraum konzipiert sind, haben sie auch meist gleich 16
oder mehr Ports und kommen im 19-Zoll-Format. Bei LANCOM-Switches geht's erst mit
einem GS-1224 für gut 300 Euro los, es ist aber nicht verboten, sich mal bei LevelOne
oder Netger & Konsorten nach so etwas umzusehen. Oder sich bei Ebay einen gebrauchten
Switch 'schießen'. Enterprise-Switches gehen dort oft für kleines Geld weg, weil sie in
den Firmen mangels Gigabit-Ports rausgeflogen sind...
Port-oder MAC-adreß-basierte 1x-Authentisierung ist bei den Switches meistens pro Port
einstellbar.
Gruß Alfred
das kommt jetzt darauf an, was Du als 'klein' bezeichnest. Ein nicht-managebarer Switch
tut's für diese Aufgabe natürlich nicht, aber wenn ich's richtig im Kopf habe, müßte man
schon so größenordnungsmäßig bei Switches für 150..200 fündig werden. Da solche
Switches für den Einsatz im Serverraum konzipiert sind, haben sie auch meist gleich 16
oder mehr Ports und kommen im 19-Zoll-Format. Bei LANCOM-Switches geht's erst mit
einem GS-1224 für gut 300 Euro los, es ist aber nicht verboten, sich mal bei LevelOne
oder Netger & Konsorten nach so etwas umzusehen. Oder sich bei Ebay einen gebrauchten
Switch 'schießen'. Enterprise-Switches gehen dort oft für kleines Geld weg, weil sie in
den Firmen mangels Gigabit-Ports rausgeflogen sind...
Port-oder MAC-adreß-basierte 1x-Authentisierung ist bei den Switches meistens pro Port
einstellbar.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015