[Switches / VLAN] Von Tagged -> Untagged

[AreWeRlyFree]

Hey ;-)

Ich bin aktuell mit meinem Latein im Netzwerkbereich am Ende und würde mich über Inputs von Expertinnen/Experten freuen. Das Dilemma, vor dem ich stehe, lässt sich leider auch nicht so einfach zusammenfassen. Ich versuch es daher in einer Kurzfassung und einer Langfassung - hoffentlich einigermaßen verständlich - rüber zu bringen.

Kurzfassung
Ich brauche eine Art "tagged"->"untagged" Converter für einen Switch. Der spezifische Anschlussport muss auf dem Switch "tagged" sein, das daran angeschlossene Gerät kann aber lediglich mit "untagged" korrekt arbeiten. Mein spontaner Gedanke wäre einen AP oder einfach einen weiteren Managed Switch hinzustellen, der am "tagged"-Port am Hauptswitch angeschlossen wird - das darauffolgende Gerät wird dann an einem "untagged"-Port zwischengeschaltet.

Langfassung
Ich habe ein - über mehrere Stockwerke verteiltes - Netzwerk mit insgesamt 200 Anschlüssen in einem Studentenwohnheim. Es sind insgesamt 12 Switches involviert, die mittels LWL miteinander verbunden sind - die Trunks sind auch korrekt konfiguriert. Die IP-Adressen für die einzelnen Anschlüsse in den Zimmern werden von einem DHCP der Universität vergeben (Verbindung zur Uni mittels eines lokalen Anbieters mit einer 500 MBit Leitung). Soweit funktioniert das auch problemlos und korrekt.

Nun haben wir die einzelnen Ports für die Zimmer auf "access" gesetzt, damit die Studenten ihre eigenen Router für ein eigenes WLAN (Handy, Tablet, ...) verwenden können. Um das Netzwerk vor fremden DHCP-Servern zu schützen (und damit lahmzulegen) ist DHCP Snooping korrekt konfiguriert (funktioniert auch bereits bei den "Standard-Switches").

Blöderweise müssen dafür alle Ports auf "tagged" gesetzt sein, zumindest habe ich anders keine funktionierende Config zusammen gebracht. Einzelne Ports aus dem Management rauszunehmen ist bei den Planet-Switches, die wir verbaut haben, im Web-Interface nicht möglich.

Mein Problem ist: Ich brauche einige Ports auf "untagged". Wir haben im ganzen Haus (über die Stockwerke, und damit über mehrere Switches verteilt) so genannte "Online-Türen". Das sind spezielle Türen, die sich Online mittels einer Türsteuerungssoftware (läuft in einem Datacenter) fernsteuern lassen - das ganze auch noch standortübergreifend (haben mehrere Standorte). Im Serverraum steht ein speziell vom Datacenter konfigurierter Router (VPN Tunnel, fixe IP-Range, ...) der - in einem eigenen VLAN - die speziell benötigten IP-Adressen (inkl. Internetverbindung) an die Türsteuerungen liefert. Das funktioniert soweit auch problemlos - nur müssen diese Ports "untagged" sein, da die Hardwaresteuerung der Türen mit "tagged" nichts anfangen kann. Wenn ich an diesen Buchsen einen Laptop anstecke, kriege ich die korrekte IP + Verbindung zum Datencenter auch mit "tagged" - die verbaute Türsteuerung stellt sich dann aber leider tot.

Jetzt ist mein Problem, dass dieser "Türen"-Router natürlich für diese 5 Türen eigene, spezielle IP-Adressen vergibt - und das natürlich mit dem generellen DHCP Snooping kollidiert, da diese natürlich nicht rausgefiltert werden sollen. Ebenso wenig wie die IP-Adressen, die die Uni vergibt.

Ich suche daher nach einer Art "Converter", die ich zwischen dem "tagged"-Port am Switch und der "untagged-erwartenden"-Türsteuerung zwischenschalten kann. Meine erste Idee wäre nun, das ich einfach einen kleinen 4er Switch dazwischen schalte, der an den "tagged"-Port angeschlossen wird und selbst aber nur "untagged" weitergibt. Ich bin mir aber noch nicht sicher, ob das tatsächlich so funktioniert.

Mein letzer Backupplan wäre: Wir haben eine zweite LWL-Verkabelung durchs Haus (hab beim Bau drauf bestanden gleich eine Backup-Leitung miteinzubauen), die wir nur spleißen müssten - dann wären diese 5 Online-Türen eben in einem ganz eigenen Netzwerk. Diese Lösung würde ich aber nur ungern machen, denn was ist, wenn in 10 Jahren die Haupt-LWL-Leitung was hat? In einem denkmalgeschütztem Gebäude mal eben neue Kabel durch zu ziehen ist - obwohl sie die Kabeltrassen schön zugänglich gemacht haben) nicht optimal.

Vielleicht hat wer einen Input?

lg + Danke

 

[ctcn]

Wie sind die Türen an die Switches angebunden. Ein Netzwerkdiagramm wäre hier hilfreich. Ansonsten wäre ein zwischengeschalteter Switch ein ziemlich teures Pflaster.

Ohne Diagramm würde ich einfach vermuten, dass ein eigenes VLAN für die Türen setzt und dort das DHCP-Snooping ausschaltest. Dann konfiguriere aber als Sicherheit eine Port-Security ein. Keine Ahnung welche Geräte Du verwendest, aber bei Cisco wäre das ein "Sticky" Port-Security mit Maximaler MAC-Adressenanzahl von 1, der bei Violation in einem Port Shutdown endet.

Aber ohne Plan ist das, wie gesagt, alles nur Rätsel raten.

 

[AreWeRlyFree]

[Switches / VLAN] Von Tagged -> Untagged

Danke für den Input!

Die Türen sind in einem eigenen VLAN. Ich kann bei dem verbauten Planet-Switches das DHCP-Snooping für das Türen-Vlan nur dann abwenden, wenn ich die Ports auf "tagged" setze. Dann macht mir aber die Türsteuerung eben leider nicht mehr mit, da sie "untagged" erwartet. Ich brauche als eine Art Converter von "tagged Port". -> "untagged Port". Ich muss am Montag testen ob es funktioniert, wenn ich da einen Mini-Switch dazwischen schalte (Eingang: Tagged; Ausgang zur Türsteuerung: Untagged").

Die Türen sind ganz normal mit einem Cat6 an den 24-Port Switches in den Stockwerken angebunden. Sie sind in einem eigenen VLAN und kriegen ihre speziellen IP-Adressen vom Datencenter-Router im Serverraum. Das funktioniert auch gut.

Die Switches sind: Layer2 Stockerwerkswitch Planet PL-GS-4210 -24T2S


Gesendet von iPhone mit Tapatalk

 

[fdsonne]

Ehrlich gesagt verstehe ich das Problem noch nicht so ganz... Kann aber auch daran liegen, das mir nicht ganz klar ist, was dieser "Converter" an dem von dir beschriebenen Problem ändern sollte...

Mir stellen sich aber noch ganz paar andere Fragen bzgl. des Aufbaus des Netzes -> und daraus resultierend Fragen nach dem warum zum DHCP Snooping Feature.

Hintergrund ist eigentlich der, wie sind denn die 200 Accessports der Studenden konfiguriert?
Ich frage deshalb, weil rein zum Schutz der Personen untereinander wäre es angebracht mit 200 VLANs zu arbeiten. Heist pro Wohnung/Anschluss/Accessport ein VLAN. Warum? Weil sonst die Gefahr besteht, dass einer mit dem notwendigen Wissen im dem Bereich bspw. durch ARP-Spoofing den Datenverkehr von unwissenden Personen einfach umleitet/abgreift -> auswertet -> und dann den regulären Weg weitersendet. Das zu erkennen ist eher schwer. Vor allem wenn die ARP Einträge nicht vollends statisch sind, was ja bei verschiedensten Clients im Netz eher selten bis nie der Fall ist.
Dein Ansatz, da Dritte DHCP Server verhindern zu wollen ist ja ein Stück weit löblich, aber mehr oder weniger sinnfrei... Der größere Angriffsvektor besteht durch Abgreifen der Daten. Das ist wie alle Fenster im Haus mit Brettern vernageln, die Eingangstür aber offen stehen lassen mit nem Schild drüber -> bitte hier einbrechen!!


Um das zu unterbinden ist es also mehr als nur angebracht, die Accessports untereinander zu trennen. Das heist, jeder Accessport landet in einem eigenen VLAN. -> der DHCP, der am Ende die IPs vergibt, kann ja der von INet Anbieter da im RZ sein/bleiben. Je nach DHCP Server kann man das mit einer großen IP-Range lösen oder mit mehreren kleinen bis hin zu bspw. pro VLAN ein eigenes Subnet. (bspw. 30Bit) -> da gibts dann nur zwei IPs pro Netz, wenn so oder so Router am anderen Ende verwendet werden (NAT). Wenn zusätzlich IPv6 gesprochen wird (DualStack) wird das ggf. noch etwas interessanter. Aber selbst das lässt sich dahingehend lösen...

Vorteil liegt klar auf der Hand, wenn da einer quer schießt und sein "Wissen" anwendet, kann er das technisch bedingt NUR in seinem eigenen VLAN tun -> er KANN damit keine anderen Personen beeinflussen geschweige denn deren Traffic einsehen, abgreifen, auswerten usw.
Weiterer Vorteil -> du kannst dir die DHCP Server Absicherung sparen. Wenn nämlich der User in SEINEM VLAN da selbst nen DHCP rein stellt, geht halt der Access zum INet und Rest des Netzes nicht mehr -> Ist er ja selbst schuld.
Dazu kommt, wenn man dieses Konstrukt so wie beschrieben baut, gibst du einfach den Türen ein eigenes VLAN -> was du hinten im RZ sauber auskoppelst. Die Ports der Etagenswitches stellst du auf Access anstatt auf Trunk und gut ist. -> damit läuft deren/dessen Traffic abgetrennt vom Rest und auch da kann nix passieren.

Aus meiner Sicht müssen bei solchen Netzen aber noch andere Dinge beachtet werden, bspw. MUSS die Spanning-Tree Konfiguration sauber sein -> undenkbar wäre, wenn da einer der Personen nen Switch anklemmt und nen Loop patcht -> und dir das ganze Netzwerk stehen bleibt... Das gilt es also zu verhindern durch saubere Konfiguration.
Oder so Themen wie UDP flood/SYN flood sollte möglichst unterbunden werden um die Servicequalität für die Studenten aufrecht zu halten usw.


Der einzige Punkt, der so einem VLAN getrennten Netz im Wege steht ist der gewollte Access zwischen den Wohnungen. Sprich wenn Wohnung A mit Wohnung B Daten austauschen will/soll/muss -> hier bekommst du ein Problem, wenn du mit mehreren VLANs und dedizierten IP-Subnetzen arbeitest (wie oben die /30er Netze) -> denn dann brauchst du nen Router mit entsprechend viel Bumms um da mehrere GBit/sec Rooutingdurchsatz hinzubekommen. Bei 10 oder gar 40GBit/sec Uplinks zwischen den Etagenswitches und dem Backbone kann das recht euer werden. Eine Serverlösung (abseits von teuren Hardwareappliances) in Software mit viel CPU Power wäre da wohl das günstigste, dafür setzt es KnowHow vorraus und ist recht pflegeintensiv...

 

[AreWeRlyFree]

Hey fdsonne!

Vielen Dank für den ausführlichen Input + die tollen Tipps!

Ich hab vom ausführenden Netzwerktechniker, der uns das eingerichtet, eine schöne Skizze über das gesamte Netzwerk. Ich weiß nur noch nicht, ob es sicherheitstechnisch eine gute Idee ist, die jetzt plain ins Internet zu laden. ;-)

Was ich mit "Converter" meine: Es sind 12 Switches mit 24 Ports in den Stockwerken verteilt. Bei 8 dieser Switches hängen ausschließlich Studenten dran, da führen Cat6 Kabel direkt vom Patchpanel direkt in die Zimmer.

An 4 dieser Switches hängt an einem Port diese "Online-Tür". Diese Ports hängen in einem eigenen VLAN und bekommen die IP-Adressen nicht von der Universität, sondern von einem eigenen Router, der im Serverraum steht (VPN Tunnel zum Datencenter inklusive). Das funktioniert soweit auch wunderbar. Das Steuerungsmodul der Türsteuerung hat einen ganz normalen Netzwerkanschluss. Dieser kann, intelligenterweise, aber nur an einen Port am Switch angeschlossen werden, der "untagged" ist. Wenn ich an den Port für die Türsteuerung meinen Laptop dranhänge, bekomme ich - auch bei "tagged" - die korrekte IP sowie den Tunnel ins Datencenter (es funktioniert alles perfekt). Ich muss am 24er Switch im Stockwerk aber alle Ports "taggen", da ansonsten das "DHCP Snopping" nicht ordnungsgemäß funktioniert.

Mein einziges Problem ist also, dass ich "etwas" zwischen dem "tagged" Port am Switch und dem "untagged Türsteuerungsmodul" dazwischen schalten muss. Ich hab das mit dem Synonym "Converter" versucht. Die aus meiner Sicht günstigste Lösung, die ich am Montag mit dem Netzwerktechniker versuche, ist, dass ich einen kleinen 4er Switch dazwischen schalte, der am "tagged"-Port beim Stockwerk-Switch angeschlossen wird. dH beim neuen 4er Switch: Port 1 -> "tagged Türsteuerungs-VLAN" am 24er Switch; Port 2 -> "untagged" zum Türsteuerungsmodul.

Damit ist am "neuen" kleinen 4er Swtich natürlich kein DHCP Snooping aktiv, aber da die Türsteuerung fest im Gebäude verbaut ist würde ich das Risiko eingehen. Die Frage ist für mich nur, ob das dann funktioniert. Ich hab zwar "Softwareentwicklung" studiert, aber Netzwerktechnologie ist leider bei weitem kein Spezialgebiet von mir.

Die Idee, jeden Studentenzimmer-Anschluss in ein eigenes VLAN zu packen (womit das DHCP Snooping nach meinem Verständnis hinfällig wäre) hatte ich auch. Jedoch ist das Problem, das wir Seitens der Universität als Standort als "ein eigenes, einziges VLAN" betrachtet werden. Unser Netzwerktechniker hat mir dann - für mich schlüssig - erklärt, dass wir dann erst wieder alle im selben VLAN wären, da ich in jedem "Zimmer"-VLAN den Hauptanschluss zur Universität miteinbinden muss, um die Internetverbindung zu gewährleisten. dH ich hätte 200 VLANS, die aber gesamt gesehen wieder in einem ganzen VLAN (Seitens der Universität für unseren Standort) zusammengefasst wären. Damit wäre dann - laut dem beauftragtem Netzwerktechniker - das DHCP Snooping wieder hinfällig.

Die von dir erwähnten Schutzmethoden hat er bei den Switches soweit ich weiß aktiviert. Ich habs mir im Detail noch nicht angesehen, aber es war da bei den Switches eine Liste von ~15 Sicherungsoptionen konfiguriert. Ich werde am Montag nachfragen, ob an all das gedacht wurde.

Nein, die Bewohner sollten untereinander nichts über das Netzwerk tauschen könnten (urheberrechtliche Frage), daher hätte ich auch die Lösung mit den einzelnen VLANs präferiert. :/

Vielen, vielen Dank dass du dir so ausführlich Zeit für die Inputs genommen hast!

 

[fdsonne]

@AreWeRlyFree
Das mit dem Converter hab ich denke ich verstanden... Nur wie gesagt, mir stellt sich die Frage nach dem warum für so eine "Krücke"? Denn ich entnehme auch deiner aktuellen Aussage, dass das Problem das DHCP-Snopping ist, wenn ihr untagged Ports am Switch fahrt. Hier wäre wie oben gesagt aus meiner Sicht der richtige Weg, die Ursache zu bekämpfen, anstatt die Krücke zu bauen.
Diese Krücke würdest du wie gesagt eigentlich nicht brauchen, wenn du die Zimmer/Anschlüsse VLAN seitig trennst, da dann, wie du es ja auch bemerkt hast, das DHCP Thema außen vor bleibt...

Also wie das Problem lösen? Ich denke es gibt mehrere Ansätze... Da du sagst, Datenkommunikation untereinander ist nicht erlaubt/gewollt, wird das sogar entsprechend "einfach"...

Eine Möglichkeit wäre folgende:
Du bräuchtest um sowohl das per Room VLAN Konzept als auch dein Türproblem in den Griff zu bekommen einfach nur einen Router Das kann ein Router sein, wie ihn Jeder kennt als Hardware Appliance (er sollte allerdings im Durchsatz mindestens so viel Bumms haben, wie euer verfügbarer INet Speed im Up/Down), oder von mir aus auch ein L3 Switch mit Routingfunktionen...
Das Problem, was du dort mit dem VLAN zur Uni beschreibst ist eigentlich kein wirkliches Problem... Denn solange ihr die Switches für die Wohnungsverkablung unter eurer Fuchtel habt und dort eben die Room-VLANs beliebig anlegen könnt, gibt es da aus meiner Sicht technisch kein Hinternis. Der angesprochene Router fängt dann die Zimmer VLANs ein und gibt hinten auf seiner "public" Seite nur den Uplink zur Uni im für die Uni richtigen VLAN... -> die Türen hingegen kannst du direkt L2 bis in die Uni bringen mit deren zugewiesenen VLAN. DHCP kann der Router dann selbst spielen. Auf der Seite der Uni/des RZ müsstet ihr maximal noch eine Route mit dem von eurem Router per DHCP vergebenen Netz eintragen und bei euch als default Gateway den Router der Uni/des RZ und fertig...
Sollte in den Routingeintrag auf der Uni/RZ Seite kein Weg reinführen, könnt ihr noch ein NAT machen... Entweder ALLE IPs auf eurer internen Seite auf die selbe IP richtung Uni -> könnte ggf. eng werden mit der Portanzahl! Oder einfach 1:1, euer internes Netz in das Uni/RZ Netz.

Damit würde bei der Uni/des RZ jeglicher Traffic der Wohnungen im definierten VLAN ankommen, ihr hättet eine physische VLAN Trennung pro Anschluss/Raum, ihr hättet ne L2 Abtrennung zwischen dem Wohnheimbereich und der Uni selbst (was auch nochmal Punkte bringt/bringen kann) und ihr hättet sogar die Möglichkeit, je nach Router, Modell und Ambition bspw. da noch so Themen wie QoS zu machen. Firewallregeln/ACLs zu nutzen, Filterregeln zu definieren usw. Technisch gesehen KÖNNTE das sogar ein Transparenter Proxy sein -> der dazu noch Kontentfiltering macht.


Ihc persönlich sehe das übrigens so:
Nur weil die Uni/der RZ Betreiber sagt, das MUSS alles im selben VLAN ankommen, ist das nicht unbedingt sinnig. Für die Uni/das RZ ist es natürlich einfach, alles in einem VLAN zu haben. Für die Studenten allerdings nicht... Wie gesagt, das Thema Arp-Snooping ist ein ziemlich heißes Eisen. Denn du kannst dich davor unter Umständen gar NICHT wirkungsvoll schützen.
Was geht, statische ARP Einträge auf den Clients für den Router -> das ist aber ziemlich viel Aufwand und nicht durchführbar, vor allem nicht, wenn eure Studenten dann dort mit SoHo Routern um die Ecke kommen, die sowas gar nicht zulassen
Was noch geht, ist eben VLAN Trennung, sinnvollerweise pro Anschluss/Wohnung ein VLAN. Dann kann da wer mit Arp Paketen rumschmeißen wer will, das Paket wird nur im eigenen VLAN bleiben.
Mit einer dynamic ARP Inspection könnte man vielleicht noch ansetzen um invalide IP/MAC Zuordnung zu unterbinden, aber das muss dann die Switchtechnik auch können... Euere PL-GS-4210 -24T2S scheinen das zu können. Ob es sauber funktioniert? Kein Plan.

Was ich mich allerdings noch frage, wenn ihr die Kommunikation zwischen den Anschlüssen verhindern wollt, wie verhindert ihr das im Moment, wenn alles im selben VLAN ist und alles im selben IP Netz? -> da fällt mir nix ein, was eine derartige Trennung überhaupt ermöglicht???


EDIT: was die Netzwerkzeichnung angeht, 1:1 werden wir das sicher hier nicht brauchen. Aber skizziert, dass man grob versteht worum es geht? Wobei mir mittlerweile das Bild schon recht klar scheint, so denke ich zumindest.

 

[AreWeRlyFree]

Vielen Dank wieder einmal für die Inputs!

Ja, es ist eine echte "Krückenlösung" leider. :/ Das sinnvollste wäre, wenn die Türsteuerung einfach mit "Tags" etwas anfangen könnte. Aber auf das Hardwareupdate zu warten ist vermutlich keine gute Idee. Die "Lösung" mit einem zwischengeschaltetem 4er Switch könnte deiner Vermutung nach aber klappen?

Die Konfiguration Uni-Seitig zu adaptieren ist leider nicht ganz so einfach. :/ Das funktioniert leider nicht mit einem simplen Anruf / E-Mail, sondern setzt einen ziemlichen Verwaltungsapparat in Gang... Den ich realistischerweise sehr gerne vermeiden würde.

Derzeit sind alle Studenten im selben VLAN, dH sie können theoretisch Sachen miteinander teilen. Wir bewerben das nicht, aber alle, die technisch einigermaßen versiert sind, sehen das natürlich. Wir haben überall Gigabit-Switches verbaut, dH meine größere Sorge dass einige mit einem intensiven Datentausch das Netzwerk für andere massiv beeinträchtigen, ist zumindest daher nicht in naher Zukunft nicht zu befürchten. Für den Fall, dass jemand das massiv nutzen sollte, habe ich zur Not die Traffic-Logs - und ich kann jeden Port einem Zimmer zuordnen.

Contentfilterung oder dergleichen machen wir nicht. Uni-Seitig sind alle P2P-Netzwerke gesperrt, weitere zusätzliche Sperren machen wir nicht.

Bzgl. ARP-Snooping: Werde da am Montag auch nachfragen, ob/wie das gesichert ist.

Nur zum Verständnis: Wenn wir für die Uni ein "gesamtes VLAN" sind ist es sinnlos, wenn wir die Zimmer in eigene VLANs geben, ohne zusätzlich weitere Punkte zu erfüllen, oder? Was ich noch erklären müsste: Jeder Anschluss kriegt zuerst von der Uni eine interne IP-Adresse (10.0.x.x) zugewiesen - anschließlich muss man sich mittels PPPoE authentifizieren und erhält dann erst eine externe IP-Adresse (78.x.x.x) mit Internetzugang. Pro Account gibt es nämlich eine Volumenbeschränkung.

Zur Erklärung, warum es 3 VLANs gibt: VLAN 1 (Studenten), VLAN 3 ist das Büro-VLAN (eigener Router im Serverraum der fürs Büro 192er IPs vergibt und auch die PPPoE-Authentifizierung direkt macht), VLAN 4 ist das Türen-VLAN (auch eigener Router vom Datencenter).





Edit: Ich habe eben per Mail beim ZID der Uni nachgefragt, ob die uns tatsächlich als gesamten Standort in ein eigenes VLAN packen bzw. wie die das nun im Detail handeln. Mal schauen, was da als Antwort kommt.

 

[magicteddy]

Moin,

man muss nicht jeden Teilnehmer in ein eigenes VLan stecken um sie voneinander zu trennen, die Ports kann man auch via Port Isolation voneinander isolieren: https://www.it-bildungsnetz.de/fileadmin/media/Akademietag_2012/Private%20VLAN.pdf

Irgendwo ist in der Konfiguration ein Bock: Teilnehmer Ports sind normalerweise untagged, d.h. alle Ports zu den Teilnehmern gehen untagged aus den Switches da sonst die Endgeräte gar nichts damit anfangen könne ohne dafür konfiguriert worden zu sein. Sie unterscheiden sich, außer durch die Zugehörigkeit zu einem andern VLan nicht von den Ports für Deine Türen. Tagged Ports nimmt man für die Trunks zwischen den Switches und zu APs die darüber mehrere SSIDs sauber in mehrere VLan einbinden. Was in Dir rein grätschen kann ist die Verwendung des VLans 1. Hierin sind erst mal alle Ports Mitglieder. Kontrolliere die PVID der Tür Ports oder sniffe mit Wireshark mal an einem Türport was das raus kommt. Ich vermute da kommen Pakete aus VLan 1 und VLan 4 raus. der Port darf aber nur Pakete von VLan 4 zu sehen bekommen erst dann kann das ganze auch funktionieren.

im absoluten Notfall könntest Du einen kleinen Switch MikroTik routerboard RB260GS Preisvergleich trotz des Namens ist das Switch und kein Router dahinter hängen der dann nur die Aufgabe hat die Tagging Information zu schlucken aber das beseitigt nicht die Ursache Deines Problems.

-teddy

 

[AreWeRlyFree]

@magicteddy

Danke für den Tipp! Werde das mit Wireshark am Montag testen, das ist eine top Idee!

Die PVID der Tür-Ports sollte überall korrekt sein (VLAN 4) - hab das vor 2 Wochen bei der Installation selbst in der Webconfig aller Router auch kontrolliert. Ich teste das aber sicherheitshalber nochmals.

Das mit dem "gehen untagged raus" irritiert mich aber jetzt ehrlich gesagt jetzt. :/ Wir haben jetzt alle Ports an allen acht 24er Switches, die ausschließlich zu den Studenten gehen, getagged - und es funktioniert problemlos, sowohl für die billigen TP-Link-Router um 15€, die von den Studenten verwendet werden, als auch wenn man PC/Notebook direkt anschließt. Lediglich das top-moderne Online-Türsteuerungsmodul kommt damit nicht klar und verweigert den Dienst.

Ja, genau das wäre meine ursprüngliche Frage zur Notfall-Lösung gewesen. Er schluckt ausschließlich die Tagging-Information und das solls dann gewesen sein.

Durch die ganzen spitzen Inputs bin ich jetzt aber so verwirrt, dass ich das mit dem Netzwerktechniker am Montag lieber nochmal grundsätzlich angehe. :/

 

[fdsonne]

EDIT: Ursprünglicher Post:

Spoiler

Mhhh, PPPoE zwischen Anschluss und Uni macht die Sache komplizierter! Vielleicht sogar unmöglich -> Das müsste man sich zumindest genauer ansehen. Denn du bräuchtest dann einen Router (wie von mir oben erwähnt) der PPPoE Relay spielt. Der also die PPPoE Pakete sozusagen weiterleitet, obwohl ihn diese gar nix angehen. Das gibt es mit Sicherheit. Möglicherweise auch in Software aka mit Linux, warscheinlich sogar definitiv mit Linux. Die Frage ist dann halt, lohnt der Aufwand ggü. dem Nutzen?
Denn so wie du das beschreibst, wird PPPoE verwendet zur Authentifizierung, die Uni wird dort wohl nen PPPoE Server stehen haben an dem die Clients am anderen Ende sich Authentifizieren. Möglicherweise macht dieser Server auch die Volumenbegrenzung und das Filterring.

Das Thema ARP-Snooping ist damit zwar auch nicht vom Tisch, aber es ist zumindest etwas schwerer und setzt mehr KnowHow vorraus, als es die wischi waschi Anleitungen im Netz beschreiben Denn würde man das einfach 1:1 so machen, wird man mit den Daten wohl erstmal wenig anfangen können. Allerdings gibt das auch wieder einen ganz anderen Angriffsvektor zu dem Thema. Denn PPPoE setzt ja eine Art Discovery vorraus. Der Client sendet also ein Paket an die FF:FF:FF:FF:FF:FF und die Gegenstelle antwortet -> das sollte natürlich niemand Drittes tun dürfen/können


Aber was passiert denn, wenn du einfach mit nem Notebook an einen Accessport gehst und gar nix in Sachen PPPoE machst? Bekommst du ne IP und kannst du mit der IP irgendwas im LAN erreichen??
Ein Router oben würde ja eigentlich schon auf IP Ebene fungieren. Du brauchst eher nen "L2 Router" dafür. Also etwas, was die Broadcasts der PPPoE Discovers zum Uni PPPoE Server weiter leitet und die Rückpakete wieder sauber zur Quelle zustellt. Das macht die VLAN Trennung halt ohne Änderungen an der Uni Seite deutlich schwierig(er), wenn ich da nicht gerade irgendwas unterschlage!?

Zu deiner Frage: "Nur zum Verständnis: Wenn wir für die Uni ein "gesamtes VLAN" sind ist es sinnlos, wenn wir die Zimmer in eigene VLANs geben, ohne zusätzlich weitere Punkte zu erfüllen, oder?"
Ja, das wird dann so pauschal nix. Die VLAN Trennung heist dann, die PPPoE Pakete kommen gar nicht an. Das ist ja einer der Hintergründe, VLANs zu trennen Zwar nicht PPPoE, aber Broadcasts zu unterbinden -> brauch es für das Discover beim PPPoE, denn der Client kennt die MAC des Servers ja nicht. Das könnte man allerdings mit einer Art PPPoE Relay/Proxy umgehen. Von eigentlichen Sinn her bspw. wenn euer "Router" selbst für alle Pakete zuständig fühlt und diese 1:1 hinten ins richtige (Uni) VLAN reintütet. Dann wäre nur noch die Verbindung von diesem "Router" zur Uni direkt anfällig. Der Rest aber sauber getrennt.
Wie gesagt, der Aufwand ist aber doch schon recht groß!! Und die Kiste MUSS dann auch funktionieren, sonst geht gar nix...

Zur anderen Frage, mit den Mini Switches, ja das müsste soweit gehen. Du solltest dann vielleicht noch die anderen Ports des Mini Switches jeweils abschalten, ggf. noch ne MAC Auth am verbleibenden Port fahren mit der jeweiligen MAC der Tür, die da dran klemmt. Aber keine Ahnung, ob da Dritte an den Switch ran kommen -> wenn nicht, kann man sich das theoretisch auch sparen.

Stimmt, das mit den private VLANs und Port Isolation hab ich mal glatt gar nicht auf dem Schirm... Die Frage ist, wie funktioniert das mit seinen Switches?
Laut: https://planetechusa.com/wp-content/uploads/2016/08/GS-4210Series_UserManual.pdf kann der Switch das.
Aber das ließt sich für mich nach einer pro Switch only Geschichte. Sprich nicht Switchübergreifend, wie es die größeren Cisco Devices bspw. könn(t)en.
Pro Switch ist das allerdings in seinem Aufbau mit 8x Switches fast witzlos, wenn es zwangsweise nur EIN VLAN als Uplink zur Uni gibt. Es müssten dann mindestens 8x sein. Warum? Weil so ein Teilnehmer von Switch A) trotz protected Port über den Uplink "seines" Switches über den Core Switch Traffic der anderen sieben Switches sehen könnte...
Oder hab ich da was übersehen???

 

[magicteddy]

Ok, ich kann jetzt leider nicht testen was die TP-Links hier so alles schlucken, ich habe sie alle mit OpenWRT beglückt , aber vielleicht sind die ja nicht so wählerisch. Auch auf der Arbeit habe ich alles Teilnehmer Ports untagged, weil die Steuerungen mit tagged Paketen nichts anfangen können. Lediglich die Uplinks zwischen den Switchen und der Port zu einem Client ist tagged weil dieser mehrere (VLan) Interfaces hat und ich mir somit das Routing spare. @Home ist noch der Port zum AP tagged weil dort 4 VLans über eine Strippe in 4 SSIDs im AP enden, der Rest ist untagged. Viel Erfolg bei Fehlersuche!

 

[AreWeRlyFree]

@fdsonne

Ja genau, da sollte niemand Drittes mit einem eigenen DHCP antworten. Deswegen das DHCP Snooping, sodass ausschließlich der Uni-DHCP durchgelassen wird.

Wenn man sich am Ethernet-Zugang im Zimmer ansteckt bekommt man vom Uni-DHCP automatisch die interne 10.0.x.x IP zugewiesen. Damit kann man erstmal aber nichts machen - man kommt weder bei uns intern ins Büro-VLAN oder sonst irgendwie ins Internet. Man kommt vom VLAN1 auch nicht auf die Web-Interfaces unserer Switches (selbst wenn man die interne IP-Range wüsste, das geht nur von zwei speziellen Anschlüssen aus).

Erst mit der PPPoE-Verbindung gibts dann die 78.x.x.x IP, mit der man Internetzugang hat.

Mein Uni-Ansprechpartner hat mir um diese Uhrzeit noch geantwortet. Er hat die Detailfrage an einen Kollegen weitergeleitet, der mir Montags Bescheid gibt.

Ja, der Aufwand dürfte leider in keinem Verhältnis stehen. :/

Die verbleibenden Ports am Mini-Switch abschalten + Mac-Auth ist eine top Idee, mach ich. Zu den Serverschränken kommt man ohne Hauptschlüssel zwar nie im Leben hin (massive Sicherheitstüren), aber das ist ja kein Aufwand das zu machen - vor allem, da die Türsteuerungs-MAC sich ja nicht ändert.

- - - Updated - - -

@magicteddy DANKE!

 

[fdsonne]

Irgendwo ist in der Konfiguration ein Bock: Teilnehmer Ports sind normalerweise untagged, d.h. alle Ports zu den Teilnehmern gehen untagged aus den Switches da sonst die Endgeräte gar nichts damit anfangen könne ohne dafür konfiguriert worden zu sein. Sie unterscheiden sich, außer durch die Zugehörigkeit zu einem andern VLan nicht von den Ports für Deine Türen.

Moment, das könnte vielleicht Switchbedingt sein. Keine Ahnung, hab von den Planet Switches keine Ahnung, aber ich kenne Nortel/Avaya Switches. Bspw. die 5500er Reihe. Da kannst du einem Trunk Port wie üblich VLANs zu weisen und auch ein native VLAN. Ebenso gibt es den Schalter "DiscardUntaggedFrames". Setzt man diesen NICHT, dann landet jeglicher untagged Traffic im native VLAN. Egal ob da noch andere Tags drauf liegen oder nicht auf dem Switchport!

Bei Cisco geht das glaube ich so explizit nicht. Denn im Trunk Mode greift die Config "switchport access vlan id xxx" gar nicht. Sondern nur die "switchport trunk allowed vlan xxx"
Könnte ja sein, der Planet Switch macht das ähnlich dem Nortel?? Könnte zumindest erklären, warum es dann geht Denn wenn der Trunk auf VLAN 1 steht und das native VLAN auch 1 ist, dann ist der Gegenstelle das ziemlich hupe.
Wo ich mir nicht mehr ganz sicher bin, wenn das gleich ist, wo kommen "Rückpakete" raus, mit Tag oder ohne? Es müsste ja dann zwangsweise ohne sein...

Das den TP-Link Routern das egal sein soll, kann ich mir nicht vorstellen, warum? Es soll ja PPPoE genutzt werden bzw. wird genutzt. Damit der Client aber den PPPoE Server findet, brauch es zwangsweise doch die Discover Pakete. Die gehen via Broadcast ins Netz. An dem Paket hängt ganz sicher kein VLAN Tag mit der richtigen ID, wenn das der Router nicht explizit mitgeteilt bekommt!!!

@fdsonne

Ja genau, da sollte niemand Drittes mit einem eigenen DHCP antworten. Deswegen das DHCP Snooping, sodass ausschließlich der Uni-DHCP durchgelassen wird.

Wenn man sich am Ethernet-Zugang im Zimmer ansteckt bekommt man vom Uni-DHCP automatisch die interne 10.0.x.x IP zugewiesen. Damit kann man erstmal aber nichts machen - man kommt weder bei uns intern ins Büro-VLAN oder sonst irgendwie ins Internet. Man kommt vom VLAN1 auch nicht auf die Web-Interfaces unserer Switches (selbst wenn man die interne IP-Range wüsste, das geht nur von zwei speziellen Anschlüssen aus).

Erst mit der PPPoE-Verbindung gibts dann die 78.x.x.x IP, mit der man Internetzugang hat.

Mein Uni-Ansprechpartner hat mir um diese Uhrzeit noch geantwortet. Er hat die Detailfrage an einen Kollegen weitergeleitet, der mir Montags Bescheid gibt.

Ja, der Aufwand dürfte leider in keinem Verhältnis stehen. :/

Ok, das bestätigt meine Vermutung... Ihr nutzt sozusagen einfach nur die PPPoE Einwahl um die Clients zu authentifizieren und "tunnelt" dann in dieser Point to Point Session den INet Traffic.
Das Thema mit der Port Isolation solltest du/ihr euch definitiv nochmal anschauen, sonst bleibt halt weiter das Problem mit möglichem sniffern bzw. auswerten der Daten der Studenten untereinander. Das DHCP Thema ist dabei wie eingangs schon erwähnt eigentlich eher witzlos. PPPoE ist ja Point to Point. Also von einem Client zu einem Ziel. Rein formal KANN auch gar keiner dort DHCP spielen bzw. wenn so oder so aus dem 10er Bereich keinerlei Kommunikation möglich ist, kann euch das sogar gelinde gesagt egal sein!
Anders aber das Thema Arp-Snooping, denn das setzt halt eine Ebene drunter an und man sniffert den Spaß inkl. der PPPoE Pakete bzw. samt diesen.
Sprich geht das mit euren Switches auch Switchübergreifend oder nicht? Wenn nicht, dann wäre die einfachere Möglichkeit (neben der kompletten VLAN Trennung!) für jeden Switch ein VLAN zu nutzen -> da muss dann die Uni aber mitspielen und das auf ihrer Seite in (du sagtest 8x) VLANs auskoppeln.

 

[AreWeRlyFree]

EDIT: Ursprünglicher Post:
Stimmt, das mit den private VLANs und Port Isolation hab ich mal glatt gar nicht auf dem Schirm... Die Frage ist, wie funktioniert das mit seinen Switches?
Laut: https://planetechusa.com/wp-content/uploads/2016/08/GS-4210Series_UserManual.pdf kann der Switch das.
Aber das ließt sich für mich nach einer pro Switch only Geschichte. Sprich nicht Switchübergreifend, wie es die größeren Cisco Devices bspw. könn(t)en.
Pro Switch ist das allerdings in seinem Aufbau mit 8x Switches fast witzlos, wenn es zwangsweise nur EIN VLAN als Uplink zur Uni gibt. Es müssten dann mindestens 8x sein. Warum? Weil so ein Teilnehmer von Switch A) trotz protected Port über den Uplink "seines" Switches über den Core Switch Traffic der anderen sieben Switches sehen könnte...
Oder hab ich da was übersehen???

Habe eben in der Doku nachgesehen: Die Ports im Studenten-VLAN sind alle auf Protected. Ob das ganze aber Switchübergreifend funktioniert kann ich leider nicht beantworten.

Seitens der Uni hab ich aber eben eine interessante Antwort erhalten:
"[...] Grundsätzlich ist es für DHCP-snooping ja nur erforderlich, alle ports, hinter welchen ein DHCP-Server erreichbar ist (Uplinks der Etagenswitches, Uplink Richtung VCG, der eine Port Richtung Türsteuerungs-DHCP-Server) auf "trusted" zu setzen und alle anderen auf "untrusted" zu belassen. [...]". Ich werde morgen unseren Netzwerktechniker fragen, warum er die Ports fürs DHCP Snooping unbedingt "taggen" musste.

Zudem habe ich die Bestätigung, dass wir als "Standort" tatsächlich uniseitig als "1 VLAN" gehandhabt werden. "[...] Und ja - bei uns sind die Clients eines Hauses immer gesammelt in einem VLAN. [...]"

Vielen, vielen Dank jedenfalls für die ganzen tollen Inputs! Werde mich morgen mit dem Netzwerktechniker dran setzen und all diese Punkte + Vorschläge durchgehen.

 

[AreWeRlyFree]

So, wir haben jetzt eine ganz "simple" und eigentlich bessere Lösung gefunden. Die Türen holen sich ihre IP nicht mehr mittels DHCP vom Router, sondern haben nun fixe IP-Adressen. Damit funktioniert die Kommunikation mit dem Datencenter auch perfekt und ich wüsste nicht, was es sonst für Nachteile dieser Lösung gäbe. Das DHCP Snopping und die anderen erwähnten Sicherheitseinstellungen sind nun auch - zumindest was ich testen konnte - korrekt implementiert. Der Netzwerktechniker und ich haben versucht, von einem Studentenanschluss aus das Netzwerk lahmzulegen oder auf Daten vom Zimmernachbarn zuzugreifen (selbst wenn die unter Windows "freigegeben" sind) - keine Chance, alles gesichert.

Vielen, vielen Dank nochmals für die ganzen Inputs!