Bien, esta pregunta se hace una y otra vez en Internet y la mayoría de las veces hay una respuesta (semi) incorrecta de que no puedes hacer lo que se describe 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 realizar envíos de ruta dentro del protocolo, pero se puede lograr fuera del protocolo.
Dado que L2TP es una invención de Microsoft, la mejor fuente de información es su documentación técnica (y, por cierto, son bastante buenos en eso). La descripción técnica de lo que voy a explicar a continuación se puede encontrar en Direccionamiento y enrutamiento de VPN. Las palabras clave para configurar todo correctamente (si va a hacer su propia investigación) son:DHCPINFORM y "rutas estáticas sin clases".
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 DHCP Classless Static Routes. 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é servilmente esta línea directamente de la documentación de Microsoft :) )
- el servidor VPN responde a ese mensaje con el conjunto de rutas adecuado
Bueno, hay una advertencia:
- hay RFC-3442 que describe "Rutas estáticas sin clase DHCP" y allí 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 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 L2TP/PPTP de código abierto
- 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.
[[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] ~]#
===
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 responda con la información necesaria. A continuación, se muestra un extracto del archivo de configuración de dnsmasq (solo brindo opciones relacionadas con 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] ~]#
En el extracto anterior, estamos impulsando 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 rastrea el tráfico de la 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? :) De acuerdo, 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 adición de ruta basada en clase':debe desactivarse ya que deshabilita explícitamente la funcionalidad que estamos tratando de implementar.