Bisher haben wir auf der Netzwerkseite nur den IPv6 Stack abgeschaltet, unsere primäre Schnittstelle hängt am Plasterouter und bekommt seine IP noch zugewiesen, die beiden anderen Schnittstellen sind noch ungenutzt.
Nun wollen wir uns darum kümmern.
Zunächst ist es notwendig das wir die mit Debian 9 eingeführten Bezeichnungen enpxxx wieder rückgängig machen auf die althergebrachten eth0, eth1, eth2…
Uns stört eigentlich weder das eine, noch das andere, aber die im nächsten Schritt beschriebene Firewallverwaltung Shorewall erwartet weiterhin die alten Bezeichnungen und weigert sich noch mit den neuen zu sprechen.
Das ist wie auf dem Dorf, es dauert immer ein bischen bis die Neuen akzeptiert werden.
gateway: /etc/exim4 #nano /etc/default/grub dazu müssen wir einen Eintrag in der Konfigurationsanweisung des Bootloaders GRUB setzen:
GRUB_CMDLINE_LINUX=““
wird auf
GRUB_CMDLINE_LINUX=“net.ifnames=0 biosdevname=0„
geändert, speichern und schliessen
gateway: /etc/exim4 #update-grub
damit erstellen wir jetzt eine neue GRUB Konfiguration
GRUB-Konfigurationsdatei wird erstellt …
Linux-Abbild gefunden: /boot/vmlinuz-4.19.0-6-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.19.0-6-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.19.0-5-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.19.0-5-amd64
erledigt
Damit wir uns nun nicht aussperren, ist vor dem notwendigen Neustart eine weitere Anpassung nötig
gateway: /etc/exim4 #nano /etc/network/interfaces
zeigt uns auch warum
# The primary network interface
allow-hotplug enp0s5
iface enp0s5 inet dhcp
nach einem Neustart wäre keine Schnittstelle enp0s5 mehr da, und wir würden ohne aktive Schnittstelle nicht umhin kommen den Monitor und die Tastatur wieder auszupacken, um uns an der Konsole ( mit dem langen Passwort ) wieder anzumelden und dort die nötigen Schritte abzuschliessen.
ein
allow-hotplug eth0
iface eth0 inet dhcp
würde nun völlig reichen um uns wieder via SSH anmelden zu können. Wir können jetzt aber auch gleich Nägel mit Köpfen machen.
In der ersten Zeile erlauben wir der ersten Schnittstelle das hotplugging, sprich, im laufenden Betrieb darf das Netzwerkkabel ein- und ausgesteckt werden.
In der zweiten Zeile bestimmen wir mit dem Parameter „inet dhcp“, das die Schnittstelle nach einem DHCP-Server im Netz fragt ( auf dem broadcast, dem Rundrufkanal ) und dessen Anweisungen befolgt.
Da wir einen Router aufbauen, ist es nicht wünschenswert von den Launen eines anderen DHCP abhängig zu sein. Wer garantiert uns denn, daß uns der Plasterouter nicht nach seinem nächsten Upgrade lieber mal eine ganz neue IP zuordnet?
Und ausserdem wollen wir vielleicht auch garnicht alle Anweisungen befolgen.
Also: ( 10.0.2.100 ist wieder nur ein Beispiel, welche Adresse auch immer Du wählst, es darf nicht die Adresse des Plasterouters ( wahrscheinlich .1 am Ende ) sein, noch darf diese Adresse bereits anderweitig in Deinem ja noch voll bestückten Heimnetz vergeben sein. Check das im Web-Login Deines Plasterouters! Dort sollten alle aktiven Geräte aufgeführt sein. )
allow-hotplug eth0
iface eth0 inet static eben kein dhcp mehr
>| address 10.0.2.100 hiervor ist ein Tabulatorabstand-keine Leerzeichen
>| netmask 255.255.255.0
>| broadcast 10.0.2.255
>| gateway 10.0.2.1unser Plasterouter
setzt unsere primäre Schnittstelle auf feste Werte, die in diesem Fall korrekt sind. Bei Dir muss das natürlich dem Adressbereich Deines Plasterouters entsprechen.
Dann wollen wir nun die beiden anderen Schnittstellen aufnehmen:
allow-hotplug eth1
iface eth1 inet static
>| address 10.0.0.1
>| netmask 255.255.255.0
>| broadcast 10.0.0.255
>| dns-domain erstes.netz
>| dns-nameservers 10.0.0.1
dns Einträge können wir schon setzen, auch wenn unser dns noch nicht läuft
allow-hotplug eth2
iface eth2 inet static
>| address 10.0.1.1
>| netmask 255.255.255.0
>| broadcast 10.0.1.255
speichern und schliessen
Jetzt sichern wir noch die Zuordnung der Schnittstellen ab, denn Debian vergibt die Namen eth0, eth1 und eth2 jetzt in der Reihenfolge in der das System beim booten die Schnittstellen erkennt, und das muss nicht immer die gleiche Reihenfolge sein, manche Hardware kann einem da nette Überraschungen bereiten.
Wir können die Zuordnung unabhängig vom Zeitpunkt der Erkennung vorgeben und erstellen dafür folgende Datei
gateway: /etc/exim4 #nano /etc/udev/rules.d/10-network.rules
und tragen folgende Zeilen ein:
SUBSYSTEM==“net“, ATTR{address}==“00:1c:42:32:6e:93″, NAME=“eth0″
SUBSYSTEM==“net“, ATTR{address}==“00:1c:42:36:ae:c8″, NAME=“eth1″
SUBSYSTEM==“net“, ATTR{address}==“00:1c:42:04:1b:04″, NAME=“eth2″
wobei die MAC-Adressen 00:1c:42:xx:xx:xx Deinen Netzwerkadaptern entsprechen müssen! ( siehe wieder ip a ). Für solche Arbeiten spricht im übrigen nichts dagegen sich auf zwei Fenstern oder Tabs des Terminals gleichzeitig am Server anzumelden. Alsdann ist auch die Zuordnung gewährleistet und ein
gateway: /etc/exim4 # reboot ist jetzt fällig
Wir verbinden uns jetzt mit der neuen IP-Adresse:
ich@meinPC: ~ # ssh [email protected]
und erhalten wieder die obligatorische Nachfrage nach der Authenzität unseres Server, bestätigen wieder mit Ja
gateway: ~ #
gateway: ~ #ip a
Das sieht gut aus, wir haben jetzt drei Netzwerksegmente oder besser Subnetze, die wir sauber voneinander trennen könnten. Soll heissen, wir könnten ganz gezielt bestimmen wer in welchem Subnetz was darf.
( eth1 und eth2 sind jetzt noch state DOWN, weil kein Kabel bzw. Geräte angeschlossen sind. Das ist das Ding mit dem allow-hotplug, schon einen Switch anzuschliessen, würde das ändern. )
Dazu muss unser Server allerdings auch routen, also weiterleiten können.
Per default macht er das nicht. Holen wir das als erstes nach:
gateway: ~ #nano /etc/sysctl.conf
wir kommentieren die Zeile
#net.ipv4.ip_forward=1
aus
net.ipv4.ip_forward=1
speichern und schliessen
Damit merkt sich unser Server diese Fähigkeit und wird sie nach einem Neustart behalten. Der Befehl sysctl -w net.ipv4.ip_forward=1ändert dies nur temporär bis zum nächsten reboot, reicht uns jetzt aber…
gateway: ~ #sysctl -w net.ipv4.ip_forward=1um nicht neu starten zu müssen
net.ipv4.ip_forward=1Bestätigung vom System
gateway: ~ #ip ro zeigt uns die Routing Tabelle
default via 10.0.2.1 dev eth0 onlink
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1 linkdown
10.0.1.0/24 dev eth2 proto kernel scope link src 10.0.1.1 linkdown
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.100
Ein einfacher Router wie dieser hier erstellt seine Routingtabelle automatisch selber, ganz gleich wie viele Netzwerkschnittstellen er hat.
Das Schema ist immer
Die default Route durch den Zusatz gateway in der /etc/network/interfaces gesetzt, und sagt:
Alles was ich nicht weiss oder kenne geht über eth0 zum Plasterouter 10.0.2.1
Dann kommen die Routen die ich kenne:
Alles ins Netz 10.0.0.0 über eth1
Alles ins Netz 10.0.1.0 über eth2
Alles ins Netz 10.0.2.0 über eth0
Vor Debian 9 hiess der zuständige Befehl route -n und hat die Routingtabelle etwas anders ausgegeben. Diesen Befehl müssten wir uns mit
apt install net-tools nachinstallieren und dann würde
gateway: ~ #route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
sowas ausgeben. Hier ist 0.0.0.0 die Defaultroute, 0.0.0.0 steht für „alles andere“
Sowohl ip als auch route sind in der Lage Routen zu erstellen oder zu löschen, lediglich die Syntax ist etwas anders.
Solange wir keine weiteren Router in unserem Heimnetz haben, die zu weiteren Subnetzen routen, müssen wir uns um die Routen aber nicht kümmern. Das erledigt Debian zuverlässig für uns.
Unser Server routet jetzt also 3 Netzwerke, die, obwohl technisch sauber getrennt, bis jetzt alle ungehindert miteinander kommunizieren dürfen.
Dem schieben wir im nächsten Kapitel dann mal einen Riegel vor und machen aus unserem Router einen Firewallrouter.
next > Shorewall