OK, questa domanda viene posta più volte su Internet e il più delle volte c'è una risposta (semi) errata che non puoi fare ciò che è stato descritto nel post originale. Vorrei chiarirlo una volta per tutte :)
La risposta breve è che L2TP (e PPTP del resto) non dispongono di strutture per eseguire push di route all'interno del protocollo, ma può essere realizzato al di fuori del protocollo.
Poiché L2TP è un'invenzione di Microsoft, la migliore fonte di informazioni è la loro documentazione tecnica (e comunque sono abbastanza bravi a farlo). La descrizione tecnica di ciò che ho intenzione di spiegare di seguito è disponibile all'indirizzo e indirizzamento VPN . Le parole chiave per impostare tutto correttamente (se hai intenzione di fare le tue ricerche) sono: DHCPINFORM e "route statiche senza classi".
Prima di tutto, come funziona:
- un client si connette al server VPN
- dopo l'autenticazione riuscita viene stabilito un tunnel sicuro
- il client utilizza un messaggio DHCPINFORM dopo la connessione per richiedere l'opzione Percorsi statici senza classi DHCP. Questa opzione DHCP contiene una serie di route che vengono automaticamente aggiunte alla tabella di routing del client richiedente ( ho copiato e incollato questa riga in modo diretto direttamente dalla documentazione Microsoft :))
- il server VPN risponde a quel messaggio con una serie appropriata di rotte
Bene, c'è un avvertimento:
- c'è RFC-3442 che descrive "DHCP Classless Static Route" e afferma che il codice per questa opzione è 121. Microsoft ha deciso di reinventare la ruota (come sempre) e usa il codice 249 per questa opzione. Pertanto, per supportare una gamma più ampia di clienti dobbiamo rispondere con entrambi i codici
Descriverò una tipica configurazione usando Linux box come server VPN (puoi configurare i server MS usando il collegamento alla documentazione Microsoft).
Per configurare i percorsi sui client avremo bisogno dei seguenti ingredienti:
- L2TP / IPSEC (o PPTP) = ad esempio, accel-ppp è un bel server L2TP / PPTP open source
- Server DHCP = ce ne sono molti, ma ho intenzione di descrivere la configurazione di dnsmasq
Di seguito è riportato un dump di una configurazione accel-ppp funzionante. Lo sto fornendo nella sua interezza, altrimenti sarebbe difficile spiegare cosa va dove. Se hai già la tua VPN funzionante, puoi saltare questo file di configurazione e concentrarti sulla configurazione DHCP descritta di seguito.
[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 ~]#
===
A questo punto i nostri clienti possono connettersi tramite L2TP (o PPTP) e comunicare con il server VPN. Quindi, l'unica parte mancante è un server DHCP che è in ascolto sui tunnel creati e che risponde con le informazioni necessarie. Di seguito è riportato un estratto dal file di configurazione di dnsmasq (sto fornendo solo opzioni relative al 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 ~]#
Nell'estratto sopra stiamo spingendo i percorsi 192.168.70.0/24, 192.168.75.0/24 e 10.0.0.0/24 tramite 192.168.99.254 (il server VPN).
Infine, se annusi il traffico di rete (ad es. Sul server VPN) vedrai qualcosa di simile al seguente per la risposta sul messaggio 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 Ho quasi dimenticato una parte essenziale richiesta per il corretto utilizzo della configurazione di cui sopra. Bene, è stato descritto nei documenti Microsoft a cui mi riferivo, ma chi ha letto la documentazione? :) OK, i client devono essere configurati senza "Usa gateway predefinito" sulla connessione VPN (su Windows è nelle proprietà della connessione -> Rete -> Protocollo Internet versione 4 (TCP / IPv4) -> Proprietà -> Avanzate -> Impostazioni IP ). Su alcuni client esiste anche un'opzione chiamata "Disabilita aggiunta route basata su classe": deve essere disinserita poiché disabilita esplicitamente la funzionalità che stiamo cercando di implementare.