SSH funziona su IPv6 ma non su IPv4

Sto configurando un sistema Linux incorporato e accedendo tramite SSH per scopi di sviluppo. Ho impostato un indirizzo IP statico e un server Dropbear SSH, ed entrambi sembrano funzionare per la maggior parte.

Posso accedere al dispositivo con il suo indirizzo IPv6, ma l'handshake scade quando utilizzo il suo indirizzo IPv4. Ho provato a cambiare detto indirizzo nel caso fosse stato preso, ma non ha cambiato nulla. Ho anche provato ad aggiungere regole firewall per assicurarmi che il client SSH non venisse bloccato.

Ho cercato informazioni su cosa potrebbe causare questo, ma la cosa più vicina che ho trovato è stata una domanda sul perché Dropbear ha funzionato su IPv4 ma non su IPv6. Io ho il problema opposto. Vorrei semplicemente usare IPv6 e aggirare il problema, ma alla fine sarà necessario accedere al sistema tramite un server Node.js su HTTP. Non voglio che richieda un indirizzo IPv6 nell'URL.

Ho il sospetto che il problema potrebbe avere qualcosa a che fare con gli ambiti degli indirizzi, poiché IPv6 è elencato come scope linkmentre IPv4 è elencato come scope global eth0. (Sto collegando la scheda direttamente al computer con un cavo Ethernet.) Se questo è effettivamente il problema, c'è un modo per configurare gli ambiti di indirizzo? Non sono riuscito a trovare nulla su quel particolare argomento.

Le informazioni pertinenti sono di seguito:

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

— Matthias Guenther
fonte

Puoi eseguire il ping tramite IPv4? Puoi raggiungerlo via HTTP su IPv4? Il tuo client SSH è sulla stessa LAN Ethernet del tuo server SSH? Come sono le impostazioni IPv4 della tua macchina client SSH? È impostato per essere sulla stessa sottorete IPv4?

— Spiff,

Posso eseguire il ping tramite IPv6 ma non IPv4. Il client e il server sono collegati direttamente tra loro con un cavo Ethernet, quindi dovrebbero essere sulla stessa LAN. (Inoltre, come ho già detto, SSH funziona su IPv6 su quella connessione.) Non riesco a raggiungerlo su HTTP su IPv4 o IPv6 perché non l'ho configurato per quello; detto questo, scade su IPv4 e si rifiuta semplicemente su IPv6. Il client ha IPv4 192.168.1.121, subnet mask 255.255.255.0 e gateway predefinito 192.168.1.1. La subnet mask è la stessa sul server. Inoltre, ho provato senza successo gli IP del server nell'intervallo 192.168.1.x.

— Matthias Guenther,

Bene, in questo momento sembra che tu abbia una discrepanza di sottorete. Il tuo server è su 192.168.0.x / 24 e il tuo client è su 192.168.1.x / 24. Risolvilo per primo. Se i problemi persistono, modificare la domanda per includere lo stesso output di comando per il client incluso per il server.

— Spiff,