Falha intermitente nas conexões VPN PPTP

1

Tenho duas semanas como administrador de sistemas em uma empresa de fabricação de médio porte com executivos e equipe de vendas que fazem uso pesado de acesso remoto. Desde quase o dia em que cheguei, comecei a reclamar de problemas de desempenho de VPN. Aqui está nossa configuração: Nosso gateway é um dispositivo Astaro que é configurado com regras DNAT que encaminham o tráfego PPTP e GRE para um servidor interno que chamaremos de COMPANY-VPN01. EMPRESA-VPN01 é uma caixa do Windows Server 2003 configurada com o RRAS. Nossos computadores cliente (principalmente o XP, mas alguns Vista e 7) têm conexões VPN do Windows PPTP configuradas para apontar para vpn.company.com, que resolve o IP público da interface externa da caixa do Astaro.

Aqui está a parte realmente estranha: a cada tempo em que os usuários se conectam à conexão VPN, parece funcionar. Na máquina cliente, a conexão VPN mostra "conectado" (e seu ipconfig mostra um adaptador PPP com um endereço IP interno emitido por DHCP), e também posso ver sua conexão na COMPANY-VPN01). No entanto, mais da metade do tempo, essas conexões não são boas - os usuários não podem acessar quaisquer recursos internos. Como experimentei isso, testei algumas das coisas óbvias - tentei usar FQDNs de recursos internos em vez de nomes NetBIOS, tentei usar endereços IP, tentei executar ping de recursos internos por nome e endereço IP. Nada passa. Mas se eu desconectar e reconectar a conexão VPN algumas vezes, eu irei eventualmente obter uma conexão que funciona sem falhas - e continuarei a funcionar perfeitamente, não importa quanto tempo eu deixe conectado. Portanto, seja qual for o problema, é a) intermitente eb) ocorre quando a conexão VPN está sendo configurada - porque se você obtiver uma conexão "boa", ela permanecerá boa.

Alguém tem alguma ideia sobre o que pode estar acontecendo aqui ou sugestões de coisas que podem ser solucionadas?

    
por Kevin Baker 20.10.2010 / 12:53

4 respostas

1

Eu acho que não devo deixar isso sem resposta para sempre quando eu tiver resolvido o problema.

Quando fui contratado, me disseram que a LAN estava "ficando sem espaço". A rede tinha uma máscara de sub-rede de 24 bits e usa o DHCP para o endereçamento do cliente. O servidor DHCP não foi configurado para verificar o DNS antes de entregar os endereços. O DNS não estava definido para recuperar registros antigos. O RRAS foi configurado para obter endereços para clientes VPN do DHCP e, por padrão, ele pega blocos de 10. Então, ele pegaria blocos de 10 e começaria a distribuí-los aos clientes, mas como o nosso espaço de endereçamento acabava, alguns deles eram "bons "e alguns já estavam registrados para outros clientes no DNS. Encurtei a máscara de sub-rede para 22 bits e o problema foi resolvido.

    
por 07.09.2011 / 05:04
0

Aqui está uma sugestão: Configurar outro servidor RRAS e direcionar as conexões VPN de entrada para este novo servidor. Se o problema persistir, você descartará o servidor como o problema e poderá se concentrar nos dispositivos a montante, mais provavelmente o dispositivo Astaro, como o problema.

    
por 20.10.2010 / 13:39
0

Eu suspeito que o aparelho é o problema aqui, apenas um palpite.

Tente atualizar o firmware. Entre em contato com a Astaro sobre este assunto.

Teste a DMZ no servidor COMPANY-VPN01 em vez das regras DNAT.

E / ou tente conectar sua internet diretamente a uma segunda NIC no servidor vpn e use o RRAS Basic Firewall + NAT, e mude seu DHCP para que o novo gateway padrão seja aquele servidor.

OU .. você pode codificar um script em lote simples ou um aplicativo c # simples para rediscar automaticamente o ponto de extremidade da VPN se o ping falhar após x vezes e enviar uma cópia para todos os laptops (.msi?).

    
por 25.02.2011 / 22:46
0

Poderia ser PPTP Passthrough sem suporte ou não funcionando corretamente no seu roteador de saída. Você também pode querer ler Múltiplas Conexões VPN - Por que não é possível que explica por que isso acontece e formas de contornar isso. É uma boa leitura!

    
por 09.08.2011 / 16:44

Tags