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:
- un client se connecte au serveur VPN
- après une authentification réussie, un tunnel sécurisé est établi
- 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 :))
- 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.