neitzels irrelevant irregular intarweb notes

I gave the May 2018 WOBlug presentation/workshop on the basics of analyzing TCP/IP network problems. After the workshop, I was asked to compile a list of the unix/linux commands I had used. For the benefit of the WOBlug audience, the rest of this blog entry will be in German.

Tip 1: DNS-Probleme aus dem Weg raeumen

DNS-Namens-Aufloesungen benoetigen bereits

1. ein ordentlich konfiguriertes /etc/resolv.conf,
2. eine ganze Menge funktionierende Internet-Erreichbarkeit,
3. ordentlich aufgesetzt Nameserver fuer die involvierten Domains.

Wenn es hier hapert, debuggt man besser direkt mit den IP-Adressen und laesst die schoenen Hostnames erst einmal aussen vor.

Viele Kommandos haben eine Option, um Namensaufloesungen zu unterdruecken und lediglich mit den numerischen Adressen zu arbeiten (deshalb oft: -n).

Erreichbarkeits-Tests

Ende-zu-Ende:

$ ping woblug.blogspot.com
PING blogspot.l.googleusercontent.com (172.217.16.161) 56(84) bytes of data.
64 bytes from fra15s11-in-f1.1e100.net (172.217.16.161): icmp_req=1 ttl=55 time=52.8 ms
64 bytes from fra15s11-in-f161.1e100.net (172.217.16.161): icmp_req=2 ttl=55 time=53.1 ms
64 bytes from fra15s11-in-f1.1e100.net (172.217.16.161): icmp_req=3 ttl=55 time=52.9 ms
^C
--- blogspot.l.googleusercontent.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 52.881/53.007/53.185/0.228 ms

Mit Pfadverfolgung:

$ traceroute woblug.blogspot.com
traceroute to woblug.blogspot.com (172.217.16.161), 30 hops max, 60 byte packets
 1  drama.marshlabs.gaertner.de (217.13.64.161)  0.379 ms  0.304 ms  0.351 ms
 2  prima-lns.gaertner.de (217.13.66.54)  46.751 ms  47.946 ms  48.845 ms
 3  skotti-vlan4.gaertner.de (217.13.66.3)  50.120 ms  50.921 ms  51.832 ms
 4  h-ea9-i.h.de.net.dtag.de (80.156.161.89)  54.274 ms  54.913 ms  56.080 ms
 5  f-ed11-i.F.DE.NET.DTAG.DE (62.154.14.102)  62.764 ms  62.737 ms  64.326 ms
 6  62.157.250.46 (62.157.250.46)  65.266 ms  55.276 ms  56.361 ms
 7  * * *
 8  209.85.240.184 (209.85.240.184)  53.618 ms 74.125.37.124 (74.125.37.124)  56.497 ms 216.239.48.44 (216.239.48.44)  57.899 ms
 9  216.239.63.255 (216.239.63.255)  57.079 ms 64.233.175.171 (64.233.175.171)  57.853 ms  58.925 ms
10  fra15s11-in-f161.1e100.net (172.217.16.161)  59.826 ms 209.85.240.113 (209.85.240.113)  61.600 ms fra15s11-in-f1.1e100.net (172.217.16.161)  62.213 ms

Tip 2: Wer lesen kann, ist klar im Vorteil

Bei Problemen genau auf den Wortlaut der Fehlermeldungen achten, die im Browser, auf der shell, oder sonstwo auftauchen:

• "Konnte Hostname nicht aufloesen" ist etwas sehr anderes als "konnte Host nicht erreichen" ist etwas sehr anderes als "Zugriff auf Seite verweigert".

• Bei einem ping kommen im Problemfall die ICMP-Antworten nicht erst vom Zielrechner, sondern schon von einem Geraet auf dem Weg dahin.

Eigenen Rechner untersuchen

Lokale Interface-Konfiguration, klassisch:

$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 02:12:04:82:82:d0  
      inet addr:217.13.64.159  Bcast:217.13.64.191  Mask:255.255.255.192
      inet6 addr: fe80::12:4ff:fe82:82d0/64 Scope:Link
      inet6 addr: 2a00:1030:100::159/64 Scope:Global
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:18060767 errors:0 dropped:0 overruns:0 frame:0
      TX packets:3587582 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:4150478964 (3.8 GiB)  TX bytes:942997151 (899.3 MiB)
      Interrupt:87 Base address:0xe000

moderner:

$ ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:12:04:82:82:d0 brd ff:ff:ff:ff:ff:ff
    inet 217.13.64.159/26 brd 217.13.64.191 scope global eth0
    inet6 2a00:1030:100::159/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::12:4ff:fe82:82d0/64 scope link 
       valid_lft forever preferred_lft forever

Achten auf:

1. Interface-Status "UP"?
2. IP-Adressen und Netzmasken bzw. CDIR-Praefixlaengen (/26).
3. error-counter

Die error-counter weisen auf Probleme mit der Verkabelung im lokalen Netz hin. Sie koennen auch gesehen werden mit:

$ netstat -i
Kernel Interface table
Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       1500 0  18062722      0      0 0       3588302      0      0      0 BMRU
lo        16436 0    244801      0      0 0        244801      0      0      0 LRU

Routen und Gateway ueberpruefen

Klassisch:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         217.13.64.161   0.0.0.0         UG        0 0          0 eth0
217.13.64.128   0.0.0.0         255.255.255.192 U         0 0          0 eth0

modern:

$ ip route list
default via 217.13.64.161 dev eth0 
217.13.64.128/26 dev eth0  proto kernel  scope link  src 217.13.64.159

Das Gateway muss im selben Adressbereich wie das eigene Interface liegen. Es muss erreichbar sein, um das restliche Internet dahinter erreichen zu koennen.

Ein lokaler ping von Arbeitsplatz zum Gateway klaert schon eine Menge Fragen:

$ ping 217.13.64.161
PING 217.13.64.161 (217.13.64.161) 56(84) bytes of data.
64 bytes from 217.13.64.161: icmp_req=1 ttl=64 time=0.523 ms
64 bytes from 217.13.64.161: icmp_req=2 ttl=64 time=0.346 ms
64 bytes from 217.13.64.161: icmp_req=3 ttl=64 time=0.354 ms
^C
--- 217.13.64.161 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.346/0.407/0.523/0.084 ms

Einen nicht-erreichbaren Nachbarn (ausgeschaltet, Kabel herausgerutscht, was auch immer) bemerkt man sofort an den Meldungen beim ping:

$ ping 217.13.64.162
PING 217.13.64.162 (217.13.64.162) 56(84) bytes of data.
From 217.13.64.159 icmp_seq=1 Destination Host Unreachable
From 217.13.64.159 icmp_seq=2 Destination Host Unreachable
From 217.13.64.159 icmp_seq=3 Destination Host Unreachable
^C
--- 217.13.64.162 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3000ms

Ausserdem ist so ein im LAN von der Bildflaeche verschwundener Rechner auch daran erkennbar, dass seine Ethernet-MAC-Adresse nicht mehr via ARP (Address Resultion Protocol) ausfindig gemacht werden kann:

Klassisch:

$ arp -an
? (217.13.64.146) at 00:1c:0f:37:c2:80 [ether] on eth0
? (217.13.64.161) at e0:91:f5:87:20:8e [ether] on eth0
? (217.13.64.179) at 00:00:a7:02:f9:fc [ether] on eth0
? (217.13.64.134) at b8:27:eb:23:87:bf [ether] on eth0
? (217.13.64.144) at 00:17:59:91:a6:40 [ether] on eth0
? (217.13.64.162) at <incomplete> on eth0

Modern:

$ ip neighbor list
fe80::d6ca:6dff:fe70:caf0 dev eth0 lladdr d4:ca:6d:70:ca:f0 router REACHABLE
2a00:1030:100::158 dev eth0 lladdr d4:ca:6d:70:ca:f0 router REACHABLE
2a00:1030:100::166 dev eth0 lladdr 00:80:48:ec:5e:9f router STALE
217.13.64.146 dev eth0 lladdr 00:1c:0f:37:c2:80 STALE
217.13.64.161 dev eth0 lladdr e0:91:f5:87:20:8e STALE
217.13.64.179 dev eth0 lladdr 00:00:a7:02:f9:fc STALE
217.13.64.134 dev eth0 lladdr b8:27:eb:23:87:bf STALE
217.13.64.144 dev eth0 lladdr 00:17:59:91:a6:40 STALE
217.13.64.162 dev eth0  FAILED

DNS

Zum Ueberpruefen der Namensaufloesung im DNS gibt es 3 Tools, die ziemlich gleichwertig sind:

1. das uralte nslookup (existiert auch auf Windows, ist aber eher umstaendlich),
2. dig (per default sehr gespraechig)
3. host (per default angenehm kompakt)

Egal, was man sich aussucht: alle drei Tools koennen alle Aspekte des DNS untersuchen, nur die Syntax ist immer anders. RTFM.

Einfache Ergebnisse / Zusammenhaenge kann man "auch so" verstehen, fuer eine echte Analyse von Fehlern im DNS benoetigt man aber echte DNS-Kenntnisse.

Wichtig: alle 3 Kommandos erlauben es, den Nameserver anzugeben, dessen Antworten einen interessieren.