Назад | Перейти на главную страницу

Некоторые туннели SSH сообщают об отказе в соединении между виртуальной машиной Linux и OSX Lion

Я пытаюсь подключиться к набору служб, работающих на гостевой виртуальной машине Centos 6.3 (VMware Fusion 4) с хоста Mac OS X Lion. Я установил сценарий .ssh / config в / var / root:

Host testbed
Hostname testbed
User <username>
Port 15922
# web server
LocalForward localhost:80 testbed:80
# zend server admin console
LocalForward localhost:10081 testbed:10081
# zend debugger
LocalForward localhost:10000 testbed:10000
# mongodb
LocalForward localhost:28017 testbed:28017
# couchdb
LocalForward localhost:10080 testbed:5984
# scrapyd
LocalForward localhost:6800 testbed:6800
# eclipse connection for zend debugger
RemoteForward testbed:10137 localhost:10137

Затем я запускаю sudo ssh testbed для подключения туннелей. Sudo требуется для туннелирования порта 80, следовательно, root.

Некоторые туннели работают нормально. Я могу просматривать localhost: 80, localhost: 6800 и localhost: 10081 в Firefox. Однако некоторые туннели не работают. Они тайм-аут в браузере и вызывают эту ошибку в оболочке:

channel 19: open failed: connect failed: Connection refused

Сначала я думал, что это артефакт номера порта, поэтому для 5984 я туннелировал его обратно на localhost: 10080. Поведение было таким же (тайм-аут + ошибка). Я проверил, что все службы работают правильно, используя текстовый браузер (lynx) в оболочке.

Я действительно задавался вопросом, была ли это проблема брандмауэра. У гостевой виртуальной машины есть брандмауэр, но он легко открывается для исходящих подключений. Брандмауэр ОС хоста выключен (Системные настройки -> Безопасность -> Брандмауэр).

netstat не показывает никаких конфликтов на портах

tcp6       0      0  ::1.6800               *.*                    LISTEN     
tcp4       0      0  127.0.0.1.6800         *.*                    LISTEN     
tcp6       0      0  ::1.10080              *.*                    LISTEN     
tcp4       0      0  127.0.0.1.10080        *.*                    LISTEN     
tcp6       0      0  ::1.28017              *.*                    LISTEN     
tcp4       0      0  127.0.0.1.28017        *.*                    LISTEN     
tcp6       0      0  ::1.10000              *.*                    LISTEN     
tcp4       0      0  127.0.0.1.10000        *.*                    LISTEN     
tcp6       0      0  ::1.10081              *.*                    LISTEN     
tcp4       0      0  127.0.0.1.10081        *.*                    LISTEN     
tcp6       0      0  ::1.80                 *.*                    LISTEN     
tcp4       0      0  127.0.0.1.80           *.*                    LISTEN

Я тестировал VM Fusion в двух сетевых конфигурациях (NAT и Bridged), и оба демонстрируют одинаковое поведение.

Возможно ли, что:

  1. есть брандмауэр IPTABLES в ОС хоста (в Mac OS X нет команды iptables)?
  2. есть ли какая-то защита в VMware Fusion, которая блокирует определенные порты от гостя к хосту?
  3. есть ли защита, встроенная в службы linux, так что некоторые службы только localhost не будут туннелироваться?

Любое руководство приветствуется. Для полноты, вот журнал транзакции SSH с использованием подробного параметра:

OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /var/root/.ssh/config
debug1: Applying options for testbed
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to testbed [XX.XX.XX.XXX] port 15922.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /var/root/.ssh/id_rsa type -1
debug1: identity file /var/root/.ssh/id_rsa-cert type -1
debug1: identity file /var/root/.ssh/id_dsa type -1
debug1: identity file /var/root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[testbed]:15922' is known and matches the RSA host key.
debug1: Found key in /var/root/.ssh/known_hosts:7
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /path/to/my/private-key.ppk
debug1: Server accepts key: pkalg ssh-dss blen 817
debug1: Authentication succeeded (publickey).
Authenticated to testbed ([10.12.1.154]:15922).
debug1: Local connections to localhost:80 forwarded to remote address testbed:80
debug1: Local forwarding listening on 127.0.0.1 port 80.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 80.
debug1: channel 1: new [port listener]
debug1: Local connections to localhost:10081 forwarded to remote address testbed:10081
debug1: Local forwarding listening on 127.0.0.1 port 10081.
debug1: channel 2: new [port listener]
debug1: Local forwarding listening on ::1 port 10081.
debug1: channel 3: new [port listener]
debug1: Local connections to localhost:10000 forwarded to remote address testbed:10000
debug1: Local forwarding listening on 127.0.0.1 port 10000.
debug1: channel 4: new [port listener]
debug1: Local forwarding listening on ::1 port 10000.
debug1: channel 5: new [port listener]
debug1: Local connections to localhost:28017 forwarded to remote address testbed:28017
debug1: Local forwarding listening on 127.0.0.1 port 28017.
debug1: channel 6: new [port listener]
debug1: Local forwarding listening on ::1 port 28017.
debug1: channel 7: new [port listener]
debug1: Local connections to localhost:10080 forwarded to remote address testbed:5984
debug1: Local forwarding listening on 127.0.0.1 port 10080.
debug1: channel 8: new [port listener]
debug1: Local forwarding listening on ::1 port 10080.
debug1: channel 9: new [port listener]
debug1: Local connections to localhost:6800 forwarded to remote address testbed:6800
debug1: Local forwarding listening on 127.0.0.1 port 6800.
debug1: channel 10: new [port listener]
debug1: Local forwarding listening on ::1 port 6800.
debug1: channel 11: new [port listener]
debug1: Remote connections from testbed:10137 forwarded to local address localhost:10137
debug1: channel 12: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: remote forward success for: listen 10137, connect localhost:10137
debug1: All remote forwarding requests processed
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
Last login: Mon Sep  3 12:27:10 2012 from something.somenet
[me@testbed ~]$ debug1: Connection to port 10080 forwarding to testbed port 5984 requested.
debug1: channel 13: new [direct-tcpip]
channel 13: open failed: connect failed: Connection refused
debug1: channel 13: free: direct-tcpip: listening port 10080 for testbed port 5984, connect from 127.0.0.1 port 54639, nchannels 14
debug1: Connection to port 10080 forwarding to testbed port 5984 requested.
debug1: channel 13: new [direct-tcpip]
channel 13: open failed: connect failed: Connection refused
debug1: channel 13: free: direct-tcpip: listening port 10080 for testbed port 5984, connect from 127.0.0.1 port 54640, nchannels 14

Привязаны ли какие-либо службы гостю к localhost? Если вы выполните ssh-пересылку с (host) localhost: 8080 на (guest) 10.x.y.z: 80, а служба прослушивает (guest) 127.0.0.1:80, вам будет отказано в соединении.

Попробуйте создать туннель из 127.0.0.1:port в 127.0.0.1:port, где первый - хост, а второй - гостевой.