SO virtualbox convidado através de vpn

43

Eu tenho um convidado do Oracle Linux executando um servidor Web no VirtualBox em um host do Windows 7. Preciso configurar a rede para que eu possa fazer três coisas:

  1. o host pode se conectar ao convidado através de um navegador e ssh
  2. o convidado pode conversar com outros servidores na rede interna através da VPN do host
  3. o hóspede pode acessar a internet externa

Eu li algumas respostas e tentei algumas configurações, e aqui está o que acontece:

Bridged

  1. host não pode alcançar o convidado
  2. o convidado não pode ver através da VPN
  3. convidado pode acessar a internet

NAT

  1. host não pode alcançar o convidado
  2. convidado pode ver através da VPN
  3. convidado não pode acessar a internet

Somente host

todas as 3 condições falham.

Rede NAT

  1. host não pode alcançar o convidado
  2. convidado pode ver através da VPN
  3. convidado não pode acessar a internet

Devo salientar também que, às vezes, o host está conectado por meio de uma VPN, enquanto outras, simplesmente é conectado diretamente à rede corporativa. Quando conectado diretamente, um adaptador em ponte satisfaz todas as 3 condições. Idealmente, haveria uma configuração que satisfaça todas as três condições, independentemente de haver uma VPN ou uma conexão direta.

ewok
fonte
Uma conexão VPN geralmente tem seu próprio adaptador, então meu primeiro pensamento é que você precisaria conectá-la ao adaptador VPN (quando conectado à VPN).
Ƭᴇcʜιᴇ007
I ponte a VM para o adaptador VPN e não obter um endereço IP
ewok
Você pode dizer se este é um adaptador de camada2 ou camada3?
MariusMatutiae
@MariusMatutiae desculpe, não sei o que você quer dizer.
ewok
Que tipo de VPN é essa?
MariusMatutiae 15/10

Respostas:

63

Eu tive exatamente o mesmo problema e resolvi o problema, por isso, fico feliz em explicar o problema e a solução em detalhes.

Sem envolver uma VPN

É importante entender a configuração necessária para atender aos seus requisitos sem envolver uma VPN. Além disso, essas informações pressupõem que nenhum firewall de software esteja interferindo, nem no host nem no convidado.

Sem uma VPN, isso normalmente é resolvido com a criação de dois adaptadores de rede na configuração da máquina virtual.

O primeiro adaptador deve estar definido no NATmodo, que permita ao convidado acessar recursos de rede (incluindo a Internet) através da interface de rede do host.

Adaptador 1: NAT

O segundo adaptador deve estar definido como Host-only, o que permite a comunicação bidirecional entre o host e o convidado.

Este adaptador é um pouco mais complexo de configurar do que o primeiro, porque requer a modificação das preferências de rede global do VirtualBox para configurar o adaptador somente host (nota: isso requer privilégios de administrador).

No VirtualBox, vá para File -> Preferences -> Network. Clique na Host-only Networksguia e clique no pequeno +ícone para adicionar um novo adaptador. Você será solicitado a elevar as permissões do VirtualBox.

O preenchimento da Adapterguia é obrigatório; deve ser algo como isto (ignore o adaptador rotulado #2; que é usado para algo não relacionado):

Preferências de rede 1

Os valores na DHCPguia do servidor são opcionais. Se você pretende codificar o endereço IP desse adaptador na configuração de rede do convidado, esses valores são desnecessários. Se, por outro lado, você pretende usar o DHCP, os valores podem ser algo assim:

Preferências de rede 2

A última etapa em relação à configuração do VirtualBox é voltar à configuração de rede da VM e adicionar o segundo adaptador, que faz referência ao adaptador somente host que acabamos de criar:

Adaptador 2: Somente Host

Agora, no sistema operacional convidado, a rede deve ser configurada para utilizar essas duas interfaces de rede.

No Debian ou Ubuntu GNU / Linux, a configuração é tão simples quanto modificar /etc/network/interfacespara se parecer com isto:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

# The secondary network interface
auto eth1
iface eth1 inet static
     address 192.168.56.101
     netmask 255.255.255.0

(o purista pode preferir utilizar o /etc/network/interfaces.ddiretório, mas isso está além do escopo desta explicação)

Reinicie os serviços de rede do convidado ou, mais simplesmente, reinicie toda a VM do convidado, e tudo deve "funcionar".

Nesse ponto, deve-se conseguir efetuar ping na VM convidada 192.168.56.101e receber uma resposta (desde que um firewall de software não esteja interferindo).

Da mesma forma, um deve poder executar ping no host em 10.0.2.2. Esse endereço IP parece estar "codificado" na implementação de NAT do VirtualBox, ou pelo menos especificado por meio de alguma diretiva de configuração não óbvia, e há poucas informações disponíveis sobre sua origem. Mas, infelizmente, "simplesmente funciona".

Dada essa configuração, todas as três condições descritas em sua pergunta são atendidas.

Enter: a VPN

Mas, aqui está o problema. A introdução da VPN causa um problema de parada da exibição (bem, dependendo da VPN específica e de sua configuração).

As VPNs modernas são capazes de dividir o encapsulamento , necessário para a configuração do VirtualBox acima mencionada para funcionar de acordo com seus três requisitos. Por (boas) razões de segurança, o tunelamento dividido geralmente é desativado, e esse é precisamente o problema no seu caso (e no meu).

Quando você se conecta à VPN, o cliente VPN (Cisco AnyConnect Secure Mobility Client, 3.1.02026, no meu caso) examina as tabelas de roteamento do computador host, lembra-se delas e as distribui com valores que geralmente vêm de local gerenciado (ou seja, mesmo com privilégios de administrador local, é impossível substituir as configurações).

Você pode examinar as tabelas de roteamento por si mesmo abrindo command.exe(no Windows):

C:\>route print

Antes de conectar-se à VPN, a tabela de roteamento contém entradas cruciais que permitem que essa configuração do VirtualBox funcione corretamente. A conexão à VPN faz com que essas entradas sejam removidas, o que impede a comunicação entre o host e o convidado.

(Existem muitas outras entradas que omiti aqui, pois são irrelevantes para a causa raiz desse comportamento.)

Antes de conectar-se à VPN:

     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266

Após conectar-se à VPN:

     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266

O cliente VPN remove as seguintes linhas:

     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266

Sem essas duas últimas entradas, o host e o convidado não podem se comunicar, e esse é precisamente o comportamento pretendido quando o tunelamento dividido é desativado na configuração da VPN.

Normalmente, esses dois comandos restaurariam essas rotas:

C:\>route ADD 192.168.56.0 MASK 255.255.255.0 192.168.56.1 METRIC 266
C:\>route ADD 192.168.56.255 MASK 255.255.255.255 192.168.56.1 METRIC 266

Mas o cliente VPN permanece vigilante: intercepta tentativas de modificar a tabela de roteamento. Meu cliente parece permitir a segunda entrada, mas não a primeira. (E pode pavimentar os dois periodicamente; não testei isso.)

Se sua VPN específica e sua configuração de atendente permitem que o tunelamento dividido seja ativado, normalmente é ativado assim:

Cliente VPN da Cisco: permite acesso aos recursos da LAN

Ao se desconectar da VPN, os clientes VPN bem comportados restaurarão as tabelas de roteamento existentes antes da conexão. Meu cliente VPN parece fazer isso de maneira confiável, o que é benéfico porque significa que a VM convidada não precisa ser reiniciada quando eu me conecto ou me desconecto da VPN. Nesses casos, o adaptador secundário da VM é redefinido, mas ele adquire seu endereço IP de forma automática e transparente, restaurando a comunicação entre o host e o convidado quase que imediatamente. Melhor ainda, as montagens NFS entre o host e o convidado (estou usando montagens CIFS) permanecem conectadas nas operações de conexão / desconexão da VPN.

No caso improvável de sua VPN permitir o tunelamento dividido, pode ser uma simples questão de habilitá-lo; nesse caso, eu gostaria de saber se você "tudo funciona" ou não.

Ben Johnson
fonte
5
Muito obrigado por todo o esforço nesta resposta (imagens e tudo). Ajudou muito a sua explicação!
Edenshaw #
Muito bem, Ben! Isso me ajudou a entender meus problemas com a VPN e a articular claramente meu caso no relatório de incidentes à TI!
precisa saber é o seguinte
11
Para sua informação, tenho acesso ao recurso "Permitir acesso local (LAN)" no AnyConnect e posso confirmar que marcar esta caixa de seleção não impede que as rotas sejam excluídas.
Lqueryvg
-1

Como eu uso meu windows host vpn no guest linux mint machine

Defina meu vpn para usar números de porta fixos nas configurações

Defina a rede vm como NAT

Defina as configurações do proxy linux no ip 10.0.2.2 (Gateway NAT da caixa virtual padrão) e as portas que eu inseri manualmente no meu vpn

mustafa candan
fonte