Teams/Ab18it08/Netzwerk: Unterschied zwischen den Versionen
imported>Hansbergner Keine Bearbeitungszusammenfassung |
K Textersetzung - „z.B.“ durch „z. B. “ |
||
(34 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
''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]].'' | |||
''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]].'' | |||
Fast alle Befehle müssen als root ausgeführt werden (markiert mit dem # am Zeilenanfang). | Fast alle Befehle müssen als root ausgeführt werden (markiert mit dem # am Zeilenanfang). | ||
Zeile 60: | Zeile 56: | ||
gateway 10.0.0.1 | 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 == | == Konfiguration für einen Client == | ||
Zeile 96: | Zeile 96: | ||
ping google.de (Namensauflösung) | ping google.de (Namensauflösung) | ||
traceroute google.de (Tatsächliches Routing ins öffentliche Internet) | traceroute google.de (Tatsächliches Routing ins öffentliche Internet) | ||
== Debugging == | |||
'''Vorbereitung''' | |||
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 | |||
Tipps: | |||
* Die Bezeichnungen der Netzwerkkarte(n) können mit <code>ip link show </code> angezeigt werden.) | |||
* tcpdump kann auch gegreppt werden, die Ausgabe dauert allerdings eine Weile; Beispiel tcpdump | grep ICMP | |||
'''Debugging-Check''' | |||
1. Auf dem Client PC einen Ping zum Gateway Router starten (ping 10.0.0.1). Kommt der ping dort an springe direkt zu Punkt 4. | |||
2. Am Router <code>tcpdump -i enp2s0</code> 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. Eine mögliche Ursache ist ein falsches Gateway am Client, eine falsche Subnetzmaske o.ä.. | |||
3. Am Router <code>tcpdump -i enp2s0:0</code> 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). | |||
4. Kommt der Ping an sollte ein neuer Ping auf 8.8.8.8 versucht werden (Google DNS). Klappt das nicht, muss es am Gateway-ITW-Router liegen, der nicht aus dem Netz kommt. Kommt der ping an sollte ein Ping auf google.de versucht werden. Klappt das nicht sollten die DNS Einstellung überprüft werden. | |||
'''Mögliche Fehlerquellen''' | |||
Client kann internen Router nicht erreichen | |||
* Der Switch verwendet VLAN und leitet nicht an die Ports weiter | |||
Client kann öffentl.Router nicht erreichen | |||
* Gateways im Router checken | |||
* Routen im Router checken | |||
* Firewall im Router checken | |||
** Aktiviere in den FW-Einstellungen : Filterung statischer Routen , Umgehe Firewall Regeln für Verkehr auf der gleichen Schnittstelle | |||
** Überprüfe NAT-Einstellungen | |||
==Known-Issues== | |||
*Der DHCP Relay funktioniert nicht | |||
== IP-Konfiguration zur Laufzeit ändern == | == IP-Konfiguration zur Laufzeit ändern == | ||
Zeile 110: | Zeile 157: | ||
# ip addr add <span style="background-color:#ccff00;">10.0.0.101/8</span> dev <span style="background-color:#ccff00;">enp2s0</span> | # ip addr add <span style="background-color:#ccff00;">10.0.0.101/8</span> dev <span style="background-color:#ccff00;">enp2s0</span> | ||
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”. | 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”. | ||
[[Kategorie:Teams]] |
Aktuelle Version vom 19. Mai 2023, 13:37 Uhr
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.
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.
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
Vorbereitung
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
Tipps:
- Die Bezeichnungen der Netzwerkkarte(n) können mit
ip link show
angezeigt werden.) - tcpdump kann auch gegreppt werden, die Ausgabe dauert allerdings eine Weile; Beispiel tcpdump | grep ICMP
Debugging-Check
1. Auf dem Client PC einen Ping zum Gateway Router starten (ping 10.0.0.1). Kommt der ping dort an springe direkt zu Punkt 4.
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. Eine mögliche Ursache ist ein falsches Gateway am Client, eine falsche Subnetzmaske o.ä..
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).
4. Kommt der Ping an sollte ein neuer Ping auf 8.8.8.8 versucht werden (Google DNS). Klappt das nicht, muss es am Gateway-ITW-Router liegen, der nicht aus dem Netz kommt. Kommt der ping an sollte ein Ping auf google.de versucht werden. Klappt das nicht sollten die DNS Einstellung überprüft werden.
Mögliche Fehlerquellen
Client kann internen Router nicht erreichen
- Der Switch verwendet VLAN und leitet nicht an die Ports weiter
Client kann öffentl.Router nicht erreichen
- Gateways im Router checken
- Routen im Router checken
- Firewall im Router checken
- Aktiviere in den FW-Einstellungen : Filterung statischer Routen , Umgehe Firewall Regeln für Verkehr auf der gleichen Schnittstelle
- Überprüfe NAT-Einstellungen
Known-Issues
- 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”.