У меня несколько машин подключены к одной сети:
- А: 134.157.xxx.xxx
- Б: 134.157.гггг.гггг
- С: 134.157.zzz.zzz
Моя проблема в том, что A больше не может подключиться к C. Но:
- А может подключиться по ssh к А и Б
- B может подключиться по ssh к A, B и C
- C может подключиться по ssh к A, B и C
Вот некоторые выходные данные команды 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
Раньше это работало, файл конфигурации не менялся, перезагрузка A ничего не меняет.
Как мне провести расследование?
[редактировать]
# 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
Только команда, запущенная на B, дает вывод на C.
[/редактировать]
[вторая правка]
# 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
[/вторая правка]
[третья правка]
# 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
~$
[/третья правка]
[четвертая правка]
# 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...
[/четвертая правка]
решение1
Поскольку ICMP работает между A и C, эта проблема, скорее всего, возникает на более высоких уровнях стека. Поскольку B может достичь C, маловероятно, что она будет на уровне приложений.
Я предполагаю, что это ограничение брандмауэра.
Для проверки я бы использовал tcpdump или подобный инструмент, чтобы увидеть, какие пакеты принимаются и отправляются — начав с tcpdump на C, чтобы проверить, получает ли он пакеты от A, а затем двигаясь в обратном направлении.
решение2
Я наконец нашел проблему: маска сети была неправильной на A (255.255.255.128 вместо 255.255.255.0). Мы, вероятно, пропустили это при обновлении сети.