Estou tentando configurar VPN usando roteamento e acesso remoto.
Eu tentei duas configurações, uma usando uma única placa de rede e outra usando duas placas de rede.
Eu posso conectar-me através da minha VPN e obter um endereço IP atribuído pelo servidor DHCP, mas não consigo "VER" nada. Com isso, quero dizer que o cliente parece completamente cego para a rede do escritório, isso significa:
Eu não tive nenhum problema em conectar a VPN (achei que tinha, mas isso foi com o roteador de teste que eu forneci).
Isso não parece ser um problema de firewall / roteador, pois configurei-o para permitir que o tráfego de VPN fosse encaminhado e encaminhado ao servidor correto.
Isso, eu acho, é confirmado quando os logs de eventos do servidor VPN mostram auditorias bem-sucedidas (isto é, eventos de logon).
No entanto, ele mostra o evento a seguir diretamente após o sucesso do evento de logon de auditoria (e eu não sei se isso é normal, mas não esperaria que fosse - o cliente VPN não se desconecta).
An account was logged off.
Subject:
Security ID: [DomainName]\[UserName]
Account Name: [UserName]
Account Domain: [DomainName]
Logon ID: 0x[xxxxxx]
Logon Type: 3
Este evento é gerado quando uma sessão de logon é destruída. Pode ser correlacionado positivamente com um evento de logon usando o valor de ID de Logon. As IDs de logon são exclusivas entre as reinicializações no mesmo computador.
Não tenho certeza se isso é de alguma utilidade, mas Wireshark me mostra uma conexão bem-sucedida e, depois, uma carga de criptografia pacotes, que é o que eu suspeito:
No entanto, o seguinte é interessante (o que não consigo explicar):
Não consigo explicar os pontos 1 ou 2 - esperaria ver o ICMP, mas o problema parece estar enviando tráfego para (D). Para verificar isso eu pingado (D) de (C) e recebi uma resposta, no entanto eu não vi correlacionar o tráfego ICMP em (D) (isso poderia ter sido o tráfego GRE?). Eu acho isso estranho, mas (C) está definitivamente pingando a máquina correta, pois ela pára de responder quando eu desconecto (D) da VPN.
Observe também que não vejo nenhum tráfego em (D) para os endereços de rede da VPN, apenas para os roteadores que têm o encaminhamento de porta configurado. Isso poderia ser algum tipo de problema de roteamento?
O servidor VPN parece ter um problema ao fazer ping (D) - diz que SEM RECURSOS, PathPing mostra que é usando a interface (A). e esse problema só ocorre ao pingar (D), ele pinga todo o resto sem problema.
Alterei o RRAS para configuração de NIC única e o problema sem recursos desapareceu - aparentemente, posso executar ping no cliente de todas as máquinas, mas não posso executar ping do cliente. Eu digo aparentemente como quando eu faço o ping do cliente leva menos de 1 ms (tenha em mente que isso é através da Internet e ISPs diferentes) e eu não vejo nenhum tráfego ICMP no servidor VPN - mais quando eu desligar o cliente, ainda é pingável! (Como se o servidor VPN estivesse respondendo a pings em nome do cliente.) Enquanto isso está acontecendo, o servidor VPN obtém tempos limite quando pula o cliente desconectado. MUITO ESTRANHO!
Depois de deixá-lo por algum tempo (beber chá, comer comida do tamanho) o servidor VPN voltou ao problema Sem recursos, e eu não tenho ping em nenhuma direção. Desativar o RRAS e ativá-lo novamente me colocou de volta onde eu estava agora, agora posso fazer ping da LAN para o cliente.
Parece ser um problema com o tráfego DHCP. Eu não sei porque.
Para resolver isso, EU MANUALMENTE adicionei um pool de endereços estáticos (não funcionará se você configurá-lo assim ao configurar o RRAS).
Agora eu posso pingar. Embora o DNS pareça ser um problema, mesmo que os servidores DNS corretos sejam escolhidos pelo cliente - para resolver isso, você precisa configurar a conexão de rede VPN no cliente para anexar o sufixo DNS.
Sua terminologia "... veja qualquer coisa na LAN ..." é imprecisa. O que você quer dizer com "ver"? Você quer dizer que você não poderia PING ou fazer conexões TCP para hosts na LAN? Você quer dizer que alguns "Network Places" ou tal função não funcionaram?
O que você está tentando fazer funcionará bem. Você provavelmente não está obtendo a resolução de nomes NetBIOS na VPN porque provavelmente não está usando um servidor WINS na LAN. Isso seria o meu "poder psíquico" adivinhar por que você está tendo problemas.
Instalar o RRAS em um controlador de domínio torna o multi-homed. Vai funcionar, mas a Microsoft não recomenda isso. Você deve pensar em evitar que o adaptador RRAS registre-se no DNS e no WINS .
Editar:
Eu não acho que haja algo "artificial" na minha resposta. Estou tentando ajudar com base em sua descrição imprecisa de seus problemas (usando o termo "ver" em vez de dizer exatamente o que está falhando quando você está conectado) e minha experiência com esses tipos de problemas. Sua declaração vaga sobre o uso do RADIUS me deu a sensação de que você não era um administrador de sistema profissional (posteriormente validado pelo seu comentário re: seu trabalho) e que provavelmente estava tentando usar alguma ferramenta gráfica ou aplicativo para acessar recursos na LAN, mas não tinha realizamos as etapas básicas de solução de problemas de verificação da comunicação da camada 3, resolução de nomes, etc.
Eu configurei servidores RRAS em controladores de domínio em LANs que estão conectadas à Internet atrás de firewalls NAT. Eu me conecto a eles várias vezes por semana. O que você está tentando fazer funciona bem.
Você está permitindo que o servidor RRAS atribua endereços IP aos clientes do DHCP, ou você especificou um intervalo de endereços? Se você especificou um intervalo de endereços, é um intervalo que está dentro da sub-rede da LAN ou é uma sub-rede diferente? O IP está sendo atribuído ao cliente quando "conectado" o que você esperaria ver?
Ainda não está claro para mim o que você tentou fazer uma vez "conectado" que faz você pensar que não pode "ver" a LAN. Você pode PING o endereço IP do servidor RRAS? Você pode fazer conexões TCP para serviços hospedados pelo servidor RRAS ou outros servidores na rede local por endereço IP? Você está recebendo a resolução de DNS?
Finalmente, eu não sugeri que mover o RRAS para outro servidor faria qualquer coisa funcionar. Eu sugeri que a Microosft não recomendasse controladores de domínio multi-homed. O RRAS funcionará bem em um controlador de domínio, desde que você entenda as ramificações com ele.
Editar 2:
Com a configuração do servidor RRAS para atribuir endereços IP do DHCP, você está vendo um bom endereço IP da LAN sendo atribuído ao cliente?
Supondo que você é, e você não pode PING o endereço IP da LAN do servidor RRAS do cliente, é hora de começar a farejar o tráfego. Eu sniff no servidor RRAS e no cliente para ver que a solicitação PING está roteando corretamente a conexão VPN (como uma carga criptografada GRE-- presumivelmente você está usando PPTP). Se o sniffing for inconveniente, você poderá observar os bytes transferidos por meio do diálogo "Status" do cliente conectado no nó "Remote Access Clients" no snap-in do console de gerenciamento "Roteamento e acesso remoto". Eu cheiraria, no entanto - não há substituto para ver os dados no fio.
A tabela de roteamento do cliente também parece que você esperaria após a conexão, suponho. Por padrão, o cliente Microsoft VPN atribui seu gateway padrão à rede remota (a caixa de seleção "Usar gateway padrão na rede remota" nas propriedades TCP / IP "Avançadas" para a conexão VPN). Se você desativar isso, em vez de ver a alteração do gateway padrão, verá uma entrada para a rede remota com um gateway do endereço IP atribuído ao adaptador VPN do cliente. Você não menciona qual é o sistema operacional cliente, mas o comportamento do cliente Microsoft VPN mudou um pouco no Windows 7 (permitindo que você desabilite explicitamente o comportamento bobo de adição de rota "classful").
Ele provavelmente não pergunta, mas a sub-rede IP do servidor VPN e a sub-rede LAN onde o cliente está conectado estão usando intervalos de endereços diferentes, não é?
Isso me parece que sua conexão VPN não está configurada corretamente. Para que uma VPN funcione, o cliente precisa alterar alguns detalhes da configuração de IP, especialmente:
Você pode verificar isso da seguinte maneira: enquanto na VPN, abra um shell (prompt do DOS, qualquer que seja) no seu cliente e execute (no Windows)
ipconfig /allor (under linux)
cat /etc/resolv.confIsso mostrará qual servidor DNS você está usando. Esse servidor DNS deve residir na rede de destino (a solução mais comumente usada) ou deve ser capaz de resolver nomes de máquinas na rede de destino para endereços IP.
O segundo teste é verificar seu roteamento. No Windows, digite
route printNo Linux, use
sudo route -nvIsso lhe dará uma saída assim:
# route -nv Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.180.0.1 10.180.0.169 255.255.255.255 UGH 0 0 0 tun0 10.180.0.169 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.172.0.0 10.180.0.169 255.255.0.0 UG 0 0 0 tun0 10.171.0.0 10.180.0.169 255.255.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.10.254 0.0.0.0 UG 0 0 0 eth0
Acima, as redes 10.171.0.0/16 e 10.172.0.0/16 são roteadas para o túnel.
Se algum desses dois estiver faltando no cliente, verifique a configuração do seu servidor VPN, esteja ele configurado de forma ativa para encaminhar os bits relevantes para o cliente. Isso obviamente depende do tipo de servidor VPN que você está usando.
Sugiro alterar sua sub-rede IP. Se você é endereço IP 192.168.x.100 em sua rede local e está tentando VPN em um site remoto que também usa a sub-rede x, seus problemas podem fazer sentido.
Altere sua sub-rede IP. Não é tão fácil eu sei ... hahah.