Da ich mir für mein Proxmox Cluster einen 10 GBit/s MikroTik Switch zugelegt habe, gehts nun um die Konfiguration der VLANs.
Der neue Switch wird als Uplink mit dem bisherigen Zyxel GS1910 Core Switch verbunden.
Inhalt
Ausgangslage
Zur Ausgangslage gibt es den Zyxel GS1910 Core Switch (nachfolgend „switch1“ genannt) und den neuen Mikrotik Switch CRS312-4C+8XG („switch2“).
Einen Teil der Portbelegung auf switch1 ist:
| 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | 22 | 24 |
| Admin Workstation | |||||||||||
| 1 | 3 | 5 | 7 | 9 | 11 | 13 | 15 | 17 | 19 | 21 | 23 |
| pfSense Gateway MGMT | pfSense Gateway LAN | server1 | Uplink switch2 auf Port T4 (combo4) |
Auf switch1 sind folgende VLANs konfiguriert:
- Port 1: VLANs 1 (MGMT) + 300 (SERVER) – PVID 1, Untag_pvid
- Port 13: VLAN 100 (LAN) – PVID 100, Untag_pvid
- Port 15: VLAN 300 (SERVER) – PVID 300, Untag_pvid
- Port 19: VLANs 1 (MGMT) + VLAN 100 (LAN) + VLAN 300 (SERVER) – PVID 100, Untag_pvid
- Port 22: VLAN 100 (LAN) – PVID 100, Untag_pvid
Die VLANs haben die folgenden Netze:
- VLAN 1, MGMT, 192.168.0.0/24
- VLAN 100, LAN, 192.168.1.0/24
- VLAN 300, SERVER,192.168.3.0/24
Die folgenden Geräte hängen an den Ports:
- Port 1: pfSense Gateway MGMT-Port, 192.168.0.1/24 (+VLAN 300, 10.1.10.1)
- Port 13: pfSense Gateway LAN-Port, 192.168.1.1/24
- Port 15: Server server1 SERVER-Port, 192.168.3.10/24
- Port 19: Uplink zu switch2 auf Port T4 (combo4)
- Port 22: Meine Admin Workstation, 192.168.1.40/24
Auf dem GS1910 Switch (switch1) funktioniert alles:
- Der Server server1 kann sein Gateway auf 192.168.3.1 pingen
- Ich kann von meiner Admin Workstation den 192.168.3.40 pingen
Das Ziel ist nun den Mikrotik Switch so zu konfigurieren, dass die VLANs ebenfalls genutzt werden können.
Dazu wird der Server „server1“ umgesteckt von Port 15 auf switch1 zum Port 5 (ether5) auf switch2.
Konfiguration des Mikrotik Switches
Tipp: In der Mikrotik CLI kann man durch drücken von CTRL+X den „SAFE mode“ aktivieren.
Alles was man dann macht kann zum Schluss durch drücken von CTRL+D wieder rückgängig gemacht werden. Oder, sollte man ganz die Verbindung zum Switch verlieren, wird alles nach ca. 10 Sekunden automatisch wieder rückgängig gemacht.
Management-IP für den Switch
Der Mikrotik Switch hat einen speziellen „MGMT/Console“ Port, welcher intern auf „ether9“ liegt.
Damit wir den Switch später im MGMT-Netz (VLAN 1) auschliesslich auf dem speziellen „MGMT/Console“ Port und unter einer eigenen IP erreichen, erstellen wir ein virtuelles Interface auf der Bridge.
# Interface erstellen
/interface list add name=OOB-MGMT comment="Local-Console Port - ether9 only"
# Den MGMT Port (ether9) zum OOB-MGMT Interface hinzufügen
/interface list member add interface=ether9 list=OOB-MGMT
# Discovery nur noch auf dem MGMT-Port erreichbar machen
/ip neighbor discovery-settings set discover-interface-list=OOB-MGMT
# Nur auf Ports in der Liste 'OOB-MGMT' darf WinBox genutzt werden
/tool mac-server set allowed-interface-list=OOB-MGMT
/tool mac-server mac-winbox set allowed-interface-list=OOB-MGMT
# Dem Management Interface eine IP zuweisen
/ip address add address=192.168.0.6/24 comment="Dedicated MGMT ether9" interface=ether9 network=192.168.0.0
# DHCP Client auf dem Switch deaktivieren
/ip dhcp-client add disabled=yes interface=bridge
# Namen vergeben
/system identity set name=switch2
# Uhr einstellen
/system clock set time-zone-name=Europe/ZurichZum Schluss sollte in der CLI noch geprüft werden, ob ether9 wirklich NICHT in der Bridge ist (denn nur dann bleibt er vom Filtering unberührt):
/interface bridge port print where interface=ether9
Wenn hier kein Ergebnis kommt: Perfekt! ether9 ist eigenständig und sicher.
Interface Listen
Als logische Gruppierung für die Sicherheit macht es Sinn einzelne Portgruppen in Listen zu verwalten.
Diese Listen sind Container. Sie enthalten keine Daten, sondern dienen als „Tags“ für die Ports.
MikroTik hat eine eingebaute Liste namens *static. Dort landet automatisch alles, was kein dynamisches Interface (wie ein VPN-Tunnel oder ein dynamisches VLAN) ist. In der Praxis sind aber die selbst erstellten Listen (LAN, UPLINK, OOB-MGMT) viel wichtiger.
Empfohlene Strategie für den Switch:
| Liste | Inhalt (Member) | Zweck |
| LAN | Alle Access-Ports (ether1-5) | Standard-Traffic, Erreichbarkeit für Clients. |
| UPLINK | Der Uplink (combo4) | Identifikation, wo das „Internet“ herkommt. |
| OOB-MGMT | Nur Management-Konsole | Extrem wichtig: Nur hier ist WinBox/SSH Zugriff erlaubt. |
Die Port-Grundlagen (PVIDs)
Wir definieren zuerst, welches VLAN an welchem Port „ungetaggt“ ankommt. Das ist die Eingangslogik.
- Uplink (combo4): PVID 100 (da der Zyxel das LAN untagged schickt).
- Server (ether5): PVID 300 (für den SERVER-Traffic).
/interface bridge port
set [find interface=combo4] pvid=100
set [find interface=ether5] pvid=300Die VLAN-Tabelle (Egress-Logik)
Jetzt legen wir fest, wie die Pakete den Switch wieder verlassen. Hier verknüpfen wir die „Tagged“ und „Untagged“ Ports.
/interface bridge vlan
# VLAN 100: Untagged am Uplink
add bridge=bridge untagged=combo4 vlan-ids=100
# VLAN 300: Tagged am Uplink, Untagged zum Server
add bridge=bridge tagged=combo4 untagged=ether5 vlan-ids=300Zusätzliche Sicherheitseinstellungen
Mittels frame-types kann für jeden Port definiert werden welche Art von Traffic (getaggt oder ungetaggt) überhaupt in die Bridge eintreten darf:
| Wert | Bedeutung |
|---|---|
admit-all (Default) | Der Port akzeptiert alles. Pakete ohne Tag (untagged) landen im VLAN der pvid. Pakete mit einem Tag (z.B. VLAN 100) werden verarbeitet, wenn das VLAN auf dem Port erlaubt ist. |
admit-only-untagged | Der Port akzeptiert nur Pakete ohne VLAN-Tag. Wenn ein Gerät versucht, selbst getaggte Pakete zu senden, werden diese sofort verworfen. |
admit-only-vlan-tagged | Der Port akzeptiert nur Pakete, die bereits einen VLAN-Tag haben. Typisch für Uplinks/Trunks zu anderen Switchen. |
Für Access-Ports (Endgeräte) macht es Sinn das VLAN tagging vom Client zu verbieten.
Es ist eine Best Practice für die Netzwerksicherheit:
- Schutz vor VLAN-Hopping: Ein Angreifer könnte versuchen, eigene VLAN-Tags zu senden, um in andere Netze zu gelangen. Mit
admit-only-untaggedwerden solche Versuche einfach ignoriert. - Sauberkeit: Es stellt sicher, dass ein Port genau das tut, wofür er gedacht ist. Ein IPMI-Port oder ein Büro-LAN-Port sollte niemals getaggten Traffic von einem Endgerät erhalten.
Achtung: Für deinen Trunk-Port (z.B. combo4), über den mehrere VLANs getaggt reinkommen, darf man das nicht setzen. Dort muss entweder admit-all oder admit-only-vlan-tagged stehen.
Auf der Konsole findet sich diese Einstellung unter /interface bridge port:
Beispiel für ether5 (Server Port):
/interface bridge port set [find interface=ether5] frame-types=admit-only-untaggedBeispiel für combo4 (Uplink Port):
# Default, muss nicht gesetzt werden wenn zuvor nicht verändert
/interface bridge port set [find interface=combo4] frame-types=admit-allDas „Scharfschalten“ (VLAN Filtering)
Bis hierhin hat der Switch die Regeln zwar gespeichert, wendet sie aber noch nicht an. Sobald wir diesen Befehl absetzen, wird die VLAN-Logik in den Switch-Chip geschrieben.
Tipp: Nutze hierfür am besten weiterhin den Safe Mode (
CTRL+X), falls du noch über einen betroffenen Port verbunden bist.
/interface bridge set bridge vlan-filtering=yes
