SSH funciona sobre IPv6, mas não sobre IPv4

Estou configurando um sistema Linux incorporado e acessando-o via SSH para fins de desenvolvimento. Configurei um endereço IP estático e um servidor Dropbear SSH, e ambos parecem estar funcionando na maior parte do tempo.

Posso acessar o dispositivo com seu endereço IPv6, mas o handshake atinge o tempo limite quando uso o endereço IPv4. Tentei alterar o endereço em questão, caso tenha sido tirado, mas não mudou nada. Também tentei adicionar regras de firewall para garantir que o cliente SSH não fosse bloqueado.

Procurei informações sobre o que poderia causar isso, mas a coisa mais próxima que pude encontrar foi uma pergunta sobre por que o Dropbear trabalhava no IPv4, mas não no IPv6. Eu tenho o problema oposto. Eu simplesmente usaria o IPv6 e contornaria o problema, mas o sistema precisará ser acessado por meio de um servidor Node.js. por HTTP. Não quero que exija um endereço IPv6 no URL.

Suspeito que o problema possa ter algo a ver com os escopos de endereço, pois o IPv6 está listado como scope linkenquanto o IPv4 está listado como scope global eth0. (Estou conectando a placa diretamente ao computador com um cabo Ethernet.) Se esse é realmente o problema, existe uma maneira de configurar os escopos de endereço? Não consegui encontrar nada sobre esse tópico em particular.

As informações relevantes estão abaixo:

~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0a:35:00:eb:e9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.130/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:35ff:fe00:ebe9/64 scope link
       valid_lft forever preferred_lft forever
~# ip route
default via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0  src 192.168.0.130
~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0a:35:00:eb:e9 brd ff:ff:ff:ff:ff:ff
~# ip tunnel
~# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:ftp                   *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
tcp        0      0 *:telnet                *:*                     LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
getnameinfo failed
getnameinfo failed
tcp6       0      0 [UNKNOWN]:ssh           [UNKNOWN]:1755          ESTABLISHED
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   Path

linux networking ssh ipv6 ipv4 Matthias Guenther
fonte

Você pode fazer ping através do IPv4? Você pode acessá-lo via HTTP sobre IPv4? O seu cliente SSH está na mesma LAN Ethernet do seu servidor SSH? Como são as configurações IPv4 da sua máquina cliente SSH? Está definido para estar na mesma sub-rede IPv4?

Spiff

Posso fazer ping através do IPv6, mas não do IPv4. O cliente e o servidor estão conectados diretamente um ao outro com um cabo Ethernet, portanto, eles devem estar na mesma LAN. (Além disso, como mencionei, o SSH funciona sobre IPv6 nessa conexão.) Não consigo acessá-lo por HTTP no IPv4 ou IPv6 porque não o configurei para isso; Dito isto, atinge o tempo limite no IPv4 e simplesmente recusa o IPv6. O cliente possui IPv4 192.168.1.121, máscara de sub-rede 255.255.255.0 e gateway padrão 192.168.1.1. A máscara de sub-rede é a mesma no servidor. Além disso, tentei IPs de servidor no intervalo 192.168.1.x sem êxito.

Matthias Guenther

Bem, agora você parece ter uma incompatibilidade de sub-rede. Seu servidor está em 192.168.0.x / 24 e seu cliente em 192.168.1.x / 24. Corrija isso primeiro. Se você ainda tiver problemas, edite sua pergunta para incluir a mesma saída de comando para o seu cliente que você incluiu no seu servidor.

Spiff