ПК (Выпуск Сервера Ubuntu 18.04.01) и ноутбук (VMware Выпуск Сервера Ubuntu 18.04.01) связанный через кабель: проверьте с помощью ping-запросов работы, только односторонние

Чтобы понять, как в конечном счете сделать кластер Беовульфа, я попробовал, после этого чтения, Создающего простой кластер Беовульфа с Ubuntu для соединения моего ПК с Выпуском Сервера Ubuntu 18.04.01 с моим ноутбуком, где я установил версию VMware того же Выпуска Сервера Ubuntu 18.04.01.

Это - содержание файла/etc/hosts в версии VMware Ubuntu 18.04.01 в ноутбуке:

127.0.0.1       localhost
127.0.1.1       ubuntu

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.1.3 pc01

И это - содержание файла/etc/hosts Ubuntu 18.04.01 ПК:

127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
192.168.229.128 laptop
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
192.168.1.3 pc01
172.17.0.1 pc01
172.18.0.1 pc01
172.20.0.1 pc01
172.19.0.1 pc01
172.21.0.1 pc01

Теперь... проверка с помощью ping-запросов от ноутбука Ubuntu до Ubuntu-ПК следует за 100%:

marco@ubuntu:~$ ping -c 3 pc01
PING pc01 (192.168.1.3) 56(84) bytes of data.
64 bytes from pc01 (192.168.1.3): icmp_seq=1 ttl=128 time=1.08 ms
64 bytes from pc01 (192.168.1.3): icmp_seq=2 ttl=128 time=2.42 ms
64 bytes from pc01 (192.168.1.3): icmp_seq=3 ttl=128 time=2.04 ms

--- pc01 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2017ms
rtt min/avg/max/mdev = 1.087/1.851/2.420/0.563 ms
marco@ubuntu:~$

В то время как проверка с помощью ping-запросов от Ubuntu-ПК к ноутбуку Ubuntu перестала работать полностью:

marco@pc01:~$ ping -c 3 laptop
PING laptop (192.168.229.128) 56(84) bytes of data.

--- laptop ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2040ms

Какова могла быть причина? Нетерпеливое ожидание Вашей любезной помощи. Marco

Обновления, как справедливо требуется: 1) sudo iptables-сохраняют в ноутбуке, дает "пустой" вывод:

marco@ubuntu:~$ sudo iptables-save
marco@ubuntu:~$

2) вывод IP в ноутбуке:

marco@ubuntu:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state
 UP group default qlen 1000
    link/ether 00:0c:29:b0:ad:7b brd ff:ff:ff:ff:ff:ff
    inet 192.168.229.128/24 brd 192.168.229.255 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:feb0:ad7b/64 scope link
       valid_lft forever preferred_lft forever

VirtualMachineSettings3): после включения первой опции "Bridged: Connected directly to the physical network, should I enable also the sub-option " Replicate physical network connection state"?

Три Важных Обновления: 1) Согласно этому документу онлайн: VMwareWorkstation9DocumentationCenter, который опция "Replicate physical network connection state" должна быть включена для разрешения IP-адресу, который будет возобновлен при перемещении от одной проводной или беспроводной сети до другого. Так, я сделал две пробных версии, включив эту опцию. Но что-то странное произошло: виртуальная машина, открытая успешно с моим именем пользователя и моим паролем. Но я не мог получить доступ к нему посредством обычного соединения SSH, потому что мой пароль не был распознан. После отключения опции "Bridged: Connected directly to the physical connection", при включении опции "NAT: used to share the host's IP address", мой пароль был распознан соединением SSH также...

2) Я обнаружил через ifconfig | grep inet, что, после включения опции "Bridged: Connected directly to the physical network" и подопции "Replicate physical network connection state", inet становится 127.0.0.1 Затем в/etc/hosts моего ПК, я обновил IP-адрес ноутбука к 127.0.0.1

marco@pc01:~$ ping -c 3 laptop
PING laptop (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64   
time=0.046 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 
time=0.025 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 
time=0.042 ms

--- laptop ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2053ms
rtt min/avg/max/mdev = 0.025/0.037/0.046/0.011 ms

Но тем не менее мой пароль не распознан при попытке получить доступ к VMware Виртуальный Machine'Ubuntu посредством соединения SSH...

3) Я попробовал также неспособное другая опция в Настройках VMware: VirtualMachineSettings02: "Только для хоста: частная сеть совместно использовала с хостом" С этой включенной опцией, как с опцией "NAT:Used to share the host's IP address", я могу соединиться с виртуальной машиной Ubuntu посредством соединения SSH, потому что в этом случае пароль распознан. Но, после обновления IP-адреса в/etc/hosts ПК ping к ноутбуку перестал работать полностью снова:

marco@pc01:~$ ping -c 3 laptop
PING laptop (192.168.30.128) 56(84) bytes of data.

--- laptop ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2055ms

Нетерпеливое ожидание Вашей любезной помощи. Marco

0
задан 28 February 2019 в 06:11

1 ответ

marco@ubuntu:~$ ping -c 3 pc01
PING pc01 (192.168.1.3) 56(84) bytes of data.

и

marco@pc01:~$ ping -c 3 laptop
PING laptop (192.168.229.128) 56(84) bytes of data.

дает нам хорошую подсказку: эти две машины находятся в различных подсетях. Это было конкретно причиной, я попросил, чтобы Вы не отредактировали IP: они дают нам информацию.

Сетевая карта (NIC) на ноутбуке, вероятно, установлена на режим NAT в Ваших настройках VMware. Это означает, что VMware выполняет подмену всего трафика, происходящего с виртуальной машины на Ваши другие сетевые устройства.

Измените настройки в конфигурации виртуальной сети к режиму моста и удостоверьтесь, что ноутбук имеет IP в той же подсети (например, 192.168.1.x) как сервер, от которого Вы пытаетесь получить доступ к нему.

Это Вопросы и ответы по superuser.com дает немного больше информации о различных режимах NIC VMware Workstation.

2
ответ дан 26 October 2019 в 03:31

Другие вопросы по тегам:

Похожие вопросы: