Não é possível acessar a Internet do convidado do VirtualBox (Arch Linux)

Question

Estou usando o VirtualBox 5.0.20. A máquina host é um MacBook rodando OS X 10.11.5 (El Capitan). O sistema operacional convidado é o Arch Linux de 64 bits. Quando eu instalei o Arch da ISO, a conectividade com a internet do convidado estava boa. No entanto, uma vez que iniciei o sistema instalado, não consegui mais acessar a Internet (por exemplo, o ping 8.8.8.8 simplesmente pára indefinidamente).

A máquina virtual possui dois adaptadores de rede: um em ponte e um somente host. Eu tentei mudar a ponte para um adaptador NAT, bem como conectar a ponte de uma vez para a interface sem fio do host e em outro momento para a interface com fio do host. O convidado não pode acessar a internet sob nenhuma dessas configurações.

O sistema operacional convidado ativou systemd-networkd.service e systemd-resolved.service. Ele não tem nenhum outro serviço de rede ativado que eu saiba. Se possível, gostaria de me ater a esses serviços, em vez de mudar para um serviço diferente, mas vou mudar se houver alguma falha inerente nesses serviços que é a raiz do meu problema.

Dentro do sistema operacional convidado, o conteúdo do arquivo de rede do adaptador em ponte:

[root@arch64 ~]# cat /etc/systemd/network/bridged.network 
[Match]
Name=enp0s3

[Network]
DHCP=ipv4

E o conteúdo do arquivo de rede do adaptador somente host:

[root@arch64 ~]# cat /etc/systemd/network/host-only.network 
[Match]
Name=enp0s8

[Network]
Address=192.168.56.2/24
Gateway=192.168.56.1

O adaptador em ponte adquire com sucesso uma concessão de DHCP e eu posso pingar hosts na minha LAN, mas não consigo pingar nada além do roteador da LAN. A conexão de internet do host está bem.

Mais informações:

[root@arch64 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:1a:7d:74 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.5/24 brd 192.168.0.255 scope global dynamic enp0s3
       valid_lft 3598sec preferred_lft 3598sec
    inet6 fe80::a00:27ff:fe1a:7d74/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:3c:0a:7d brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.2/24 brd 192.168.56.255 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe3c:a7d/64 scope link 
       valid_lft forever preferred_lft forever

[root@arch64 ~]# ip route
default via 192.168.56.1 dev enp0s8  proto static 
default via 192.168.0.1 dev enp0s3  proto dhcp  src 192.168.0.5  metric 1024 
192.168.0.0/24 dev enp0s3  proto kernel  scope link  src 192.168.0.5 
192.168.0.1 dev enp0s3  proto dhcp  scope link  src 192.168.0.5  metric 1024 
192.168.56.0/24 dev enp0s8  proto kernel  scope link  src 192.168.56.2 

    

Answer 1

Por minha configuração, eu tinha dois arquivos de unidade de rede systemd: um para o adaptador em ponte e um para o adaptador somente host. Eu queria que o adaptador em ponte tivesse um endereço dinâmico porque a máquina virtual está em um laptop que se move entre redes, e eu queria que o adaptador somente host tivesse um endereço estático para que eu pudesse acessá-lo, como por ssh, sem ter para determinar manualmente o endereço.

No entanto, ao criar os arquivos da unidade de rede, copiei cegamente o que encontrei em um tutorial do wiki - uma seção descrevendo como configurar rapidamente um endereço dinâmico e a outra como configurar rapidamente um endereço estático. Obviamente, o tutorial pressupunha que eu usaria uma ou outra configuração simples - não ambas lado a lado, o que é um cenário mais complexo.

Basta dizer que o arquivo de rede do adaptador somente host tinha a opção Gateway especificada, enquanto o arquivo do adaptador em ponte não. Portanto, parece que o gateway do adaptador somente host tornou-se a rota preferencial para o tráfego proveniente da máquina virtual. Remover esta opção do arquivo de rede resolveu o problema.

Arquivo de rede do adaptador somente host após correção (removido a opção Gateway):

[root@arch64 ~]# cat /etc/systemd/network/host-only.network 
[Match]
Name=enp0s8

[Network]
Address=192.168.56.2/24