Est-il possible pour le VPN L2TP de faire la configuration automatique de l'itinéraire pour le client pendant la connexion?

13

Nous avons configuré un serveur VPN L2TP avec ce tutoriel , tout fonctionne comme un charme.

Le seul problème est

  1. Nous ne voulons pas que le client achemine tout le trafic à l'aide de ce VPN, seulement un sous-réseau particulier, par exemple 10.0.0.0/20

  2. Sur Mac, nous devons définir l'itinéraire manuellement à l'aide de la commande, mais pour les appareils mobiles, il semble qu'il n'y ait aucun moyen de le faire?

Donc, il est possible de configurer automatiquement pour le client pour le sous-réseau "10.0.0.0/20"?

linux vpn linux-networking ipsec l2tp Howard
la source
Avez-vous essayé de désactiver l'option «envoyer tout le trafic via VPN» ou une option similaire sur le client?
Bert

Réponses:

33

OK, cette question est posée maintes et maintes fois sur Internet et la plupart du temps il y a une réponse (semi-) incorrecte que vous ne pouvez pas faire ce qui a été décrit dans le message d'origine. Permettez-moi de le clarifier une fois pour toutes :)

La réponse courte est que L2TP (et PPTP d'ailleurs) n'ont pas de fonctionnalités pour effectuer des poussées de route à l'intérieur du protocole, mais cela peut être réalisé en dehors du protocole.

Étant donné que L2TP est une invention de Microsoft, la meilleure source d'informations est leur documentation technique (et ils sont très bons dans ce domaine, soit dit en passant). La description technique de ce que je vais expliquer ci-dessous peut être trouvée sur l' adressage et le routage VPN . Les mots clés pour tout configurer correctement (si vous voulez faire votre propre recherche) sont: DHCPINFORM et "routes statiques sans classe".

Tout d'abord, comment cela fonctionne:

  1. un client se connecte au serveur VPN
  2. après une authentification réussie, un tunnel sécurisé est établi
  3. le client utilise un message DHCPINFORM après la connexion pour demander l'option DHCP Classless Static Routes. Cette option DHCP contient un ensemble de routes qui sont automatiquement ajoutées à la table de routage du client demandeur ( j'ai copieusement copié et collé cette ligne directement à partir de la documentation Microsoft :))
  4. le serveur VPN répond à ce message avec un ensemble approprié de routes

Eh bien, il y a une mise en garde:

  • il y a la RFC-3442 décrivant "DHCP Classless Static Routes" et là, elle déclare que le code de cette option est 121. Microsoft a décidé de réinventer la roue (comme toujours) et utilise le code 249 pour cette option. Par conséquent, pour prendre en charge un plus large éventail de clients, nous devons répondre avec les deux codes

Je vais décrire une configuration typique utilisant la boîte Linux comme serveur VPN (vous pouvez configurer les serveurs MS en utilisant le lien vers la documentation Microsoft).

Pour configurer les itinéraires sur les clients, nous aurons besoin des ingrédients suivants:

  • L2TP / IPSEC (ou PPTP) = par exemple, accel-ppp est un joli serveur L2TP / PPTP open source
  • Serveur DHCP = il y en a beaucoup, mais je vais décrire la configuration de dnsmasq

Ce qui suit est un vidage d'une configuration d'accel-ppp qui fonctionne. Je le fournis dans son intégralité, sinon il serait difficile d'expliquer ce qui se passe où. Si votre VPN fonctionne déjà, vous pouvez ignorer ce fichier de configuration et vous concentrer sur la configuration DHCP décrite ci-dessous.

[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 ~]# 
===

À ce stade, nos clients peuvent se connecter via L2TP (ou PPTP) et communiquer avec le serveur VPN. Ainsi, la seule partie manquante est un serveur DHCP qui écoute sur les tunnels créés et qui répond avec les informations nécessaires. Ci-dessous, un extrait du fichier de configuration dnsmasq (je ne fournis que des options liées à 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 ~]#

Dans l'extrait ci-dessus, nous poussons les routes 192.168.70.0/24, 192.168.75.0/24 et 10.0.0.0/24 via 192.168.99.254 (le serveur VPN).

Enfin, si vous reniflez le trafic réseau (par exemple sur le serveur VPN), vous verrez quelque chose comme ce qui suit pour la réponse sur le message 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 J'ai presque oublié une partie essentielle requise pour une utilisation réussie de la configuration ci-dessus. Eh bien, cela a été décrit dans les documents Microsoft auxquels j'ai fait référence, mais qui a lu la documentation? :) OK, les clients doivent être configurés sans 'Utiliser la passerelle par défaut' sur la connexion VPN (sous Windows, il est dans les propriétés de la connexion -> Réseau -> Protocole Internet version 4 (TCP / IPv4) -> Propriétés -> Avancé -> Paramètres IP ). Sur certains clients, il existe également une option appelée «Désactiver l'ajout d'itinéraire basé sur une classe» - elle doit être désactivée car elle désactive explicitement la fonctionnalité que nous essayons d'implémenter.

galaxie
la source
Je crois comprendre que le L2TP classique encapsule les paquets PPP sur UDP. Je peux me tromper, mais je ne pense pas que DHCP soit pris en charge sur PPP, en particulier pour l'envoi de routes supplémentaires. La version 3 de L2TP (encore assez nouvelle dans le noyau Linux) vous permet d'encapsuler des trames Ethernet afin que cela soit possible là-bas, mais je suis presque sûr que le kilométrage peut varier quant à la qualité de la prise en charge sur les appareils mobiles.
Matthew Ife
Matthew, je ne sais pas vraiment comment répondre correctement à votre question puisque vous avez mélangé tant de choses en une seule phrase :) Eh bien, commençons par ce qui suit: la configuration fournie fonctionne sur des centaines de routiers que je supervise. C'est donc un exemple de travail. Vous pouvez Google pour DHCP sur PPP et lire beaucoup de documentation technique sur la façon dont il est mis en œuvre par Cisco, Juniper, etc. Si vous ne voulez pas vous y plonger, imaginez simplement que L2TP encapsule PPP sur UDP, PPP est un point- protocole point à point où vous pouvez utiliser IP, DHCP est un protocole sur IP, donc nous sommes bons ici :)
galaxy
1
En outre, il est assez étrange d'obtenir ce genre de commentaires lorsque j'ai inclus un lien vers la documentation technique Microsoft pour L2TP où ils décrivent comment configurer correctement les choses à l'aide de DHCPINFORM. Je peux comprendre quand les gens ne veulent pas lire la réponse (bien que cela comprenne des fichiers de configuration à partir d'un système qui fonctionne) car c'est la recherche de quelqu'un, mais dire "je ne pense pas que DHCP est pris en charge sur PPP" quand il y a une spécification technique de le créateur du protocole où il déclare que c'est ainsi qu'il a été conçu est assez étrange.
galaxy
Eh bien pour clarifier mon point "DHCP n'est pas pris en charge sur PPP", je veux dire que l'attribution d'adresse IP se produit sur le protocole de contrôle de liaison PPP (les points à points n'ont aucune notion d'adresse de "diffusion"). Je pense donc que vous avez mal compris où je voulais en venir. Je vois maintenant ce que vous voulez dire, c'est que DHCPINFORM se produit à l'intérieur du tunnel après l'établissement de la connexion et n'a rien à voir avec la connexion initiale. J'accepte maintenant que ce schéma fonctionne, à condition que le client envoie un message DHCPINFORM une fois la connexion établie.
Matthew Ife
Mathew, merci :). Oui, nous n'utilisons pas DHCP pour l'attribution d'adresses, cela se fait par IPCP (et non LCP comme vous l'avez dit, mais cela n'est pas pertinent), cependant, la documentation technique de Microsoft indique qu'un client valide doit envoyer le message DHCPINFORM avec l'option 249 pour obtenir configuration de l'itinéraire, et c'est exactement ce que j'ai décrit dans ma réponse. Eh bien, quelqu'un a déjà voté ma réponse bien que ce soit une réponse valide et fonctionnelle :)
Galaxy
1

Je ne pense pas que vous puissiez pousser une route vers le client dans un VPN L2TP / IPSEC. Vous devrez faire la configuration directement sur le client.

Avec quel client mobile rencontrez-vous des problèmes? Il est plus facile de fournir une entrée si nous connaissons le système d'exploitation et le logiciel que vous utilisez.

pehrs
la source