L2TP VPN이 연결된 동안 클라이언트에 대한 자동 라우팅 구성을 수행 할 수 있습니까?

이 튜토리얼 로 L2TP VPN 서버를 설정했습니다 . 모든 것이 매력처럼 작동합니다.

유일한 문제는

우리는 클라이언트가이 VPN을 사용하여 모든 트래픽을 라우팅하지 않기를 원합니다.
Mac에서는 명령을 사용하여 경로를 수동으로 설정해야하지만 모바일 장치의 경우 그렇게 할 수있는 방법이없는 것 같습니다.

따라서 서브넷 "10.0.0.0/20"에 대해 클라이언트를 자동으로 구성 할 수 있습니까?

— 하워드
소스

클라이언트에서 'VPN을 통한 모든 트래픽 보내기'또는 이와 유사한 옵션을 비활성화하려고 했습니까?

— Bert

좋습니다.이 질문은 인터넷을 통해 계속해서 다시 묻습니다. 대부분의 경우 원래 게시물에 설명 된 내용을 수행 할 수 없다는 (반) 정답이 있습니다. 한 번에 모두 명확하게 설명하겠습니다. :)

짧은 대답은 L2TP (그리고 그 문제에 대한 PPTP)는 프로토콜 내부에서 경로 푸시를 수행하는 기능이 없지만 프로토콜 외부에서 달성 할 수 있다는 것입니다.

L2TP는 Microsoft의 발명품이므로 정보의 가장 좋은 출처는 기술 문서입니다 (그리고 기술적으로도 능숙합니다). 아래에서 설명 할 내용에 대한 기술적 설명은 VPN 주소 지정 및 라우팅 에서 찾을 수 있습니다 . 모든 것을 올바르게 설정하기위한 키워드는 (자신의 연구를하려는 경우) DHCPINFORM 및 "classless static route"입니다.

우선, 작동 방식 :

클라이언트가 VPN 서버에 연결
인증에 성공하면 보안 터널이 설정됩니다
클라이언트는 연결 후 DHCPINFORM 메시지를 사용하여 DHCP Classless Static Routes 옵션을 요청합니다. 이 DHCP 옵션에는 요청 클라이언트의 라우팅 테이블에 자동으로 추가되는 라우트 세트가 포함되어 있습니다 ( Microsoft 문서에서이 라인을 직접 복사하여 붙여 넣기했습니다. ))
VPN 서버는 적절한 경로 집합을 사용하여 해당 메시지에 회신합니다.

글쎄, 경고가 있습니다 :

이 RFC-3442 "DHCP 클래스없는 정적 경로"를 설명하고이 옵션에 대한 코드는 마이크로 소프트 (항상) 다시 발명 바퀴에 결정 (121)하고 있음이 상태 사용이 옵션 코드 249. 따라서 더 넓은 범위의 고객을 지원하려면 두 코드로 모두 응답해야합니다.

Linux 상자를 VPN 서버로 사용하는 일반적인 구성에 대해 설명하겠습니다 (Microsoft 설명서 링크를 사용하여 MS 서버를 구성 할 수 있음).

클라이언트에서 경로를 구성하려면 다음 구성 요소가 필요합니다.

L2TP / IPSEC (또는 PPTP) = 예를 들어 accel-ppp는 훌륭한 오픈 소스 L2TP / PPTP 서버입니다
DHCP 서버 = 다수가 있지만 dnsmasq의 구성을 설명하겠습니다

다음은 작동중인 accel-ppp 구성의 덤프입니다. 나는 그것을 전체적으로 제공하고 있습니다. VPN이 이미 작동중인 경우이 구성 파일을 건너 뛰고 아래 설명 된 DHCP 구성에 집중할 수 있습니다.

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

이 시점에서 클라이언트는 L2TP (또는 PPTP)를 통해 연결하고 VPN 서버와 통신 할 수 있습니다. 따라서 누락 된 유일한 부분은 생성 된 터널에서 수신 대기하고 필요한 정보로 다시 응답하는 DHCP 서버입니다. 다음은 dnsmasq 구성 파일에서 발췌 한 것입니다 (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 ~]#

위의 발췌에서 우리는 192.168.99.254 (VPN 서버)를 통해 192.168.70.0/24, 192.168.75.0/24 및 10.0.0.0/24 경로를 푸시합니다.

마지막으로 네트워크 트래픽을 스니핑하면 (예 : VPN 서버에서) 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 나는 위의 구성을 성공적으로 사용하는 데 필요한 필수 부분을 거의 잊어 버렸습니다. 글쎄, 그것은 내가 언급 한 Microsoft 문서에 설명되어 있지만 누가 문서를 읽었습니까? :) OK, 클라이언트는 VPN 연결에서 '기본 게이트웨이 사용'없이 구성해야합니다 (Windows의 경우 연결 속성-> 네트워킹-> 인터넷 프로토콜 버전 4 (TCP / IPv4)-> 속성-> 고급-> IP 설정) ). 일부 클라이언트에는 '클래스 기반 경로 추가 비활성화'라는 옵션도 있습니다. 구현하려는 기능을 명시 적으로 비활성화하기 때문에 설정 해제해야합니다.

— 은하
소스

고전적인 L2TP가 UDP를 통해 PPP 패킷을 캡슐화한다는 것을 이해합니다. 나는 틀릴 수 있지만 DHCP가 PPP를 통해 지원되는 것으로 생각하지 않으며, 특히 추가 경로를 보냅니다. L2TP 버전 3 (여전히 리눅스 커널 랜드에서 아주 새로운 기능)을 사용하면 이더넷 프레임을 캡슐화하여 가능할 수 있지만 모바일 장치에서 얼마나 잘 지원되는지에 따라 마일리지가 다를 수 있습니다.

— Matthew Ife

매튜, 당신이 한 문장으로 많은 것들을 섞어 놓았 기 때문에 질문을 올바르게 처리하는 방법을 모르겠습니다. : 다음으로 시작합시다. 제공된 구성은 내가 감독하고있는 수백 명의로드 워리어에서 작동합니다. 실제 사례입니다. PPP를 통한 DHCP를 위해 Google을 사용하고 Cisco, Juniper 등에 의해 구현되는 방법에 대한 많은 기술 문서를 읽을 수 있습니다. P2가 PPP를 통해 PPP를 캡슐화한다고 L2TP가 PPP를 요약한다고 가정하면 당신이 IP를 사용할 수있는 지점 간 프로토콜, DHCP는 IP를 통한 프로토콜이므로 우리는 여기에 좋습니다 :)

— galaxy

또한 DHCPINFORM을 사용하여 올바르게 설정하는 방법을 설명하는 L2TP에 대한 Microsoft 기술 문서에 대한 링크를 포함시킬 때 이런 종류의 의견을 얻는 것이 매우 이상합니다. 누군가가 연구 한 결과 사람들이 답변을 읽고 싶지 않을 때 (작동 시스템의 구성 파일이 포함되어 있지만) 이해할 수 있지만 기술 사양이있을 때 "PPP를 통해 DHCP가 지원되지 않는다고 생각합니다." 프로토콜이 설계된 방식이라는 프로토콜 작성자는 이상합니다.

— 은하

"PPP를 통해 DHCP가 지원되지 않는다"는 요점을 명확히하기 위해 IP 주소 할당이 PPP 링크 제어 프로토콜을 통해 발생한다는 것을 의미합니다. 그래서 내가 뭘했는지 오해했다고 생각합니다. 이제는 연결 설정 후 DHCPINFORM이 터널 내부에서 발생하며 초기 연결과 관련이 없음을 의미합니다. 연결이 설정된 후 클라이언트가 DHCPINFORM 메시지를 보내면이 구성표가 작동한다는 것에 동의합니다.

— Matthew Ife

매튜, 감사합니다 :). 예, 우리는 주소 할당을 위해 DHCP를 사용하지 않고 IPCP에 의해 수행되지만 LCP가 아닙니다.하지만 Microsoft 기술 문서에는 유효한 클라이언트가 옵션 249와 함께 DHCPINFORM 메시지를 보내야한다고 명시합니다 라우트 구성이며, 이것이 내가 대답 한 내용과 정확히 같습니다. 글쎄, 누군가가 이미 작동 비록, 유효한 답 : 아래 내 대답 투표

— 은하

L2TP / IPSEC VPN에서 클라이언트로 경로를 푸시 할 수 있다고 생각하지 않습니다. 클라이언트에서 직접 구성을 수행해야합니다.

어떤 모바일 클라이언트에 문제가 있습니까? 사용중인 운영 체제와 소프트웨어를 알고 있으면 입력하는 것이 더 쉽습니다.

— 페르
소스