Teams/Ab18it08/Netzwerk

Die folgenden Konfigurationen und Befehle wurden im Dezember 2018 unter Debian 9.6 entworfen und getestet. Eine grafische Oberfläche (KDE) war installiert; auf einem nackten / minimalen Debian-System gibt es sonst z.B. keinen aktiven NetworkManager. ^{[Citation needed]}

Fast alle Befehle müssen als root ausgeführt werden (markiert mit dem # am Zeilenanfang).

Die für den konkreten Fall anzupassenden Parameter (also nicht buchstäblich zu übernehmenden) mit grünem Marker gekennzeichnet.

Beispiel einer Netzwerk-Toplogie mit Routing

Exkurs: Statische / klassische IP-Konfiguration aktivieren

NetworkManager (einen Dienst im Rahmen von systemd) deaktivieren

# systemctl stop NetworkManager
# systemctl disable NetworkManager

DNS: (wird "normalerweise" auch vom NetworkManager verwaltet)

# unlink /etc/resolv.conf
# echo "nameserver 10.0.0.1" > /etc/resolv.conf

Glückwunsch, jetzt (spätestens nach einem Reboot) hat der Rechner keine vom System autokonfigurierte / im Hintergrund verwaltete IP-Schnittstelle mehr.

Konfiguration für einen Router

… also für einen Netzwerk-Knoten, der Zugriff auf mindestens zwei getrennte logische Netzwerke hat und IP-Pakete zwischen ihnen vermitteln kann.

Hier: Für einen Router zwischen “Level-1-LAN” und “Level-2-LAN” in der oben gegebenen Topologieskizze.

Generell: Forwarding von IP-Paketen zwischen Netzwerkschnittstellen aktivieren (das ist per Default abgeschaltet):

# nano /etc/sysctl.conf

In der Datei folgende Einstellung suchen und das “#” am Zeilenanfang entfernen:

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

… und die geänderte System-Konfiguration neu laden:

# sysctl -p

Bezeichnungen der Netzwerk-Hardware-Schnittstelle(n) bestimmen:

ip link show

# nano /etc/network/interfaces.d/$INTERFACE

In der Datei folgende Konfiguration anlegen (generell sind die gesamten Netz-IDs und Adressen auf den konkreten Fall anzupassen!):

auto enp2s0
iface enp2s0 inet static
           address 172.16.X.254/24
auto enp2s0:0
iface enp2s0:0 inet static
           address 10.0.0.10X/8
           gateway 10.0.0.1

Die neue Konfiguration starten :

# systemctl restart networking

Anschließend muss am Hauptrouter (welcher den Zugang zum ITW Netz liefert, d.h. der Gateway-Router, in unserem Beispiel 10.0.0.1) eine Route zum internen Netz des Routers gelegt werden. Zunächst müssen wir uns dafür an dem ITW-Router einloggen und eine Route einrichten. Zunächst sollte nur eine temporäre Route gesetzt werden zu Testzwecken. Sollte diese Route nicht funktionieren ist sie nach einem Reboot nicht mehr eingetragen und das Netz wieder in den Ausgangszustand versetzt. Die folgenden Befehle sind ungeprüft und sollten zusammen mit dem Dozenten ausgeführt werden.

# ssh root@10.0.0.1
# ip route add 172.16.X.0/24 via 10.0.0.10 dev enp2s0

Konfiguration für einen Client

… also hier für einen Netzwerk-Knoten in einem privaten Netz, der selbst keine Verbindung in andere Netze hat – der aber Zugriff auf einen Router in seinem Netz hat.

Bezeichnungen der Netzwerk-Hardware-Schnittstelle(n) bestimmen:

ip link show

# nano /etc/network/interfaces.d/$INTERFACE

In der Datei folgende Konfiguration anlegen (generell sind die gesamten Netz-IDs und Adressen auf den konkreten Fall anzupassen!):

auto enp2s0
iface enp2s0 inet static
           address 172.16.X.Y/24
           gateway 172.16.X.254

Theoretisch sollte die neue Konfiguration mit dem folgenden Befehl aktiviert werden; tatsächlich war trotzdem ein Reboot nötig:

# systemctl restart networking

Konfiguration testen

ip addr show (oder kurz: ip a – IP-Adressen des Systems anzeigen)
ip route show (oder kurz: ip r – IP-Routen des System anzeigen)

ping 172.16.X.254  (Erreichbarkeit des Routers)
ping 10.0.0.10X  (Erreichbarkeit der “öffentlichen” Schnittstelle des Routers)
ping 10.0.0.1  (Erreichbarkeit des “öffentlichen” Gateways
ping 8.8.8.8  (Erreichbarkeit einer öfffentlichen IP-Adresse)
ping google.de  (Namensauflösung)
traceroute google.de  (Tatsächliches Routing ins öffentliche Internet)

Debugging

Sollte ein Ping nicht funktionieren kann man durch das Überwachen des TCP-Traffics eine Fehlerdiagnose durchgeführt werden. Vorsicht : Auch eine SSH Verbindung läuft via TCP, deshalb kann dieses Debugging nicht mit einer SSH verwendet werden.

# apt install tcpdump

Nun kann unter Angabe des Gerätes der TCP-Traffic einer Netzwerkkarte mitgeschnitten werden. Wir haben am Router eine externe und eine interne Schnittstelle.

In diesem Beispiel

extern : enp2s0:0 intern : enp2s0 (Die Bezeichnungen der Netzwerkkarte(n) können mit ip link show angezeigt werden.)

Debugging-Check

1. Auf dem Client PC einen Ping zum Gateway Router starten (ping 10.0.0.1) 2. Am Router tcpdump -i enp2s0 ausführen und schauen ob der Ping dort ankommt und eine Reply ankommt. Wenn ping dort nicht ankommt dann gibt es schon im internen Netz ohne Routing ein Problem 3. Am Router tcpdump -i enp2s0:0 ausführen und schauen ob der Ping dort ankommt und eine Reply ankommt. Wenn ping dort nicht ankommt dann gibt es im Routing ein Problem (vermutlich liegt es dann an der Routingtabelle - siehe ip r). Wenn der ping dort ankommt, aber die Antwort nicht, so liegt er vermutlich an der Routingtabelle im Gateway router (10.0.0.1).

Known-Issues:

• Trotz korrektem Routing kann der Client eines Subnetzes nicht zu einem Client eines anderen Subnetzes pingen
• Der DHCP Relay funktioniert nicht

IP-Konfiguration zur Laufzeit ändern

Routen löschen und anlegen:

# ip route del default
# ip route add default via 10.0.0.1 (Default-Route, Next Hop)
# ip route add 172.16.A.0/24 via 10.0.B.C (spezielles Netz, Next Hop)

IP-Adressen löschen und anlegen:

# ip addr del 10.0.0.101/8 dev enp2s0 (Adresse und “Device” muss angegeben werden)
# ip addr add 10.0.0.101/8 dev enp2s0

Der Befehl ip gehört zum Software-Paket “iproute2”. Er ersetzt bekannte / ältere Befehle wie z.B. ifconfig und route aus dem Paket “net-tools”.