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 selon laquelle 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 la possibilité de faire 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'information est leur documentation technique (et ils sont assez bons dans ce domaine, d'ailleurs). La description technique de ce que je vais expliquer ci-dessous se trouve dans Adressage et routage VPN. /P>
Tout d'abord, comment ça marche :
- 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 copié-collé servilement cette ligne directement à partir de la documentation Microsoft :) )
- le serveur VPN répond à ce message avec un ensemble de routes approprié
Eh bien, il y a une mise en garde :
- il y a RFC-3442 décrivant "DHCP Classless Static Routes" et là, il indique 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 machine Linux comme serveur VPN (vous pouvez configurer les serveurs MS en utilisant le lien vers la documentation Microsoft).
Pour configurer les routes sur les clients, nous aurons besoin des ingrédients suivants :
- L2TP/IPSEC (ou PPTP) =par exemple, accel-ppp est un bon serveur open source L2TP/PPTP
- 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 accel-ppp fonctionnelle. Je le fournis dans son intégralité, sinon il serait difficile d'expliquer ce qui va 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.
[[email protected] ~]# 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
[[email protected] ~]#
===
À 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 les tunnels créés et qui répond avec les informations nécessaires. Vous trouverez ci-dessous un extrait du fichier de configuration dnsmasq (je ne fournis que les options liées au DHCP) :
[[email protected] ~]# 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
[[email protected] ~]#
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'allais oublier une partie essentielle nécessaire à la bonne utilisation 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, c'est dans les propriétés de la connexion -> Réseau -> Internet Protocol 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 la classe" - elle doit être désactivée car elle désactive explicitement la fonctionnalité que nous essayons d'implémenter.