È possibile per la VPN L2TP eseguire la configurazione automatica del percorso per il client durante la connessione?

OK, questa domanda viene posta più e più volte su Internet e la maggior parte delle volte c'è una risposta (semi) errata che non puoi fare ciò che è stato descritto nel post originale. Chiarisco una volta per tutte :)

La risposta breve è che L2TP (e PPTP per quella materia) non hanno strutture per fare instradamenti push all'interno del protocollo, ma possono essere raggiunti al di fuori del protocollo.

Poiché L2TP è un'invenzione di Microsoft, la migliore fonte di informazioni è la loro documentazione tecnica (e tra l'altro sono piuttosto bravi). La descrizione tecnica di ciò che spiegherò di seguito può essere trovata in Indirizzamento e routing VPN. Le parole chiave per impostare tutto correttamente (se hai intenzione di fare le tue ricerche) sono:DHCPINFORM e "percorsi statici senza classi".

Prima di tutto, come funziona:

1. un client si connette al server VPN
2. dopo che l'autenticazione ha avuto successo, viene stabilito un tunnel sicuro
3. il client utilizza un messaggio DHCPINFORM dopo la connessione per richiedere l'opzione DHCP Classless Static Routes. Questa opzione DHCP contiene una serie di route che vengono aggiunte automaticamente alla tabella di routing del client richiedente (ho copiato e incollato pedissequamente questa riga direttamente dalla documentazione Microsoft :) )
4. il server VPN risponde a quel messaggio con un set di route appropriato

Bene, c'è un avvertimento:

• c'è RFC-3442 che descrive "DHCP Classless Static Routes" 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 configurazione tipica utilizzando Linux box come server VPN (è possibile configurare i server MS utilizzando 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 buon server L2TP/PPTP open source
• Server DHCP =ce ne sono molti, ma descriverò la configurazione di dnsmasq

Quello che segue è un dump di una configurazione accel-ppp funzionante. Lo fornisco nella sua interezza, altrimenti sarebbe difficile spiegare cosa va dove. Se la tua VPN è già funzionante, puoi saltare questo file di configurazione e concentrarti sulla configurazione DHCP descritta di seguito.

[[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] ~]# 
===

A questo punto i nostri client 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 dnsmasq (fornisco solo opzioni relative a 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] ~]#

Nell'estratto precedente stiamo inviando le route 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 sniffi 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

P.S. Quasi dimenticavo una parte essenziale richiesta per il corretto utilizzo della suddetta configurazione. Bene, è stato descritto nei documenti Microsoft a cui ho fatto riferimento, 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 c'è anche un'opzione chiamata 'Disable class based route addition' - deve essere disattivata poiché disabilita esplicitamente la funzionalità che stiamo cercando di implementare.