Hi.
Auf der Suche nach Möglichkeiten, wie man das WLAN in der Schule verbessern bzw performanter machen kann, bin ich über interessante Dinge gestolpert wie z.B. das hier:
Der Hintergrund der Sache ist einfach zu verstehen:
Um unnötigen Overhead zu verhindern, sollte man tunlichst nicht „möglichst viele“ unterschiedliche SSIDs über einen AP abstrahlen sondern im Gegenteil möglichst wenige bzw. nur eine einzige SSID für das WLAN verwenden.
Mit dynamischen VLANs (802.1X) benötigt man u.U. für das gesamte WLAN nur noch eine einzige SSID, die die User/Geräte entsprechend ihrer Credentials in das passende VLAN dynamisch einsortiert. Nicht registrierte Gäste könnten so in einem VLAN mit einem Captive Portal und Einmalpasswörtern landen usw.
Das klingt zunächst super und der Unifi-Controller beherrscht das auch alles. Das größere Problem dabei ist, dass man am FreeRADIUS-Server diverse Einstellungen machen muss. Daher habe ich weitergesucht nach Dingen wie „FreeRADIUS & Docker“. Früher oder später stolpert man dann immer über ein WebUI für den RADIUS-Server namens daloRADIUS, so auch hier:
aber auch hier:
Meine Überlegung dazu ist nun: Wie wäre es, wenn man sich einen passenden docker-Container mit freeRADIUS und daloRADIUS herunterlädt und mit ins Servernetz packt. Falls man den produktiv laufenden FreeRADIUS-Server, der bei uns momentan mit auf dem v7-Server läuft, durch so eine aufgebohrte Lösung ersetzen will, müsste man dem v7-Server und Unifi-Controller natürlich mitteilen, dass der RADIUS-Server nun woanders läuft. Hat sowas mal jemand von Euch gemacht / ausprobiert?
Ich weiß nicht, ob das ein (zu) großer Eingriff ins System ist oder ob sowas ein ehrgeiziges aber machbares Unterfangen darstellt?
Über einen Ideenaustausch würde ich mich jedenfalls freuen.
Viele Grüße,
Michael
insgesamt kein schlechter Ansatz, aber wenn man schon NAC sinnvoll betreiben will, warum macht man es dann nicht gleich „richtig“ über eine NAC-Appliance mit z.B. https://www.packetfence.org/ sondern über selbstgebastelte Docker-Konstrukte?
Umso besser, wenn es fix und fertige Lösungen gibt .
Die Integration in eine bereits laufende v7-Umgebung bereitet mir aber weiterhin etwas Kopfzerbrechen, da ich sicher nicht alle Stellen kenne, an denen man die Einstellung auf den neuen FreeRADIUS-Server umstellen müsste
Im v7-WebUI besteht ja die Möglichkeit, das WLAN für einzelne Gruppen an-/auszuschalten. Dieser Button wäre bei der Nutzung einer „externen“ Lösung vermutlich tot – oder?
nein, warum? Packetfence z.B. unterstützt AD, LDAP und auch RADIUS-Authentisierung…heißt, du kannst die RADIUS-Authentisierung der Appliance einfach gegen den freeradius auf der lmn7 laufen lassen. Was auf dem lmn7 geblocked ist, geht dann auch über die paketfence nicht weiter.
Ok – damit wären wir schon mittendrin: In einem anderen Beitrag habe ich erst kürzlich festgestellt, dass
" der FreeRADIUS-Server auf dem v7-Server ins AD schaut und dort lediglich den Eintrag WiFi=Ja oder Nein findet. Ich hab’s gerade in den docs wiedergefunden: Scheinbar wird das über den Befehl /usr/bin/ntlm_auth ... abgefragt."
Wenn ich das richtig sehe (so wie hier beschrieben), besteht damit im Moment nur die Möglichkeit „Ja/Nein“ zu unterscheiden aber nicht die Möglichkeit, genauer nach Gruppen/Zugehörigkeiten zu sortieren, richtig?!?
Ein verbesserter FreeRADIUS-Server wie Packetfence könnte also genau an dieser Stelle ansetzen, es genauer unterscheiden und den User, der sich gerade anmelden will, gemäß seiner Gruppenzugehörigkeit in das passende VLAN einsortieren, richtig?
das Problem ist, das ntlm-auth, also das freeradius-Modul, welches zur Überprüfung der Gruppenzugehörigkeit wifi genutzt wird, laut Doku nur genau eine Gruppe abfragen kann und keine weitere. Andere Module z.B. LDAP können deutlich mehr, u.a. anhand der Gruppenzugehörigkeit den Benutzer einem VLAN zuordnen.
Dafür ist die Konfiguration unter freeradius ohne zusätzliche Tools etwas aufwendiger. Die ntml-auth-Methode reicht i.d.R für 89% aller Anwendungsfälle aus.
Aber wenn man das so umsetzen möchte und dynamische VLANs einführen würde, müsste man ja genauer unterscheiden und käme mit Ja/Nein bei weitem nicht hin. Man hätte dann mindestens 5 Gruppen:
Lehrer (Zugriff immer erlaubt)
Schüler der Oberstufe (Zugriff immer erlaubt)
Schüler anderer Klassen (kein Zugriff – außer z.B. über ein gemeinsames Voucher → Captive Portal)
Vermutlich könnte man das alles dem jetzt laufenden FreeRADIUS-Server auch beibringen, in dem man von ntml_auth auf ldap + sql umschaltet … aber da tun sich direkt Abgründe auf…
sicher, kann man auch alles mit freeradius selbst bauen. Letztlich ist eine NAC Appliance wie packetfence auch „nur ein Frontend“ und im Hintergrund passiert dann genau dasselbe, als würde man alles selbst konfigurieren. Die Fragen sind dann immer: 1) wieviel Zeit will ich in dieses Thema investieren? 2) Erreiche ich einen Mehrwert, wenn ich alles selbst mache, der diesen Zeitaufwand rechtfertigt?
Daher finde ich, wenn man sich schon Gedanken zum Thema NAC macht, packetfence an sich eine gute Lösung, zumal man auch hier zusätzlich zu dynamischen VLANs mit 802.1X z.B. auch CaptivePortal mit Password-of-the-Day, bzw. Voucher, inkl. PKI mit SCEP-Enrollment für EAP-TLS abbilden kann.
Hi nochmal.
Ok – im Sinne des Projektes gedacht wäre es natürlich toll, wenn ich mit so einem Vorstoß nicht völlig alleine auf weiter Flur da stehe sondern wenn die Idee auch andere Unterstützer und im besten Fall sogar „offiziellen Einzug in das Projekt“ erhält. Das kann ich als Nordlicht natürlich nicht entscheiden / überblicken, ob so ein Weg für das linuxmuster-Projekt …
schon längst angedacht
sinnvoll
umsetzbar ist?
Aber ich vermute, dass es für andere Schulen mit WLAN-Performance-Problemen bei steigender Anzahl von Endgeräten auch interessant sein oder werden dürfte!?!
ich denke, das Thema dürfte ein optionale Geschichte bleiben. Diejenigen die das brauchen, werden über kurz oder lang zu einer Lösung finden.
Wirklich interessant wird es erst, wenn ich das auch auf Layer2 Basis konsequent umsetze. Das heißt dann: Egal an welchem Port im Schulgebäude ich mein Verwaltungsnotebook, Drucker etc…einstecke → es landet immer im Verwaltungsnetz. Selbst wenn ich eine WIfI-Verbindung aufbaue → ich lande mit meinem Gerät immer im Verwaltungsnetz. Ich kann das Telefon anschließen, wo ich will → solange es über PoE versorgt wird, ist es immer im Telefonienetz. Der Schüler XY kann mit 42 verschiedenen Geräten kommen, seine MAC-Adressen 112fach verdrehen → er landet immer im GastNetz und muss sich per CaptivePortal authentisieren.
Blöd wird es halt, wenn ich mit meinem Gerät in ein anderes Netzwerk muss oder möchte, weil nur dort die Präsentationsmedien (AppleTV, Cynap etc.) zuhause sind und ich diese nur dann erreiche, wenn ich im selben Netz bin, weil die Geräte nicht routingfähige Protokolle verwenden. Dann wird NAC zum Krampf und ich muss doch wieder Krücken bauen und auf ungeliebte Konstrukte wie HotSpots zurückgreifen („Wäääääääääääääääh…warum kann ich nicht aus dem Lehrernetz auf das AppleTV zugreifen, aber aus dem paedNetz schon…ich muss da immer erst Funknetz wechseln. Das ist für meinen Unterricht untragbar. Unterricht ist so nicht möglich! Mach, dass das einfacher geht!“ Beliebt ist auch: „Damit können die Kollegen nicht umgehen! Wir brauchen eine einfachere Lösung!“).
Und schon hat man wieder den Konflikt zwischen Sicherheit und Komfort.
Hm – und wie müsste man das wiederum realsisieren?
Wenn die anderen Dinge mit Packetfence halbwegs einfach umsetzbar sind, werde ich es mir jedenfalls mal ansehen. Es gibt ja offenbar ein fertiges ISO zum Download…
Viele Grüße und besten Dank für die ganzen HIntergrundinfos
Michael
das ist eben so einfach wie aufwendig und im Prinzip das Kernstück der Zugangskontrolle mit 802.1X. Man muss die MAC-Adressen aller Geräte erfassen, die einem bestimmten VLAN zugeordnet werden sollen. Alle unbekannten Geräte werden dann z.B. dem Gastnetz zugewiesen. Der Switch fragt den RADIUS-Server „Ich hab hier ein Gerät mit dieser und jener MAC, in welches VLAN soll das?“ Der Radius gibt dann die zugeordnete VLAN ID zurück und der Switch passt das die VLAN ID des SwitchPorts entsprechend an. Entsprechende Switch-Hardware vorausgesetzt.
Hallo Thomas.
Ok – dann scheint mir das mit schuleigenen Geräte machbar zu sein, denn deren MAC hat man sowieso bereits in der devices.csv stehen. Aber mit Lehrergeräten oder gar BYOD der SuS ist das dann ja nahezu ausgeschlossen, dass man deren MAC-Adressen von „völlig unbekannten“ Gast-Geräten trennen kann!??
Ich dachte, dass die Zuordnung nicht anhand der MAC-Adresse (MAC-Spoofing ) erfolgt, sondern dass aufgrund des Logins entschieden wird, in welches VLAN man gepackt wird?
In der Praxis ist es vermutlich eine Kombination aus beidem, richtig?
Viele Grüße,
Michael
es kommt drauf an was du machen willst. Nicht alles was aus Sicht der Netzwerksicherheit möglich ist und geboten erscheint, erweißt sich als schulalltagstauglich. Ich würde z.B. in keiner Weise zwischen unverwalteten Lehrerendgeräten und BYOD-Lehrer/Schüler-Endgeräten unterscheiden. In all diesen Fällen kann ich mir nicht sicher sein, dass die nicht in irgendeiner Weise „verseucht“ sind (erinnert sei an die berühmten Lehrer-USB-Sticks, die von Gerät zu Gerät wandern. Niemand soll behaupten an seiner Schule gäbe es das nicht. Sperrt einfach mal die USB-Ports am Kopierer, dann wisst ihr wieviele USB-Sticks im Umlauf sind). An sich gehören alle diese Geräte in ein abgeschottetes Gast-Netz mit Portisolation bzw. dem WIFI-Pendent. Mach das in der Praxis, aber geh am besten sofort auf ein Sabbatical irgendwohin weit weg…den Aufschrei wirst du selbst in Feuerland noch hören können.
VG
Thomas
PS. In einem Unternehmen kann ich sagen: Das machen wir so, weil isso! An einer Schule undenkbar.
Sicher alles richtig
Ich denke über diese Dinge aber gar nicht so sehr aus sicherheitstechnischer Sicht als vielmehr aus Sicht der Performance des WLANs nach.
Das Problem bei zu vielen unterschiedlichen SSIDs über die UniFi APs ist ja, dass das Netz dadurch (massiv??) an Performance verliert, weil man viel Overhead erzeugt. Ich habe mal gehört, dass daher 3 SSIDs schon als „absolute Obergrenze“ angesehen werden sollte
richtig…wenn Performance das Problem ist, stell ich mir die Frage, ob man dass nicht über etwas anderes regulieren sollte, z.B. Zugriffe auf z.B. Instagram auf 16,5KB/s begrenzen. Die Zuordnung der Benutzer in unterschiedliche VLANs bringt Performancetechnisch wenig bis gar nichts.
das mag alles sein…ich habe 4 SSID (AllgemeinWlan, LehrerWlan, UnterrichtsWlan, AdminWlan) und in den ersten drei SSID sind insgesamt jeden Tag zwischen 350 und 700 Nutzer unterwegs. Dabei wird auch wirklich viel Traffic, v.a. im UnterrichtsWlan durch den Klassroommanager, AppleTV und die permanente Einbidung unserer Cloud in die IPads erzeugt. Zudem wird auch viel von unserer Cloud über die IPads gestreamt. Bei Veranstaltungen sind auch mal > 1000 User im allgemeinen Wlan gewesen. Ich habe noch keine Performanceprobleme feststellen können oder gemeldet bekommen. Ich frage mich, ab welcher Auslastung die Probleme sichtbar werden?
Vom Prinzip her hört sich der neue Ansatz klasse an, die Frage ist, ob, bzw. ab welcher Auslastung sich der Aufwand lohnt.
Bin mal gespannt, falls du das Umsetzt wie das funktioniert!
VG Dominik
Ne, das alleine nicht, aber ich zitiere mal aus einer Nachricht, in der ich das neulich gelesen habe:
Deshalb würde ich gerne die Anzahl der SSIDs auf das nötigste reduzieren…
Deine andere Idee (Reduzierung der Bandbreite für gewisse Dienste) habe ich schon länger auf meiner To-Do-Liste stehen. Im Moment haben wir uns einfach so geholfen, dass alle User in dem BYOD-WLAN im Up-/Downstream auf eine gerade noch hinnehmbare Bandbreite begrenzt werden. Das ist nicht sehr elegant aber verhindert immerhin, dass BYOD-User auf die Idee kommen, in der Schule Netflix & Co schauen zu wollen. Viel besser wäre natürlich echtes Traffic-Shaping, was mit der OPNSense ja auch kein Problem ist, wie man hier sieht: Setup Traffic Shaping — OPNsense documentation
Dazu fehlte mir bisher aber die Zeit und vor allem die Ruhe, das in unserer Testumgebung einzustellen.
Und um auch Dominik (@foer) zu antworten: Ab wie vielen Usern man die Effekte merkt, kann ich nicht genau sagen. Fest steht aber, dass wir täglich ein paar Probleme mit Tablets im iPad-WLAN haben, die ich mir nicht erklären kann. Ich habe schon so ziemlich jede Einstellung bzgl der WLAN-Optimierung ausprobiert und kann es nicht genauer eingrenzen. Leider habe ich aber mehr und mehr den Eindruck, dass die Unifi-APs nicht wirklich für mehr als 20 User pro AP gemacht sind — hier würde ich mich aber sehr gerne eines besseren belehren lassen, da die Dinger nunmal überall bei uns in der Schule herumhängen
wir hatten ebenfalls diese undefinierbaren Probleme mit IPads. Seit etwa einem halben Jahr überwiegend nicht mehr. Gebracht haben es folgende Dinge:
6er Firmware
BandSteering auf den AP`s mit 5GhZ Bevorzugung
Fast Roaming im IPadWlan
Erzwingung, dass high performance Geräte ausschließlich mit 5GhZ verbunden werden (im IpadWlan)
Automatische Kanalwahl im Topo, so das die Frequenzverteilung nach Scan optimiert wird
Sendeleistung auf gering
Wahrscheinlich hast du das auch schon alles ausprobiert…bei uns hat das eine wesenentliche Verbesserung gebracht und es gibt eigentlich keine Klagen mehr aus den IPadKlassen.
Kann ich so nicht bestätigen. Bei uns hängen in den IPadKlassen machmal > 30 Geräte dran und trotzdem scheint es zu funktionieren?
Viel mehr Probleme als die IPads machen mir diese drecks AppleTV, die sich alle paar Tage verschlucken, nicht aufwachen, ihre Konfiguration vergessen…
Hi.
Ja. Genau das sind die Settings, die wir rauf- und runter ausprobiert haben. Wir haben die APs (alles UAP-AC-PRO) im Gebäude so verteilt, dass in jedem Klassenraum einer hängt. Daher sollte es theoretisch so sein, dass max. 30 Geräte/User pro AP verbunden sind. In der Praxis sind’s auch schon mal ein paar mehr, da z.B. in einer Etage auch noch ein Wagen mit Tablets herumsteht.
Bei uns ist es genau umgekehrt und die AppleTV machen überhaupt keine Probleme. Das liegt bei uns aber ziemlich sicher daran, dass sie über einen Schlüsselschalter am Ende der Stunde stromlos gemacht werden und zu Beginn der nächsten Stunde neu hochfahren