К SSH из другой подсети!

[iveg]

Добрый день!
Комп А <-> Шлюз А <-> VPN over Internet <-> Шлюз Б <-> Комп Б. Между сетями никаких натов, разрешено все. По ssh к Комп А из своей сети подключается. Также подключается с Комп Б при пробросе порта на шлюзе. Напрямую с Комп Б к Комп А не получается. В логе: Mar 20 10:36:25 user sshd[7061]: Did not receive identification string from 192.168.1.18

Что и где прописать, чтобы ssh принимал подключения из других подсетей?

[koshev]

В конфиге sshd (/etc/ssh/sshd_config), но это тебе не поможет, по-умолчанию там разрешены все подключения.
Ты ведь сам понимаешь, дело-то не в sshd ибо

Также подключается с Комп Б при пробросе порта на шлюзе.

Т.е всё таки NAT есть. И что за шлюзы, я так понимаю, должны догадаться форумчане (может у кого-то всё-таки сорался libastral).
Я тебе все же предлагаю более подробно описать твою сеть.

[iveg]

Нету там ната. При пробросе порта шлюз подменяет адрес источника своим внутренним адресом (DNAT) и Комп А думает что пакет пришел из его подсети. В случае же попытки соединения напрямую от Комп Б(192.168.1.18) к Компу А(192.168.0.15) он принимает пакет (Mar 20 10:36:25 user sshd[7061]: Did not receive identification string from 192.168.1.18), но так как он из другой подсети то не знаю чего он делает, но соедениться не дает. Кстати пинги между ними прекрасно ходят, telnet на 25 порт прекрасно подключается.

[drako]

Т.е всё таки NAT есть. И что за шлюзы, я так понимаю, должны догадаться форумчане (может у кого-то всё-таки сорался libastral).

Не, у меня точно не собралась. Так что хотелось бы все-таки реальных данных: шлюзы, правила и т.д.

[iveg]

Шлюзы виндовые, ISA Server, VPN site-to-site. Если поможет: Network rule между сетями - route, wirewall rule - All outbound traffic. ISA c пакетами ничего не делает, только маршрутизирует. А вот Ubuntu отфутболивает ssh, на стороне клиента пишет:ssh_exchange_identification: read: Connection reset by peer. Да и на стороне сервера видно что пакеты до него доходят (писал ранее). Так что шлюзы здесь не причем.

[skytrain]

АП.

Есть у кого что либо сказать по этому вопросу.
Ситуация аналогичная.
Подсети шлюзует OpenVPV.
Маршруты ровные. Пакеты ходят.

[fisher74]

В аналогичной ситуации требования к информации аналогичные, как и к первичной:

хотелось бы все-таки реальных данных: шлюзы, правила и т.д.

[skytrain]

Да. Именно так. Требования те-же. Шлюз OpenVPN в режиме бриджа.

Я решил так.
На  ВПН шлюзе сети Б
Что-бы sshd видел в качестве отправителя адрес своей сети.
sudo iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 22 -j MASQUERADE
Та-же песня и с VNC.
sudo iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 5900 -j MASQUERADE

Я думаю что дело в самих протоколах. А не в шлюзе. (А может и в шлюзе)
Скорее всего из соображений безопасности длину маршрута соединения для удаленного администрирования ограничили до одного прыжка. Видимо для защиты от какой-то сетевой атаки. Либо шлюз обрывает соединения тем самым защищая свои машины от атак , либо протоколы защищают себя сами.

Во всех других случаях (при подключении из инета по проброшенному порту) трафик идет через нат. И для SSHD пакеты с шлюза своей сети считаются доверенными.
И если грамотно.... то между сетями должен быть межсетевой экран в любом случае. Если его нет, то это в любом случае плохо.
 
Но все-таки интересно.... Как это отключить? Так.. для развития и кругозора.

[fisher74]

Вообще-то это было предложением предоставить хоть какую-то техническую информацию о конфигурации сети.
Пользователь решил продолжить мысль 18 Декабря 2014, 16:25:42:

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

А ничего, что NAT и TTL две разные песни и друг друга не задевают?

[skytrain]

Сеть А 192.168.3.0/24

(Нажмите, чтобы показать/скрыть)

ladmin@vpnsrv:~$ ip route
default via 192.168.3.1 dev br0  metric 100
default via 192.168.3.8 dev br0  metric 200
10.17.224.0/24 dev eth1  proto kernel  scope link  src 10.17.224.1
10.200.200.5 dev ppp0  proto kernel  scope link  src 10.200.200.1
10.200.200.6 dev ppp2  proto kernel  scope link  src 10.200.200.1
10.200.200.7 dev ppp1  proto kernel  scope link  src 10.200.200.1
192.168.1.0/24 via 192.168.3.246 dev br0  metric 25                   << ПАКЕТЫ ИДУТ СЮДА!!!!
192.168.1.0/24 via 10.200.200.5 dev ppp0  metric 50
192.168.3.0/24 dev br0  proto kernel  scope link  src 192.168.3.11
192.168.5.0/24 via 10.200.200.7 dev ppp1  metric 50
192.168.6.0/24 via 10.200.200.6 dev ppp2  metric 50

Фаервол
В шлюз 192.168.3.246 никакой трафик не блокируется.

Сеть Б 192.168.1.0/24

(Нажмите, чтобы показать/скрыть)

ladmin@mos-srv:~$ ip route
default via 192.168.1.2 dev eth0
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.3
192.168.3.0/24 dev tap0  proto kernel  scope link  src 192.168.3.246    << ПАКЕТЫ ИДУТ СЮДА!!!!

Фаервол

(Нажмите, чтобы показать/скрыть)

ladmin@mos-srv:~$ sudo iptables -L -v
Chain INPUT (policy DROP 380 packets, 101K bytes)
 pkts bytes target     prot opt in     out     source               destination         
15819 5419K ACCEPT     all  --  lo     any     anywhere             anywhere           
 430K   95M ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
67843 8635K ACCEPT     all  --  any    any     192.168.3.0/24       anywhere           
57177 6978K ACCEPT     all  --  any    any     192.168.1.0/24       anywhere           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
29404 5772K ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED
 7542  393K TCPMSS     tcp  --  any    any     anywhere             anywhere             tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
 7754  745K ACCEPT     all  --  any    any     anywhere             192.168.3.0/24     
12110  788K ACCEPT     all  --  any    any     192.168.3.0/24       anywhere           

Chain OUTPUT (policy DROP 7 packets, 308 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 322K   65M ACCEPT     all  --  any    any     anywhere             anywhere             state NEW,RELATED,ESTABLISHED

Пользователь решил продолжить мысль [time]18 Декабрь 2014, 17:45:51[/time]:

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

А как еще рациональнее объяснить такое поведение? Аутенитификация проходит только от клиентов СВОЕЙ доверенной сети. И это факт... по моему.

Ну черт с этим SSH... но VNC почему ведет себя так-же?

[fisher74]

Код: [Выделить]

sudo iptables -L -v -t natПользователь решил продолжить мысль 18 Декабря 2014, 17:26:19:

А как еще рациональнее объяснить такое поведение? Аутенитификация проходит только от клиентов СВОЕЙ доверенной сети. И это факт... по моему.

Это факт притянутый за уши. С какого адреса подключение фиксируется?

[skytrain]

(Нажмите, чтобы показать/скрыть)

ladmin@mos-srv:~$ sudo iptables -L -v -t nat
Password:
Chain PREROUTING (policy ACCEPT 10032 packets, 1052K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 8111 packets, 924K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 2627 packets, 392K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 4128 packets, 490K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   180 MASQUERADE  tcp  --  any    eth0    anywhere             anywhere             tcp dpt:ssh
    2   120 MASQUERADE  tcp  --  any    eth0    anywhere             anywhere             tcp dpt:5900

С какого адреса подключение фиксируется?

Плохо понял вопрос..
Аутентификация на SSH сервере проходит только от клиентов доверенной (своей) сети.
В случае с правилами выше, при подключении из другой подсети, выхлоп tcpdump сервера SSH выглядит так

(Нажмите, чтобы показать/скрыть)

17:43:31.781543 IP 192.168.1.41.22 > 192.168.1.3.52796: Flags [P.], seq 552:588, ack 1, win 334, options [nop,nop,TS val 78666 ecr 23181366], length 36
17:43:31.853735 IP 192.168.1.3.52796 > 192.168.1.41.22: Flags [.], ack 552, win 479, options [nop,nop,TS val 23181617 ecr 78666], length 0

ГДЕ 192.168.1.3 - адрес eth0 на шлюзе сети Б
192.168.1.41 - Адрес сервера SSH.

А вот если правила iptables убрать, то до сервера доходит только 2 ssh пакета c РЕАЛЬНЫМ АДРЕСОМ ОТПРАВИТЕЛЯ и подключение разрывается.

[fisher74]

Плохо понял вопрос..

Код: [Выделить]

grep sshd /var/log/auth.log | tailбез тех правил.

Кстати, погуглил... скорее всего с ssh придётся применять маскарадный костыль. Видимо openssl не терпит себя же внутри тоннеля... Но это уже мои догадки.
С VNC видимо такая же беда. Не уверен (просто не интересно), но шифрование вроде так же openssl использует.
Пользователь решил продолжить мысль 18 Декабря 2014, 18:11:52:А ещё... можно глянуть конфиги OpenVPN?

[skytrain]

Такой ход конем я думаю отразит суть.

(Нажмите, чтобы показать/скрыть)

ladmin@mos-super2:~$ sudo /usr/sbin/sshd -D -d -p 23
[sudo] password for ladmin:
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: private host key: #3 type 4 ED25519
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-D'
debug1: rexec_argv[2]='-d'
debug1: rexec_argv[3]='-p'
debug1: rexec_argv[4]='23'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 23 on 0.0.0.0.
Server listening on 0.0.0.0 port 23.
debug1: Bind to port 23 on ::.
Server listening on :: port 23.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.3.53 port 55900 on 192.168.1.41 port 23               <<<<<  Вот тут светится реальный IP ssh клиента
debug1: Client protocol version 2.0; client software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: permanently_set_uid: 116/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
Read from socket failed: Connection reset by peer [preauth]         <<<<<<  Вот на чем закрывается соединие
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: Killing privsep child 13519

Видимо openssl не терпит себя же внутри тоннеля

Не знаю. Если-б оно так было, то маскарадинг бы не помог 100%. Ибо в тонель инкапсулируется все под ряд. Он для того и VPN.

 

ssh придётся применять маскарадный костыль

Ну зачем так грубо... костыль...
Думаю это лишний раз натолкнет админов на умную мысль об организации нормальных межсетевых экранов. Даже в формате внутренних ЛВС.
Вирусни в корпоративном секторе станет еще меньше.

[shyatan007]

Попробуйте сделать трасировку по порту ssh с  хоста к серверу и обратно

Код: [Выделить]

sudo traceroute -Tp 22 xx.xx.xx.xx