에서 자료를 가져왔습니다OpenVPN 클라이언트의 라우팅 테이블을 이해하는 방법.
라우팅 테이블은 다음과 같습니다.
# route -n
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0
54.202.18.143 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 eth0
OpenVPN을 구성했지만 다음 두 가지 사항에 대해 혼란스럽습니다.
- tun0을 통한 TCP 패킷
- 54.202.18.143(공용 VPN IP)을 통한 UDP OpenVPN 패킷
질문:
- OpenVPN에 다음 줄이 필요한 이유는 무엇입니까
54.202.18.143 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0
? - 어떤 패킷이 tun0을 통과합니까?
- 54.202.18.143을 통과하는 패킷은 무엇입니까?
당신의 도움을 주셔서 감사합니다!
답변1
어찌할 바를 모르는:
- .NET을 통해 흐르는 것은 단지 TCP 패킷이 아닙니다
tun0
. UDP 및 ICMP도 가능합니다. - UDP는 OpenVPN 트래픽을 캡슐화하는 프로토콜입니다.
질문과 답변:
이는 VPN 게이트웨이에 대한 명시적인 경로입니다( IP 주소와 정확히 일치하는지 확인하세요. 그 이상은 아닙니다)
255.255.255.255
.54.202.18.143
54.202.18.143 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0
나는 이것이
10.0.2.2
귀하의 LAN 라우터라고 가정하고 있으므로 VPN 엔드포인트로의 모든 트래픽이 귀하의 라우터eth0
(및 이후)를 통해 전송된다는 것을 클라이언트에게 알려줍니다. 이렇게 하면 VPN을 통해 모든 트래픽을 전송하도록 의사 기본 경로가 업데이트되었기 때문에 캡슐화된 패킷 자체가 VPN을 통해 라우팅되지 않습니다. (뱀이 꼬리를 물어뜯는 것처럼 상황이 좋지 않습니다.)의사 기본 경로는 다음 두 줄로 구성됩니다.
0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0 128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
이러한 라인은 실제 기본 경로보다 우선순위가 높지만 라우팅 테이블의 다른 라인보다 우선순위가 낮습니다. 함께 라우팅 테이블의 다른 행과 일치하는 트래픽을 제외한 모든 트래픽과 일치합니다.
- OpenVPN UDP 캡슐화 트래픽을 제외한 모든 패킷은 tun0을 통과합니다.
- OpenVPN UDP 캡슐화된 트래픽만 54.202.18.143을 통과합니다.