Błąd połączenia SSH: brak trasy do hosta

W tym scenariuszu istnieją trzy maszyny:

• Pulpit A: użytkownik@1.23.xx
• Laptop A: użytkownik@1.23.yy
• Komputer B: użytkownik@192.168.zz

Wszystkie maszyny mają Ubuntu 11.04 (Desktop A jest 64-bitowy) i mają zarówno openssh-server, jak i openssh-client.

Teraz, gdy próbuję podłączyć komputer stacjonarny A do laptopa A lub odwrotnie, pojawia ssh user@1.23.y.ysię błąd jako

port 22: No route to host

w obu przypadkach.

Posiadam oba komputery, teraz jeśli wypróbuję te same polecenia z komputera mojego przyjaciela, tj. Za pośrednictwem pulpitu B, mogę uzyskać dostęp zarówno do mojego laptopa, jak i pulpitu. Ale jeśli spróbuję uzyskać dostęp do pulpitu B z laptopa lub pulpitu, dostanę

port 22: Connection timed out

Próbowałem nawet zmienić numer portu ssh. w ssh_configpliku, ale bez powodzenia.

Uwaga : „Laptop A” korzysta z połączenia WiFi, podczas gdy „Maszyna A” korzysta z połączenia Ethernet, a „Maszyna B” jest w zupełnie innej sieci.

@ Lekensteyn Oto jest ->

Laptop A&& Desktop A -> Router / Nano_Rcvr dostarczone mi przez dostawcę usług internetowych. Tak więc do jednego routera są podłączone dwie maszyny i można uzyskać do nich dostęp w tym samym czasie. oto moje wyjście ifconfig dla obu komputerów: - Laptop

wlan0

      Link encap:Ethernet  HWaddr X:X:X:X:00:bc  
      inet addr:1.23.73.111  Bcast:1.23.95.255  Mask:255.255.224.0
      inet6 addr: fe80::219:e3ff:fe04:bc/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:108409 errors:0 dropped:0 overruns:0 frame:0
      TX packets:82523 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:44974080 (44.9 MB)  TX bytes:22973031 (22.9 MB)

Pulpit

eth0

      Link encap:Ethernet  HWaddr X:X:X:X:c5:78  
      inet addr:1.23.68.209  Bcast:1.23.95.255  Mask:255.255.224.0
      inet6 addr: fe80::227:eff:fe04:c578/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:10380 errors:0 dropped:0 overruns:0 frame:0
      TX packets:4509 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:1790366 (1.7 MB)  TX bytes:852877 (852.8 KB)
      Interrupt:43 Base address:0x2000 

Wyjście z ip route show

      1.23.64.0/19 dev wlan0  proto kernel  scope link  src 1.23.73.111  metric 2 

      169.254.0.0/16 dev wlan0  scope link  metric 1000 

Wyjście z traceroute -n 1.23.73.111

       traceroute to 1.23.73.111 (1.23.73.111), 30 hops max, 60 byte packets
       1  1.23.68.209  3008.787 ms !H  3008.786 ms !H  3008.784 ms !H

Trasy wyglądają dobrze. Zakładam, że te adresy IP są prywatne (LAN) i niedostępne publicznie.

Ponieważ jesteś podłączony na różne sposoby do sieci (Wi-Fi / przewodowej), jest bardzo prawdopodobne, że twój router oddzielił sieci przewodowe / bezprzewodowe. Spróbuj połączyć oba za pomocą połączenia przewodowego (lub bezprzewodowego). Inną możliwością jest to, że zapora na komputerach z systemem Ubuntu blokuje połączenia.

W przeciwnym razie skonfiguruj router, aby korzystał z tej samej sieci (podsieci) dla połączeń bezprzewodowych i przewodowych. Upewnij się także, że router nie blokuje komunikacji klient-klient.

Router prawdopodobnie odrzuca wszystkie niechciane pakiety, dlatego Twój przyjaciel otrzymuje komunikat „Przekroczono limit czasu połączenia” na Twój publiczny adres IP. Skonfiguruj przekierowanie portów NAT, aby kombinacja publicznego adresu IP + portu była przekazywana na Twój adres LAN.

Przykładowa sieć:

YOUR NETWORK (A)
    Router A (public address: 198.51.100.1)
    Desktop A - 10.0.0.2
    Laptop  A - 10.0.0.3

YOUR FRIENDS NETWORK (B)
    Router B (public address: 203.0.113.1)
    Machine B - 192.168.0.2

Na routerze A skonfiguruj przekazywanie NAT:

To make your desktop accessible:
  forward the public port 22 to 10.0.0.2
To make your laptop accessible:
  forward the public port 2222 to 10.0.0.3

Jeśli masz firewall ( ufw, iptables...) na maszynach określonych pozwalają przychodzący ruch na porcie 22 (Pulpit A) i port 2222 (laptop A).

Dostęp do pulpitu można teraz uzyskać za pomocą SSH za pomocą:

ssh user@198.51.100.1 -p 22

Dostęp do laptopa można teraz uzyskać za pomocą SSH za pomocą:

ssh user@198.51.100.1 -p 2222

Jeśli chcesz uzyskać dostęp do komputera znajomych, zastosuj te instrukcje do jego komputera + routera.

miałem podobny problem. Jedna maszyna przewodowa jedna bezprzewodowa. Znalazłem pole wyboru w moim routerze oprócz „oddzielnych IP dla sieci LAN i WLAN” i zaznaczyłem je. Teraz mogę zalogować się do komputera Wireles. Wcześniej otrzymałem komunikat o błędzie „Brak trasy do hosta”.

Zaznacz pole wyboru ssh podczas instalacji RHEL. Nie sprawdziłem tego i spowodowałem ten sam problem. Sprawdź ten parametr

Sam mam teraz ten sam problem na VPS i jest to całkowicie dziwne, nigdy nie widziałem czegoś takiego.

Jestem doświadczonym administratorem serwera i tego rodzaju błędy są zwykle usuwane i usuwane.

Brak trasy do hosta oznacza, że ​​serwer nie wie, jak trasować pakiet (tablica routingu, jednak nigdy nie widziałem, aby występowała tylko na jednym protokole, a nie na innym).

W moim przypadku.

Brak połączenia z Internetem NAT. Ping IPTABLES nie działa Ping mogę podłączyć do ip po obu stronach uszkodzonego ip. Uszkodzony ip mówi „brak trasy do hosta” na dowolnym porcie TCP.

To sugeruje, że coś w środku zwraca kod błędu lub błąd w systemie operacyjnym z tabelą routingu.

Uwaga: błąd jest natychmiastowy, a nie opóźnienie oznacza, że ​​odrzucenie jest lokalne. Ale to wszystko, co mogę zdiagnozować.

root@vps1 network # telnet 83.149.xx.xx 23
Trying 83.149.xx.xx...
telnet: Unable to connect to remote host: No route to host
root@vps1 network # telnet 83.149.xx.xx 80
Trying 83.149.xx.xx...
telnet: Unable to connect to remote host: No route to host
root@vps1 network # ping 83.149.xx.xx
PING 83.149.xx.xx (83.149.xx.xx) 56(84) bytes of data.
64 bytes from 83.149.xx.xx: icmp_seq=1 ttl=56 time=8.89 ms
64 bytes from 83.149.xx.xx: icmp_seq=2 ttl=56 time=7.93 ms

Dziwnie dostałbym ten błąd, nawet po pomyślnym uruchomieniu SSH między moim komputerem a Raspberry Pi. Naprawdę to dla mnie wyłącza i włącza Wi-Fi (zarówno klienta, jak i hosta), restartuje terminal i używa nowych adresów IP.

W moim przypadku sieć Docker znajdowała się na tym samym CIDR co moja sieć VPN.

Użyłem następującego polecenia, aby dowiedzieć się, która sieć, a następnie go usunąłem:

docker inspect $(docker network ls -q) | jq '.[] | {name: .Name, cidr: .IPAM.Config[0].Subnet}'

Potem wszystko działało dobrze.

Jeśli zmieniłeś / wymieniłeś systemowy dysk twardy, spróbuj usunąć klucz hosta z pliku .ssh / known_hosts, a następnie spróbuj połączyć się ponownie.