VMware может ssh угадать, но не может telnet

Question

Я использую VMware Workstation 9.0.2 в Windows 7 Professional с гостем CentOS 6.4, используя мостовую сеть. Локальная сеть, в которой работает хост, - 192.168.123. *, Хост - статический IP 192.168.123.2, а у гостя - статический IP 192.168.123.70.

Я могу пропинговать и ssh с хоста на гость CentOS, но telnet и http оба не могут соединиться. Я могу telnet и http от гостя к гостю, используя адрес 192.168.123.70, поэтому порты гостя определенно открыты и прослушиваются.

Брандмауэр был отключен на госте, и в журнале нет сообщений о сбое telnet. (Брандмауэр Windows не ограничивает исходящие соединения.)

Я не могу придумать ничего, что могло бы разрешить ssh, но не разрешить telnet. (Я могу подключиться от хоста к гостю, когда использую telnet 192.168.123.70 22 , но telnet 192.168.123.70 23 не подключается).

Другие данные:

Вот вывод из /sbin/ifconfig -a от гостя:

eth0      Link encap:Ethernet  HWaddr 00:0C:29:1F:A5:E3  
          inet addr:192.168.123.70  Bcast:192.168.123.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:589132 errors:0 dropped:0 overruns:0 frame:0
          TX packets:292849 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:864633856 (824.5 MiB)  TX bytes:19627138 (18.7 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:275 errors:0 dropped:0 overruns:0 frame:0
          TX packets:275 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:121617 (118.7 KiB)  TX bytes:121617 (118.7 KiB)

Вот вывод netstat -l от гостя:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State      
tcp        0      0 *:8008                      *:*                         LISTEN      
tcp        0      0 *:8010                      *:*                         LISTEN      
tcp        0      0 *:8011                      *:*                         LISTEN      
tcp        0      0 *:http                      *:*                         LISTEN      
tcp        0      0 *:intu-ec-svcdisc           *:*                         LISTEN      
tcp        0      0 *:ssh                       *:*                         LISTEN      
tcp        0      0 election-t1,:ipp            *:*                         LISTEN      
tcp        0      0 *:https                     *:*                         LISTEN      
tcp        0      0 *:8030                      *:*                         LISTEN      
tcp        0      0 *:ssh                       *:*                         LISTEN      
tcp        0      0 *:telnet                    *:*                         LISTEN      
udp        0      0 *:ipp                       *:*                                     
udp        0      0 192.168.123.70:ntp          *:*                                     
udp        0      0 election-t1,:ntp            *:*                                     
udp        0      0 *:ntp                       *:*                                     
udp        0      0 *:ntp                       *:*                                     

Будем весьма благодарны за любые предложения относительно возможной причины поиска дополнительной информации. У меня нет ментальной модели, которая могла бы объяснить это поведение.

Приложение: перезапустил службу xinetd на гостевой и остановил брандмауэр Windows на хосте - никакого эффекта вообще нет.

Приложение 2: Вывод sudo iptables -L -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Answer 1

Это немного трудно сказать (я должен был сказать после выхода sudo iptables -L -n -v вместо этого, чтобы мы могли видеть интерфейс спецификатором, это, вероятно , lo на правиле , которое появляется , чтобы принять все), но, похоже , межсетевой экран гостя блокирует соединение, поскольку единственное, по-видимому, релевантное согласие, которое у вас есть, относится к state NEW tcp dpt:22 (разрешение новых соединений SSH; существующие соединения TCP обрабатываются по первому правилу).

Попробуйте выполнить sudo iptables -I INPUT 5 -p tcp --dport 80 -j ACCEPT и повторить попытку подключения с хоста; это должно позволить вам подключаться через HTTP. (5 ставит его непосредственно перед правилом REJECT Если это сработает, вам нужно выяснить, как правильно разрешить соединения с хостом по telnet (23/tcp), http (80/tcp) и, возможно, https (443/tcp) порты. (Вероятно, есть способ CentOS, но я не знаком с CentOS конкретно.)

Однако, если это не только для тестирования (и даже тогда у меня возникнут сомнения), пересмотрите свое решение разрешить доступ через telnet. Telnet не зашифрован и совершенно небезопасен; Любой, кто имеет анализатор пакетов в любом месте пути, сможет отслеживать весь трафик, включая незашифрованные имена пользователей и пароли. Telnet восходит к 1969 году, когда Интернет был совсем другим местом. Вместо этого рассмотрите возможность использования только SSH, если только у вас нет определенного приложения, для которого требуется telnet.

Я также заметил, что у вас есть правило REJECT в конце цепочки INPUT, за которым следует политика ACCEPT. Если у вас нет какой-либо конкретной причины для его настройки таким образом, обычный способ установить действие по умолчанию для отклонения - это просто установить политику в цепочке (sudo iptables -P INPUT REJECT должен это сделать); тогда вам не нужно явное правило отклонения.

Answer 2

Если подозревается блокировка брандмауэра, вы можете попробовать некоторые из тестов VMware на IsMyPortBlocked

Вы также можете ввести свой собственный список портов TCP и UDP.