Netzwerk-Debugging ist die Gegend, in der jedes Werkzeug dasselbe tut — mit leicht anderer Syntax. netstat wurde abgelöst von ss. dig, host, nslookup überlappen. Das route auf macOS ist nicht das route auf Linux. Nach dem Was zu fragen statt nach dem Werkzeug umgeht das ganze Problem.
1. Lauschende Ports
clai
$ clai zeige alle lauschenden TCP-Ports mit Prozessnamen→ ss -ltnpState Recv-Q Local Address:Port ProcessLISTEN 0 0.0.0.0:22 users:(("sshd",pid=812))LISTEN 0 127.0.0.1:5432 users:(("postgres",pid=1234))
2. Verbindungen zu einem Service
clai
$ clai wer ist gerade mit meinem postgres verbunden→ ss -tnp 'sport = :5432'ESTAB 10.0.1.12:54322 10.0.1.50:5432 users:(("postgres",pid=1234))
3. Warum DNS langsam ist
clai
$ clai verfolge, warum DNS für example.com langsam auflöst→ dig +trace +stats example.com;; Query time: 312 msec;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
+stats ist die Hälfte, die niemand tippt. Der Unterschied zwischen ich weiß, dass es langsam ist und ich weiß, welcher Hop langsam ist.
4. MTU prüfen
clai
$ clai prüfe MTU zu 8.8.8.8→ ping -M do -c 3 -s 1472 8.8.8.81480 bytes from 8.8.8.8: ttl=58 time=12.4 ms
-M do setzt das Don't-Fragment-Bit. Wenn 1472+8+20 = 1500 fehlschlägt, liegt deine effektive MTU unter dem Standard.
5. Routing-Tabelle — lesbar
clai
$ clai zeige die Routing-Tabelle in lesbarer Form→ ip -4 route showdefault via 10.0.0.1 dev eth0 proto dhcp src 10.0.1.1210.0.0.0/16 dev eth0 proto kernel scope link src 10.0.1.12
Siehe auch
- Prozess auf Port killen — wenn die Lauschport-Untersuchung sagt, was zu stoppen ist.
- Docker- und Kubernetes-Einzeiler — wenn das Netzwerkproblem in Containern liegt, nicht auf dem Host.