라우팅 테이블과 실제 조회: VPN 트래픽은 어디로 가는가

라우팅 테이블 덤프는 VPN 문제 해결에서 가장 쓸모없는 진단이며 가장 자주 붙여넣는 것입니다. 마흔 줄의 프리픽스는 기계가 무엇을 할 수 있었는지 알려 줄 뿐, 실패한 요청에 대해 무엇을 했는지는 알려 주지 않습니다. 실제로 원하는 메커니즘은 조회입니다: 이 출발지와 이 목적지가 주어졌을 때 어떤 규칙이 일치했고, 어떤 테이블을 참조했으며, 어떤 인터페이스와 다음 홉이 나왔는지. 하나의 목적지와 하나의 출발지에서 시작해 그 질문을 손에 들고 테이블을 읽으면, 같은 출력이 소음이 아니라 증거가 됩니다.

테이블은 후보의 집합이지 결정이 아니다

각 항목은 프리픽스와 그에 맞는 트래픽을 어떻게 처리할지(인터페이스로 보내거나, 다음 홉에 넘기거나, 버리는)를 설명합니다. 그 목록은 의도 순으로 정렬되어 있지 않고, 사람에게 가장 구체적으로 보이는 항목이 항상 커널이 고르는 항목은 아닙니다: 선택은 최장 프리픽스 일치를 따르고, 같은 프리픽스 사이에서는 메트릭을 따르기 때문입니다.

따라서 첫 단계는 목록을 읽는 대신 커널에 묻는 것이며, 조회 명령은 목적지에 대해 답하고, 출발지 인자를 주면 전달되거나 바인딩된 연결이 사용할 정확한 쌍에 대해 답합니다.

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

위의 각 주소는 문서용 예시입니다. 요점은 답의 형태입니다: 인터페이스, 선택된 출발지 주소, 게이트웨이, 그리고 항목이 나온 테이블. 그 출력이 예상한 인터페이스와 맞지 않으면 한 명령으로 문제를 국소화한 것이며, 전체 테이블을 아무리 읽어도 어떤 후보가 이겼는지는 알려 주지 않았을 것입니다.

조회는 먼저 규칙을 지나고, 다음으로 테이블을 지난다

Linux에서는 결정이 두 단계입니다. 정책 규칙은 우선순위 순으로 평가되고, 처음 일치하는 규칙이 참조할 테이블을 지목하고, 그다음 그 테이블이 최장 프리픽스 일치를 수행합니다. 규칙은 출발지, 목적지, 방화벽 마크, 인터페이스 또는 그 조합으로 일치할 수 있어서, 메인 테이블 덤프가 완벽하게 정확하면서도 조사 중인 패킷에는 완전히 무관할 수 있습니다.

ip rule show
ip route show table all | head -40
ip route show table 100

규칙이 VPN 풀의 트래픽을 테이블 100으로 보낸다면 중요한 것은 테이블 100이며, 메인 테이블은 미끼입니다. 이것은 라우터의 출발지 기반 라우팅 뒤에 있는 메커니즘이기도 합니다: 같은 목적지라도 패킷이 어디서 왔는지에 따라 두 가지 다른 답이 있을 수 있고, 출발지 인자가 있는 조회만이 어느 것이 적용되는지 드러냅니다.

IPv6에는 자체 규칙과 테이블이 있습니다. 두 계열을 모두 운영하는 설계에는 두 조회가 모두 필요하며, 동작하는 IPv4 답은 듀얼 스택 클라이언트가 선호할 수 있는 v6 경로에 대해 아무것도 말하지 않습니다.

VPN 클라이언트가 설치하는 것

클라이언트는 보통 기본 경로를 교체하지 않습니다: 그러면 터널 자체의 외부 경로가 깨지기 때문입니다. 대신 프리픽스 길이로 이기는 더 구체적인 것을 설치하며, 0.0.0.0/1과 128.0.0.0/1을 덮는 한 쌍의 절반-기본 경로가 고전적인 방법이고, 둘 다 0.0.0.0/0보다 긴 프리픽스이며 함께 전체 공간을 덮습니다. 다른 클라이언트는 특정 사설 프리픽스와 정책 규칙을 설치하고, 일부는 선택된 트래픽만 잡히도록 마크를 추가합니다.

그래서 "VPN이 내 기본 경로를 바꾸지 않았다"는 실패의 증거가 아닙니다: 실제로 무엇을 추가했는지, 문제의 목적지가 그 프리픽스 안에 들어가는지 확인하세요.

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

두 개의 절반 경로는 기본처럼 보이지 않아 덤프에서 놓치기 쉽습니다. 프리픽스를 포함하는 것을 잊은 분할 터널 구성은 추적 중인 증상을 그대로 만듭니다: 터널을 사용해야 할 애플리케이션이 대신 로컬에서 이름을 풀고 연결하는 것입니다. 설치된 프리픽스를 우연히 시험한 주소가 아니라 사용자가 실제로 필요로 하는 목적지와 비교하세요. 파일 서버는 덮지만 그 리졸버는 덮지 않는 분할 터널 목록은 공인 주소로 풀린 뒤 인증에 실패하는 연결을 만들며, 이것은 비밀번호 문제처럼 보이지만 경로 문제입니다.

외부 경로도 살아남아야 한다

터널 자체가 트래픽입니다. 캡슐화된 페이로드를 나르는 패킷은 물리 인터페이스를 통해 피어 주소로 가며, 그 경로가 터널로 다시 라우팅되어서는 안 됩니다. 그렇게 되면 터널이 수립된 뒤 트래픽을 통과시키지 않는 특징적인 장애가 발생합니다: 터널의 전송이 이제 터널 안에 있기 때문입니다.

피어 주소를 내부 목적지를 확인한 것과 같은 방식으로 확인하고, 터널이 아니라 물리 인터페이스로 풀리는지 확인하세요:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

재귀 경로, 피어를 잡는 정책 규칙, 또는 전체 터널 클라이언트로 교체된 기본 경로가 세 가지 흔한 원인입니다. 셋 모두 외부 조회에서 보이고, 사후에 찍은 메인 테이블 덤프에서는 어느 것도 보이지 않습니다.

라우팅 출력이 말해 줄 수 없는 것

올바른 조회는 커널이 패킷을 합당한 곳으로 보낸다는 뜻입니다. 방화벽이 허용한다거나, IPsec 정책이 덮는다거나, NAT 규칙이 변환한다거나, 원격 측에 반환 경로가 있다는 뜻은 아닙니다. 각각은 이후 단계이며, " strongSwan의 포워딩 노트 는 패킷이 양 끝에서 통과해야 하는 사슬을 설명합니다.

애플리케이션 수준 바인딩도 고려하지 않습니다. 프로세스는 인터페이스에 바인딩하거나, 마크를 설정하거나, 자체 리졸버를 사용해 시험한 것과 다르게 풀리는 이름으로 연결할 수 있습니다. 조회가 옳은데도 연결이 계속 실패하면, 다음 질문은 어느 프로세스가 그것을 만드는지, 그 프로세스가 당신과 같은 테이블을 보는지입니다.

그러므로 진단을 순서대로 유지하세요: 목적지와 출발지를 지목하고, 조회를 실행하고, 조회가 지목한 테이블과 규칙만 읽고, 다음 단계를 시험하세요. 그 순서는 라우팅 조사를 몇 분 안에 끝내고 다른 사람이 따라갈 수 있는 기록을 남기며, 붙여넣은 테이블은 결코 그렇게 하지 못합니다.