Criar rota para tráfego VPN de trabalho

Question

O que criou seu problema

O que está acontecendo aqui é que a conexão com a VPN colocará uma rota muito ampla na tabela de rotas do seu sistema operacional. Você pode executar `route print` antes e depois de conectar a VPN para ver quais rotas estão sendo adicionadas como efeito colateral da conexão da VPN.

Você verá que a seguinte combinação de rotas foi adicionada à sua tabela de rotas:

===========================================================================
  Network Address          Netmask         Gateway         Interface  Metric
          0.0.0.0          0.0.0.0         On-link    172.17.101.209      56
      65.70.114.5  255.255.255.255    192.168.86.1     192.168.86.37    4516
      172.17.15.0    255.255.255.0         On-link    172.17.101.209      56
===========================================================================

Outras rotas também são adicionadas. Não nos importamos tanto com isso.

A primeira rota adicionada diz que o tráfego destinado a “qualquer lugar” deve usar o túnel VPN. Portanto, esta é uma rota padrão. Exceto algum destino mais específico, qualquer tráfego que saia da sua máquina usará o gateway VPN. Observe que ainda existe a antiga rota padrão listada na tabela que indica "usar o gateway LAN para qualquer lugar", mas sua métrica é maior (pior). Essa rota não é mais preferida.

A segunda rota adicionada abre uma lacuna que diz que o tráfego destinado ao IP público do servidor VPN deve usar o gateway antigo. Observe que mesmo que a métrica seja mais alta, a rota é mais específica. A máscara de rede 255.255.255.255significa "somente para este endereço IP". A especificidade tem precedência sobre a métrica.

A terceira rota adicionada é um intervalo de IP específico que deve usar o gateway VPN. Dado que o gateway VPN já é a rota padrão, esta é uma informação redundante. Eu realmente não sei por que isso foi adicionado, mas posso adivinhar que o administrador de TI do serviço VPN provavelmente adicionou isso manualmente devido a algum problema específico encontrado por alguns usuários.

Outras rotas que foram adicionadas incluem o novo multicast padrão (224.0.0.0) e broadcast (..*.255) rotas. Também foram adicionadas rotas para o endereço IP da sua máquina em cada rede. Não sei por que isso é necessário; pode ser uma coisa do Windows.

Tecnicamente, qual é o problema?

Essas rotas dizem ao seu computador para enviar através do túnel VPN TODO o tráfego, exceto o próprio túnel VPN e o tráfego para a LAN local imediata. Isso é feito porque o gateway VPN pode (e muitas vezes precisa) rotear seu tráfego para mais sub-redes na intranet remota (diferentemente da Internet). Por exemplo, ao conectar a VPN, seu computador recebe um endereço IP 172.17.101.209/24. Os servidores de e-mail na rede remota podem estar localizados em 172.17.15.4/24, Sharepoint em 172.17.7.16/24, Skype em 172.17.55.27/24, etc. Todos eles estão em sub-redes separadas do seu IP VPN e apenas do gateway VPN pode direcionar o tráfego para essas máquinas. Em vez de enviar cada IP ou sub-rede individualmente para sua tabela de rotas (por exemplo, sua rota para 172.17.15.0), é mais fácil para a TI corporativa definir/substituir a rota padrão de todo o tráfego para usar VPN e deixar o gateway VPN descobrir como conectá-lo a todas as sub-redes que você deseja alcançar.

Enviar uma nova rota padrão para clientes VPN torna-se um problema quando esses clientes também têm recursos em sua rede local que estão tentando acessar. Os mesmos exemplos se aplicam: servidores de e-mail, sites internos, Skype, etc. Você precisa do seu gateway local para acessá-los.

Teoricamente, como resolvemos esse problema?

Precisamos saber quais redes estão em qual gateway. Se tentarmos usar um gateway para uma rede que não é roteável a partir desse gateway, obteremos uma resposta `DESTINATION NOT REACHABLE`. Se usarmos o gateway remoto para acessar nosso servidor SharePoint local, obteremos essa resposta. Isso nos coloca em uma posição complicada de adicionar rotas manualmente à tabela de rotas do nosso sistema operacional, informando qual gateway usar para diferentes intervalos de IP. Isto pode ser seriamente temperamental, especialmente em grandes redes corporativas, porque ambas as redes podem utilizar os mesmos intervalos de IP internos. Basicamente, estamos em uma situação em que escolhemos um dos dois gateways para ser nosso gateway padrão e, em seguida, adicionamos rotas para sub-redes individuais necessárias do outro gateway.

Que comando executo para resolver esse problema?

Você está certo. Você executa comandos do tipo `route -p add` para adicionar as rotas para qualquer gateway que não seja seu gateway padrão. Parece que seu colega decidiu usar o gateway da VPN como gateway padrão e, em seguida, adicionar rotas manualmente para cada subconjunto local ao qual você precisa acessar. Você pode usar `nslookup` para encontrar os endereços IP dos servidores necessários em sua LAN local e, em seguida, adicionar toda a sub-rede em que o serviço reside à sua tabela de rotas.

Por exemplo, eu executaria nslookup sharepoint.localcompany.come receberia um IP 192.168.12.51. Eu então correria route -p add 192.168.12.0 mask 255.255.255.0 <LAN-gateway-ip>.

Esperamos que você só precise adicionar uma ou duas sub-redes para que tudo funcione. Esperamos que essas sub-redes não sejam comuns (por exemplo, 192.168.0.0/24, 192.168.0.1/24 ou 10.0.0.0/24). Consulte "outros problemas" abaixo.

Editar para novas informações

Dados os endereços IP que estou vendo na sua tabela de rotas, eu executaria este comando e veria se as coisas funcionavam melhor. Não sei se a interface 10 ou 14 é a que você usa para LAN, então escolha o número correspondente com base na sua configuração.

route -p add 192.168.0.0 mask 255.255.0.0 0.0.0.0 IF [10/14]

Este comando diz "Use o gateway aprendido na interface LAN para IPs no intervalo 192.168.0.0 a 192.168.255.255". Isso pode quebrar certas coisas; nesse caso, você pode revertê-lo trocando addpor delete.

Outros problemas

Todo esse problema é replicado no subsistema DNS. Você tem servidores DNS para duas redes diferentes e `internal-sharepoint..com` não está no servidor DNS remoto. Detesto deixar este exercício para o usuário, mas é uma questão totalmente separada de ser capturada. DR: Acredito que você confia em 'sufixos DNS' para saber qual servidor DNS usar. Poste uma pergunta separada se precisar de ajuda com isso.

Isso não é portátil. Você codificou quais sub-redes usar com quais gateways. Se você trabalha em casa e usa a VPN da sua própria empresa, todas as rotas adicionadas precisam ser atualizadas para usar o gateway VPN da sua empresa, em vez de qualquer gateway que você possa ter usado no seu escritório. Se você alguma vez fizer roaming para outra rede onde precisa que essas sub-redes funcionem, essas rotas precisarão ser removidas. Primeiramente, é por isso que minha resposta é tão longa. Se você apenas executar os comandos, não reconhecerá novos problemas que surgirão apenas mais tarde. Quando esses problemas acontecem, você deve voltar atrás ou modificar as alterações feitas em sua tabela de rotas.

Problemas de conflito de IP. Se você tivesse que adicionar um subconjunto comum, inevitavelmente/em breve se depararia com uma situação em que precisaria que essa sub-rede funcionasse tanto na rede local quanto na remota. Acho que é mais fácil simplesmente aceitar o inconveniente, remover todas as rotas adicionadas manualmente e ativar/desativar a VPN conforme necessário para acessar serviços locais/remotos.

Por favor, deixe-me saber se esta explicação não está clara ou se posso explicar uma parte com mais detalhes.

Answer 1

O que criou seu problema

O que está acontecendo aqui é que a conexão com a VPN colocará uma rota muito ampla na tabela de rotas do seu sistema operacional. Você pode executar `route print` antes e depois de conectar a VPN para ver quais rotas estão sendo adicionadas como efeito colateral da conexão da VPN.

Você verá que a seguinte combinação de rotas foi adicionada à sua tabela de rotas:

===========================================================================
  Network Address          Netmask         Gateway         Interface  Metric
          0.0.0.0          0.0.0.0         On-link    172.17.101.209      56
      65.70.114.5  255.255.255.255    192.168.86.1     192.168.86.37    4516
      172.17.15.0    255.255.255.0         On-link    172.17.101.209      56
===========================================================================

Outras rotas também são adicionadas. Não nos importamos tanto com isso.

A primeira rota adicionada diz que o tráfego destinado a “qualquer lugar” deve usar o túnel VPN. Portanto, esta é uma rota padrão. Exceto algum destino mais específico, qualquer tráfego que saia da sua máquina usará o gateway VPN. Observe que ainda existe a antiga rota padrão listada na tabela que indica "usar o gateway LAN para qualquer lugar", mas sua métrica é maior (pior). Essa rota não é mais preferida.

A segunda rota adicionada abre uma lacuna que diz que o tráfego destinado ao IP público do servidor VPN deve usar o gateway antigo. Observe que mesmo que a métrica seja mais alta, a rota é mais específica. A máscara de rede 255.255.255.255significa "somente para este endereço IP". A especificidade tem precedência sobre a métrica.

A terceira rota adicionada é um intervalo de IP específico que deve usar o gateway VPN. Dado que o gateway VPN já é a rota padrão, esta é uma informação redundante. Eu realmente não sei por que isso foi adicionado, mas posso adivinhar que o administrador de TI do serviço VPN provavelmente adicionou isso manualmente devido a algum problema específico encontrado por alguns usuários.

Outras rotas que foram adicionadas incluem o novo multicast padrão (224.0.0.0) e broadcast (..*.255) rotas. Também foram adicionadas rotas para o endereço IP da sua máquina em cada rede. Não sei por que isso é necessário; pode ser uma coisa do Windows.

Tecnicamente, qual é o problema?

Essas rotas dizem ao seu computador para enviar através do túnel VPN TODO o tráfego, exceto o próprio túnel VPN e o tráfego para a LAN local imediata. Isso é feito porque o gateway VPN pode (e muitas vezes precisa) rotear seu tráfego para mais sub-redes na intranet remota (diferentemente da Internet). Por exemplo, ao conectar a VPN, seu computador recebe um endereço IP 172.17.101.209/24. Os servidores de e-mail na rede remota podem estar localizados em 172.17.15.4/24, Sharepoint em 172.17.7.16/24, Skype em 172.17.55.27/24, etc. Todos eles estão em sub-redes separadas do seu IP VPN e apenas do gateway VPN pode direcionar o tráfego para essas máquinas. Em vez de enviar cada IP ou sub-rede individualmente para sua tabela de rotas (por exemplo, sua rota para 172.17.15.0), é mais fácil para a TI corporativa definir/substituir a rota padrão de todo o tráfego para usar VPN e deixar o gateway VPN descobrir como conectá-lo a todas as sub-redes que você deseja alcançar.

Enviar uma nova rota padrão para clientes VPN torna-se um problema quando esses clientes também têm recursos em sua rede local que estão tentando acessar. Os mesmos exemplos se aplicam: servidores de e-mail, sites internos, Skype, etc. Você precisa do seu gateway local para acessá-los.

Teoricamente, como resolvemos esse problema?

Precisamos saber quais redes estão em qual gateway. Se tentarmos usar um gateway para uma rede que não é roteável a partir desse gateway, obteremos uma resposta `DESTINATION NOT REACHABLE`. Se usarmos o gateway remoto para acessar nosso servidor SharePoint local, obteremos essa resposta. Isso nos coloca em uma posição complicada de adicionar rotas manualmente à tabela de rotas do nosso sistema operacional, informando qual gateway usar para diferentes intervalos de IP. Isto pode ser seriamente temperamental, especialmente em grandes redes corporativas, porque ambas as redes podem utilizar os mesmos intervalos de IP internos. Basicamente, estamos em uma situação em que escolhemos um dos dois gateways para ser nosso gateway padrão e, em seguida, adicionamos rotas para sub-redes individuais necessárias do outro gateway.

Que comando executo para resolver esse problema?

Você está certo. Você executa comandos do tipo `route -p add` para adicionar as rotas para qualquer gateway que não seja seu gateway padrão. Parece que seu colega decidiu usar o gateway da VPN como gateway padrão e, em seguida, adicionar rotas manualmente para cada subconjunto local ao qual você precisa acessar. Você pode usar `nslookup` para encontrar os endereços IP dos servidores necessários em sua LAN local e, em seguida, adicionar toda a sub-rede em que o serviço reside à sua tabela de rotas.

Por exemplo, eu executaria nslookup sharepoint.localcompany.come receberia um IP 192.168.12.51. Eu então correria route -p add 192.168.12.0 mask 255.255.255.0 <LAN-gateway-ip>.

Esperamos que você só precise adicionar uma ou duas sub-redes para que tudo funcione. Esperamos que essas sub-redes não sejam comuns (por exemplo, 192.168.0.0/24, 192.168.0.1/24 ou 10.0.0.0/24). Consulte "outros problemas" abaixo.

Editar para novas informações

Dados os endereços IP que estou vendo na sua tabela de rotas, eu executaria este comando e veria se as coisas funcionavam melhor. Não sei se a interface 10 ou 14 é a que você usa para LAN, então escolha o número correspondente com base na sua configuração.

route -p add 192.168.0.0 mask 255.255.0.0 0.0.0.0 IF [10/14]

Este comando diz "Use o gateway aprendido na interface LAN para IPs no intervalo 192.168.0.0 a 192.168.255.255". Isso pode quebrar certas coisas; nesse caso, você pode revertê-lo trocando addpor delete.

Outros problemas

Todo esse problema é replicado no subsistema DNS. Você tem servidores DNS para duas redes diferentes e `internal-sharepoint..com` não está no servidor DNS remoto. Detesto deixar este exercício para o usuário, mas é uma questão totalmente separada de ser capturada. DR: Acredito que você confia em 'sufixos DNS' para saber qual servidor DNS usar. Poste uma pergunta separada se precisar de ajuda com isso.

Isso não é portátil. Você codificou quais sub-redes usar com quais gateways. Se você trabalha em casa e usa a VPN da sua própria empresa, todas as rotas adicionadas precisam ser atualizadas para usar o gateway VPN da sua empresa, em vez de qualquer gateway que você possa ter usado no seu escritório. Se você alguma vez fizer roaming para outra rede onde precisa que essas sub-redes funcionem, essas rotas precisarão ser removidas. Primeiramente, é por isso que minha resposta é tão longa. Se você apenas executar os comandos, não reconhecerá novos problemas que surgirão apenas mais tarde. Quando esses problemas acontecem, você deve voltar atrás ou modificar as alterações feitas em sua tabela de rotas.

Problemas de conflito de IP. Se você tivesse que adicionar um subconjunto comum, inevitavelmente/em breve se depararia com uma situação em que precisaria que essa sub-rede funcionasse tanto na rede local quanto na remota. Acho que é mais fácil simplesmente aceitar o inconveniente, remover todas as rotas adicionadas manualmente e ativar/desativar a VPN conforme necessário para acessar serviços locais/remotos.

Por favor, deixe-me saber se esta explicação não está clara ou se posso explicar uma parte com mais detalhes.

Criar rota para tráfego VPN de trabalho

Responder1

O que criou seu problema

Tecnicamente, qual é o problema?

Teoricamente, como resolvemos esse problema?

Que comando executo para resolver esse problema?

Editar para novas informações

Outros problemas

informação relacionada