SSH działa na IPv6, ale nie na IPv4


0

Konfiguruję wbudowany system Linux i uzyskuję dostęp do niego przez SSH w celach programistycznych. Skonfigurowałem statyczny adres IP i serwer Dropbear SSH i oba wydają się działać w większości.

Mogę uzyskać dostęp do urządzenia z jego adresem IPv6, ale czas uzgadniania upłynął, gdy korzystam z jego adresu IPv4. Próbowałem zmienić ten adres na wypadek, gdyby został zajęty, ale nic to nie zmieniło. Próbowałem również dodać reguły zapory, aby mieć pewność, że klient SSH nie zostanie zablokowany.

Rozejrzałem się w poszukiwaniu informacji o tym, co może to powodować, ale najbliższą rzeczą, jaką mogłem znaleźć, było pytanie, dlaczego Dropbear działa na IPv4, ale nie na IPv6. Mam odwrotny problem. Chciałbym po prostu użyć protokołu IPv6 i ominąć ten problem, ale do systemu będzie trzeba uzyskać dostęp za pośrednictwem serwera Node.js przez HTTP. Nie chcę, aby wymagał adresu IPv6 w adresie URL.

Podejrzewam, że problem może mieć coś wspólnego z zasięgami adresów, ponieważ IPv6 jest wymieniony jako scope linkpodczas gdy IPv4 jest wymieniony jako scope global eth0. (Podłączam płytkę bezpośrednio do komputera za pomocą kabla Ethernet.) Jeśli to w rzeczywistości jest problem, czy istnieje sposób na skonfigurowanie zakresów adresów? Nie mogłem znaleźć niczego na ten konkretny temat.

Odpowiednie informacje są poniżej:

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

1
Czy możesz pingować za pomocą IPv4? Czy można to zrobić za pośrednictwem protokołu HTTP przez IPv4? Czy Twój klient SSH jest w tej samej sieci Ethernet co serwer SSH? Jakie są ustawienia IPv4 twojego klienta SSH? Czy jest ustawiony na tę samą podsieć IPv4?
Spiff

Mogę pingować za pomocą IPv6, ale nie IPv4. Klient i serwer są połączone bezpośrednio za pomocą kabla Ethernet, więc powinny znajdować się w tej samej sieci LAN. (Jak już wspomniałem, SSH działa na tym połączeniu przez IPv6). Nie mogę połączyć się z nim przez HTTP na IPv4 lub IPv6, ponieważ nie skonfigurowałem go do tego; powiedziawszy, limit czasu dla IPv4 i po prostu odmawia na IPv6. Klient ma IPv4 192.168.1.121, maskę podsieci 255.255.255.0 i bramę domyślną 192.168.1.1. Maska podsieci jest taka sama na serwerze. Próbowałem również adresów IP serwerów w zakresie 192.168.1.x bez powodzenia.
Matthias Guenther

1
Wygląda na to, że masz niedopasowanie podsieci. Twój serwer to 192.168.0.x / 24, a twój klient to 192.168.1.x / 24. Napraw to pierwszy. Jeśli nadal masz problemy, edytuj pytanie, aby uwzględnić takie same dane wyjściowe polecenia dla klienta, jakie podałeś dla swojego serwera.
Spiff
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.