Ошибка соединения SSH: Никакой маршрут для хостинга
В этом сценарии существует три машины:
- Рабочий стол A: user@1.23.x.x
- Ноутбук A: user@1.23.y.y
- Машина B: user@192.168.z.z
Все машины имеют Ubuntu 11.04 (Рабочий стол A является на 64 бита), и имейте и openssh-сервер и openssh-клиент.
Теперь, когда я пытаюсь подключить Рабочий стол к Ноутбуку A или наоборот ssh user@1.23.y.y Я получаю ошибку как
port 22: No route to host
в обоих случаи.
Я владею обоими машины, теперь если я пробую те же команды от машины своего друга, т.е. через Рабочий стол B, я могу получить доступ и к своему Ноутбуку и к Рабочему столу. Но если я пытаюсь получить доступ к Рабочему столу B от моего Ноутбука, или Рабочим столом я добираюсь
port 22: Connection timed out
Я даже пытался изменить ssh порт нет. в ssh_config файл, но никакой успех.
Примечание: тот 'Ноутбук' использование соединение WiFi, в то время как 'Машина' соединение Ethernet использования и 'Машина B' находятся в совершенно другой сети.
@Lekensteyn Здесь это->
Ноутбук && Рабочий стол-> Router/Nano_Rcvr, предоставленный мне ISP. Таким образом к одному Маршрутизатору две Машины подключены и могут быть получены доступ одновременно. вот является мой вывод ifconfig для обоих машинами:-Ноутбук
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)
Рабочий стол
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
Вывод 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
Вывод 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
7 ответов
Маршруты выглядят хорошо. Я предположу, что те IP-адреса являются частными (LAN) и не общедоступные доступный.
Так как Вы подключены по-разному к сети (Wi-Fi / соединенный проводом), вероятно, что Ваш маршрутизатор отделился соединенный проводом / беспроводные сети. Попытайтесь соединить их обоих на проводном (или беспроводная связь) соединение. Другая возможность состоит в том, что брандмауэр на машинах Ubuntu блокирует соединения.
Иначе настройте свой маршрутизатор для использования той же сети (подсеть) для беспроводных и проводных соединений. Также удостоверьтесь, что маршрутизатор не блокирует коммуникацию от клиента к клиенту.
Ваш маршрутизатор возможно отбрасывает все незапрашиваемые пакеты, вот почему Ваш друг добирается, "соединение привело к таймауту" сообщения на Вашем общедоступном IP-адресе. Настройте перенаправление портов NAT так, чтобы общедоступный IP-адрес + комбинация портов вперед к Вашему адресу локальной сети.
Сеть Example:
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
На Маршрутизаторе A, установите передачу 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
Если у Вас есть брандмауэр (ufw, iptables...) на наборе машин, позвольте входящему трафику портировать 22 (Рабочий стол A) и порт 2222 (Ноутбук A).
К рабочему столу можно теперь получить доступ с помощью SSH с:
ssh user@198.51.100.1 -p 22
К ноутбуку можно теперь получить доступ с помощью SSH с:
ssh user@198.51.100.1 -p 2222
Если Вы хотите получить доступ к своим друзьям машина, применить эти инструкции к его машине + маршрутизатор.
у меня была подобная проблема. Одна машина на проводе одна беспроводная связь. Я нашел tickbox в своем маршрутизаторе помимо "отдельного дюйм/с для LAN и wlan" и убрал галочку в нем. Теперь я могу войти в беспроводной компьютер. Перед этим я заставил сообщение об ошибке "Никакой маршрут размещать".
Если Вы изменились/заменили, Ваш системный жесткий диск упаковывают затем попытку, удаляющую hostkey из .ssh/known_hosts файла, затем пытаются соединиться снова.
Проверьте ssh флажок при установке RHEL. Я не проверял его и порождение той же проблемы. Проверьте тот параметр
Я получил ту же проблему сам теперь о vps и его абсолютно странном, никогда не замечаемом что-либо как он.
Я - опытный администратор сервера, и этот вид ошибки обычно сокращается и сух.
Никакой маршрут для хостинга средств, которые не знает сервер, как направить пакет (таблица маршрутизации, однако я никогда не видел, что он только происходит на одном протоколе и не другом).
В моем случае.
Никакое Интернет-соединение NAT. Никакой Ping IPTABLES не работает, я могу соединиться с любой стороной IP поврежденного IP. Поврежденный IP не говорит "маршрута для хостинга" на любом tcp порте.
Это предполагает, что или что-то в середине возвращает код ошибки или ошибку в ОС с таблицей маршрутизации.
Обратите внимание, что ошибка мгновенна, не задержка, означающая, что отклонение локально. Но это - все, что я могу диагностировать.
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
Я странно получил бы эту ошибку даже после успешного выполнения SSH между моим ПК и малиной Pi. Что фиксирует, это для меня выключает и включает Wi-Fi (и клиент и хост), перезапуская Ваш терминал и с помощью новых IP-адресов.
В моем случае была сеть Docker на том же CIDR как моя VPN.
Я использовал следующую команду для выяснения, какая сеть, и затем я удалил ее:
docker inspect $(docker network ls -q) | jq '.[] | {name: .Name, cidr: .IPAM.Config[0].Subnet}'
После этого это хорошо работало.