OK, diese Frage wird immer und immer wieder über das Internet gestellt und die meiste Zeit gibt es eine (halb-) falsche Antwort, die Sie nicht tun können, was im ursprünglichen Beitrag beschrieben wurde. Lass es mich ein für alle Mal klarstellen :)
Die kurze Antwort lautet: L2TP (und PPTP in diesem Fall) verfügen nicht über die Möglichkeit, Routing-Pushs innerhalb des Protokolls durchzuführen, sie können jedoch außerhalb des Protokolls durchgeführt werden.
Da es sich bei L2TP um eine Erfindung von Microsoft handelt, ist die beste Informationsquelle die technische Dokumentation (und sie sind übrigens recht gut darin). Die technische Beschreibung dessen, was ich unten erläutern werde, finden Sie unter VPN-Adressierung und -Routing . Die Schlüsselwörter für die ordnungsgemäße Einrichtung sind: DHCPINFORM und "klassenlose statische Routen".
Zuallererst, wie es funktioniert:
- Ein Client stellt eine Verbindung zum VPN-Server her
- Nach erfolgreicher Authentifizierung wird ein sicherer Tunnel aufgebaut
- Der Client verwendet eine DHCPINFORM-Nachricht nach der Verbindung, um die Option DHCP Classless Static Routes anzufordern. Diese DHCP-Option enthält eine Reihe von Routen, die automatisch zur Routing-Tabelle des anfordernden Clients hinzugefügt werden ( diese Zeile habe ich direkt aus der Microsoft-Dokumentation kopiert und eingefügt :)).
- Der VPN-Server antwortet auf diese Nachricht mit den entsprechenden Routen
Nun, es gibt eine Einschränkung:
- Es gibt RFC-3442 , der "DHCP Classless Static Routes" beschreibt, und dort heißt es, dass der Code für diese Option 121 lautet. Microsoft hat beschlossen, das Rad (wie immer) neu zu erfinden, und verwendet Code 249 für diese Option. Um eine größere Anzahl von Kunden zu unterstützen, müssen wir daher mit beiden Codes antworten
Ich beschreibe eine typische Konfiguration unter Verwendung der Linux-Box als VPN-Server (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) = accel-ppp ist zum Beispiel ein netter Open-Source-L2TP / PPTP-Server
- DHCP-Server = es gibt viele, aber ich werde die Konfiguration von dnsmasq beschreiben
Das Folgende ist ein Speicherauszug einer funktionierenden accel-ppp-Konfiguration. Ich biete es in seiner Gesamtheit an, sonst wäre es schwierig zu erklären, was wohin geht. Wenn Ihr VPN bereits funktioniert, können Sie diese Konfigurationsdatei überspringen und sich auf die unten beschriebene DHCP-Konfiguration konzentrieren.
[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 ~]#
===
Zu diesem Zeitpunkt können unsere Clients eine Verbindung über L2TP (oder PPTP) herstellen und mit dem VPN-Server kommunizieren. Der einzige fehlende Teil ist also ein DHCP-Server, der die erstellten Tunnel überwacht und mit den erforderlichen Informationen antwortet. Unten finden Sie einen Auszug aus der dnsmasq-Konfigurationsdatei (ich biete nur DHCP-bezogene Optionen an):
[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 ~]#
Im obigen Auszug werden 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) übertragen.
Wenn Sie den Netzwerkverkehr abhören (z. B. auf dem VPN-Server), wird für die Antwort auf die DHCPINFORM-Nachricht Folgendes angezeigt:
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 Ich habe 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 für die VPN-Verbindung ohne "Standard-Gateway verwenden" konfiguriert werden (unter Windows finden Sie dies in den Eigenschaften der Verbindung -> Netzwerk -> Internetprotokoll Version 4 (TCP / IPv4) -> Eigenschaften -> Erweitert -> IP-Einstellungen ). Auf einigen Clients gibt es auch die Option "Klassenbasiertes Hinzufügen von Routen deaktivieren". Diese Option muss deaktiviert werden, da die von uns zu implementierende Funktionalität explizit deaktiviert wird.