Czy L2TP VPN może przeprowadzić automatyczną konfigurację trasy dla klienta podczas połączenia?

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ć.

galaktyka
źródło

Rozumiem, że klasyczny L2TP hermetyzuje pakiety PPP przez UDP. Mogę się mylić, ale nie sądzę, że DHCP jest obsługiwany przez PPP, szczególnie wysyłanie dodatkowych tras. L2TP wersja 3 (wciąż całkiem nowa w jądrze Linuksa) pozwala na enkapsulację ramek ethernetowych, więc może być tam możliwe, ale jestem pewien, że przebieg może się różnić w zależności od tego, jak dobrze jest obsługiwany na urządzeniach mobilnych.

Matthew Ife

Matthew, tak naprawdę nie wiem, jak właściwie odpowiedzieć na twoje pytanie, ponieważ pomieszałeś tyle rzeczy w jednym zdaniu :) Cóż, zacznijmy od tego: podana konfiguracja działa na setkach wojowników, których nadzoruję. Jest to działający przykład. Możesz Google dla DHCP za pośrednictwem PPP i przeczytać wiele dokumentacji technicznej na temat tego, jak jest on wdrażany przez Cisco, Juniper itp. Jeśli nie chcesz się w to zanurzać, po prostu wyobraź sobie, że L2TP kapsułkuje PPP przez UDP, PPP to punkt protokół point-point, w którym możesz używać IP, DHCP jest protokołem przez IP, więc jesteśmy tutaj dobrzy :)

galaxy

Ponadto dość dziwne jest otrzymywanie tego rodzaju komentarzy, gdy zamieściłem link do dokumentacji technicznej Microsoft dla L2TP, gdzie opisują one, jak poprawnie skonfigurować ustawienia za pomocą DHCPINFORM. Rozumiem, kiedy ludzie nie chcą czytać odpowiedzi (chociaż zawiera pliki konfiguracyjne z działającego systemu), ponieważ czyjąś badania, ale mówiąc: „Nie sądzę, że DHCP jest obsługiwany przez PPP”, gdy istnieje specyfikacja techniczna z twórca protokołu, w którym stwierdza, że w taki sposób został zaprojektowany, jest dość dziwny.

galaktyka

Cóż, aby wyjaśnić mój punkt: „DHCP nie jest obsługiwany przez PPP”, mam na myśli, że przypisanie adresu IP następuje przez protokół kontroli łącza PPP (punkt do punktu nie ma pojęcia adresu „rozgłoszeniowego”). Myślę więc, że źle zrozumiałeś, o co mi chodziło. Rozumiem teraz, co masz na myśli, że DHCPINFORM występuje w tunelu po ustanowieniu połączenia i nie ma nic wspólnego z początkowym połączeniem. Zgadzam się teraz, że ten schemat działa, pod warunkiem, że klient wyśle komunikat DHCPINFORM po skonfigurowaniu połączenia.

Matthew Ife

Mathew, dzięki :). Tak, nie używamy DHCP do przypisywania adresów, robi to IPCP (a nie LCP, jak powiedziałeś, ale to nie ma znaczenia), jednak dokumentacja techniczna Microsoft stwierdza, że prawidłowy klient powinien wysłać komunikat DHCPINFORM z opcją 249, aby uzyskać konfiguracja trasy, i dokładnie to opisałem w mojej odpowiedzi. Cóż, ktoś już głosował na moją odpowiedź, chociaż jest to poprawna, działająca odpowiedź :)

galaktyka

Czy L2TP VPN może przeprowadzić automatyczną konfigurację trasy dla klienta podczas połączenia?

Odpowiedzi: