ssh no puede establecer conexión

ssh no puede establecer conexión

Tengo varias máquinas conectadas en la misma red:

  • R: 134.157.xxx.xxx
  • B: 134.157.aaa.aaa
  • C: 134.157.zzz.zzz

Mi problema es que A ya no puede conectarse a C. Pero:

  • A puede enviar ssh a A y B
  • B puede enviar ssh a A, B y C
  • C puede enviar ssh a A, B y C

Aquí hay algunas salidas de comandos de 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

Ya funcionó antes, no se cambió ningún archivo de configuración, reiniciar A no cambia nada.

¿Cómo debo investigar?

[editar]

# 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

Sólo el comando iniciado en B da una salida en C.

[/editar]

[segunda edición]

# 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

[/segunda edición]

[tercera edición]

# 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
~$ 

[/tercera edición]

[cuarta edición]

# 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...

[/cuarta edición]

Respuesta1

Como ICMP funciona entre A y C, es probable que este problema ocurra en las capas superiores de la pila. Como B puede llegar a C, es poco probable que esté en la capa de aplicación.

Supongo que es una restricción del firewall.

Para verificar esto, usaría tcpdump o similar para ver qué paquetes se reciben y envían; comenzando con tcpdump en C para ver si recibe paquetes de A y luego trabajando hacia atrás.

Respuesta2

Finalmente encontré el problema: la máscara de red era incorrecta en A (255.255.255.128 en lugar de 255.255.255.0). Probablemente nos perdimos esto al actualizar la red.

información relacionada