Ich habe mehrere Maschinen mit demselben Netzwerk verbunden:
- Eine: 134.157.xxx.xxx
- B: 134.157.yyy.yyy
- C: 134.157.zzz.zzz
Mein Problem ist, dass A keine Verbindung mehr zu C herstellen kann. Aber:
- A kann per SSH auf A und B zugreifen
- B kann per SSH auf A, B und C zugreifen
- C kann per SSH auf A, B und C zugreifen
Hier sind einige Befehlsausgaben von A:
~$ telnet 134.157.zzz.zzz 22
Trying 134.157.zzz.zzz...
telnet: Unable to connect to remote host: Connection timed out
~$ ping 134.157.zzz.zzz
PING 134.157.zzz.zzz (134.157.zzz.zzz) 56(84) bytes of data.
64 bytes from 134.157.zzz.zzz: icmp_seq=1 ttl=64 time=0.283 ms
64 bytes from 134.157.zzz.zzz: icmp_seq=2 ttl=64 time=0.315 ms
64 bytes from 134.157.zzz.zzz: icmp_seq=3 ttl=64 time=0.314 ms
^C
--- 134.157.zzz.zzz ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2082ms
rtt min/avg/max/mdev = 0.283/0.304/0.315/0.014 ms
~$ ssh -vvv 134.157.zzz.zzz
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "134.157.zzz.zzz" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 134.157.zzz.zzz [134.157.zzz.zzz] port 22.
debug1: connect to address 134.157.zzz.zzz port 22: Connection timed out
ssh: connect to host 134.157.zzz.zzz port 22: Connection timed out
Hat vorher schon geklappt, keine Konfigurationsdatei verändert, auch ein Neustart von A ändert nichts.
Wie soll ich das untersuchen?
[bearbeiten]
# on C
~$ tcpdump src 134.157.xxx.xxx -vv -i eno3
~$ tcpdump src 134.157.yyy.yyy -vv -i eno3
# on A
~$ ssh 134.157.zzz.zzz
# on B
~$ ssh 134.157.zzz.zzz
Nur der auf B gestartete Befehl liefert eine Ausgabe auf C.
[/bearbeiten]
[zweite Bearbeitung]
# on A
~$ tcpdump -vv -i any dst 134.157.zzz.zzz
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
12:32:18.609219 IP (tos 0x0, ttl 64, id 24010, offset 0, flags [DF], proto TCP (6), length 60)
AAA.33648 > 134.157.zzz.zzz.ssh: Flags [S], cksum 0xf9fc (correct), seq 3301194634, win 64240, options [mss 1460,sackOK,TS val 2209953097 ecr 0,nop,wscale 7], length 0
12:32:19.628185 IP (tos 0x0, ttl 64, id 24011, offset 0, flags [DF], proto TCP (6), length 60)
AAA.33648 > 134.157.zzz.zzz.ssh: Flags [S], cksum 0xf601 (correct), seq 3301194634, win 64240, options [mss 1460,sackOK,TS val 2209954116 ecr 0,nop,wscale 7], length 0
12:32:21.676188 IP (tos 0x0, ttl 64, id 24012, offset 0, flags [DF], proto TCP (6), length 60)
AAA.33648 > 134.157.zzz.zzz.ssh: Flags [S], cksum 0xee01 (correct), seq 3301194634, win 64240, options [mss 1460,sackOK,TS val 2209956164 ecr 0,nop,wscale 7], length 0
# and so on until timeout
[/zweite Bearbeitung]
[dritte Bearbeitung]
# on A
~$ arp -an # contains 134.157.zzz.zzz with correct hardware address
~$ arp -d 134.157.yyy.yyy # success
~$ arp -d 134.157.zzz.zzz # error (see below)
SIOCDARP(dontpub): Network is unreachable
# on C
~$ arp -an # does not contain 134.157.xxx.xxx
~$ arp -s 134.157.xxx.xxx aa:aa:aa:aa:aa:aa # adds it, but solves nothing
~$
[/dritte Bearbeitung]
[vierte Bearbeitung]
# After a while running
# tcpdump -vv -i any dst 134.157.zzz.zzz
# on A, I finally got
13:19:09.716711 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 134.157.zzz.zzz tell 134.157.mmm.mmm, length 46
13:23:55.162747 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 134.157.zzz.zzz tell 134.157.nnn.nnn, length 46
13:29:59.119983 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 134.157.zzz.zzz tell 134.157.nnn.nnn, length 46
# which is strange...
[/vierte Bearbeitung]
Antwort1
Da ICMP zwischen A und C arbeitet, tritt dieses Problem wahrscheinlich in den höheren Schichten des Stapels auf. Da B C erreichen kann, liegt es wahrscheinlich nicht auf der Anwendungsschicht.
Ich vermute, es handelt sich um eine Firewall-Einschränkung.
Zur Überprüfung würde ich tcpdump oder etwas Ähnliches verwenden, um zu sehen, welche Pakete empfangen und gesendet werden – beginnend mit tcpdump auf C, um zu sehen, ob es Pakete von A empfängt, und mich dann rückwärts vorarbeiten.
Antwort2
Ich habe endlich das Problem gefunden: Die Netzmaske war auf A falsch (255.255.255.128 statt 255.255.255.0). Das haben wir wahrscheinlich beim Aktualisieren des Netzwerks übersehen.