L2TP VPN'nin bağlıyken istemci için otomatik rota yapılandırması yapması mümkün müdür?


13

Bu öğretici ile bir L2TP VPN sunucusu kurduk , her şey bir cazibe gibi çalışıyor.

Tek sorun şudur:

  1. İstemcinin bu VPN'yi kullanarak tüm trafiği yönlendirmesini istemiyoruz, yalnızca belirli bir alt ağ, örneğin 10.0.0.0/20

  2. Mac'te, komutu kullanarak rotayı manuel olarak ayarlamamız gerekiyor, ancak mobil cihazlar için bunu yapmanın bir yolu yok mu?

Yani, istemci için "10.0.0.0/20" alt ağı için otomatik olarak yapılandırmak mümkün mü?


İstemcideki 'tüm trafiği VPN üzerinden gönder' veya benzeri bir seçeneği devre dışı bırakmayı denediniz mi?
Bert

Yanıtlar:


33

Tamam, bu soru Internet üzerinden tekrar tekrar soruluyor ve çoğu zaman orijinal yayında açıklananları yapamayacağınız (yarı) yanlış bir cevap var. Bir kez ve herkes için netleştireyim :)

Kısa cevap L2TP (ve bu konu için PPTP) protokol içinde rota itme yapmak için imkanlar yoktur, ancak protokol dışında elde edilebilir.

L2TP bir Microsoft buluşu olduğundan, en iyi bilgi kaynağı teknik dokümantasyonudur (ve bu arada oldukça iyidirler). Aşağıda açıklayacağım şeyin teknik açıklaması VPN Adresleme ve Yönlendirme'de bulunabilir . Her şeyi doğru bir şekilde ayarlamak için anahtar kelimeler (kendi araştırmanızı yapacaksanız): DHCPINFORM ve "sınıfsız statik yollar".

Her şeyden önce, nasıl çalışır:

  1. bir istemci VPN sunucusuna bağlanır
  2. başarılı bir kimlik doğrulamasından sonra güvenli bir tünel kurulur
  3. istemci bağlantıdan sonra DHCP Sınıfsız Statik Yollar seçeneğini istemek için bir DHCPINFORM iletisi kullanır. Bu DHCP seçeneği, istekte bulunan istemcinin yönlendirme tablosuna otomatik olarak eklenen bir dizi yol içerir ( Bu satırı doğrudan Microsoft belgelerinden körü körüne kopyalayıp yapıştırdım :))
  4. VPN sunucusu bu iletiyi uygun rota kümesiyle yanıtlar

Bir uyarı var:

  • orada RFC 3442 "DHCP Sınıfsız Statik Yolları" açıklayan ve bu seçenek için kodu, Microsoft (her zaman olduğu gibi) yeniden icat tekerlek karar 121. olduğunu ve orada devletler kullanır Bu seçenek için kod 249. Bu nedenle, daha geniş bir müşteri yelpazesini desteklemek için her iki kodla da yanıt vermemiz gerekiyor

Linux kutusu kullanarak tipik bir yapılandırmayı VPN sunucusu olarak tanımlayacağım (MS sunucularını Microsoft belgelerine bağlantı kullanarak yapılandırabilirsiniz).

İstemcilerdeki rotaları yapılandırmak için aşağıdaki bileşenlere ihtiyacımız olacak:

  • L2TP / IPSEC (veya PPTP) = örneğin, accel-ppp güzel bir açık kaynak kodlu L2TP / PPTP sunucusudur
  • DHCP sunucusu = çok var, ama dnsmasq'ın yapılandırmasını açıklayacağım

Aşağıda, çalışan bir hızlanma-ppp yapılandırmasının bir dökümü verilmektedir. Ben bütünüyle sağlıyorum, aksi halde nereye gittiğini açıklamak zor olurdu. VPN'iniz zaten çalışıyorsa, bu yapılandırma dosyasını atlayabilir ve aşağıda açıklanan DHCP yapılandırmasına konsantre olabilirsiniz.

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

Bu noktada müşterilerimiz L2TP (veya PPTP) üzerinden bağlanabilir ve VPN sunucusuyla iletişim kurabilir. Bu nedenle, eksik olan tek bölüm, oluşturulan tünelleri dinleyen ve gerekli bilgilerle yanıt veren bir DHCP sunucusudur. Aşağıda dnsmasq yapılandırma dosyasından bir alıntı (sadece DHCP ile ilgili seçenekler sağlıyorum):

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

Yukarıdaki alıntıda 192.168.70.0/24, 192.168.75.0/24 ve 10.0.0.0/24 yollarını 192.168.99.254 (VPN sunucusu) üzerinden zorluyoruz.

Son olarak, ağ trafiğini (örneğin VPN sunucusunda) koklarsanız, DHCPINFORM mesajındaki yanıt için aşağıdakine benzer bir şey görürsünüz:

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: Yukarıdaki yapılandırmanın başarılı bir şekilde kullanılması için gerekli olan önemli bir parçayı neredeyse unuttum. Peki, bahsettiğim Microsoft belgelerinde açıklandı, ancak belgeleri kim okudu? :) Tamam, istemciler VPN bağlantısında 'Varsayılan ağ geçidini kullan' olmadan yapılandırılmalıdır (Windows'ta bağlantının özelliklerinde bulunur -> Ağ -> İnternet Protokolü Sürüm 4 (TCP / IPv4) -> Özellikler -> Gelişmiş -> IP Ayarları ). Bazı istemcilerde 'Sınıf tabanlı yol eklemeyi devre dışı bırak' adlı bir seçenek de vardır - uygulamaya çalıştığımız işlevselliği açıkça devre dışı bıraktığı için ayarsız olmalıdır.


Klasik L2TP'nin PPP paketlerini UDP üzerinden kapsadığı anlayışım. Yanılıyor olabilirim ama DHCP'nin PPP üzerinden desteklendiğini düşünmüyorum. L2TP sürüm 3 (linux çekirdek arazisinde hala oldukça yeni), orada mümkün olabilmesi için ethernet çerçevelerini kapsüllemenize izin veriyor, ancak milin mobil cihazlarda ne kadar iyi desteklendiğine göre değişebileceğinden eminim.
Matthew Ife

Matthew, bir cümleyi çok fazla şey karıştırdığından sorunuzu doğru bir şekilde nasıl ele alacağımı gerçekten bilmiyorum :) Pekala, aşağıdakilerle başlayalım: sağlanan yapılandırma, denetlediğim yüzlerce yol savaşçısı üzerinde çalışıyor. Yani, çalışan bir örnek. PPP üzerinden DHCP için Google'a ve Cisco, Juniper vb. Tarafından nasıl uygulandığına ilişkin birçok teknik belgeyi okuyabilirsiniz. Buna dalmak istemiyorsanız, L2TP'nin UDP üzerinden PPP'yi kapsadığını hayal edin, PPP bir nokta IP'yi kullanabileceğiniz noktadan noktaya protokol, DHCP IP üzerinden bir protokoldür, bu yüzden burada iyiyiz :)
galaxy

1
Ayrıca, L2TP için Microsoft teknik belgelerine bir bağlantı eklediğimde, DHCPINFORM kullanarak işleri düzgün bir şekilde nasıl kuracaklarını açıkladığımda bu tür yorumları almak oldukça garip. Birisinin araştırmasından bu yana insanların cevabı (bir çalışma sisteminden yapılandırma dosyalarını içermesine rağmen) okumak istemediğini anlayabiliyorum, ancak teknik bir özellik olduğunda "DHCP'nin PPP üzerinden desteklendiğini sanmıyorum" diyerek protokolün yaratıcısı, bu şekilde tasarlandığını belirttiği gariptir.
galaksi

Benim noktaya "DHCP PPP üzerinden desteklenmiyor", IP adresi atamasının PPP bağlantı kontrol protokolü üzerinden gerçekleştiğini açıklığa kavuşturmak için (noktadan noktaya 'yayın' adresi nosyonu yoktur). Sanırım ne elde ettiğimi yanlış anladın. Şimdi ne demek istediğini görüyorum ki DHCPINFORM bağlantı kurulduktan sonra tünelin içinde meydana geliyor ve ilk bağlantıyla ilgisi yok. Bağlantı kurulduktan sonra istemcinin bir DHCPINFORM iletisi göndermesi koşuluyla bu şemanın çalıştığını kabul ediyorum.
Matthew Ife

Mathew, teşekkürler :). Evet, adres ataması için DHCP kullanmıyoruz, IPCP tarafından yapılıyor (söylediğiniz gibi LCP değil, ancak bu önemsiz), ancak Microsoft teknik belgeleri geçerli bir istemcinin DHCPINFORM iletisini Seçenek 249 ile göndermesi gerektiğini belirtiyor rota yapılandırması, ve tam da cevabımda anlattığım bu. Eh, birileri her ne kadar çalışan, geçerli bir cevap olmasına rağmen cevabımı aşağıya
galaxy

1

L2TP / IPSEC VPN'de istemciye bir rota aktarabileceğinizi sanmıyorum. Yapılandırmayı doğrudan istemcide yapmanız gerekecektir.

Hangi mobil istemciyle sorun yaşıyorsun? Kullandığınız işletim sistemini ve yazılımı biliyorsanız, bazı girdiler sağlamak daha kolaydır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.