LINUX.ORG.RU
ФорумAdmin

Debian + VMware + Brige - невозможно подключиться извне

 , ,


0

1

Есть ноутбук с OS Win 10 x64 подключением по WiFi к сети На ноутбуке установлена VMware Workstation v12.1.1 но которой создана виртуальная машина с установленной Debian v8.6.0 x64. В настройках сети VMware для данной машины установлен Brige. Требуется получить доступ к Debian извне по SSH. Сам SSH на Debian установлен и настроен. Изнутри (из Debian) подключение работает, с ноутбука или извне подключиться невозможно - тишина как будто на том конце вовсе никого нет.

Ставлю вторую сетевую карту для VMware, делаю ее «только для узла» и без проблем подключаюсь хоть с Debian хоть с Win10 ... но это работает только между ноутом и виртуальной машиной, из вне такая сеть закрыта. NAT ставить не хочу, так как виртуалка нужна как отдельная машина в сети.

Пробовал запускать nmap для обоих машин на Debian и Win10. На Debian показывает открытые порты для виртуалки и винды как они есть. Под Win10 для обоих машин показывает одинаковые порты соответствующие ноутбуку(винде).

Заметил одну особенность: для внешней сети MAC обоих машин одинаковый и соответствует ноутбуку, хотя на Debian показывает свой уникальный MAC сетевой карты.

Получается, что сам Debian отрабатывает подключения по SSH исправно и без проблем. Такое ощущение, что по каким то причинам нет трафика между Win10 и Debian ...

стоит Comodo, но пока не вижу причин на него грешить, так как на других подключениях то работает (вторая сетевая «только для узла»).

В какую сторону копать даже не понимаю ...

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

К сожалению ничего нового в данной статье я не обнаружил. В описании Brige написано именно то, что мне нужно получить. Проблема в том, что по факту не все из этого имеет место быть - в чем причина и пытаюсь разобраться...

Tanatos ()

Собственно лог выполнения nmap для Win (*.*.0.46) и Debian (*.*.0.47)

===============================================================c:\!Portable\nmap-7.40>nmap 192.168.0.46

Starting Nmap 7.40 ( https://nmap.org ) at 2017-02-06 15:57 RTZ 2 (ceia)
Nmap scan report for 192.168.0.46
Host is up (0.000011s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
443/tcp  open  https
445/tcp  open  microsoft-ds
902/tcp  open  iss-realsecure
912/tcp  open  apex-mesh
5357/tcp open  wsdapi

Nmap done: 1 IP address (1 host up) scanned in 7.06 seconds

===============================================================
c:\!Portable\nmap-7.40>nmap 192.168.0.47

Starting Nmap 7.40 ( https://nmap.org ) at 2017-02-06 15:59 RTZ 2 (ceia)
Nmap scan report for 192.168.0.47
Host is up (0.0018s latency).
Not shown: 994 filtered ports
PORT     STATE  SERVICE
135/tcp  closed msrpc
443/tcp  closed https
445/tcp  closed microsoft-ds
902/tcp  closed iss-realsecure
912/tcp  closed apex-mesh
5357/tcp closed wsdapi
MAC Address: 00:0C:29:74:29:70 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 10.55 seconds

===============================================================
root@avzserver:~# nmap 192.168.0.47

Starting Nmap 6.47 ( http://nmap.org ) at 2017-02-06 16:06 MSK
Nmap scan report for 192.168.0.47
Host is up (0.000037s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 24.59 seconds


===============================================================
root@avzserver:~# nmap 192.168.0.46

Starting Nmap 6.47 ( http://nmap.org ) at 2017-02-06 16:07 MSK
Nmap scan report for 192.168.0.46
Host is up (0.00037s latency).
Not shown: 993 filtered ports
PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
443/tcp  open  https
445/tcp  open  microsoft-ds
902/tcp  open  iss-realsecure
912/tcp  open  apex-mesh
5357/tcp open  wsdapi
MAC Address: A4:02:B9:82:C0:53 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 21.47 seconds
===============================================================
Tanatos ()

Как ни печально признавать видимо не доглядел. Несколько экспериментов показали, что при отключении Comodo появляется доступ и к SSH и nmap нормально показывает порты для Debian (*.*.0.47) ... вот только убейте не понимаю какое из правил таким образом режет трафик ... понимаю, что вопрос уже выходит за рамки специализации форума, но если кто-то сможет помочь буду очень признателен!

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

С сервера в локальной сети DHCP и хост и гость.

100% виноват Comodo. Отключаю - работает, включаю - трафик режет. При этом хоть убейте не нахожу как разрешить трафик. Он на него вообще не реагирует. Отключил закрытие портов - должен выдавать оповещения при попытке подключиться к порту ... но подключения между хостом и гостем видимо обрабатываются как-то иначе, оповещения нет, но трафик режется. Уже всерьез рассматриваю смену firewall, проблема в том что не вижу достойных аналогов из бесплатного софта - тупик какой-то.

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

а вы с хоста каким приложением стучитесь по ssh, смотрите что у вас в правилах на это приложение в комодо. Давно правда его не юзал, может там что то изменилось.

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

Это первое что проверил. Прикол в том, что обращение с хоста в гостевую машину Comodo режет даже не спрашивая! Проверил на чистой инсталляции: снес, поставил заново, включил режим пользовательских правил, максимальное количество оповещений (по идее должен выдавать запрос на каждый чих приложения), глобальные правила ставлю все в разрешено, выставляю оповещать о входящих подключениях ... запускаю Putty, спрашивает пустить ли его в сеть ... говорю что ему допустим любой трафик (доверенное приложение) ... и тишина ... на Debian нет записей об обращении (т.е. пакеты не доходят). Закрываю Comodo, соединение проходит на ура. И никаких записей в журнале Comodo, что он прервал какой-то трафик (обозначает как «Заблокированное вторжение») Вот такие дела. Пробую задать вопрос на сайте Comodo, но там регистрация с проверкой и не понятно сколько они будут меня проверять ))). Пока вижу только одно решение - держать костыль специально ради Comodo: для подключения с хоста держать вторую сетевую карту типа «только для узла».

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

Выясняются все новые подробности ... оказывается такая проблема присутствует только для подключения по WiFi. При подключении через проводное соединение пакеты между хостом и гостевой ОС прекрасно проходят. Теперь уже думаю, что может виноват Brige драйвер VMware ... проскакивали в сети сообщения, что VMware имеет проблемы при подключении через WiFi ... но решений не видел ...

Tanatos ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.