LINUX.ORG.RU

Не могу подключиться к серверу по SSH с другого сервера

 


0

1

Добрый вечер!

Не могу разобраться с проблемой, не хватает опыта. Есть два сервера на Debian 9 (назовем сервер 1 и сервер 2)

Не могу подключиться по SSH с сервера 2 на сервер 1.

IP первого 185.162.8.12
IP второго 94.250.251.88

При этом с сервера 2, сервер 1 не пингуется. Команда ping просто висит, пока принудительно не завершить команду. После принудительного завершения:
--- 185.162.8.12 ping statistics --- 363 packets transmitted, 0 received, 100% packet loss, time 362024ms

Команда tracerout (с ключами -T итд такой же результат):
traceroute to 185.162.8.12 (185.162.8.12), 30 hops max, 60 byte packets
1 vlan4047.dci (185.60.132.54) 0.079 ms 0.021 ms 0.025 ms
2 edge.webdc.ru (92.63.108.97) 0.311 ms 0.289 ms 0.272 ms
3 213.219.206.17 (213.219.206.17) 0.835 ms 0.857 ms 0.961 ms
4 xe-7-1-5.mbr1.msk1.ip.di-net.ru (213.248.3.128) 1.084 ms 1.076 ms 1.065 ms
5 xe-7-0-1.mbr2.ip.di-net.ru (213.248.7.91) 1.090 ms 1.075 ms 1.061 ms
6 ams-ix-gw1.serverius.net (80.249.211.95) 47.492 ms 45.685 ms 45.917 ms
7 * 185.8.179.22 (185.8.179.22) 45.801 ms *
8 * * *
9 185.53.163.135 (185.53.163.135) 42.389 ms 42.550 ms 42.349 ms
10 185.53.163.135 (185.53.163.135) 42.751 ms * 42.699 ms
11 * * *
* * *
30 * * *

Результат подключения ssh
$ sudo ssh -vvv 185.162.8.12
OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving «185.162.8.12» port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 185.162.8.12 [185.162.8.12] port 22.
debug1: connect to address 185.162.8.12 port 22: Connection timed out
ssh: connect to host 185.162.8.12 port 22: Connection timed out

При этом с ноута под виндой tracert команда отлично видит сервер 1:
1 1 ms 1 ms 1 ms 192.168.1.1
2 38 ms 17 ms 10 ms vidcore.VIDN2.prolink.ru [10.77.189.1]
3 8 ms 2 ms 4 ms 10.76.5.1
4 6 ms 11 ms 6 ms m9sw1.prolink.ru [10.76.255.161]
5 5 ms 4 ms 3 ms 78.25.67.145
6 10 ms 4 ms 7 ms 83.169.204.29
7 11 ms 8 ms 7 ms 83.169.204.46
8 27 ms 23 ms 23 ms ae10.RT.NTL.KIV.UA.retn.net [87.245.237.126]
9 53 ms 51 ms 53 ms ae0-4.RT.SRV.MEP.NL.retn.net [87.245.234.102]
10 76 ms 55 ms 54 ms GW-Serverius.retn.net [87.245.236.191]
11 51 ms 51 ms 51 ms 185.8.179.19
12 57 ms 51 ms 55 ms 185.8.179.25
13 58 ms 50 ms 57 ms 185.53.163.135
14 57 ms 55 ms 53 ms hosting.eurohoster.org [185.162.8.12]

и пингуется с ноута отлично

и через putty с ноута также отлично подключаюсь по SSH к серверу 1.

Локально на самом 185.162.8.12 команда SSH также без проблем.

При этом, если подключаться с сервера 1 на сервер 2 - всё то же самое.

Не знаю где искать проблему.

Если есть мысли, поделитесь пожалуйста.

Ответ на: комментарий от leonidko

честно говоря не смогу предоставить. оба сервера - обычные VDS. srv1 у одного хостера srv2 у другого (firstvds). как устроены их сети - узнать нереально. На самих серверах голый debian без изменений маршрутизации, настроек фаервола итд.

deepart ()

2 -> 1

Не будет работать. Т.к. 1й не имеет публичного адреса.

1 -> 2

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

Это вкратце.

leonidko ★★★ ()
Ответ на: комментарий от anc

tcpdump запустил на обоих. в общем 1 сервер и отдает и принимает пакеты со 2 сервера.

А вот второй сервер отдает пакеты 1 серверу, но не принимает от него ничего.

Другими словами на 2 сервере команда tcpdump src 185.162.8.12 слушает и ничего не выдает.

При этом на 1 сервере команда tcpdump src 185.162.8.12 and dst 94.250.251.88 успешно видит отправляемые пакеты: 23:03:00.657661 IP 185.162.8.12.3306 > 94.250.251.88.50138: Flags [S.], seq 3284545398, ack 306766084, win 28960, options [mss 1460,sackOK,TS val 712457344 ecr 3849632209,nop,wscale 7], length 0

как такое может быть?

deepart ()
Ответ на: комментарий от deepart

попробовал обычный ping с сервера 2 на сервер 1.

на 1 сервере запущено tcpdump src 185.162.8.12 and dst 94.250.251.88. Успешно вижу, что 1 сервер отвечает на ping 2 серверу.

Но на 2 сервере tcpdump не видит получаемых ответных пакетов. То есть пакеты просто не доходят до 2 сервера.

как понять где сбой?

deepart ()
Ответ на: комментарий от zolden

1 сервер:
$ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
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
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether d6:48:f0:47:4d:74 brd ff:ff:ff:ff:ff:ff
inet 185.162.8.12/24 brd 185.162.8.255 scope global ens18
valid_lft forever preferred_lft forever

$ip r
default via 185.162.8.1 dev ens18 onlink
185.162.8.0/24 dev ens18 proto kernel scope link src 185.162.8.12

$ip ru
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

$ iptables-save
# Generated by iptables-save v1.6.0 on Fri Mar 16 09:23:17 2018
*filter
:INPUT ACCEPT [203884:21105271]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [194816:481096001]
:f2b-sshd - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A f2b-sshd -j RETURN
COMMIT

$ ip r g 94.250.251.88
94.250.251.88 via 185.162.8.1 dev ens18 src 185.162.8.12
cache

---------------------------------------------------------------------------------------------
2 сервер:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/void
inet 127.0.0.2/32 scope host venet0
inet 94.250.251.88/32 brd 94.250.251.88 scope global venet0:0

$ ip r
default dev venet0 scope link

$ ip ru
0: from all lookup local
32766: from all lookup main
32767: from all lookup default


$ iptables-save
# Generated by iptables-save v1.6.0 on Fri Mar 16 10:48:22 2018
*mangle
:PREROUTING ACCEPT [34342:3818130]
:INPUT ACCEPT [34342:3818130]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [37450:5466785]
:POSTROUTING ACCEPT [37450:5466785]
COMMIT
# Completed on Fri Mar 16 10:48:22 2018
# Generated by iptables-save v1.6.0 on Fri Mar 16 10:48:22 2018
*filter
:INPUT ACCEPT [34342:3818130]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [37450:5466785]
COMMIT
# Completed on Fri Mar 16 10:48:22 2018
# Generated by iptables-save v1.6.0 on Fri Mar 16 10:48:22 2018
*raw
:PREROUTING ACCEPT [34342:3818130]
:OUTPUT ACCEPT [37450:5466785]
COMMIT
# Completed on Fri Mar 16 10:48:22 2018


$ ip r g 185.162.8.12
185.162.8.12 dev venet0 src 94.250.251.88
cache mtu 1500 hoplimit 64

deepart ()
Ответ на: комментарий от deepart

Подведем промежуточный итог как я его понял:
С любого другого адреса есть соединение (в том числе ping) к
185.162.8.12
и к
94.250.251.88
но нет соединения с 94.250.251.88 к 185.162.8.12 ? А обратное есть?

anc ★★★★★ ()
Ответ на: комментарий от anc

да всё верно. Вы сами можете попробовать сделать ping и того и другого. всё работает.

но нет соединения с 94.250.251.88 к 185.162.8.12 ? А обратное есть?

Не совсем так. На примере pinga
До 94.250.251.88 не доходят пакеты с 185.162.8.12.

Делаем ping с 94.250.251.88 на 185.162.8.12.

tcpdump на 185.162.8.12 показывает что успешно приходят echo request и успешно отправляются обратно echo reply.

Но на 94.250.251.88 tcpdump на входящий трафик молчит как рыба. На исходящий показывает echo request.

То есть пакеты уходят на 185.162.8.12 и отправляются ответы обратно. Но до 94.250.251.88 не доходят.

Вот как итог. Честно говоря, мне это совсем не понятно.

deepart ()
Ответ на: комментарий от deepart

Провайдер от вас скорее всего отмахнется и правильно сделает. Пока вы сами не локализуете причину, и четко не сформулируете неисправность. Нужно больше экспериментов. Другие ip этого же провайдера вам в помощь.

vaddd ★★ ()
Ответ на: комментарий от vaddd

Провайдер от вас скорее всего отмахнется и правильно сделает.

Не факт. Во всяком случае у меня была история успеха. Когда говоришь Прову 2, что вот с Прова3,4,5... все работает а вот с Прова1 не работает. Вариантов Пров3,4...N желательно подобрать побольше.

anc ★★★★★ ()
Ответ на: комментарий от anc

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

vaddd ★★ ()
Ответ на: комментарий от vaddd

Честно говоря у меня было интереснее, где-то межпровайдерский роутинг терялся на 3-й стороне. Но по письму в ТП они сами все порешали. А так конечно тоже ставлю на бан подсети по какой-то причине. В любом случае направление движения для ТС как я описал выше.

anc ★★★★★ ()