Проблемы с сетью в гостевых виртуальных машинах VirtualBox

Question

Я не могу подключиться к Интернету с виртуальных машин VirtualBox - как Windows 7, так и Debian Linux. Мне нужно выяснить, что не так, чтобы я мог снова запустить эти виртуальные машины.

У меня есть лэптоп Debian, на котором в прошлом работали виртуальные машины VMware, а теперь виртуальные машины VirtualBox без каких-либо проблем. Большинство моих виртуальных машин настроили мостовую сеть через Wi-Fi карту моего ноутбука, а мой домашний маршрутизатор обслуживает адреса DHCP на ноутбуке и его виртуальных машинах.

В последнее время я также использую Docker и Docker Compose без проблем. У меня есть мост docker0, но сетевой менеджер моего ноутбука также показал мосты br-xxxxxxxxxxxx, а также другие мосты, с которыми я не знаком, но я замечаю, что получаю все больше и больше каждый раз, когда создаю или, возможно, просто запускаю контейнеры Docker.

В любом случае, я был в состоянии использовать мостовую сеть в гостевых системах VirtualBox для подключения с хост-ноутбука к гостевым виртуальным машинам через SSH, HTTP и т.д. И наоборот, а также для подключения с ноутбука и с гостевых виртуальных машин к Интернет, по крайней мере, возможность пинговать Google 8.8.8.8.

Я не уверен, что это является причиной, но это определенно отличалось: в выходные я создал файл docker-compose.yaml, объединяющий воедино из других источников, и добавил следующее в свой, который раньше не использовал в любом docker-compose.yaml перед:

networks:
   default:
      driver: bridge

Из всех моих файлов Docker Compose это единственный файл с networks .

Когда я впервые рассказал об этом с помощью docker-compose up , я мог поклясться, что увидел другой пузырь в области уведомлений для Network Manager, но я не уверен.

Обычно я вспоминаю, что получаю дополнительные мосты, и через пару дней или недель я прохожу через Редактирование соединений и вручную удаляю эти дополнительные мосты, когда они стареют.

Во всяком случае, я не обращал особого внимания на дополнительный пузырь, и мои контейнеры появились без проблем. Я выставил порты и смог просматривать их через http://localhost:nnnn, как обычно, и я об этом не задумывался.

Сегодня, примерно за неделю или две, я запустил одну из своих виртуальных машин VirtualBox - гость Windows 7. Как только он появился, я понял, что не могу подключиться к Интернету. Я запустил командную строку и понял, что не могу даже ping 8.8.8.8 , а ipconfig сообщает ни одного IP-адреса.

Я попробовал одну из моих виртуальных машин Debian. То же самое - не может ping 8.8.8.8 и IP-адрес не сообщается /sbin/ifconfig eth0 .

Хозяин ноутбука очень доволен частным IP-адресом, и я захожу на сайт http://superuser.com, чтобы опубликовать этот вопрос.

Каковы мои следующие шаги для устранения этой проблемы?

РЕДАКТИРОВАТЬ: Я не совсем уверен, что я сделал, но мне удалось заставить свои виртуальные машины получить IP-адрес и подключиться к Интернету.

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

Я помню ранее перезапуск демона Docker на хосте (sudo /etc/init.d/docker restart), но после этого я не увидел никаких явных изменений.

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

До перезагрузки я выполнил глупые небольшие ifdown/ifup и ipconfig /release и ipconfig /renew , а затем начал удалять те мосты, которые я упомянул в Network Manager, но на этот раз я удалил все мосты - даже те, которые были текущими и мост docker0. В то время это не имело никакого значения.

Я также включал и выключал виртуальные машины в произвольном порядке.

Вот и все.

Обновление (15.03.2008): теперь намного хуже; мои виртуальные машины испытывают трудности с получением IP-адреса и теперь вообще не могут пропинговать 8.8.8.8 изнутри виртуальных машин. Это происходит как с виртуальными машинами VirtualBox, так и с виртуальными машинами VMware.

Контейнеры Docker могут без проблем попасть в Интернет.

Вот мои мосты на хост-ноутбуке, когда у меня работает одна из моих виртуальных машин Debian:

# brctl show
bridge name bridge id       STP enabled interfaces
br-993886a09e53     8000.02424635b59c   no      
br-9d3771956e43     8000.0242c5e9afa6   no      
br-ce4e98cb7458     8000.0242561fb6fc   no      
br-ef846b86506c     8000.0242982b55d7   no      
br-fd2186a1e375     8000.02426f4ae98a   no      
docker0     8000.024258c6aaa0   no

Сетевые настройки виртуальной машины показывают ее адаптер 1 прикреплен к мостовому Adapter Name wlan0. Промежуточный режим установлен на «Запретить» и проверен « Подключен кабель» .

Вот устройства, которые у меня есть:

# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 24:b6:fd:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether c0:18:85:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 00:50:56:xx:xx:xx brd ff:ff:ff:ff:ff:ff
5: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 00:50:56:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: br-ef846b86506c: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:98:xx:xx:xx brd ff:ff:ff:ff:ff:ff
7: br-fd2186a1e375: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:6f:xx:xx:xx brd ff:ff:ff:ff:ff:ff
8: br-993886a09e53: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:46:xx:xx:xx brd ff:ff:ff:ff:ff:ff
9: br-9d3771956e43: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:c5:xx:xx:xx brd ff:ff:ff:ff:ff:ff
10: br-ce4e98cb7458: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:56:xx:xx:xx brd ff:ff:ff:ff:ff:ff
11: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:58:xx:xx:xx brd ff:ff:ff:ff:ff:ff
12: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 0a:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff
13: vboxnet1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 0a:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff

Вот мои правила брандмауэра. Список был намного короче, пока я не попытался установить ufw и gufw , затем запустил gufw , включил его, а затем отключил.

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ufw-before-logging-input  all  --  anywhere             anywhere            
ufw-before-input  all  --  anywhere             anywhere            
ufw-after-input  all  --  anywhere             anywhere            
ufw-after-logging-input  all  --  anywhere             anywhere            
ufw-reject-input  all  --  anywhere             anywhere            
ufw-track-input  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DOCKER-ISOLATION  all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ufw-before-logging-forward  all  --  anywhere             anywhere            
ufw-before-forward  all  --  anywhere             anywhere            
ufw-after-forward  all  --  anywhere             anywhere            
ufw-after-logging-forward  all  --  anywhere             anywhere            
ufw-reject-forward  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ufw-before-logging-output  all  --  anywhere             anywhere            
ufw-before-output  all  --  anywhere             anywhere            
ufw-after-output  all  --  anywhere             anywhere            
ufw-after-logging-output  all  --  anywhere             anywhere            
ufw-reject-output  all  --  anywhere             anywhere            
ufw-track-output  all  --  anywhere             anywhere            

Chain DOCKER (6 references)
target     prot opt source               destination         

Chain DOCKER-ISOLATION (1 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain ufw-after-forward (1 references)
target     prot opt source               destination         

Chain ufw-after-input (1 references)
target     prot opt source               destination         

Chain ufw-after-logging-forward (1 references)
target     prot opt source               destination         

Chain ufw-after-logging-input (1 references)
target     prot opt source               destination         

Chain ufw-after-logging-output (1 references)
target     prot opt source               destination         

Chain ufw-after-output (1 references)
target     prot opt source               destination         

Chain ufw-before-forward (1 references)
target     prot opt source               destination         

Chain ufw-before-input (1 references)
target     prot opt source               destination         

Chain ufw-before-logging-forward (1 references)
target     prot opt source               destination         

Chain ufw-before-logging-input (1 references)
target     prot opt source               destination         

Chain ufw-before-logging-output (1 references)
target     prot opt source               destination         

Chain ufw-before-output (1 references)
target     prot opt source               destination         

Chain ufw-reject-forward (1 references)
target     prot opt source               destination         

Chain ufw-reject-input (1 references)
target     prot opt source               destination         

Chain ufw-reject-output (1 references)
target     prot opt source               destination         

Chain ufw-track-input (1 references)
target     prot opt source               destination         

Chain ufw-track-output (1 references)
target     prot opt source               destination         

Я попытался создать /etc/sysctl.d/bridge.conf со следующим:

# Reference: https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf

net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0

Затем запустил sysctl -p .

Я попытался запустить Wireshark, а также tcpdump на хост-ноутбуке и посмотреть, что произошло, когда я запустил dhclient eth0 внутри виртуальной машины:

# tcpdump -ni wlan0 port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:03:45.275713 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.275788 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.418183 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.418277 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:49.220658 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:49.220749 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:51.953865 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:51.953936 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.275713 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.275788 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.418183 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.418277 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:49.220658 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:49.220749 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:51.953865 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:51.953936 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:04.084840 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:04.084909 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:16.898585 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:16.898688 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:26.201038 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:26.201150 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300

Если я все сделал правильно, это говорит о том, что трафик покидает мост, но не возвращается, так что это проблема входа?

Также я заметил сегодня, что другой ноутбук в той же домашней сети не может войти через SSH на этот ноутбук; Я не уверен, если это связано.

Я могу SSH к ноутбуку от себя:

$ ssh user@localhost
$ ssh user@192.168.1.8

Тем не менее, если я пытаюсь подключиться через WinSCP с другого ноутбука, похоже, истекло время ожидания. Wireshark абсолютно не проявлял активности, поступая в этот ноутбук с другого ноутбука.

Этот ноутбук имел обыкновение подключаться около шести недель назад.

Я проверил конфигурацию роутера, и не было ничего необычного.

Аналогичным образом я попытался подключиться через SSH с телефона Android с помощью приложения ConnectBot. Раньше это тоже работало, и теперь я вижу следующее в выводе ConnectBot:

Connecting to 192.168.1.8:22 via ssh

Connection Lost
recvfrom failed: ECONNRESET (Connection reset by peer)
recvfrom failed: ECONNRESET (Connection reset by peer)

Answer 1

Хотя я не думаю, что у меня есть четкий ответ для вас на основе предоставленных данных, я могу предоставить некоторые шаги, которые в целом могут помочь вам решить эту проблему.

Во-первых, если проблема повторяется, и вы используете обычные мостовые соединения Linux, вы можете использовать brctl show чтобы получить список мостов и подключенных устройств, например:

$ brctl show
bridge name bridge id       STP enabled interfaces
bridge0     8000.fc4ee55116da   no      eno1
                                        vnet0
                                        vnet1
docker0     8000.0242e112327f   no      vethb4eb5fc
virbr0      8000.5254004579e4   yes     virbr0-nic

Выше, у bridge0 есть моя сетевая карта и две виртуальные машины, каждая с одним интерфейсом за штуку. Я также запускаю Docker, у меня есть докерский мост, и у меня есть сеть libvirt с NAT, которая порождает virtio как мост (но у меня сейчас нет виртуальных машин, которые бы с этим ничего не делали). Я полагаю, что если вы испытываете проблемы, вы можете отключиться или не появиться под мостом. Вы можете использовать ip link show чтобы увидеть, какие устройства присутствуют.

Если там все в порядке, возможно, межсетевой экран / сетевой фильтр блокирует трафик моста. Вы можете прочитать больше об этом здесь на странице документации Libvirt (я знаю, что вы используете VirtualBox, но это относится ко всем мостам, а не только к одному механизму виртуализации).

Наконец, вы можете захотеть посмотреть, попадает ли трафик на виртуальные машины вообще. Вы можете сделать это с помощью tcpdump, хотя, если вы не знакомы с сетью, может быть немного сложно расшифровать трафик. Просто выберите интерфейс и нажмите на него; Могу ли я порекомендовать коснуться моста, чтобы увидеть, можно ли вообще увидеть трафик DHCP, исходящий из виртуальной машины. Шаги будут примерно такими:

1. На виртуальной машине запустите dhclient eth0 или подходящий процесс, чтобы попытаться получить IP-адрес от вашего DHCP-сервера.

2. На хосте коснитесь моста и проверьте трафик DHCP (UDP-порт 67).

   $ sudo tcpdump -ni bridge0 port 67
   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
   listening on bridge0, link-type EN10MB (Ethernet), capture size 262144 bytes
   

3. Если вы видите, что трафик, проходящий мимо, имеет MAC-адрес вашей виртуальной машины, то трафик покидает мост, но, вероятно, не возвращается обратно, что означает, что у нас проблема входа. Если вы вообще не видите трафика, коснитесь устройства vnet же, как и сам мост, и посмотрите, видите ли вы трафик DHCP; если вы это сделаете, то движение не покинет мост, то есть у нас проблема с выходом. Оба, вероятно, требуют просмотра правил брандмауэра /sysctls /netfilter.

Answer 2

Перезагрузка домашнего роутера устранила обе проблемы для меня. Удаленный ноутбук смог подключиться по SSH к моему ноутбуку Debian после перезагрузки маршрутизатора, и доступ в Интернет и доступ к локальной сети моей виртуальной машины снова заработали.