Como rotear o tráfego em um túnel VPN ativo por nome de domínio?

Question

Eu configurei um túnel VPN para o meu servidor web, direcionando seu FQDN: (por exemplo, my.server.com) usando o recurso interno do Windows 7 VPN e o recurso integrado VPN do Windows 8 Roteamento e Acesso Remoto (RRAS). .

Como posso garantir que todo o tráfego destinado ao FQDN "my.server.com" seja roteado pelo túnel da VPN? Especificamente, se eu digitei \my.server.com\sharedfolder na barra de endereços do Explorer ou mapeei uma unidade compartilhada no Explorer para esse caminho, quero que o tráfego passe pela VPN associada a my.server.com.

Basicamente, quero que o Windows seja inteligente o suficiente para rotear o tráfego para "my.server.com" sobre a VPN criptografada quando a VPN para "my.server.com" estiver conectada e para rotear normalmente quando não estiver conectada . Isso é pedir demais?

Parece-me que, uma vez conectada, a VPN obtém um endereço IP local como 192.168.1.101 (que eu atribuí estaticamente no servidor na guia de discagem das propriedades da minha conta de usuário), e direcionar esse endereço não direcionar o tráfego pela VPN. Parece que o tráfego segmentado "my.server.com" nunca é roteado pela VPN e é tratado separadamente do endereço IP da VPN, e eu tenho que usar esse endereço IP da VPN para rotear as coisas pela VPN. O único benefício para isso é que o firewall pode ser configurado para que o tráfego de compartilhamento de arquivos possa se originar somente desse endereço IP.

Existem dois problemas com essa configuração:

1. O direcionamento de tráfego "my.server.com" não é roteado automaticamente pela VPN, o que é inseguro e confuso porque a VPN está ativa. Não é intuitivo.
2. O Windows Explorer tende a deixar as conexões da unidade atingirem o tempo limite ao usar um endereço de sub-rede local como \192.168.1.101\sharedfolder e o Explorer congela por uns bons 30 segundos quando tento acessar a unidade novamente. É realmente irritante, e o problema NÃO ocorre quando a unidade é mapeada usando o FQDN como \my.server.com\sharedfolder ... mas depois não é roteado pela VPN!

Como posso resolver este problema?

Atualização: Eu também noto o seguinte quando tenho 2 VPN's conectadas, uma com IP estático 192.168.1.101 e outra com 192.168.1.102. Com as duas VPNs estabelecidas e ambas configuradas para NÃO usar o gateway padrão na VPN e as duas VPNs mostrando esses dois endereços IP independentes em seu status de conexão, o Explorer fica confuso, não pode se conectar à segunda e, se eu abrir uma nova janela e tentar ir para o segundo endereço, parece igualá-lo ao primeiro e, a partir daí, ambos os endereços (101 e 102) acessam a mesma pasta em um servidor através da primeira VPN. Não faz sentido.

    

Answer 1

Eu descobri isso por conta própria.

Para rotear com base no FQDN, pode ser necessário executar um servidor DNS no cliente capaz de detectar quando uma VPN está ativa no endereço WAN desse FQDN. Quando detecta uma conexão VPN ativa, pode resolver o FQDN para o endereço do túnel da VPN, para que os aplicativos (navegadores da Web, etc.) recebam o endereço do túnel da VPN em vez do endereço da WAN do servidor. Como isso representaria problemas para os certificados SSL que mostram quais endereços IP são válidos, seria realmente necessário um driver de rede com reconhecimento de VPN capaz de encapsular dados de forma automática e transparente a partir de aplicativos no túnel VPN. Isso pode ser feito, mas não sei se esses drivers de rede inteligentes existem. De acordo com essa resposta a uma resposta incorreta, você CAN ROUTE BASED ON FQDN com a configuração apropriada, como eu suspeitava:

Quanto à questão de endereços IPv4 duplicados do servidor serem atribuídos a diferentes servidores VPN em um cliente Windows 7, isso parece ser por design. No Roteamento e Serviços de Acesso Remoto (RRAS) do Windows Server 2008/2012, o servidor utiliza um roteador IPv4 que pode ser configurado para usar um pool de endereços estáticos como esse. Esse pool estático determinará o endereço IPv4 do servidor no cliente. Aqui eu configurei meu segundo servidor para usar 192.168.2.0/24 como sua sub-rede, assim ele receberá um IP de servidor 192.168.2.1 no cliente Windows 7.

MinhacontadeusuárioemcadaservidorVPNrecebeumendereçoIPestáticonaguiaDiscagemdaspropriedadesdousuárioemgerenciamentodocomputador.IssosetornaráoendereçoIPv4doclientenaVPN.

Finalmente, para garantir que o tráfego de compartilhamento de arquivos seja originado apenas da sub-rede VPN do servidor, os protocolos / portas apropriados no firewall podem ter seu IP remoto restrito à sub-rede designada:

Agora,nocliente,possoconectar-meacompartilhamentosdearquivospelaInternetpormeiodessaVPN,quenãorequernenhumsoftwaredeterceiros.SimplesmentemapeioumaunidadederedeparacadaumdosendereçosVPNdoservidor(porexemplo,\192.168.1.1\sharedfoldere\192.168.2.1\sharedfolder\).

Infelizmente,nãopodemosusaroFQDNcomo\my.server.com\sharedfolder\porqueoWindowsnãoéinteligenteosuficienteparaperceberqueterumaVPNconectadaaesseendereçoIPimplicatodootráfegoemtodasasportasparaesseendereço,excetoospacotesVPNcriptografadosdeveserroteadoatravésdoIPdaVPN.UmladodoefeitodenãopoderusaroFQDNparaocaminhodecompartilhamentodearquivoséqueasjanelaspodemnãomanteraconexãoativaepresumirãoqueelepodeserrestabelecidorapidamentecomoumendereçolocal,quandonarealidadeeleficaráinativodepoisdeumminutoe,emseguida,leva30segundospararestabelecerumaconexãocomapastacompartilhada. Isso pode ser resolvido configurando-se um limite de tempo ocioso maior no registro . O tempo limite de inatividade padrão para um compartilhamento de rede é padronizado para 600 segundos (10 minutos). Para manter a conexão ativa por mais tempo, adicione um valor de registro DWORD chamado "KeepConn" à chave de registro "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ LanmanWorkstation \ Parameters" e atribua a ele um valor mais alto (em segundos) como 3600, o que seja uma hora. De acordo com o link:

Increase the value of this entry if your application closes and opens Universal Naming Convention (UNC) files on a server less frequently than every 10 minutes. This decreases the number of reconnections to a server.

ATUALIZAÇÃO: Esqueci de mencionar que, embora o compartilhamento de arquivos via VPN use recursos internos do Windows 7 e Windows Server 2012, há uma etapa extra necessária para o Windows Server 2008 devido a algum bug / recurso onde o tráfego nas portas SMB parecem estar bloqueados no adaptador de rede padrão, independentemente do firewall. Você deve instalar o adaptador microsoft loopback, que funcionará de forma idêntica à interface padrão, além de permitir o tráfego SMB, portanto, uma vez instalado, ele deverá se parecer com isso. Então, em vez de se conectar ao compartilhamento em 192.168.1.1 (o endereço VPN do servidor), você se conecta ao 192.168.1.2, que é o endereço dos adaptadores de loopback:

Asinstruçõessobrecomoinstalaroadaptadordeloopbackpodemserencontradasaqui: link