Seite 5: Linux

Inhaltsverzeichnis

Linux

Linux bringt weitreichende Unterstützung für VLANs mit, diese ist aber in den Kernels mancher Distributionen nicht aktiviert. Die Existenz des Verzeichnisses /proc/net/vlan zeigt die 802.1Q-Unterstützung an – eventuell muss vorher das Modul 8021q geladen werden. Sowohl bei Suse 9.2, Debian-Sarge als auch bei Fedora Core 3 kommen alle nötigen Pakete mit der Distribution.

Fehlen sie, so muss man die Kernelquellen installieren und einen eigenen Kernel bauen: Zuerst passt ein make oldconfig die Quellen an die Einstellungen des laufenden Kernels an – somit funktioniert mit dem neuen Kernel alle Hardware weiter. Dann ruft man mit make xconfig oder make menuconfig das Konfigurationsskript des Kernels auf. Dabei kann es je nach Distribution vorkommen, dass einige Entwicklerpakete fehlen, die man dann nachinstallieren muss.

Im Menüpunkt "Device drivers/Networking support/Networking options" aktiviert ein Haken bei "802.1Q VLAN Support" die virtuellen Netze. Nun übersetzt ein make den Kernel und seine Module. Die Befehle make install und make modules_install kopieren den frisch übersetzten Code an die passenden Stellen im Dateisystem. Je nach Bootmanager und Distribution sind noch weitere Schritte erforderlich. Für den älteren 2.4er-Kernel bietet www.candelatech.com die offiziellen Kernel-Patches an.

Zur Konfiguration dient das Programm vconfig (Suse: vlan-xx.rpm), das ebenfalls www.candelatech zum Download anbietet. Es verwaltet die virtuellen Schnittstellen und teilt dem Kernel mit, als welche Devices er sie einblenden soll. So ordnet der Befehl

vconfig add eth0 1

das erste virtuelle Netz mit der VID 1 (für den Webserver) der Netzwerkkarte eth0 zu. Es steht dann als eth0.1 allen Linux-Programmen zur Verfügung. Da manche Switches mit der VID 1 Probleme haben, muss man eventuell die Nummerierung bei 2 beginnen. Falls mehrere Karten im PC stecken, helfen die Kommandos ifconfig, lspci und lsmod, die gewünschte Karte anhand von MAC-Adresse, PCI-ID oder geladenem Treiber zu finden.

Die IP-Adresse weisen entweder ein

ifconfig eth0.1 192.168.1.1

oder die Tools der jeweiligen Distribution der virtuellen Schnittstelle zu. Die physikalische eth0, die ungetaggte Pakete verschicken würde, bekommt keine IP zugewiesen. Ein ifconfig eth0 0.0.0.0 stellt dies sicher. Die anderen vier VLANs richten die Befehle

vconfig add eth0 2
vconfig add eth0 3
vconfig add eth0 4
vconfig add eth0 5

ein. Die Zuteilung der IP-Adressen auf dem Router geschieht auch für diese Interfaces manuell:

ifconfig eth0.2 192.168.2.1
ifconfig eth0.3 192.168.3.1
ifconfig eth0.4 192.168.4.1
ifconfig eth0.5 192.168.5.1

	Router	DSL	PC4	PC3	PC2	PC1
Server	VID1	-	-	-	-	-
PC1	VID2	-	-	-	VID2
PC2	VID2	-	-	-
PC3	VID3	-	-
PC4	VID4	-
DSL	VID5
- keine Verbindung

	Netz	Router	Clients
VLAN1	192.168.1.0/24	192.168.1.1	Webserver: 192.168.1.2
VLAN2	192.168.2.0/24	192.168.2.1	PC4:192.168.2.2
VLAN3	192.168.3.0/24	192.168.3.1	PC3:192.168.3.2
VLAN4	192.168.4.0/24	192.168.4.1	PC1:192.168.4.2, PC2:192.168.4.3
VLAN5	192.168.5.0/24	192.168.5.1	DSL-Modem: 192.168.5.2

Sobald man den Client-Rechnern und dem Webserver eine IP aus dem jeweiligen Netz zugewiesen hat, kann man mit dem Programm ping die Installation testen. Auf den Befehl (Windows-Eingabeaufforderung von PC1)

ping 192.168.4.3

sollte die Ausgabe ungefähr so aussehen:

Antwort von 192.168.4.3: Bytes=32  Zeit<1ms TTL=30

Die Gegenprobe, von PC1 zum Webserver, sollte auch dann fehlschlagen, wenn man PC1 temporär eine IP aus dem Subnetz des Servers gibt. Eine Kommunikation zwischen den Zonen und ins Internet ist mit dieser Konfiguration allerdings noch nicht möglich. Dazu fehlen noch einige Firewall- und Routing-Einstellungen auf dem Server. Da sich diese nicht von Installationen ohne VLANs unterscheidet, zeigen wir hier nur eine nicht unbedingt sichere Minimallösung. Zuerst die iptables-Regeln für den Internet-Zugang – wir gehen dabei davon aus, dass ein vorhandener DSL-Router über die IP 192.168.5.2 erreichbar ist:

iptables -P FORWARD DROP
iptables -A FORWARD -o eth0.5 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0.5 -j MASQUERADE
echo "1" > /proc/sys/net/ipv4/ip_forward
route add default gw 192.168.5.2

Mit diesen Regeln dürfen alle Clients alle Internet-Dienste nutzen. Gegenseitig erreichen sie sich jedoch nicht. In der Praxis sollte man das Regelwerk deutlich strikter halten und genau an die eigenen Bedürfnisse anpassen.

Komfortabler wird die Administration der Clients beim Einsatz eines DHCP-Servers. Dieser weist ihnen IP-, Gateway- und DNS-Adressen zu. Dafür muss man ihm lediglich mitteilen, auf welchen Schnittstellen er überhaupt auf DHCP-Anfragen lauschen soll (/etc/sysconfig/dhcpd). Für jedes der vier Netze legt ein eigener Eintrag in der Datei dhcpd.conf den IP-Bereich fest:

subnet 192.168.2.0 netmask 255.255.255.0 {
  range 192.168.2.2 192.168.2.100;
  option routers 192.168.2.1;
}

subnet 192.168.3.0 netmask 255.255.255.0 {
  range 192.168.3.2 192.168.3.100;
  option routers 192.168.3.1;
}

…