☰

tun1을 통해 tun0 트래픽 라우팅(이중 홉 VPN)

tag-icon • tag-icon linux vpn routing tunneling
tun1을 통해 tun0 트래픽 라우팅(이중 홉 VPN)

목표: 더블 홉 VPN을 위해 eth0 -> tun0 -> tun1의 모든 인터넷 트래픽을 라우팅합니다. 해당 목표에 대해 다음 라우팅 테이블이 맞습니까?

$ IP 경로 표시:

0.0.0.0/1 via 10.8.1.1 dev tun1 
default via 10.8.3.1 dev tun0 proto static metric 50 
10.8.1.0/24 dev tun1 proto kernel scope link src 10.8.1.6 
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.4 metric 50 
101.133.213.73 via 10.8.3.1 dev tun0 
127.0.0.0/8 dev lo scope link 
128.0.0.0/1 via 10.8.1.1 dev tun1 
191.72.65.45 via 182.160.0.1 dev eth0 proto static metric 100 
182.160.0.0/24 dev eth0 proto kernel scope link src 182.160.0.19 metric 100 
182.160.0.0/24 dev eth0 proto dhcp scope link src 182.160.0.19 metric 208 
182.160.0.1 dev eth0 proto static scope link metric 100

답변1

eth0 : 182.160.0.19/24 (GW: 182.160.0.1)
tun0 : 10.8.3.4/24 (GW: 10.8.3.1 / VPN endpoint : 191.72.65.45 via eth0)
tun1 : 10.8.1.6/24 (GW: 10.8.1.1 / VPN endpoint : 101.133.213.73 via tun0)

이렇게 하면 이더넷(182.160.0.0/24)의 로컬 트래픽과 tun0 / "VPN1"(10.8.3.0/24)의 로컬 트래픽을 제외한 모든 트래픽(tun0에서 들어오는 것을 포함)이 tun1을 통해 라우팅됩니다.

이 라우팅 테이블을 사용하면또한 eth0에서 들어오는 모든 트래픽은 tun1을 통해 라우팅됩니다.질문에 언급/요청되지 않은 사항... 이 상황이 괜찮으신가요? 대답이 '예'인 경우 이 설정을 유지할 수 있습니다.

이것이 원하지 않는 상황인 경우(eth0에서 tun1 / tun0으로 트래픽을 라우팅하고 싶지 않은 경우) 이를 처리하는 방법에는 (적어도) 두 가지 옵션이 있습니다.

  • "사용자 정의" 라우팅 테이블

하나 이상의 라우팅 테이블이 있을 수 있으며 규칙/정책에 따라 기본 테이블이 아닌 다른 트래픽이 처리될 트래픽을 관리할 수 있습니다. 이 방법으로 기본 GW가 tun1이고 tun0에서 들어오는 트래픽만 이 사용자 정의 라우팅 테이블을 가리키는 사용자 정의 라우팅 테이블을 설정할 수 있습니다.

  • 네트워크 네임스페이스

이렇게 하면 eth0에서 전체 tun 인터페이스를 분리할 수 있으므로(네임스페이스 간 내부 라우팅 사용) 네임스페이스에 간단한(기본) 라우팅 테이블을 설정하여 tun0의 트래픽만 tun1에 도달할 수 있습니다.

답변2

원하는 시퀀스가 ​​LAN의 트래픽이 로컬 시스템 -> tun0 -> tun1에서 이동해야 한다고 가정하면 이러한 일이 발생할 가능성이 높지만 tracreroute에서는 볼 수 없는 방식으로 발생합니다.

임의의 인터넷 주소로 향하는 패킷을 받아보겠습니다. 이 예에서는 8.8.8.8을 사용하겠습니다.

컴퓨터는 패킷을 선택하여 보낼 방법을 찾습니다. tun1을 통해 전송되어야 한다는 것을 확인합니다(아래 2개 경로는 기본 경로와 동일하지만 더 제한적이므로 기본 경로보다 선호됩니다. 이 경우 첫 번째 경로가 적중됩니다).

 0.0.0.0/1 via 10.8.1.1 dev tun1
 128.0.0.0/1 via 10.8.1.1 dev tun1

그러나 여기에는 명확하지 않을 수 있는 부분이 있습니다. tun1의 구성을 살펴보면 101.133.213.73이라는 엔드포인트가 있음을 알 수 있습니다. 이 IP 주소에는 tun0을 통과하는 특정 경로가 있습니다.

 101.133.213.73 via 10.8.3.1 dev tun0

마찬가지로 다른 루트도 있어요

  191.72.65.45  via 182.160.0.1 dev eth0 proto static metric 100

이 경로를 사용하면 tun0을 통해 전송된 트래픽을 이더넷 인터페이스를 통해 직접 액세스할 수 있습니다.

이는 매우 구체적인 경로이므로 101.133.213.73으로의 트래픽은 tun0을 통과합니다. 따라서 (tun1을 통해) 인터넷으로 흐르는 모든 트래픽은 그 자체가 터널인 101.133.213.73을 통과해야 합니다.그렇습니다. 데이터는 두 터널을 모두 통해 흐르게 됩니다.

패킷이 터널을 통해 터널링되고 있다는 것을 모르기 때문에 추적 경로는 이를 표시하지 않습니다. 즉, 낮은 수준(다른 창에서 "sudo tcpdump -n -i any"를 수행하는 동안 트래픽 생성)을 보면 이러한 일이 발생하는지 확인할 수 있습니다. 패킷이 더 넓은 인터넷으로 전송될 때마다 패킷은 각각 eth0, tun0, tun1을 통해 전송되고 반환된 패킷도 마찬가지라는 것을 알 수 있습니다. tun0과 관련된 패킷은 모두 101.133.213.73의 대상을 갖습니다.

관련 정보