Проще говоря, перенаправленный порт 45922 доступен на хосте через 127.0.0.1:45922, но не доступен на самом хосте через его общедоступный IP-адрес плюс номер порта 45922. Подробности в следующем.

Хост ОС: Ubuntu 14.04.2 LTS
Гостевая ОС: CentOS 6.6 (Финал)
Виртуальная машина: VMware Player 7

ВМ запускается в терминале с помощью следующей команды:

vmrun -T player start vmware/CentOS/CentOS.vmx nogui

У хоста есть публичный IP-адрес, который является 128.xx221
Гость имеет два сетевых адаптера, один соединен мостом и имеет открытый IP-адрес 128.xx219, другой работает в режиме NAT и имеет локальный IP-адрес 192.168.106.129.

Содержимое файла конфигурации хоста /etc/vmware/vmnet8/nat/nat.conf

45922 = 192.168.106.129:22
45911 = 192.168.106.129:5911

Первая переадресация порта для SSH, вторая для VNC. В основном они страдают от одной и той же проблемы, поэтому я хотел бы собрать их здесь.

Наблюдаемые проблемы:

  1. На гостя CentOS:
    SSH 127.0.0.1 работает
    SSH 192.168.106.129 работает

  2. На хосте Ubuntu:
    SSH 192.168.106.129 работает
    ssh -p 45922 127.0.0.1 работает
    ssh -p 45922 128.xx221 НЕ работает

  3. Со случайной публичной машины:
    ssh -p 45922 128.xx221 НЕ работает

Однако в то же время мостовая сеть работает нормально. Со случайной публичной машины:
SSH 128.xx219 работает

Ни на хосте, ни на госте не включен брандмауэр. iptables -L возвращает пустые списки.

Похоже, это не проблема межсетевого экрана шлюза, поскольку на хосте открыт другой порт 45940, и он доступен с произвольной общедоступной машины.

Дополнительная информация

Запуск netstat на хосте:

$ netstat -ano | grep 459 
tcp        0      0 0.0.0.0:45911           0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 0.0.0.0:45922           0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 0.0.0.0:45940           0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp6       0      0 :::45940                :::*                    LISTEN      off (0.00/0/0)
udp        0      0 0.0.0.0:45932           0.0.0.0:*                           off (0.00/0/0)

Запуск tcpdump port 45922 на хосте не перехватывает пакет, когда я выполняю ssh -p 45922 128.x.x.221 на самом хосте.

Запуск ssh -vvv -p 45922 128.x.x.221 на случайной машине выдает это:

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 128.x.x.221 [128.x.x.221] port 45922.
debug1: Connection established.
debug1: identity file /home/x/.ssh/id_rsa type -1
debug1: identity file /home/x/.ssh/id_rsa-cert type -1
debug1: identity file /home/x/.ssh/id_dsa type -1
debug1: identity file /home/x/.ssh/id_dsa-cert type -1
debug1: identity file /home/x/.ssh/id_ecdsa type -1
debug1: identity file /home/x/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/x/.ssh/id_ed25519 type -1
debug1: identity file /home/x/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
ssh_exchange_identification: read: Connection reset by peer

Запуск tcpdump port 45922 -vv на хосте выводит следующую информацию, когда я пытаюсь подключиться к гостю со случайной машины в публичной сети:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:56:56.942537 IP (tos 0x0, ttl 60, id 64633, offset 0, flags [DF], proto TCP (6), length 60)
    vcv069158.x.x.x.44417 > dhcp-x221.x.x.x.45922: Flags [S], cksum 0x13ee (correct), seq 584972499, win 25820, options [mss 1291,sackOK,TS val 2545185 ecr 0,nop,wscale 7], length 0
12:56:56.942603 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    dhcp-x221.x.x.x.45922 > vcv069158.x.x.x.44417: Flags [S.], cksum 0x7d30 (incorrect -> 0xfd9e), seq 2889461335, ack 584972500, win 28960, options [mss 1460,sackOK,TS val 1093302 ecr 2545185,nop,wscale 0], length 0
12:56:57.042734 IP (tos 0x0, ttl 60, id 64634, offset 0, flags [DF], proto TCP (6), length 52)
    vcv069158.x.x.x.44417 > dhcp-x221.x.x.x.45922: Flags [.], cksum 0x9c9f (correct), seq 1, ack 1, win 202, options [nop,nop,TS val 2545212 ecr 1093302], length 0
12:56:57.046954 IP (tos 0x0, ttl 60, id 64635, offset 0, flags [DF], proto TCP (6), length 93)
    vcv069158.x.x.x.44417 > dhcp-x221.x.x.x.45922: Flags [P.], cksum 0x7748 (correct), seq 1:42, ack 1, win 202, options [nop,nop,TS val 2545212 ecr 1093302], length 41
12:56:57.046973 IP (tos 0x0, ttl 64, id 151, offset 0, flags [DF], proto TCP (6), length 52)
    dhcp-x221.x.x.x.45922 > vcv069158.x.x.x.44417: Flags [.], cksum 0x7d28 (incorrect -> 0x2c06), seq 1, ack 42, win 28960, options [nop,nop,TS val 1093328 ecr 2545212], length 0
12:57:01.371307 IP (tos 0x0, ttl 64, id 50327, offset 0, flags [DF], proto TCP (6), length 52)
    dhcp-x221.x.x.x.45922 > vcv069158.x.x.x.44416: Flags [R.], cksum 0x7d28 (incorrect -> 0x58b6), seq 81219880, ack 929809342, win 28960, options [nop,nop,TS val 1094409 ecr 2542228], length 0
12:57:27.042892 IP (tos 0x0, ttl 64, id 152, offset 0, flags [DF], proto TCP (6), length 52)
    dhcp-x221.x.x.x.45922 > vcv069158.x.x.x.44417: Flags [R.], cksum 0x7d28 (incorrect -> 0x0eb7), seq 1, ack 42, win 28960, options [nop,nop,TS val 1100827 ecr 2545212], length 0
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

Кажется, что каждый отправленный хостом (221) пакет имеет cksum incorrect . Я понятия не имею, почему это произошло ...

|источник

1 ответ1

0

Я наконец понял, что случилось. Проблема заключалась в том, что «у гостя есть два сетевых адаптера, один соединен мостом и имеет общедоступный IP-адрес 128.xx219, другой работает в режиме NAT и имеет локальный IP-адрес 192.168.106.129». Кажется, мы не должны этого делать. У нас не должно быть двух виртуальных адаптеров на одной виртуальной машине, один из которых работает в режиме моста (подключен к общедоступному Интернету), а другой - в режиме NAT (переведен в общедоступный Интернет).

Решением было просто удалить мостовой адаптер в VMWare Player и сохранить файл конфигурации. Не имеет значения, запускаю ли я виртуальную машину с помощью vmplayer или vmrun .

Кажется, что когда виртуальная машина получает запрос на соединение через переадресацию портов, она пытается подключиться к отправителю запроса, который находится в общедоступном Интернете, но ее попытка проходит через мостовой адаптер вместо адаптера NAT, что приводит к неправильным контрольным суммам. Вероятно, это связано с таблицей маршрутизации на виртуальной машине.

|источник

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