VPN cai (problema de latência de DPC)

2

Estou usando a VPN para me conectar ao trabalho. Estou acostumado a ouvir streaming de música quando estou no escritório, mas quando faço isso pela VPN, a conexão cai. Então, não é grande coisa, eu só não vou usar o streaming de música quando estou na VPN.

Mas acabei de ter uma reunião do Skype com o escritório e perdi a VPN. Então agora isso está ficando no meu caminho e eu quero consertar isso. Alguma idéia de onde devo olhar?

Estou executando o Server 2008 em um laptop, usando uma conexão sem fio em minha casa para uma conexão DSL decente e acessível. Estou usando o cliente VPN interno do Windows.

update: No lado do escritório, a VPN está em um firewall DLink - é o PPTP com criptografia MPPE de 128 bits.

update: Acredito que isso esteja relacionado ao problema de latência do DPC, que parece estar incomodando muitos laptops no mercado. Ainda não resolvi o problema. No meu caso, estou usando um Dell Studio XPS 16, que é um dos laptops com esse problema. Espero, eventualmente, encontrar a combinação certa de drivers para resolver o problema.

    
por ScottStonehouse 10.06.2009 / 16:30

11 respostas

1

Mais do que provavelmente você tem uma causa raiz: como o tráfego está sendo roteado.

Por exemplo, ouvir streaming de música não deve ser um problema - porque NÃO deveria estar passando por cima da VPN.

Da mesma forma, eu apostaria se você estiver usando um cliente de vídeo comum para suas conferências, como o Skype, e ainda assim não precisar desse tráfego na VPN. Obviamente, isso pode não se aplicar se você estiver se conectando a uma ponte de vídeo atrás do firewall corporativo.

Se você estiver usando o cliente VPN do Windows, existe uma maneira simples de enviar tráfego não VPN por meio do seu gateway local. Se você estiver usando um cliente de terceiros, terá que consultar sua documentação.

    
por 16.06.2009 / 19:35
1

Eu tive problemas semelhantes a isso ao usar uma conexão VPN do Windows com nosso escritório principal e encontrei o seguinte.

Certifique-se de limitar o tráfego de envio (e possivelmente de recebimento de dados) para qualquer sistema de uso pesado em sua rede. Minha torrent box dedicada foi configurada para que não coma todo o meu pipe e cause problemas. Mesmo com o QOS habilitado para priorizar o tráfego VPN, ele tende a diminuir se eu saturar o link e aumentar a latência com a qual a conexão tem que lidar. As conexões vpn PPTP são bem complicadas quando se trata de latência, elas tendem a cair MUITO prontamente.

Eu também notei em sua pergunta que você disse que está transmitindo música por sua conexão VPN? Você está ciente de que as conexões VPN padrão do Windows estão definidas para enviar todo o tráfego através do gateway padrão remoto? Isso está no lugar para que você possa rotear para outras redes através da VPN, que pode não estar na mesma sub-rede que sua conexão. Você pode contornar isso desabilitando o "usar gateway padrão na rede remota" aqui: Propriedades de conexão - > Guia Rede - > Propriedades de TCP / IP - > Botão Avançado - > Guia Geral

Uma vez verificado, isso só enviará o tráfego destinado à sub-rede remota através da sua conexão VPN, permitindo que o seu streaming de música saia da sua conexão de rede local sem incidentes. Acho isso extremamente útil quando você está tentando navegar na web enquanto trabalha em uma rede remota, você obtém sua velocidade local para tudo, exceto a LAN remota.

OBSERVAÇÃO: se o dispositivo do servidor pptp atribuir endereços IP ao sistema do cliente que esteja em uma sub-rede à parte da rede que você está tentando acessar, talvez seja necessário contorná-lo.

exemplo: Endereço de rede LAN no site remoto: 192.168.0.0/24 Endereço de rede LAN em sua casa: 172.16.7.0/24 Sub-rede VPN atribuída aos clientes no roteador ao conectar-se: 192.168.254.0/24

Esta é a maneira como o servidor windows manipula as conexões VPN quando você usa o RRAS para hospedar as conexões VPN, e eu vi os roteadores lidarem com as conexões dessa maneira também.

Solução alternativa: você precisará executar manualmente um comando de rota para adicionar uma entrada à sua tabela de roteamento depois de se conectar à VPN, o comando será algo como isto: rota ADICIONAR network_to_reach MASK subnet_mask gateway_ip_of_vpn_connection (possivelmente) route add 192.168.0.0 MASK 255.255.255.0 192.168.254.1

Isto irá dizer à sua máquina que tem que usar o roteador em 192.168.254.1 para acessar qualquer sistema na rede 192.168.0.0/24. Os sistemas dentro da rede usarão o roteador que hospeda a conexão como seu gateway padrão, para que não precisem saber como voltar ao seu sistema.

Isso pode ser automatizado e adicionado à conexão VPN. É assim que gerenciamos e implantamos clientes em nosso escritório e funciona EXTREMAMENTE bem. Você pode usar o microsoft CMAK (Kit de Administração do Gerenciador de Conexões) para criar um "conectóide" VPN que contém instruções de automação, incluindo rotas para adicionar, scripts para executar durante diferentes fases do processo de conexão e desconexão e algumas outras coisas que nunca toquei .

Espero que isso resolva seus problemas e faça com que você se conecte enquanto aprisiona suas músicas e ajude outras pessoas a alcançar um estado de VPN ZEN.

    
por 20.06.2009 / 17:03
0

Provavelmente, é melhor usar as mesmas ferramentas dos dois lados. Por exemplo, você mencionou que você executa o servidor VPN no DLink, eu diria que tente o cliente VPN fornecido pelo Dlink para ver se ele fica melhor. Ou ative o RRAS na sua caixa Server 2008 e vincule-o usando a conexão VPN do Windows e veja se faz alguma diferença.

    
por 10.06.2009 / 17:32
0

Tivemos um problema como esse há algum tempo com um dos produtos VPN que usamos. Não era tolerante a chegada de pacotes fora de ordem e terminaria a sessão VPN quando isso acontecesse. Na época, o trabalho estava usando um par de T1s ligados e isso levou a alguns problemas fora de ordem para vários protocolos. TCP é supostamente tolerante a isso, mas nem todos os protocolos usando TCP são.

    
por 10.06.2009 / 17:56
0

Você pode querer procurar em um roteador que tenha QoS para que a conexão VPN tenha prioridade sobre os outros pacotes.

A outra coisa que pode ser a causa (como mencionado por outros) é verificar sua largura de banda de upstream. Normalmente, a largura de banda downstream é bastante alta, mas o upstream é limitado (256k ou 356k). Você pode querer mudar o seu plano de banda larga se o upstream for realmente baixo.

-JFV

    
por 10.06.2009 / 18:32
0

Uma conexão PPTP é realmente duas conexões, uma conexão de controle e uma conexão de dados. Isso em si é um problema com roteadores e especialmente firewalls.

Degradação (e promoção) dos tamanhos de pacotes é parte do protocolo, então não vejo como isso poderia ser um problema, a menos que você tenha uma linha realmente ruim - porque então o tamanho do seu pacote pode cair para 1 e seu upstream será reduzido para a velocidade do modem analógico ruim devido à sobrecarga do protocolo.

Mas o que é um pouco pior é que, se a conexão de controle receber pacotes fora de ordem, toda a conexão VPN será descartada. Ou a conexão de controle é "sobrecarregada" pela conexão de dados, o que leva a um tempo limite e, portanto, a uma queda de toda a conexão VPN.

Você menciona o Skype e, até onde eu sei, o Skype usa o máximo de largura de banda possível para fornecer imagens suaves e bom som. Até mesmo as conexões de som do Skype usam até 16 kBytes / s, o que significa cerca de 128kBit / s, portanto, se o seu envio de ADSL estiver próximo, isso pode ser o problema, especialmente se você adicionar sobrecarga de protocolo à sua conexão VPN. O vídeo agrava ainda mais esses problemas de largura de banda.

Portanto, se você tiver alguma possibilidade de implementar QoS na sua linha ADSL (ou seja, seu roteador a suporta), defina uma alta prioridade para a porta 1723 TCP (que é sua conexão de controle), logo abaixo de ICMP. Isso pode ajudar.

    
por 10.06.2009 / 21:41
0

Algumas coisas para começar:

1) Qual extremidade está soltando a conexão? Com a VPN ativada, execute pings em ambas as direções e realize capturas de pacotes nas duas extremidades, idealmente do tráfego criptografado e não criptografado. Porque falhar e ver o que acontece; você provavelmente encontrará uma extremidade enviando pacotes, mas a outra extremidade está silenciosamente soltando-os no chão ou ativamente rejeitando-os.

2) Comece simplificando as coisas e tente novamente em cada etapa; remova o wireless e conecte diretamente ao seu roteador. Ignore o roteador e conecte-o diretamente ao seu modem. Faça o mesmo do outro lado. Você pode identificar algumas formas de problemas NAT removendo os roteadores da equação e colocando seus IPs públicos diretamente no kit final; a quantidade de equipamento de rede com NAT ou ALG é espantosa.

3) Verifique os logs de eventos VPN e os logs de firewall para ver se eles fornecem alguma ideia de por que o túnel VPN está morrendo. No mínimo, eles devem registrar a falha e, idealmente, uma razão pela qual.

4) Tente um PC diferente, tente um sistema operacional diferente. Veja se você consegue encontrar uma combinação que funcione.

Depois de encontrar o equipamento com falha, você poderá continuar a solucionar o problema. talvez seja necessário atualizar o firmware de um dispositivo, adicionar algumas entradas de encaminhamento de porta / NAT ou ajustar o conjunto de regras do firewall. Se for específico de uma máquina, pode ser necessário redefinir ou empilhar a pilha de rede (alguns aplicativos do Broadband Optimiser podem quebrar a configuração da pilha de rede e outros aplicativos que se injetam na pilha de rede podem atrapalhar os pacotes).

    
por 11.06.2009 / 12:03
0

Se o problema for devido à falta de largura de banda, é provável que seja a sua largura de banda do fluxo de dados que é o problema (supondo que você esteja em uma conexão assíncrona).

A voz será usada em algum lugar na região de 4Kbyte / seg para 11Kbyte / seg no upstream quando você estiver falando. Ouvir música em si é a direção oposta, então não deve afetar nada. Você está, por acaso, usando o Spotfire para ouvir música ou qualquer outra coisa que faça peer-to-peer e, assim, usando todo o seu upstream?

    
por 12.06.2009 / 14:08
0

Eu duvido que este seja seu problema, mas vale a pena investigar. Eu gerencio alguns concentradores vpn da série Cisco VPN3000, e por causa da criptografia que eles estão executando, eles são muito mais restritos à CPU do que a restrição de largura de banda. Apesar de estar em uma conexão de 100Mb / s (e ter largura de banda mais do que suficiente para saturar que, muito obrigado, a latência do dispositivo aumenta significativamente e o dispositivo começa a eliminar pacotes. Pode ser que o dispositivo mencionado seja manipulado problemas de largura de banda / CPU eliminando conexões, em vez de degradar. Algo para investigar.

    
por 12.06.2009 / 20:47
0

Qual é a velocidade da sua conexão (taxas esperadas usuais, não taxas "até" de título) e em que taxa é o streaming de áudio?

Pode ser que o tráfego extra esteja atrasando pacotes e respostas da VPN que o cliente VNOP vê como uma queda de conexão. Em uma configuração moderna (ou seja, não discada), eu não esperaria ver um único fluxo de áudio de entrada suficiente para preencher seu fluxo descendente até o ponto em que outro tráfego é afetado, mas se você tiver uma conexão com uma taxa muito pequena Os dados do skype podem ser suficientes para induzir atrasos mensuráveis.

Se o problema se deve a problemas de latência causados por outro tráfego, há duas coisas que você pode tentar: ver se há configurações de tempo limite no cliente VPN que você pode alterar e que estão atualmente muito baixas e / ou tentar modelagem de tráfego no seu final (embora isso só ajude se a largura de banda upstream estiver saturada, não o downstream, pois você não pode controlar diretamente o fluxo downstream).

    
por 10.06.2009 / 17:10
0

O que você pode querer considerar é o tamanho do pacote. Streaming e skype certamente irão gerar alguns pacotes grandes e vpn algumas vezes não funcionam bem com pacotes grandes, pois eles irão adicionar seus cabeçalhos e, às vezes, passar por cima do MTU.

Um hack rápido seria colocar seu MTU em um valor baixo (~ 1000B) no seu cliente. Isso ajudará você a determinar rapidamente se o tamanho do pacote é realmente o problema.

Se bem me lembro, o MTU é definido no registro no windows ...

    
por 10.06.2009 / 17:29