OK, esta pregunta se hace una y otra vez a través de Internet y la mayoría de las veces hay una respuesta (semi) incorrecta de que no puedes hacer lo que se describió en la publicación original. Déjame aclararlo de una vez por todas :)
La respuesta corta es que L2TP (y PPTP para el caso) no tienen facilidades para hacer empujes de ruta dentro del protocolo, pero se puede lograr fuera del protocolo.
Como L2TP es un invento de Microsoft, la mejor fuente de información es su documentación técnica (por cierto, son bastante buenos). La descripción técnica de lo que voy a explicar a continuación se puede encontrar en Direccionamiento y enrutamiento VPN . Las palabras clave para configurar todo correctamente (si va a hacer su propia investigación) son: DHCPINFORM y "rutas estáticas sin clase".
En primer lugar, cómo funciona:
- un cliente se conecta al servidor VPN
- Después de una autenticación exitosa, se establece un túnel seguro
- el cliente usa un mensaje DHCPINFORM después de la conexión para solicitar la opción Rutas estáticas sin clase de DHCP. Esta opción de DHCP contiene un conjunto de rutas que se agregan automáticamente a la tabla de enrutamiento del cliente solicitante ( copié y pegué esta línea directamente desde la documentación de Microsoft :))
- el servidor VPN responde a ese mensaje con el conjunto apropiado de rutas
Bueno, hay una advertencia:
- hay RFC-3442 que describe "Rutas estáticas sin clase DHCP" y establece que el código para esta opción es 121. Microsoft decidió reinventar la rueda (como siempre) y usa el código 249 para esta opción. Por lo tanto, para admitir una gama más amplia de clientes, debemos responder con ambos códigos
Voy a describir una configuración típica usando Linux box como el servidor VPN (puede configurar servidores MS usando el enlace a la documentación de Microsoft).
Para configurar rutas en los clientes necesitaremos los siguientes ingredientes:
- L2TP / IPSEC (o PPTP) = por ejemplo, accel-ppp es un buen servidor de código abierto L2TP / PPTP
- Servidor DHCP = hay muchos, pero voy a describir la configuración de dnsmasq
El siguiente es un volcado de una configuración accel-ppp en funcionamiento. Lo estoy proporcionando en su totalidad, de lo contrario sería difícil explicar qué va a dónde. Si ya tiene su VPN funcionando, puede omitir este archivo de configuración y concentrarse en la configuración de DHCP que se describe a continuación.
[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 ~]#
===
En este punto, nuestros clientes pueden conectarse a través de L2TP (o PPTP) y comunicarse con el servidor VPN. Entonces, la única parte que falta es un servidor DHCP que está escuchando en los túneles creados y que responde con la información necesaria. A continuación se muestra un extracto del archivo de configuración dnsmasq (solo proporciono opciones relacionadas con 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 ~]#
En el extracto anterior, estamos empujando las rutas 192.168.70.0/24, 192.168.75.0/24 y 10.0.0.0/24 a través de 192.168.99.254 (el servidor VPN).
Finalmente, si olfatea el tráfico de red (por ejemplo, en el servidor VPN) verá algo como lo siguiente para la respuesta en el mensaje 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
PD: casi olvido una parte esencial requerida para el uso exitoso de la configuración anterior. Bueno, se describió en los documentos de Microsoft a los que me referí, pero ¿quién leyó la documentación? :) OK, los clientes deben configurarse sin 'Usar puerta de enlace predeterminada' en la conexión VPN (en Windows está en las propiedades de la conexión -> Redes -> Protocolo de Internet Versión 4 (TCP / IPv4) -> Propiedades -> Avanzado -> Configuración de IP ) En algunos clientes también hay una opción llamada 'Deshabilitar la adición de ruta basada en la clase': debe estar deshabilitada ya que deshabilita explícitamente la funcionalidad que estamos tratando de implementar.