É possível que a VPN L2TP faça a configuração automática de rota para o cliente durante a conexão?

13

Configuramos um servidor VPN L2TP com este tutorial , tudo funciona como um encanto.

O único problema é

  1. Não queremos que o cliente roteie todo o tráfego usando esta VPN, apenas uma sub-rede específica, por exemplo, 10.0.0.0/20

  2. No Mac, precisamos definir a rota manualmente usando o comando, mas para dispositivos móveis, parece que não há como fazê-lo?

Portanto, é possível configurar o cliente automaticamente para a sub-rede "10.0.0.0/20"?

linux vpn linux-networking ipsec l2tp Howard
fonte
Você já tentou desativar a opção 'enviar todo o tráfego pela VPN' ou semelhante no cliente?
10444 Bert

Respostas:

33

OK, essa pergunta é repetida na Internet e na maioria das vezes há uma resposta (semi) incorreta de que você não pode fazer o que foi descrito na postagem original. Deixe-me esclarecer de uma vez por todas :)

A resposta curta é que o L2TP (e o PPTP) não têm recursos para fazer push de rotas dentro do protocolo, mas isso pode ser alcançado fora do protocolo.

Como o L2TP é uma invenção da Microsoft, a melhor fonte de informação é a documentação técnica (a propósito, eles são muito bons nisso). A descrição técnica do que vou explicar abaixo pode ser encontrada em Endereçamento e roteamento de VPN . As palavras-chave para configurar tudo corretamente (se você for fazer sua própria pesquisa) são: DHCPINFORM e "rotas estáticas sem classe".

Primeiro de tudo, como funciona:

  1. um cliente se conecta ao servidor VPN
  2. após a autenticação bem-sucedida, um túnel seguro é estabelecido
  3. o cliente usa uma mensagem DHCPINFORM após a conexão para solicitar a opção Rotas estáticas sem classe DHCP. Esta opção DHCP contém um conjunto de rotas que são adicionadas automaticamente à tabela de roteamento do cliente solicitante ( copiei e colei essa linha de forma escassa diretamente da documentação da Microsoft :))
  4. o servidor VPN responde a essa mensagem com o conjunto apropriado de rotas

Bem, há uma ressalva:

  • existe o RFC-3442 que descreve "Rotas estáticas sem classe DHCP" e afirma que o código para esta opção é 121. A Microsoft decidiu reinventar a roda (como sempre) e usa o código 249 para esta opção. Portanto, para oferecer suporte a uma ampla gama de clientes, precisamos responder com os dois códigos

Vou descrever uma configuração típica usando a caixa Linux como servidor VPN (você pode configurar servidores MS usando o link para a documentação da Microsoft).

Para configurar rotas nos clientes, precisaremos dos seguintes ingredientes:

  • L2TP / IPSEC (ou PPTP) = por exemplo, o accel-ppp é um bom servidor L2TP / PPTP de código aberto
  • Servidor DHCP = existem muitos, mas vou descrever a configuração do dnsmasq

A seguir, é apresentado um despejo de uma configuração accel-ppp em funcionamento. Estou fornecendo-o em sua totalidade, caso contrário, seria difícil explicar o que vai aonde. Se você já tem sua VPN funcionando, pode pular este arquivo de configuração e se concentrar na configuração DHCP descrita abaixo.

[root@vpn ~]# cat /opt/accel-ppp/config/accel-ppp.conf
[modules]
log_syslog
pptp
l2tp
auth_mschap_v2
ippool
sigchld
chap-secrets
logwtmp

[core]
log-error=/var/log/accel-ppp/core.log
thread-count=4

[ppp]
verbose=1
min-mtu=1280
mtu=1400
mru=1400
check-ip=1
single-session=replace
mppe=require
ipv4=require
ipv6=deny
ipv6-intf-id=0:0:0:1
ipv6-peer-intf-id=0:0:0:2
ipv6-accept-peer-intf-id=1

[lcp]
lcp-echo-interval=30
lcp-echo-failure=3

[auth]
#any-login=0
#noauth=0

[pptp]
echo-interval=30
echo-failure=3
verbose=1

[l2tp]
host-name=access-vpn
verbose=1

[dns]
dns1=192.168.70.251
dns2=192.168.70.252

[client-ip-range]
disable

[ip-pool]
gw-ip-address=192.168.99.254
192.168.99.1-253

[log]
log-file=/var/log/accel-ppp/accel-ppp.log
log-emerg=/var/log/accel-ppp/emerg.log
log-fail-file=/var/log/accel-ppp/auth-fail.log
log-debug=/var/log/accel-ppp/debug.log
copy=1
level=3

[chap-secrets]
gw-ip-address=192.168.99.254
chap-secrets=/etc/ppp/chap-secrets

[cli]
telnet=127.0.0.1:2000
tcp=127.0.0.1:2001

[root@vpn ~]# 
===

Nesse ponto, nossos clientes podem se conectar via L2TP (ou PPTP) e se comunicar com o servidor VPN. Portanto, a única parte que falta é um servidor DHCP que está escutando nos túneis criados e responde com as informações necessárias. Abaixo está um trecho do arquivo de configuração dnsmasq (estou fornecendo apenas opções relacionadas ao DHCP):

[root@vpn ~]# grep -E '^dhcp' /etc/dnsmasq.conf 
dhcp-range=192.168.99.254,static
dhcp-option=option:router
dhcp-option=121,192.168.70.0/24,192.168.99.254,192.168.75.0/24,192.168.99.254,10.0.0.0/24,192.168.99.254
dhcp-option=249,192.168.70.0/24,192.168.99.254,192.168.75.0/24,192.168.99.254,10.0.0.0/24,192.168.99.254
dhcp-option=vendor:MSFT,2,1i
[root@vpn ~]#

No trecho acima, estamos enviando rotas 192.168.70.0/24, 192.168.75.0/24 e 10.0.0.0/24 por 192.168.99.254 (o servidor VPN).

Finalmente, se você farejar o tráfego de rede (por exemplo, no servidor VPN), verá algo como o seguinte para a resposta na mensagem DHCPINFORM:

19:54:46.716113 IP (tos 0x0, ttl 64, id 10142, offset 0, flags [none], proto UDP (17), length 333)
    192.168.99.254.67 > 192.168.99.153.68: BOOTP/DHCP, Reply, length 305, htype 8, hlen 6, xid 0xa27cfc5f, secs 1536, Flags [none]
      Client-IP 192.168.99.153
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 192.168.99.254
        Domain-Name Option 15, length 18: "vpn.server.tld"
        Classless-Static-Route-Microsoft Option 249, length 24: (192.168.70.0/24:192.168.99.254),(192.168.75.0/24:192.168.99.254),(10.0.0.0/24:192.168.99.254)
        Vendor-Option Option 43, length 7: 2.4.0.0.0.1.255

PS: Eu quase esqueci uma parte essencial necessária para o uso bem-sucedido da configuração acima. Bem, foi descrito nos documentos da Microsoft a que me referi, mas quem leu a documentação? :) OK, os clientes devem ser configurados sem 'Usar gateway padrão' na conexão VPN (no Windows, ele está nas propriedades da conexão -> Rede -> Protocolo Internet Versão 4 (TCP / IPv4) -> Propriedades -> Avançado -> Configurações de IP ) Em alguns clientes, há também uma opção chamada 'Desativar adição de rota baseada em classe' - ela deve estar desabilitada, pois desativa explicitamente a funcionalidade que estamos tentando implementar.

galáxia
fonte
Entendo que o L2TP clássico encapsula pacotes PPP sobre UDP. Eu posso estar errado, mas não acho que o DHCP seja suportado por PPP, principalmente enviando rotas extras. A versão 3 do L2TP (ainda bastante nova no Linux kernel land) permite que você encapsule quadros ethernet para que seja possível lá, mas tenho certeza de que a milhagem pode variar quanto à compatibilidade com dispositivos móveis.
Matthew Ife
Matthew, eu realmente não sei como resolver sua pergunta corretamente, porque você misturou muitas coisas em uma frase :) Bem, vamos começar com o seguinte: a configuração fornecida está funcionando em centenas de guerreiros que estou supervisionando. Então, é um exemplo de trabalho. Você pode pesquisar no Google para DHCP sobre PPP e ler muita documentação técnica sobre como ela é implementada pela Cisco, Juniper etc. a-ponto protocolo onde você pode usar IP, DHCP é um protocolo sobre IP, por isso estamos bem aqui :)
galáxia
1
Além disso, é bastante estranho receber esse tipo de comentário quando incluí um link para a documentação técnica da Microsoft para L2TP, onde eles descrevem como configurar as coisas corretamente usando DHCPINFORM. Eu posso entender quando as pessoas não querem ler a resposta (embora ela inclua arquivos de configuração de um sistema em funcionamento), pois é uma pesquisa de alguém, mas dizendo "Eu não acho que o DHCP seja suportado por PPP" quando houver uma especificação técnica de o criador do protocolo em que afirma que foi assim que foi projetado é meio estranho.
galaxy
Bem, para esclarecer meu ponto "DHCP não é suportado por PPP", quero dizer que a atribuição de endereço IP ocorre através do protocolo de controle de link PPP (os pontos a ponto não têm noção de um endereço de "transmissão"). Então eu acho que você não entendeu o que eu estava falando. Entendo agora o que você quer dizer é que o DHCPINFORM ocorre dentro do túnel após o estabelecimento da conexão e não tem nada a ver com a conexão inicial. Concordo agora que esse esquema funciona, desde que o cliente envie uma mensagem DHCPINFORM após a conexão ser configurada.
Matthew Ife
Mathew, obrigado :). Sim, não estamos usando o DHCP para atribuição de endereços, é feito pelo IPCP (e não pelo LCP, como você disse, mas isso é irrelevante); no entanto, a documentação técnica da Microsoft afirma que um cliente válido deve enviar a mensagem DHCPINFORM com a opção 249 para obter configuração de rota, e é exatamente isso que descrevi na minha resposta. Bem, alguém já votou a minha resposta para baixo embora seja um trabalho, resposta válida :)
galáxia
1

Eu não acho que você pode enviar uma rota para o cliente em uma VPN L2TP / IPSEC. Você precisará fazer a configuração diretamente no cliente.

Com qual cliente móvel você está tendo problemas? É mais fácil fornecer alguma entrada se conhecermos o sistema operacional e o software que você está usando.

pehrs
fonte