OK, to pytanie jest zadawane w kółko przez Internet i przez większość czasu istnieje (częściowo) niepoprawna odpowiedź, że nie możesz zrobić tego, co opisano w oryginalnym poście. Pozwól, że wyjaśnię to raz na zawsze :)
Krótka odpowiedź brzmi: L2TP (i PPTP w tym przypadku) nie mają możliwości wykonywania wypychania trasy wewnątrz protokołu, ale można to osiągnąć poza protokołem.
Ponieważ L2TP jest wynalazkiem Microsoft, najlepszym źródłem informacji jest ich dokumentacja techniczna (a przy okazji są w tym całkiem dobrzy). Opis techniczny tego, co wyjaśnię poniżej, można znaleźć w Adresowaniu i routingu VPN . Słowami kluczowymi do prawidłowego skonfigurowania wszystkiego (jeśli zamierzasz przeprowadzić własne badania) są: DHCPINFORM i „bezklasowe trasy statyczne”.
Po pierwsze, jak to działa:
- klient łączy się z serwerem VPN
- po udanym uwierzytelnieniu ustanawiany jest bezpieczny tunel
- klient używa komunikatu DHCPINFORM po połączeniu, aby zażądać opcji bezklasowych tras statycznych DHCP. Ta opcja DHCP zawiera zestaw tras, które są automatycznie dodawane do tabeli routingu klienta żądającego ( niewolniczo skopiowałem i wkleiłem ten wiersz bezpośrednio z dokumentacji Microsoft :))
- serwer VPN odpowiada na ten komunikat odpowiednim zestawem tras
Jest jednak zastrzeżenie:
- istnieje RFC-3442 opisujący „Bezklasowe trasy statyczne DHCP” i tam stwierdza, że kodem tej opcji jest 121. Microsoft postanowił ponownie wynaleźć koło (jak zawsze) i używa kodu 249 dla tej opcji. Dlatego, aby wesprzeć szerszy zakres klientów, musimy odpowiedzieć na oba kody
Opiszę typową konfigurację z wykorzystaniem Linux-a jako serwera VPN (możesz skonfigurować serwery MS, korzystając z łącza do dokumentacji Microsoft).
Aby skonfigurować trasy na klientach, będziemy potrzebować następujących składników:
- L2TP / IPSEC (lub PPTP) = na przykład accel-ppp to fajny serwer L2TP / PPTP typu open source
- Serwer DHCP = jest ich wiele, ale opiszę konfigurację dnsmasq
Poniżej znajduje się zrzut działającej konfiguracji accel-ppp. Podaję w całości, w przeciwnym razie trudno byłoby wytłumaczyć, co się dzieje. Jeśli masz już działającą sieć VPN, możesz pominąć ten plik konfiguracyjny i skoncentrować się na konfiguracji DHCP opisanej poniżej.
[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 ~]#
===
W tym momencie nasi klienci mogą łączyć się przez L2TP (lub PPTP) i komunikować się z serwerem VPN. Tak więc jedyną brakującą częścią jest serwer DHCP, który nasłuchuje w utworzonych tunelach i odpowiada niezbędnymi informacjami. Poniżej znajduje się fragment pliku konfiguracyjnego dnsmasq (podaję tylko opcje związane z 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 ~]#
W powyższym fragmencie wypychamy trasy 192.168.70.0/24, 192.168.75.0/24 i 10.0.0.0/24 przez 192.168.99.254 (serwer VPN).
Wreszcie, jeśli wykryjesz ruch sieciowy (np. Na serwerze VPN), zobaczysz coś w rodzaju odpowiedzi na komunikat 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 Prawie zapomniałem o istotnej części wymaganej do udanego użycia powyższej konfiguracji. Cóż, zostało to opisane w dokumentach Microsoft, o których mówiłem, ale kto czyta dokumentację? :) OK, klienci powinni zostać skonfigurowani bez użycia opcji „Użyj domyślnej bramy” na połączeniu VPN (w systemie Windows jest to we właściwościach połączenia -> Sieć -> Protokół internetowy w wersji 4 (TCP / IPv4) -> Właściwości -> Zaawansowane -> Ustawienia IP ). Na niektórych klientach dostępna jest również opcja o nazwie „Wyłącz dodawanie tras w oparciu o klasy” - należy ją wyłączyć, ponieważ wyraźnie wyłącza funkcję, którą próbujemy wdrożyć.