Netzwerksegmentierung mit VLANs richtig umsetzen: der Fahrplan, den ich nach drei verkorksten Projekten endlich habe
Ein Kunde rief mich an einem Dienstag an. Verschlüsselte Dateien auf dem Fileserver, drei Workstations ebenfalls betroffen, ein Notebook aus der Marketingabteilung als Patient null. Der Angreifer war nicht durch die Firewall gekommen — er hatte sich über eine einzelne ungepatchte Maschine im selben Subnetz lateral weiterbewegt, bis er beim Fileserver angekommen war. Ein VLAN hätte das nicht verhindert. Aber ohne Segmentierung hatte er freie Bahn über alle Systeme, die sich per Broadcast erreichen konnten.
Genau deshalb geht es bei Netzwerksegmentierung mit VLANs nicht um Technik-Fetischismus. Es geht darum, wie viel Bewegungsspielraum ein Angreifer bekommt, wenn er einmal drin ist. Und es geht darum, dass ein schlecht aufgebautes VLAN-Konzept mehr Arbeit macht als es Nutzen bringt — das habe ich selbst auf die harte Tour gelernt.
Wichtige Erkenntnisse
- VLANs trennen Netze logisch auf Layer 2, ersetzen aber keine Firewall — Routing zwischen Segmenten muss aktiv gefiltert werden.
- In der Praxis bewähren sich 5 bis 7 VLANs für ein typisches mittelständisches Netz: Clients, Server, Management, Gäste, DMZ, VoIP, ggf. IoT.
- Ein Trunk-Port trägt mehrere VLANs über eine Leitung, markiert per IEEE 802.1Q. Eine falsche native VLAN-Zuordnung ist eine der häufigsten Fehlerquellen.
- Die PVID bestimmt, in welches VLAN ein ungetaggtes Frame beim Eintritt in den Port fällt — Access-Ports haben genau eine, Trunk-Ports oft eine andere.
- Zwei VLANs verbinden heißt routen, nicht brücken. Wer sie trotzdem per Bridge koppelt, hat die Segmentierung faktisch aufgehoben.
- Ohne zentrale Dokumentation der VLAN-IDs und IP-Bereiche wird aus dem Konzept binnen zwei Jahren ein Flickenteppich.
Warum VLAN einrichten, wenn es doch auch ein zweiter Switch tut?
Die Frage kommt in fast jedem Projekt. Zwei Switches, zwei Netze, fertig — klingt billiger. Stimmt nur kurzfristig.
Der entscheidende Punkt: Ein VLAN ist eine logische Grenze auf Schicht 2. Sie besteht unabhängig davon, an welchem Port ein Gerät hängt. Wer sein Notebook umsteckt, bleibt im selben Segment — sofern die Portkonfiguration das vorsieht. Physische Trennung über separate Switches dagegen kostet Ports, Kabel, Patchfelder und vor allem Zeit, wenn ein Team umzieht und plötzlich im falschen Netz landet.
Der zweite Grund ist der Angriffspfad. Ein klassisches flaches Netz mit einem einzigen /24 erlaubt jedem kompromittierten Gerät, direkt mit jedem anderen zu sprechen. Das ist der Modus, in dem Ransomware-Kampagnen ihre beste Trefferquote erzielen. Segmentierung zwingt den Angreifer, zwischen den Segmenten erneut zu arbeiten — und schafft die Stellen, an denen Monitoring anspringt. Nicht weil das Netz sicher ist, sondern weil es laut wird, wenn jemand durch soll, der dort nicht hingehört.
VLAN-Segmentierung oder gleich Firewall?
Beides. Wer nur VLANs baut und zwischen ihnen einen L3-Switch ohne Filter routet, hat sich eine schöne logische Struktur geschaffen und keinerlei Sicherheitsgewinn. Der Angreifer im Client-VLAN kann den Fileserver im Server-VLAN weiterhin direkt erreichen, solange keine Regel das unterbindet.
Meine Faustregel: VLANs ordnen. Firewall-Regeln entscheiden. Ein oder zwei VLANs ohne Regelwerk dazwischen sind ein Organisationsgewinn und ein Sicherheitsverlust zugleich.
VLAN Trunk: warum die meisten Fehler hier passieren
Ein Trunk-Port überträgt Frames mehrerer VLANs über eine Leitung. Damit der Empfänger weiß, wohin ein Frame gehört, wird ein 4-Byte-Tag nach IEEE 802.1Q eingefügt — darin steht unter anderem die VLAN-ID.
Zwei Dinge müssen auf beiden Seiten übereinstimmen, sonst funktioniert es nicht:
- Die VLAN-ID existiert auf beiden Switches — nicht nur auf dem einen.
- Der native VLAN (das ungetaggte VLAN auf dem Trunk) ist auf beiden Seiten identisch.
Punkt zwei wird regelmäßig vergessen. Beide Switches sind meist auf VLAN 1 als native konfiguriert. Wer das ändert — was ich aus Sicherheitsgründen empfehle, weil VLAN 1 oft unnötig weit offen ist — muss es auf beiden Seiten gleichzeitig tun. Sonst landen ungetaggte Frames im falschen Netz und das Debugging kann einen halben Nachmittag kosten. Ich spreche aus Erfahrung: einmal war der Fehler ein vergessener Port auf einem Access-Switch, den niemand mehr auf dem Radar hatte.
Welche Rolle spielt die PVID?
Die PVID (Port VLAN ID) legt fest, in welches VLAN ungetaggte Frames eintreten, wenn sie an einem Port ankommen. An einem Access-Port ist das eindeutig: genau ein VLAN, und der Endgerätestecker weiß nichts von VLANs. An einem Trunk-Port ist die PVID das native VLAN.
Wichtig für die Praxis: Die PVID hat nichts mit der VLAN-ID im Tag zu tun. Ein Frame kann auf einem Access-Port mit PVID 20 eintreffen und ungetaggt weiterlaufen — solange es innerhalb desselben VLANs bleibt.
VLAN herausfinden: wie Sie im Bestand überhaupt sehen, was läuft
In gewachsenen Netzen ist das ein eigenes Projekt. Drei Wege, die sich in der Praxis bewährt haben:
- Switch-Administration prüfen. Auf jedem verwalteten Switch zeigt die VLAN-Übersicht (meist
show vlan,show vlan briefoder ein Webinterface-Punkt) die konfigurierten IDs und ihre Port-Zuordnungen. - LLDP einsehen. Der Link Layer Discovery Protocol-Report zeigt, was der Nachbar-Switch über sich preisgibt — inklusive VLAN-Informationen, wenn diese mitgesendet werden.
- Verhalten testen. Ein Rechner in ein anderes Segment umstecken und schauen, ob er noch DHCP bekommt und welche IP er erhält. Das ist der pragmatischste Weg, wenn die Dokumentation fehlt.
Der letzte Punkt klingt primitiv, ist aber oft der einzige, der wirklich zeigt, was tatsächlich passiert statt was konfiguriert sein sollte.
Wie viele VLANs brauchen Sie wirklich?
Die Frage, die in der Vorbereitung fast nie gestellt wird, obwohl sie den ganzen Aufwand bestimmt. Zu wenige VLANs bringen keinen Sicherheitsgewinn. Zu viele machen jede Änderung zur Zeremonie.
| Segment | Zweck | Typische Fallen |
|---|---|---|
| Client | Arbeitsplätze, Drucker, Peripherie | Drucker oft vergessen — sind eigenes Risiko |
| Server | Applikationen, Fileservices, Datenbanken | Zu offen konfiguriert, weil Admins Zugriff brauchen |
| Management | Switch- und iLO/IPMI-Zugänge | Viel zu oft im Client-Netz |
| Gäste / WLAN-Gast | Fremdgeräte ohne Unternehmenszugriff | Manchmal nur per Subnetz getrennt, nicht per VLAN |
| DMZ | Öffentlich erreichbare Dienste | Ohne klare Firewall-Regeln nahezu wertlos |
| VoIP | Telefonie | QoS ohne VLAN kaum sauber machbar |
| IoT / OT | Kameras, Sensoren, Steuerungen | Immer wieder mitverwaltet wie Clients |
Für ein mittelständisches Netz mit 50 bis 300 Endpunkten sind fünf bis sieben VLANs ein sinnvoller Ausgangspunkt. Alles darüber lohnt sich erst, wenn ein konkreter Grund da ist — getrennte Abteilungen mit unterschiedlichen Compliance-Anforderungen, Mandantentrennung, oder eine Produktionsumgebung, die nicht ins Büronetz darf.
Zwei VLANs verbinden: routen ja, brücken nein
Wenn zwei Segmente miteinander kommunizieren sollen, brauchen Sie ein Gerät auf Layer 3: einen Router, einen L3-Switch oder eine Firewall. Jedes dieser Geräte bekommt eine Schnittstelle pro VLAN und leitet zwischen ihnen weiter.
Was Sie nicht tun sollten: die beiden VLANs über eine Bridge koppeln oder einen Server mit zwei Interfaces als Brücke konfigurieren. Damit heben Sie die Segmentierung auf — die Broadcast-Domänen verschmelzen, und Sie haben den Aufwand ohne den Nutzen.
Realistischer Kompromiss in der Praxis: ein L3-Switch mit ACLs. Er routet zwischen Client- und Server-VLAN, aber nur für die Ports, die tatsächlich gebraucht werden. Beim Kunden aus meinem Eingangsbeispiel hätte eine einzige ACL zwischen Client- und Server-VLAN den Dateiserver-Zugriff auf SMB beschränkt — der Angreifer hätte von der Workstation aus nicht die Datenbank im selben Segment erreicht.
Und was ist mit VLAN-Trunking über WLAN?
Funktioniert technisch — WLAN-Controller können VLANs auf SSIDs mappen — aber nur, wenn die gesamte Kette vom Access Point über den Controller bis zum Uplink sauber getaggt ist. Ein falsch konfigurierter AP-Port bringt schnell das Gastnetz ins interne VLAN. Wenn ich das einrichte, teste ich grundsätzlich mit einem frisch aufgesetzten Client pro SSID und prüfe die erhaltene IP, bevor irgendjemand produktiv arbeitet.
Die Reihenfolge, in der Sie das Projekt wirklich angehen sollten
Meine ersten zwei VLAN-Rollouts habe ich rückwärts gemacht. Erst VLANs konfiguriert, dann überlegt, welche Geräte wohin gehören, dann festgestellt, dass die Firewall-Regeln fehlten, dann zwei Nächte durchgearbeitet. Heute mache ich es so:
- Ist-Aufnahme. Welche Geräte, welche Dienste, welche Abhängigkeiten. Papier und Bleistift reichen.
- Segmentplan. Welche VLAN-IDs, welche IP-Bereiche, welches Gateway, welcher DHCP-Server. Diese Liste ist das eigentliche Arbeitsergebnis.
- Regelwerk. Welche Kommunikation zwischen den Segmenten ist erlaubt — explizit, mit Ports und Richtung.
- Testaufbau. VLANs auf einem einzelnen Switch mit zwei Testclients. Ohne Produktivberührung.
- Rollout in Wellen. Nicht alles auf einmal. Erst das Gästenetz, dann Management, dann Server, dann Clients.
- Dokumentation. Kein Wiki ohne Netzplan. Sonst ist in zwei Jahren der nächste Kollege genauso blind wie Sie am Anfang.
Punkt drei ist der, an dem die meisten Projekte scheitern — nicht an der Technik, sondern daran, dass niemand die Zeit investiert, die erlaubten Pfade aufzuschreiben. Wer die Regeln erst während des Rollouts ausdenkt, baut sich selbst eine Baustelle.
Am Ende bleibt ein Gedanke, der mich seit jenem Dienstagmorgen nicht loslässt: Der Vorfall wäre nicht verhindert worden, wenn das Netz segmentiert gewesen wäre. Aber der Angreifer wäre auf einem anderen Weg unterwegs gewesen — sichtbarer, langsamer, mit mehr Gelegenheiten für die Logs, Alarm zu schlagen. Genau das ist der eigentliche Wert von VLAN-Segmentierung. Sie macht das Netz nicht sicher. Sie macht es ehrlich.
