VPN em uma sessão da Área de Trabalho Remota


13

Eu me conecto a um servidor na minha rede local via Área de Trabalho Remota. Preciso fazer uma conexão VPN com a Internet a partir dessa sessão da Área de Trabalho Remota. No entanto, isso desconecta imediatamente minha sessão da área de trabalho remota.

O que está acontecendo aqui e existe uma maneira de corrigi-lo?

Informação extra:

Computador local nº 1:

  • Inicia a sessão RDP para # 2
  • Windows 7
  • 10.1.1.140/24

Computador local # 2:

  • Windows Vista
  • 10.1.1.132/24
  • Inicia a conexão VPN ao IP público
  • VPN é PPTP
  • Defina para obter IP e DNS automaticamente
  • 'Usar gateway padrão na rede remota' está desmarcado
  • 'Ativar LMHosts' está selecionado
  • 'Ativar Netbios' sobre TCP / IP está selecionado
  • Tem a capacidade de ser multi-homed (ou seja, possui 2 nichos)

Roteador ADSL voltado para o público:

  • Servidor VPN
  • recebe conexão de # 2 via IP externo
  • A rede interna é 192.168.0.0/24

Posso fazer uma conexão VPN do meu PC sem problemas (sem RDP envolvido).

Tom sugeriu o uso de duas placas de rede em um comentário abaixo. Tenho duas placas de rede na caixa (nº 2 acima), mas não sei como configurá-las corretamente ou como atribuir a VPN para usar uma sobre a outra.

Tentei configurar a NIC extra para estar na mesma rede privada (10.1.1.200/24), iniciando a VPN e depois tentando RDP para uma das NICs, 10.1.1.132 ou 10.1.1.200, mas não tive sorte. Existe alguma maneira de dizer à VPN para usar uma NIC por outra?

Conforme solicitado - aqui estão minhas tabelas de roteamento do PC # 2:

Antes da conexão da VPN:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.1.1.254       10.1.1.132     20
         10.1.1.0    255.255.255.0         On-link        10.1.1.132    276
       10.1.1.132  255.255.255.255         On-link        10.1.1.132    276
       10.1.1.255  255.255.255.255         On-link        10.1.1.132    276
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      169.254.0.0      255.255.0.0         On-link        10.1.1.132    296
  169.254.255.255  255.255.255.255         On-link        10.1.1.132    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.1.1.132    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.1.1.132    276
===========================================================================

e após a conexão da VPN:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.1.1.254       10.1.1.132     20
         10.1.1.0    255.255.255.0         On-link        10.1.1.132    276
       10.1.1.132  255.255.255.255         On-link        10.1.1.132    276
       10.1.1.255  255.255.255.255         On-link        10.1.1.132    276
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      169.254.0.0      255.255.0.0         On-link        10.1.1.132    296
  169.254.255.255  255.255.255.255         On-link        10.1.1.132    276
      192.168.0.0    255.255.255.0    192.168.0.254    192.168.0.234    267
    192.168.0.234  255.255.255.255         On-link     192.168.0.234    522
    remote-vpn-ip  255.255.255.255       10.1.1.254       10.1.1.132     21
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.1.1.132    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.1.1.132    276
  255.255.255.255  255.255.255.255         On-link     192.168.0.234    522
===========================================================================

Eu até tentei conectar a segunda interface (10.1.1.232) e brincar com as rotas padrão:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.1.1.254       10.1.1.132     21
         10.1.1.0    255.255.255.0       10.1.1.254       10.1.1.232     11
       10.1.1.132  255.255.255.255         On-link        10.1.1.132    276
       10.1.1.232  255.255.255.255         On-link        10.1.1.232    266
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      169.254.0.0      255.255.0.0         On-link        10.1.1.132    296
  169.254.255.255  255.255.255.255         On-link        10.1.1.132    276
      192.168.0.0    255.255.255.0    192.168.0.254    192.168.0.235    267
    192.168.0.235  255.255.255.255         On-link     192.168.0.235    522
    remote-vpn-ip  255.255.255.255       10.1.1.254       10.1.1.132     21
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.1.1.132    276
        224.0.0.0        240.0.0.0         On-link        10.1.1.232    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.1.1.132    276
  255.255.255.255  255.255.255.255         On-link        10.1.1.232    266
  255.255.255.255  255.255.255.255         On-link     192.168.0.235    522

Forneça mais informações sobre sua configuração. Em particular, qual tecnologia VPN (IPsec, SSL VPN, ...), qual cliente VPN e que tipo de roteamento na LAN?
sleske

Você tem a configuração de VPN para não rotear todo o tráfego pela VPN? se estiver configurado assim, você será cortado.
Sirex

Eu adicionei mais informações. Além disso - tentei ter 'Usar gateway padrão na rede remota' selecionado e desmarcado. Sem sorte Obrigado pela sua contribuição até agora.
Dan

Todo o tráfego de outros hosts na rede 10.1.1.0/24 é rejeitado pelo PC # 2 quando a VPN está ativa? ICMP (Ping) etc.?
Goyuix

Sim Goyuix - está correto. Pings para o PC nº 2 só são bem-sucedidos quando a VPN está inativa.
Dan

Respostas:


10

O que está acontecendo é que você está efetivamente cortando a rota IP do servidor para si mesmo - daí a perda de sessão RDP. Você pode corrigi-lo configurando a VPN de maneira que ela esteja vinculada a uma segunda interface (física ou virtual), para que o link VPN e RDP possam coexistir. Como você faz isso depende enormemente de uma variedade de configurações muito detalhadas que ainda não sabemos, por isso, se você quiser ajuda, precisará voltar para nós com MUITO mais informações, tanto quanto possível por favor.


3
+1. Esse seria o meu palpite também. Gostaria de saber se algo como o LogMeIn pode ser uma solução mais fácil do que tentar descobrir uma solução alternativa para fazer a sessão RDP funcionar.
joeqwerty

Coloque uma segunda NIC na caixa e faça com que o cliente VPN se origine daquele com a rota padrão atribuída.
quer

Você pode estar pensando em algo aqui, Tom. Veja editar em questão.
Dan

Como isso aconteceria, se a configuração do gateway remoto estiver desativada e ele estiver se conectando pela rota local (mesma sub-rede)?
JORIS #

5

Essa pode ser uma prática comum - por padrão, em uma caixa do Windows (isso pode ter sido alterado), todo o tráfego é forçado no túnel da VPN; portanto, sim, seu RDP será desativado.

Sugiro que você vá às configurações avançadas da sua VPN no servidor e verifique se ele não envia todo o tráfego pela VPN.

Além disso, verifique se a rede de destino não usa as mesmas configurações de sub-rede que você, caso contrário, novamente, os sintomas que você descreve.


Só para verificar, você está realmente sentado fisicamente no computador local nº 1, certo?
Mister IT Guru

Sim, está certo. Tentei definir 'Usar gateway padrão na rede remota' como desmarcada. Sem sorte
Dan

Além disso - é uma sub-rede diferente, #
219 Dan Dan

1

Eu tive o mesmo problema. Verifique se o provedor de VPN pode adicionar você a um grupo que possui uma política definida para 'tunelamento dividido' - isso é feito no lado do host da VPN e se o servidor não tiver esse recurso ativado, você não poderá fazer o que deseja. está tentando.

Ver se o seu vpn tem o endereço 192. * quando você o conecta, destrói a interface na qual você está se conectando (interrompendo-o).

Se o tunelamento dividido não estiver ativado no servidor VPN (entre em contato com o administrador do servidor VPN sobre isso!), Você não poderá se conectar.

Isso tudo pressupõe que você esteja configurando suas conexões VPN locais corretamente (parece).


Obrigado - Não consigo ver nenhuma opção para 'Split Tunneling' no servidor VPN. Para ser claro - Estou apenas usando um router ADSL (Draytek) com funcionalidade de servidor VPN construído em Pode não ter algumas opções avançadas ....
Dan

Este roteador tem um daemon pptp em execução? Se isso acontecer, você precisará desativá-lo. Pode estar interferindo nos pacotes GRE.
Senhor TI Guru

1

Eu já tinha esse problema e a solução é "tunelamento dividido", ou seja, envia o tráfego da Internet para o gateway padrão e o tráfego para a rede VPN usando o túnel.

O que você precisa fazer é configurar uma rota estática para a sua máquina no Computador nº 2. E definindo a prioridade para esta rota como 0

Portanto, o resultado final será uma rota padrão 0.0.0.0/0 para o endereço IP do gateway VPN e uma rota estática para sua máquina usando o gateway padrão.

No Windows, o que você faria é algo como isto:

 route add 10.1.1.140 netmask 255.255.255.255 <defaultGW> -P

onde defaultGW é o endereço IP do seu roteador.

Isso garantirá que o tráfego indo para 10.1.1.140 não seja roteado para o túnel.

se você tiver acesso físico ao computador nº 2, conecte-se à VPN e informe-nos a tabela de roteamento da máquina:

route print

um antes de conectar ao vpn e um depois.

Com essas informações, podemos ajudá-lo a configurar o "túnel dividido"

Espero ajudar


Adicionei tabelas de roteamento à pergunta acima. Obrigado pela sua contribuição.
Dan

Quando você se conecta à VPN no PC # 2, você ainda pode navegar na WEB? e se você puder, pode verificar se está saindo com o mesmo IP público? whatismyip.net deve fornecer o endereço IP que você está usando para sair para o mundo. Outra pergunta, você está usando a interface dial-up do Windows para conectar-se à VPN ou a outro cliente VPN?
Hugo Garcia

1

Descobri que o uso do endereço IPv6 para conectar não resulta na interrupção da VPN da sessão RDP.

Na minha configuração, tenho um convidado e host do Windows VirtualBox e minha VPN no convidado força todo o tráfego via VPN (este é o servidor configurado, não posso alterar isso)

Se eu conectar do meu host ao convidado através do endereço ipv4 (por exemplo, 192.168.1.x), assim que iniciar a conexão VPN no convidado, a sessão RDP será interrompida. No entanto, se eu conectar o RDP por meio do nome do host convidado (que resolve o endereço IPv6), a conexão VPN não interromperá a sessão do RDP.


0

Difícil dizer sem mais informações, mas muitos clientes VPN têm o hábito desagradável de desconectar (logicamente) o computador host da LAN enquanto configuram a conexão VPN. Ou seja, você pode estar conectado à sua LAN ou à VPN, mas não a ambos.

Se o seu cliente VPN fizer isso, obviamente a sua sessão RDP será eliminada como um efeito colateral da exclusão da LAN.

Não sei por que os clientes VPN fazem isso, seja uma medida intencional (segurança?) Ou apenas um efeito colateral da reconfiguração da rede, mas sempre o encontrei.

Verifique o manual para obter detalhes e como corrigir isso.


1
Os clientes VPN fazem isso para impedir que as pessoas vinculem duas redes (usando roteamento) e roubem todos os dados de seus sistemas expostos (ou até mesmo sejam comprometidos com malware), um ataque dessa maneira parecerá originar do sistema que faz a vinculação, deixando praticamente nenhuma evidência
Senhor TI Guru

0

Normalmente, usei sessões RDP "aninhadas" via VPN sem nenhum problema especial (além de um pouco mais lento) O esquema subjacente era Cliente-> VPN-> Primeiro servidor RDP-> Internet-> Segundo servidor RDP. O único problema que você poderia ter, eu acho, é que o First server pode ter um firewall que bloqueia a chamada do protocolo RDP. Usando uma VPN, você pode "entrar" na rede do servidor, mas isso não garante que o mesmo servidor ou outras máquinas LAN possam estabelecer uma sessão RDP com um servidor LAN externo. Se o seu segundo servidor estiver na LAN do primeiro, verifique se ele pode ser acessado por uma sessão RDP (por exemplo: pode ter um firewall local bloqueando a porta RDP) e o Windows permite usá-lo. O corte imediato da segunda sessão RDP significa que existe um "problema" na rede (firewalls, auth e assim por diante) na rota para o segundo servidor, para que seja necessária uma verificação precisa das chamadas não atendidas do primeiro servidor. Segundo a mim, a solução é mais simples do que você pensa também se o primeiro servidor tiver apenas uma placa de rede. Durante muito tempo, eu operava sessões rdp aninhadas com servidores montando o Windows 2000, Windows 2003 e 2008 usando um servidor VPN no servidor Windows 2003 e aninhava sessões RDP para as outras duas, às vezes juntas, da primeira. Portanto, verifique as condições de rede do primeiro servidor. Windows 2003 e 2008 usando um servidor VPN no servidor Windows 2003 e aninhando sessões RDP para as outras duas, às vezes juntas, desde a primeira. Portanto, verifique as condições de rede do primeiro servidor. Windows 2003 e 2008 usando um servidor VPN no servidor Windows 2003 e aninhando sessões RDP para as outras duas, às vezes juntas, da primeira. Portanto, verifique as condições de rede do primeiro servidor.


0

Você mencionou que "Usar gateway padrão" está desmarcado - o que, se for aceitável (nenhum roteamento necessário fora da sub-rede 192.168.0.0/24) deveria ter resolvido o seu problema.

O que resta com sons como potencialmente o firewall atrapalhando? Você pode desativar completamente o Firewall do Windows (ou qualquer outro produto que esteja usando) e verificar se o sintoma ainda existe?

Você consegue reconectar a sessão descartada após o estabelecimento do link VPN e permanecer ativo?


Tentei com todos os firewalls desativados e não consigo reconectar o RDP enquanto a VPN está ativa.
Dan

0

Edit : Eu perdi a resposta dos sleskes, explicando o mesmo.

Talvez algum produto de segurança instalado (firewall, "segurança na Internet", antivírus, ...) detecte a conexão PPTP e tenha a mesma funcionalidade?

Observe que alguns desses produtos têm opções ocultas profundamente na GUI por trás de caixas de seleção despretensiosas.


0

É provável que o cliente VPN esteja configurado para rotear TODO o tráfego no túnel, não apenas o tráfego para as redes às quais a VPN encaminha. Isso elimina todas as conexões abertas no momento e altera o comportamento de roteamento no servidor, daí o motivo pelo qual sua conexão é descartada.


0

Isso não resolve o problema específico mencionado, mas foi o que eu usei para resolver o mesmo tipo de problema no suporte a uma variedade de clientes usando uma variedade de clientes vpn que não são todos compatíveis e alguns que criam uma conexão vpn de túnel fechado. Eu tenho um servidor VMware que hospeda várias máquinas virtuais e usa o cliente vSphere para conectar-se à sessão do Windows. Posso abrir uma conexão VPN de túnel fechado e não perder o acesso à sessão do Windows.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.