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


13

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

유일한 문제는

  1. 우리는 클라이언트가이 VPN을 사용하여 모든 트래픽을 라우팅하지 않기를 원합니다.

  2. Mac에서는 명령을 사용하여 경로를 수동으로 설정해야하지만 모바일 장치의 경우 그렇게 할 수있는 방법이없는 것 같습니다.

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


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

답변:


33

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

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

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

우선, 작동 방식 :

  1. 클라이언트가 VPN 서버에 연결
  2. 인증에 성공하면 보안 터널이 설정됩니다
  3. 클라이언트는 연결 후 DHCPINFORM 메시지를 사용하여 DHCP Classless Static Routes 옵션을 요청합니다. 이 DHCP 옵션에는 요청 클라이언트의 라우팅 테이블에 자동으로 추가되는 라우트 세트가 포함되어 있습니다 ( Microsoft 문서에서이 라인을 직접 복사하여 붙여 넣기했습니다. ))
  4. 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

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

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

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

1

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

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

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.