OpenVPN 경로 메트릭: 선택한 경로가 여전히 지는 이유

프로필의 경로에 메트릭을 추가하고 다시 연결했는데도 트래픽이 여전히 잘못된 인터페이스로 나갑니다. 문제는 대개 숫자에 있지 않습니다. 메트릭은 운영 체제가 이미 비교하고 있는 후보들의 순서만 정할 뿐이며, 더 구체적인 프리픽스나 더 이른 정책 테이블이 어떤 메트릭보다도 먼저 결정합니다.

먼저 프로필을, 다음으로 설치된 테이블을, 마지막으로 선택 규칙을 차례로 살펴보십시오. 그 순서는 클라이언트가 경로를 만드는 방식과 맞고, 비교에 들어가지도 않는 값을 조정하는 일을 막아 줍니다.

경로 줄을 필드 순서대로 읽기

Community OpenVPN 2.6 클라이언트는 IPv4 route 줄에서 네 개의 필드를 받습니다: 네트워크, 넷마스크, 게이트웨이, 그리고 선택적인 메트릭입니다. 게이트웨이 자리에는 특수한 vpn_gateway 키워드가 들어갑니다. 이것은 이 연결의 VPN 쪽 다음 홉을 뜻하며, 라우팅 테이블 번호도 아니고 물리 라우터도 아닙니다. 이를 놓치면 줄의 나머지를 그것이 하는 일에 대한 잘못된 이해로 읽게 됩니다. 네트워크 옵션 참조는 네 필드를 모두 설명합니다.

사설 대상에 대해서는 줄이 이렇게 될 수 있습니다:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

명시된 30은 그 경로에 적용되고, 50은 프로필에서 숫자를 생략한 다른 모든 경로의 기본값으로 남습니다. 줄을 왼쪽에서 오른쪽으로 읽으면 어떤 값이 어디에 적용되는지 알 수 있습니다.

route-metric은 순위가 아니라 기본값

route-metric은 자체 숫자가 없는 경로의 대체값을 설정합니다. 어떤 경로를 다른 무엇보다 위로 올리지 않고, 명시적 메트릭으로 설치된 경로의 순서도 바꾸지 않습니다.

프로필이 두 형태를 섞을 때 이 차이가 중요해집니다. 맨 위의 route-metric 한 줄은 권위 있어 보이고 탓하기 쉽지만, 실제로 트래픽을 나르는 경로는 세 줄 아래에서 자체 메트릭을 가질 수 있습니다.

한 경로가 특정 길을 선호하게 하려면 그 경로에 숫자를 넣으십시오. 생성된 프로필 전체에 일관된 기본값이 필요하면 route-metric을 쓰고 개별 줄은 그대로 두십시오. 이유 없이 둘을 섞는 것이 바로 아무도 설명할 수 없는 경로를 프로필에 남기는 방법입니다.

클라이언트가 설치한 것을 확인하기

다시 연결이 끝나면 프로필이 아니라 커널에 물어보십시오.

ip route show는 클라이언트가 추가한 경로를 나열하고, ip route get 172.20.5.10은 더 유용한 질문에 답합니다: 이 대상이 실제로 어느 경로를 어느 소스 주소로 사용하는가입니다. 대상이 테이블에 없으면 클라이언트가 설치하지 않은 것입니다.

로컬 지시문, 서버 푸시 또는 다른 네트워크 관리자가 같은 프리픽스를 추가하거나 제거할 수 있고, 마지막에 쓴 쪽이 이깁니다. 작업하는 동안 엔드포인트 경로를 계속 보십시오, 연결에는 자기가 만드는 터널을 통하지 않는 원격 서버 경로가 필요하기 때문입니다.

더 작은 메트릭이 여전히 지는 이유

메트릭은 같은 대상에 대한 경로를 비교합니다. 넓은 프리픽스를 더 구체적으로 만들지는 않습니다. redirect-gateway def1이 쓰이면 클라이언트는 0.0.0.0/1과 128.0.0.0/1을 설치하고, 그 두 프리픽스는 0.0.0.0/0보다 더 구체적으로 IPv4 전체 공간을 덮습니다. 기본 경로의 메트릭 1은 그것들을 앞서지 못합니다.

같은 논리가 겹치는 모든 쌍에 적용됩니다. 내부 주소에 대해서는 /24가 /16을 이깁니다, 숫자가 무엇이든 마찬가지인데, 조회가 가장 구체적인 일치를 먼저 고르고 그다음에야 동등한 것들 사이에서 메트릭을 비교하기 때문입니다.

이 부분은 메트릭 버그처럼 보이지만 그렇지 않습니다. 숫자를 바꾸기 전에 두 후보의 프리픽스 길이를 확인하십시오.

정책 규칙은 테이블보다 먼저 실행된다

Linux에서 ip rule은 어떤 라우팅 테이블을 참조할지 결정합니다. 규칙은 우선순위 순으로 평가되므로, 더 이른 테이블이 메인 테이블을 읽기도 전에 경로를 돌려줄 수 있습니다. 메인 안의 메트릭은 먼저 참조된 테이블의 일치를 앞설 수 없습니다.

ip rule show를 쓰고 나서 특정 테이블을 조회하고, 예를 들어 ip route show table 100으로 그 규칙이 무엇을 돌려줄지 볼 수 있습니다. VPN 클라이언트나 컨테이너 런타임이 규칙을 추가했다면 답은 지금까지 읽던 테이블이 아니라 거기에 있을 수 있습니다. 소스 주소도 중요합니다, 규칙이 소스에 일치해 같은 대상을 터널 트래픽과 LAN 트래픽에 다르게 해석할 수 있기 때문입니다.

순위가 아니라 대상을 확인하십시오

논쟁을 끝내는 시험은 의도한 서브넷 안의 호스트에 대한 단일 질의와 커널이 선택한 소스 주소의 확인입니다. 그 쌍이 설계와 맞으면, 목록이 깔끔한 순위처럼 보이지 않더라도 메트릭은 제 일을 하고 있는 것입니다.

IPv6와 DNS는 이 확인에서 빼십시오. 그것들은 다른 지시문으로 구성되고 다른 메커니즘으로 해석되며, 동작하는 IPv4 경로는 그 둘에 대해 아무것도 말해 주지 않습니다. 계층을 한 번에 하나씩 바꾸고 질의를 다시 실행하십시오.