VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
stillebucht
Beiträge: 31
Registriert: 30.10.2013 11:13:19

VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Beitrag von stillebucht » 16.04.2018 18:15:05

Hi,

ich betreibe einen kleinen Router/Firewall mit Debian. Dort habe ich nun eine Netzwerkschnittstelle als VLAN Trunk eingerichtet und mit einem VLAN-fähigen Switch verbunden. Das funktioniert soweit alles wunderbar, aber ich frage mich, wie man das Parent-Interface der einzelnen VLANs eigentlich idealerweise oder korrekterweise in Debian in /etc/network/interfaces konfiguriert, wenn man keinen anderen Traffic als die festgelegten VLANs darauf zulassen möchte. Das Wiki beschreibt zwar die Konfiguration einzelner VLAN-Interfaces, aber das Parent-Interface wird dort nicht erwähnt. Auf diversen Webseiten gibt es dazu unterschiedliche Hinweise, mal taucht das Parent-interface in der Konfiguration dann gar nicht mehr auf, mal wird es auf manuelle Konfiguration gesetzt oder auch eine statische Konfiguration, bei der tatsächlich auch Adressen festgelegt werden.

Mein Ziel wäre es, das Parent-Interface so zu konfigurieren, dass untagged frames (also Pakete, die keinem VLAN zugeordnet sind) von der Debian Maschine gar nicht erst angenommen werden. Auf dem VLAN Trunk will ich wirklich nur festgelegte VLANs verwenden. Der Switch sollte natürlich verhindern, dass da anderer Traffic überhaupt ankommt, aber man weiß ja nie, ob da nicht jemand ein Kabel vertauscht, usw.

Aktuell sieht meine Konfiguration so aus:

Code: Alles auswählen

allow-hotplug enp2s0
iface enp2s0 inet manual
iface enp2s0 inet6 manual
	pre-up /sbin/sysctl -w net.ipv6.conf.enp2s0.disable_ipv6=1

auto enp2s0.10
iface enp2s0.10 inet static
	address 172.18.128.1/24
	vlan-raw-device enp2s0
iface enp2s0.10 inet6 manual
	# IPv6 Konfiguration erfolgt durch den DHCPv6-Client mittels Präfix-Delegation
Wenn ich die manuelle Konfiguration des Parent-Interfaces oben entferne, funktionieren die VLANs zwar ebenfalls wie gewünscht, aber dann bekommt das Parent-Interface (enp2s0) trotzdem eine link-lokale IPv6-Addresse, die ja eigentlich nicht benötigt wird.

Daher, wie habt ihr eure VLAN Trunk-Schnittstellen konfiguriert und gibt es da so etwas wie ein "Best Practice"?

Danke!

hec_tech
Beiträge: 1093
Registriert: 28.06.2007 21:49:36
Wohnort: Wien
Kontaktdaten:

Re: VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Beitrag von hec_tech » 16.04.2018 21:40:44

Wenn du dem Switch nicht vertrauen kannst hast du ein Problem.

Ich finde deine Konfiguration eigentlich OK. Wenn du auf deiner Seite auch noch etwas deaktivieren bzw filtern willst wäre openvswitch etwas für dich.

Das ist aber für die meisten Anwendungen absoluter overkill. Bis jetzt habe ich openvswitch nur für Virtualisierung verwendet müsste aber so auch funktionieren.

stillebucht
Beiträge: 31
Registriert: 30.10.2013 11:13:19

Re: VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Beitrag von stillebucht » 16.04.2018 22:30:01

Ich vertraue dem Switch natürlich. Es geht mehr darum, dass ich grundsätzlich versuche, solche Dinge möglichst "sauber" umzusetzen und ich mich eben gefragt habe, wie das mit VLANs unter Linux und Debian idealerweise gemacht wird. Und grundsätzlich kann ein zusätliches Sicherheitsnetz ja nie schaden und sei es nur, dass man mal einen Konfigurationsfehler am Switch begangen hat. Aber ich versuhe auch nicht mit Kanonen auf Spatzen zu schießen. Wenn meine bisherige Konfiguration vernünftig genug erscheint, dann muss ich daran meinetwegen auch nichts ändern.

BenutzerGa4gooPh

Re: VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Beitrag von BenutzerGa4gooPh » 17.04.2018 12:40:04

stillebucht hat geschrieben: ↑ zum Beitrag ↑
16.04.2018 22:30:01
Ich vertraue dem Switch natürlich. Es geht mehr darum, dass ich grundsätzlich versuche, solche Dinge möglichst "sauber" umzusetzen und ich mich eben gefragt habe, wie das mit VLANs unter Linux und Debian idealerweise gemacht wird.
Du solltest berücksichtigen, wie standardgerecht (802.1q) deine Intention ist und was Billig-Switches vs. professionellen vs. proprietären Erweiterungen so tun. Bei deinem Debian-VLAN-Problem kann ich nur indirekt helfen, nutze derzeit VLANs mit Cisco und dlan-Pro WLAN-Accespoints über PowerLAN mit Ethernet-VLAN-Trunk, Debian-Hosts untagged angeschlossen.

Von (unsmarten / nicht-VLAN-fähigen) Billig-Switches habe ich gelesen, dass manche alles über den Uplink ("Trunk") weiterleiten. Auch tagged (VLAN-) Frames: Ob tagged Frames standardgerecht über Trunk weitergeleitet werden dürfen, glaube ich mal nicht, habe das aber nicht näher recherchiert.

Jedenfalls gibt es ein default native VLAN (Suchworte für Recherchen). Native besagt untagged (neben weiteren tagged VLANs). Default ist Voreinstellung, änderbar. 802.1q sieht m. E. ein native "VLAN" (untagged) bei Nutzung von VLANs vor. Wird bei Cisco benutzt für Inter-Switch-Konfiguration (Trunk-Protokoll, automatische Bekanntgabe von VLANs in Domain (proprietär?), wohl auch Spannig Tree Protocol etc.) und soll "für sich" laufen, VLAN01 nicht mal für extra/outband Managementnetz angeraten. VLAN01 kann auch tagged sein, default ist aber native/untagged. Man kann das native VLAN auf eine andere VLAN-ID (auf tagged Trunk) ändern. Ich habe aber auch nur einen Router mit integriertem Switch und daran WLAN-APs mit SSID-VLAN-Mapping für trusted WLAN und Gast-WLAN per VLAN-Trunk über Ethernet über PowerLAN.

Quintessenz:

Beschäftige dich vor der Umsetzung deines Anliegens mit der möglichst standardkonformen Anwendung des (default) native VLANs bezüglich 802.1q. Wenn du nur 1 Switch hast, m. E. unkritisch, dass du kein native (untagged) VLAN auf VLAN-Trunk verwenden möchtest. Da werden eben untagged Frames (hoffentlich) auf Trunk verworfen. Auf den anderen Ports je nach Konfig. nicht unbedingt.

Bei mehreren Switches oder notwendigem Spanning Tree Protocol evtl. Probleme mit Kommunikation der Switches untereinander. Cisco kann VLAN-Propagation über mehrere Switches, Spanning Tree Protocol pro VLAN, Lastausgleich verschiedener VLANS über pro VLAN unterschiedlich aktive "Spanning-Tree-Uplinks" zu redundanten Core-Switches möglich. Das ist aber nicht mein (unser?) kleines Heimnetz-Problem.

Aber:
Wenn du WLAN-Accesspoints mit SSID-VLAN-Mapping (Anschluss per Switch mit VLAN-Trunk zum Router/FW) betreiben möchtest, kann gut sein, dass deren Management ein native/untagged VLAN benötigt. Zumindest bei Inbetriebnahme - ohne sich selber den Management-Ast abzusägen.
Zuletzt geändert von BenutzerGa4gooPh am 17.04.2018 17:41:40, insgesamt 3-mal geändert.

dufty2
Beiträge: 1709
Registriert: 22.12.2013 16:41:16

Re: VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Beitrag von dufty2 » 17.04.2018 16:59:54

Oh, die Frage finde ich durchaus berechtigt.
Gemäß [1] kannst ja mal probieren:

Code: Alles auswählen

# iptables -A FORWARD -i enp2s0.10 -j ACCEPT 
# iptables -A FORWARD -i enp2s0 -j DROP
Ist jetzt mehr (falls es klappt ;) ) ein Workaround aber dann besser als nichts :)

[1] https://serverfault.com/questions/50504 ... with-vlans

Und falls es nicht klappt, kannst ja mal ebtables testen.

stillebucht
Beiträge: 31
Registriert: 30.10.2013 11:13:19

Re: VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Beitrag von stillebucht » 18.04.2018 13:29:10

Jana66 hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 12:40:04
Von (unsmarten / nicht-VLAN-fähigen) Billig-Switches habe ich gelesen, dass manche alles über den Uplink ("Trunk") weiterleiten. Auch tagged (VLAN-) Frames: Ob tagged Frames standardgerecht über Trunk weitergeleitet werden dürfen, glaube ich mal nicht, habe das aber nicht näher recherchiert.
Jettz bin ich verwirrt. Ist es nicht vielmehr so, dass auf einem Trunk Port Frames, die nicht zum default VLAN gehören, getaggt sein müssen, sonst könnte man sie ja am anderen Ende nicht mehr unterscheiden und wüsste nicht, welche Frames zu welchem VLAN gehören?
Jana66 hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 12:40:04
Beschäftige dich vor der Umsetzung deines Anliegens mit der möglichst standardkonformen Anwendung des (default) native VLANs bezüglich 802.1q.
Ich habe bisher nur einen Switch angeschlossen, benötige also STP nicht. Aber gibt es eine gute Referenz für eine standardkonforme Umsetzung? Der Standard selbst ist beim IEEE ja nur kostenpflichtig einsehbar.
dufty2 hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 16:59:54
Oh, die Frage finde ich durchaus berechtigt.
Gemäß [1] kannst ja mal probieren:

Code: Alles auswählen

# iptables -A FORWARD -i enp2s0.10 -j ACCEPT 
# iptables -A FORWARD -i enp2s0 -j DROP
Ich habe das bereits in ähnlicher Form so konfiguriert. Ich nutze shorewall zum Firewall-Management und habe eine Zone für das Parent-Interface mit der Default-Policy drop definiert. Bisher wurde aber auch noch keine Pakete geloggt, was ja prinzipiell auch erst mal richtig sein sollte, da der Switch so konfiguriert ist, nur bestimmte VLANs auf dem Trunk-Port weiterzuleiten. Ggf. stell ich das am Wochenende aber auch mal versuchsweise um, um zu schauen, ob iptables dann etwas protokolliert.

Benutzeravatar
cosinus
Beiträge: 3410
Registriert: 08.02.2016 13:44:11
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Bremen

Re: VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Beitrag von cosinus » 18.04.2018 14:15:18

Jana66 hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 12:40:04
Jettz bin ich verwirrt. Ist es nicht vielmehr so, dass auf einem Trunk Port Frames, die nicht zum default VLAN gehören, getaggt sein müssen, sonst könnte man sie ja am anderen Ende nicht mehr unterscheiden und wüsste nicht, welche Frames zu welchem VLAN gehören?
So ist es, sonst können die frames switchübergreifend nicht dem richtigen VLAN zugeordnet werden. Wir haben nur zwei VLANs, das default VLAN ist untagged, das andere natürlich tagged aber nur auf den Trunkports. Und über den Trunkport gehen natürlich alle frames.

BenutzerGa4gooPh

Re: VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Beitrag von BenutzerGa4gooPh » 19.04.2018 07:37:57

stillebucht hat geschrieben: ↑ zum Beitrag ↑
18.04.2018 13:29:10
Jana66 hat geschrieben: ↑ zum Beitrag ↑
Di 17. Apr 2018, 12:40
Von (unsmarten / nicht-VLAN-fähigen) Billig-Switches habe ich gelesen, dass manche alles über den Uplink ("Trunk") weiterleiten. Auch tagged (VLAN-) Frames: Ob tagged Frames standardgerecht über Trunk weitergeleitet werden dürfen, glaube ich mal nicht, habe das aber nicht näher recherchiert.

Jetz bin ich verwirrt. Ist es nicht vielmehr so, dass auf einem Trunk Port Frames, die nicht zum default VLAN gehören, getaggt sein müssen, sonst könnte man sie ja am anderen Ende nicht mehr unterscheiden und wüsste nicht, welche Frames zu welchem VLAN gehören?
Die "unsmarten" Switches, die ich meinte, sind nicht VLAN-fähig, deshalb "unsmart". Blöde Handelsbezeichnung "Smart-Switch". Manche der "unsmarten" Switches forwarden wohl auch getaggte Frames (größer als Ethernet wegen VLAN-ID). Ein daran angeschlossener weiterer aber VLAN-fähiger "Smart-Switch" könnte somit Tags auswerten und entsprechend seiner Konfiguration korrekt zuordnen. K. A. ob das Weiterleiten nach 802.1q getaggter Frames durch nicht-VLAN-fähige (Billig-) Switches standardgerecht ist. So wegen Sniffing.
stillebucht hat geschrieben: ↑ zum Beitrag ↑
18.04.2018 13:29:10
Jana66 hat geschrieben: ↑ zum Beitrag ↑
Di 17. Apr 2018, 12:40
Beschäftige dich vor der Umsetzung deines Anliegens mit der möglichst standardkonformen Anwendung des (default) native VLANs bezüglich 802.1q.

Ich habe bisher nur einen Switch angeschlossen, benötige also STP nicht. Aber gibt es eine gute Referenz für eine standardkonforme Umsetzung? Der Standard selbst ist beim IEEE ja nur kostenpflichtig einsehbar.
Wenn ein ungetagtes native VLAN für Manangement und Hosts nicht notwendig ist, tagge doch einfach VLAN01 auf dem Trunk. Damit hast du kein native VLAN. Das native VLAN benötigt man nur für Hosts am Trunk, die keine VLANs verstehen. VLAN01 dient der Kommunikation zwischen Switches und wird manchmal auch für Management derer verwendet. Cisco rät ab, VLAN01 für Management zu nutzen. Also wenn du VLAN01 gar nicht brauchst (nur 1 Switch, Switch Management über anderes/getagtes VLAN, somit keine "Hosts" am Trunk) kannst du das auch weglassen.

Andere Hersteller sehen das wohl anders als Cisco:
Meinen beiden PowerLAN-WLAN-APs (devolo, dlan) haben je 2 Ethernetanschlüsse für Hosts/PCs und 2 SSIDS auf 2 VLANs gemappt. Für Hosts mit Ethernet am remote Adapter muss ich ein zusätzliches native VLAN benutzen, der VLAN-Trunk wird über PowerLAN "durchgereicht". Der andere Adapter ist per 802.1q-Trunk mit dem Router verbunden. Leider ist das native VLAN auch das Management-VLAN der APs. Hosts / Produktivnetz und Managementnetz der Netzwerkkomponenten (Server) sollte man eigentlich mittels unterschiedlicher VLANs trennen.

Vielleicht habe ich dich auch mit dem native VLAN bissel durcheinander gebracht, sorry. Kurze Erklärung von anderer Seite: http://etherealmind.com/basics-cisco-ios-native-vlans/
Zu Kommentaren: CDP ist Cisco Discovery Protocol, da sieht man benachbarte Netzwerkkomponenten von Cisco, sogar für Linux: http://lcdpd.sourceforge.net/

dufty2
Beiträge: 1709
Registriert: 22.12.2013 16:41:16

Re: VLAN/802.1Q: Korrekte Konfiguration des Parent-Interface in Debian?

Beitrag von dufty2 » 19.04.2018 22:20:51

Eine Möglichkeit, ohne iptables/ebtables oder openvswitch auszukommen, wäre evtl. eine sogenannte
vlan-aware bridge 'br0' einzurichten und dann dem 'native VLAN'
br0 1 PVID Egress Untagged
eine andere Nummer zu verpassen (um den unge-tagged-ten traffic zu blackhole-n).
Frägt sich dann, wie man dem Teil noch eine IP verpassen kann?
Reicht es, der Bridge eine zu geben oder dem Port (geht das dann überhaupt noch?) oder muss man diese "1-Port-Bridge" mit einem dummy-Interface erweitern?
Fragen über Fragen ;)

Antworten