VPN 트래픽에서 정책 라우팅이 바꾸는 것과 바꾸지 않는 것

정책 라우팅은 대부분의 문제 해결 노트가 던지는 질문과 다른 질문에 답한다. 메인 테이블은 목적지가 어디로 가는지를 말하고, 정책 규칙은 어떤 테이블을 아예 조회할지를 말하며, 출발지 주소, 패킷 마크, 또는 패킷이 도착한 인터페이스로 그것을 결정할 수 있다. 터널이 일관성 없이 동작할 때 원인은 규칙 집합인 경우가 많고 라우팅 테이블인 경우는 적다.

규칙이 테이블을 고르고, 다음으로 테이블이 경로를 고른다

각 규칙은 우선순위, 일치 조건, 대상 테이블을 지닌다. 커널은 우선순위 순서로 규칙을 훑고 첫 일치에서 멈춘 뒤, 그 테이블에서 평범한 최장 접두사 조회를 수행한다. 빈 테이블을 가리키는 규칙은 다음 규칙이 고르는 것으로 넘어가며, 정성껏 쓴 규칙이 아무것도 하지 않는 것처럼 보이는 이유가 이것이다.

메인 테이블을 덤프해도 동작하는 VPN 클라이언트를 설명하지 못하는 경우가 많은 이유도 같다. 클라이언트는 보통 낮은 우선순위 번호에 규칙을 넣으며, 메인 테이블의 기본 규칙보다 훨씬 앞서므로 패킷은 당신이 바라보던 경로에 결코 도달하지 않는다. 메인 테이블의 메트릭을 낮추는 것은 이미 우회된 트래픽에 아무것도 바꾸지 않는다.

규칙은 의도적으로 접두사를 블랙홀이나 도달 불가로 만들 수도 있다. 일부 클라이언트는 그런 규칙을 킬 스위치로 추가하며, 그러면 드롭은 구성된 터널이 아니라 망가진 터널처럼 보인다.

규칙 집합은 목록이 아니라 순서로 읽어라

규칙을 우선순위와 참조하는 테이블과 함께 출력하고, 다음으로 기본 경로나 터널 경로를 지닌 각 테이블을 출력하라. 중요한 것은 순서이며, 스크린샷이 보통 빠뜨리는 부분도 바로 그것이다:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

마지막 두 명령이 이론을 관찰로 바꾼다, 왜냐하면 그것들이 묻기 때문이다: 커널이 그 출발지와 그 마크에 대해 무엇을 할지. 만약 마크가 바뀔 때 답이 바뀐다면 마크 기반 규칙이 작동 중이고, 마크를 빼놓은 시험은 다른 패킷을 시험하는 것이다. 바깥 연결은 자기만의 규칙을 가질 자격이 있다. 모든 트래픽을 자기 자신을 통해 라우팅하는 터널은 자신이 연결하는 종단점 주소를 제외해야 한다, 그렇지 않으면 암호화된 패킷이 방금 떠난 터널로 되돌아간다. 대부분의 클라이언트는 그 제외를 자동으로 넣으며, 손으로 편집한 규칙 집합이 바로 그것이 빠지는 곳이다.

마크와 소켓: 클라이언트가 트래픽을 나누는 두 가지 방식

일부 클라이언트는 방화벽에서 패킷에 마크를 붙이고 그 마크와 일치하는 규칙을 추가한다. 다른 클라이언트는 소켓 수준 라우팅을 사용해 연결하기 전에 소켓에 경로를 설정한다. 전자는 ip rule 에서 보이고, 후자는 보이지 않으며 일반 조회에도 나타나지 않는다.

시험 프로그램이 대표해야 할 애플리케이션과 다르게 동작한다면, 그 애플리케이션이 마크를 설정하는지 장치에 바인딩하는지 확인하라. 메커니즘에 이름이 붙으면 그 차이는 수수께끼가 아니며, 같은 머신에서 셸의 curl과 브라우저 탭이 다른 경로를 탈 수 있는 이유도 설명된다. 두 기법 모두 넓은 의미의 정책 라우팅이다: 목적지가 아닌 무언가로 경로를 고른다. 어느 쪽도 트래픽을 승인하지 않으며, 어느 쪽도 피어가 기대하는 방화벽 규칙이나 자격 증명을 대신하지 않는다.

또 하나의 규칙을 더하기 전에 소유권을 추적하라

규칙은 무언가가 설치한다. VPN 클라이언트, 네트워크 관리자, 손으로 쓴 스크립트가 각각 시작할 때 규칙을 추가할 수 있고, 재연결 로직은 이전 집합을 남겨 둘 수 있다. 이전 프로필의 낡은 규칙 두 개는 프로필이 삭제된 한참 뒤에도 트래픽을 계속 유도한다.

우선순위와 모양으로 어느 프로세스가 그 규칙을 소유하는지 찾고, 그 소유자가 연결마다 집합을 다시 쓰는지 확인하라. 다시 쓴다면 오늘 추가한 수동 규칙은 내일 사라지며, 수정은 셸 기록 파일이 아니라 클라이언트 구성에 들어가야 한다. 시험을 위해 규칙 집합 전체를 지우는 것은 예측 가능한 대가가 따르는 유혹적인 지름길이다: 클라이언트가 자기 터널을 유지하는 데 필요한 규칙까지 없앤다. 한 번에 하나씩 지우거나, 재부팅할 수 있는 머신에서 시험하라.

범위는 하나가 아니라 두 흐름으로 증명하라

수정은 영향을 받아야 할 흐름과 받지 않아야 할 흐름으로만 검증된다. 정책이 터널로 보내는 목적지와 바깥에 남겨야 할 목적지를 골라, 둘 모두의 조회와 캡처를 비교하라:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

두 조회가 서로 다른 인터페이스를 돌려주면 규칙은 무언가를 하고 있다. 같은 인터페이스를 돌려주면 규칙은 의도보다 넓게 일치하며, 그것이 하나의 애플리케이션을 위해 만든 터널로 서브넷 전체를 조용히 보내는 고장이다.

티켓에 규칙 우선순위와 소유 서비스를 두 시험 주소와 함께 기록하라. 그러면 다음 사람은 증상 설명 대신 재현 가능한 쌍을 얻고, 정책 라우팅이 아직 작동 중인지 일 분 안에 판단할 수 있다.