3

В этом сценарии есть три машины:

  • Рабочий стол A: user@1.23.xx
  • Ноутбук A: user@1.23.yy
  • Машина B: user@192.168.zz

Все машины имеют Ubuntu 11.04 (рабочий стол A является 64-битным) и имеют как openssh-сервер, так и openssh-клиент.

Теперь, когда я пытаюсь подключить рабочий стол A к ноутбуку A или наоборот по ssh user@1.23.y.y я получаю сообщение об ошибке: 

port 22: No route to host

в обоих случаях.

Я владею обеими машинами, и теперь, если я попробую те же команды с машины моего друга, то есть через Рабочий стол B, я смогу получить доступ как к своему ноутбуку, так и к рабочему столу. Но если я пытаюсь получить доступ к Desktop B с моего ноутбука или с рабочего стола, я получаю

port 22: Connection timed out

Я даже попытался изменить порт SSH нет. в файле ssh_config но безуспешно.

Обратите внимание: что «Портативный компьютер A» использует соединение WiFi, а «Устройство A» использует соединение Ethernet, а «Устройство B» находится в совершенно другой сети.

Ноутбук A && Desktop A -> Router/Nano_Rcvr, предоставленный мне провайдером. Таким образом, к одному маршрутизатору подключены две машины, и к ним можно получить доступ одновременно. Вот мой вывод 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
|источник

2 ответа2

-1

Подобные проблемы частичного подключения с использованием беспроводной связи обычно сводятся к нарушению многоадресной обработки, в результате чего ARP не могут надежно пройти.

См. Шаги по устранению неполадок, которые я рекомендовал в этом ответе:Wi-Fi сеть подходит для Macbook Pro и Win XP, но Win Vista "Ограниченное подключение"

|источник
-1

Это плохое сообщение об ошибке. Эти ошибки SSH могут привести вас к мысли, что есть проблема с сетью, когда ее нет. Маршрут к удаленной машине может быть просто нормальным, но тогда iptables, блокирующий ssh (и до сих пор на CentOS6.7), выдает ssh: connect to host ec239dict port 22: No route to host

Если другой TCP-трафик надежно попадает на компьютер, то это не проблема сетевого маршрута. Помимо ssh, какие еще сервисы вы пытались протестировать? HTTP? пинг? tracepath? Веб-сервер будет работать нормально, но ssh не работает.

Следующий файл /etc /sysconfig /iptables взят с компьютера CentOS6.7 (декабрь 2015 г.), и попытки подключения ssh к этому компьютеру приводят к ssh: connect to host ec239dict port 22: No route to host Проблема с брандмауэром заключается в том, что строка 12 ПРИНИМАЕТ входящие ssh-соединения никогда не достигается, потому что его нужно переместить до REJECT в строке 10. 

 1  # Firewall configuration written by system-config-firewall
 2  # Manual customization of this file is not recommended.
 3  *filter
 4  :INPUT ACCEPT [0:0]
 5  :FORWARD ACCEPT [0:0]
 6  :OUTPUT ACCEPT [0:0]
 7  -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 8  -A INPUT -p icmp -j ACCEPT
 9  -A INPUT -i lo -j ACCEPT
10  -A INPUT -j **REJECT** --reject-with icmp-host-prohibited
11  -A FORWARD -j **REJECT** --reject-with icmp-host-prohibited
12  -A INPUT -m state --state NEW -m tcp -p tcp -**-dport 22 -j ACCEPT**
13  COMMIT

Как ни странно, сообщения об ошибках ssh ухудшаются, если порт брандмауэра открыт, но демон ssh НЕ работает, то ошибка
ssh: connect to host ec239dict port 22: Connection refused.
« Отказ в соединении », конечно, звучит как брандмауэр, блокирующий попытку подключения, но на самом деле это сообщение об ошибке, когда брандмауэр открыт, но демон ssh выключен. Опять же, есть ошибка в сообщениях об ошибках ssh. Убедитесь, что демон ssh работает:

netstat -tunap | grep 22
chkconfig --list | grep ssh
/etc/init.d/ssh? status

Теперь в вашем случае, скорее всего, где-то на этом пути неправильно настроен аппаратный или программный брандмауэр.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .