VPN 연결 후 경로 메트릭이 바뀌었습니다: 무슨 뜻인가
낮은 메트릭은 똑같이 구체적인 경로 사이의 동점만 가릅니다. VPN 경로 번호를 편집하기 전에 정책 규칙, 프리픽스, 엔드포인트 호스트 경로를 읽으세요.
VPN에 연결하고 route print를 실행하면 기본 경로가 이전보다 훨씬 낮은 메트릭을 갖게 됩니다. 자연스러운 결론은 VPN이 숫자가 더 작기 때문에 기본 경로를 가져갔다는 것입니다. 때로는 정말 그렇게 일어납니다. 그러나 자주 메트릭은 결정 요인이 아니며, 편집해도 아무것도 바뀌지 않습니다, 선택은 더 앞에서 프리픽스 길이나 정책 규칙에 의해 이루어졌기 때문입니다.
증상은 실제입니다: 이전에 Wi-Fi 어댑터로 나가던 트래픽이 이제 터널로 나가거나 그 반대입니다. 메트릭은 고정된 순서로 실행되는 조회의 입력 하나이며, 숫자를 건드리기 전에 읽어야 하는 것은 바로 그 순서입니다.
숫자가 실제로 경쟁하는 대상
첫 비교는 우선순위가 아니라 구체성입니다. 10.20.0.0/16 경로는 10.0.0.0/8을 이기고, 메트릭이 무슨 말을 하든 둘 다 0.0.0.0/0을 이깁니다. 머신에서 가장 낮은 메트릭으로 기본 경로를 설치하는 VPN도 목적지와 일치하는 더 구체적인 경로에는 집니다, 클라이언트가 자기 서버용으로 설치하는 호스트 경로까지 포함해서.
그래서 기본 경로의 메트릭을 낮춰도 직접 연결된 서브넷을 터널로 밀어 넣을 수 없습니다. 그 서브넷을 VPN 안에 두고 싶다면 프리픽스에 대한 경로를 추가하거나 정책 규칙으로 터널 테이블을 선택하세요. 메트릭은 그 작업에 맞지 않는 지렛대입니다.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
리눅스는 메트릭보다 먼저 테이블을 결정한다
리눅스에서 커널은 먼저 정책 데이터베이스를 조회합니다. ip rule는 규칙과 그 규칙이 선택하는 테이블을 나열하고, ip route get 203.0.113.10는 커널이 그 목적지에 실제로 사용할 테이블, 경로, 원본 주소를 보고합니다. 테이블 100 안의 메트릭은 메인 테이블의 경로와 절대 경쟁하지 않습니다, 어떤 메트릭을 비교하기 전에 규칙이 테이블을 골랐기 때문입니다.
그래서 경로가 ip route show table all에서 올바르게 보여도 트래픽을 나르지 않을 수 있습니다. 일치한 규칙을 읽고, 그 규칙이 선택한 테이블을 읽고, 그 안의 경로를 비교하세요. 잘못된 테이블이 선택되었다면 다른 테이블에서 메트릭을 편집해도 도움이 되지 않습니다.
윈도우는 두 메트릭을 결합한다
윈도우에는 기본적으로 정책 데이터베이스가 없지만 경로 메트릭과 인터페이스 메트릭을 결합하며, 자동 인터페이스 메트릭은 링크 속도와 어댑터 상태에 따라 달라질 수 있습니다. 그래서 같은 경로도 도킹 스테이션이나 가상 어댑터가 나타난 뒤 다르게 동작할 수 있습니다. Find-NetRoute -RemoteIPAddress 203.0.113.10는 선택된 원본 주소, 다음 홉, 인터페이스를 보고하며, 이는 원시 테이블보다 실제 결정에 더 가깝습니다.
경로와 인터페이스 값을 함께 읽으세요. 인터페이스 메트릭을 올리면 경로 항목이 하나도 바뀌지 않고 트래픽이 옮겨질 수 있으며, 자기 경로를 소유한 VPN 클라이언트는 다시 연결할 때 경로를 재설치하고 당신의 편집을 버립니다.
터널 엔드포인트를 터널 밖에 두라
모든 터널은 터널을 지나지 않는 자기 서버로의 경로가 필요합니다. 클라이언트는 물리 게이트웨이를 통해 엔드포인트에 대한 호스트 경로를 설치하며, 그 경로는 클라이언트가 추가하는 기본 경로보다 더 구체적으로 남아 있어야 합니다. 그것을 지우거나 그 주소에 대한 조회에서 터널이 이기게 하면, 캡슐화된 패킷이 마땅히 구축해야 할 터널로 들어가려 합니다. 연결이 실패하거나 루프에 빠집니다.
메트릭을 바꾸기 전과 후에 그 호스트 경로를 확인하세요: 물리적인 다음 홉을 가리켜야 하고 다시 연결한 뒤에도 남아 있어야 합니다. 클라이언트가 소유한다면 덮어써질 런타임 값이 아니라 프로필이나 관리 구성을 바꾸세요.
두 주소 체계와 앱 컨텍스트를 모두 확인하라
IPv4와 IPv6는 별도 테이블을 가진 별도 결정입니다. VPN이 IPv4를 나르는 동안 IPv6는 로컬 라우터를 계속 쓸 수 있고, 한 체계의 메트릭 변경은 다른 체계에 대해 아무것도 말하지 않습니다. 둘 다 확인한 다음 애플리케이션 컨텍스트를 확인하세요. 인터페이스에 묶인 프로세스, 컨테이너 네임스페이스, 앱별 VPN은 셸과 다른 테이블을 볼 수 있습니다.
실제 목적지에 대한 결정을 보고하는 도구로 검증하고, 테이블 전체 목록으로 판단하지 마세요. 선택된 경로가 설계가 의도한 것이라면 멈추세요. 화면에서 가장 작은 숫자가 아닌 메트릭은 결함이 아니며, 억지로 가장 작게 만들면 터널이 의존하는 엔드포인트 경로가 깨질 수 있습니다.