OK, diese Frage wird im Internet immer wieder gestellt und meistens kommt eine (halb-)falsche Antwort, dass man nicht das machen kann, was im ursprünglichen Post beschrieben wurde. Lass es mich ein für alle Mal klarstellen :)
Die kurze Antwort ist, dass L2TP (und PPTP in dieser Hinsicht) keine Einrichtungen haben, um Route Pushes innerhalb des Protokolls durchzuführen, aber es kann außerhalb des Protokolls erreicht werden.
Da L2TP eine Erfindung von Microsoft ist, ist die beste Informationsquelle ihre technische Dokumentation (und sie sind übrigens ziemlich gut darin). Die technische Beschreibung dessen, was ich im Folgenden erläutern werde, finden Sie unter VPN-Adressierung und -Routing. Die Schlüsselwörter, um alles richtig einzurichten (wenn Sie selbst recherchieren wollen), lauten:DHCPINFORM und "classless static routes".
Zunächst einmal, wie es funktioniert:
- ein Client verbindet sich mit dem VPN-Server
- nach erfolgreicher Authentifizierung wird ein sicherer Tunnel aufgebaut
- Der Client verwendet nach der Verbindung eine DHCPINFORM-Nachricht, um die DHCP-Option für klassenlose statische Routen anzufordern. Diese DHCP-Option enthält eine Reihe von Routen, die automatisch zur Routing-Tabelle des anfragenden Clients hinzugefügt werden (Ich habe diese Zeile sklavisch direkt aus der Microsoft-Dokumentation kopiert und eingefügt :) )
- der VPN-Server antwortet auf diese Nachricht mit einem geeigneten Satz von Routen
Nun, es gibt einen Vorbehalt:
- Es gibt RFC-3442, das "DHCP Classless Static Routes" beschreibt und besagt, dass der Code für diese Option 121 ist. Microsoft hat sich entschieden, das Rad neu zu erfinden (wie immer) und verwendet Code 249 für diese Option. Um eine breitere Palette von Kunden zu unterstützen, müssen wir daher mit beiden Codes antworten
Ich werde eine typische Konfiguration mit einer Linux-Box als VPN-Server beschreiben (Sie können MS-Server über den Link zur Microsoft-Dokumentation konfigurieren).
Um Routen auf den Clients zu konfigurieren, benötigen wir die folgenden Zutaten:
- L2TP/IPSEC (oder PPTP) =zum Beispiel ist accel-ppp ein netter Open-Source-L2TP/PPTP-Server
- DHCP-Server =es gibt viele, aber ich werde die Konfiguration von dnsmasq beschreiben
Das Folgende ist ein Dump einer funktionierenden accel-ppp-Konfiguration. Ich stelle es in seiner Gesamtheit zur Verfügung, sonst wäre es schwierig zu erklären, was wohin gehört. Wenn Ihr VPN bereits funktioniert, können Sie diese Konfigurationsdatei überspringen und sich auf die unten beschriebene DHCP-Konfiguration konzentrieren.
[[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] ~]#
===
An diesem Punkt können sich unsere Clients über L2TP (oder PPTP) verbinden und mit dem VPN-Server kommunizieren. Das einzige, was fehlt, ist ein DHCP-Server, der die erstellten Tunnel abhört und mit den erforderlichen Informationen zurückantwortet. Unten ist ein Auszug aus der dnsmasq-Konfigurationsdatei (ich stelle nur DHCP-bezogene Optionen bereit):
[[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] ~]#
Im obigen Auszug pushen wir die Routen 192.168.70.0/24, 192.168.75.0/24 und 10.0.0.0/24 über 192.168.99.254 (den VPN-Server).
Wenn Sie schließlich den Netzwerkverkehr ausspähen (z. B. auf dem VPN-Server), sehen Sie für die Antwort auf die DHCPINFORM-Nachricht etwa Folgendes:
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
P.S. Ich hätte fast einen wesentlichen Teil vergessen, der für die erfolgreiche Verwendung der obigen Konfiguration erforderlich ist. Nun, es wurde in den Microsoft-Dokumenten beschrieben, auf die ich mich bezog, aber wer hat die Dokumentation gelesen? :) OK, Clients sollten ohne 'Standard-Gateway verwenden' auf der VPN-Verbindung konfiguriert werden (unter Windows in den Verbindungseigenschaften -> Netzwerk -> Internetprotokoll Version 4 (TCP/IPv4) -> Eigenschaften -> Erweitert -> IP-Einstellungen ). Auf einigen Clients gibt es auch eine Option namens „Klassenbasiertes Hinzufügen von Routen deaktivieren“ – sie muss deaktiviert werden, da sie die Funktionalität, die wir zu implementieren versuchen, explizit deaktiviert.