로컬 경로가 VPN 기본 경로를 이기는 이유

책상 위 프린터는 터널이 올라온 뒤에도 계속 동작하고, 다른 사무실의 서버는 조용히 로컬 주소로 해석된다. 두 동작은 같은 규칙에서 나온다: 가장 구체적인 경로가 이기며, 직접 연결된 프리픽스는 가능한 한 구체적이다. 보통 그것이 원하는 설계이고, 중복된 사설 범위가 원격 주소를 훔치는 방식도 같다. 커널의 선택을 먼저 읽으면 불가사의한 실패가 프리픽스 비교로 바뀐다.

연결된 프리픽스가 기본 경로보다 더 구체적이다

터널은 보통 기본 경로나 프리픽스 집합을 설치하고, 로컬 인터페이스는 연결된 프리픽스와 LAN 전체로 가는 경로를 함께 갖는다. 둘 사이는 최장 프리픽스 일치가 결정하므로 LAN 프리픽스 안의 목적지는 터널에 닿지 않는다. 그래서 VPN이 켜져 있어도 프린터, 라우터 관리 페이지, 로컬 NAS는 접근 가능하다. 겹치는 범위 안의 원격 리소스가 잘못된 기계로 가는 것도 같은 이유다.

사설 주소 공간은 유일하지 않으며, 두 사이트가 같은 프리픽스를 고르는 일은 계획할 만큼 흔하다. 범위가 겹치면 로컬 응답이 빠르게 도착하고 권위 있어 보이므로, 실패를 로그인 문제로 잘못 읽기 쉽다. 목적지는 응답했지만 의도한 곳이 아니었다.

커널이 내릴 선택을 읽기

테이블을 위에서 읽는 대신 커널에 정확한 목적지에 어떤 경로를 쓸지 물어보라. 그다음 다른 테이블을 고를 수 있는 정책 규칙을 찾아라. 두 명령이 두 질문 모두에 몇 초 만에 답한다.

ip route get 10.20.30.41
ip route show table all | grep -E '10\.|default'
ip rule show

첫 출력은 인터페이스, 다음 홉, 커널이 쓸 원본 주소를 알려 주며 이것이 중요한 답이다. 로컬 브리지를 가리키는 dev 값은 VPN 클라이언트의 상태 패널이 무엇을 주장하든 패킷이 터널로 들어가지 않는다는 뜻이다. 걸러진 테이블 목록은 다른 테이블이 같은 프리픽스를 가졌는지 보여 주고, 규칙 목록은 그 테이블들을 참조하는 순서를 보여 준다. 정책 규칙은 프리픽스를 특정 테이블로 보낼 수 있다 메인 테이블이 동의하지 않을 때도 마찬가지이므로 그 순서도 답의 일부다.

로컬 접근은 별개의 권한

경로가 있다는 것과 그것을 쓸 권한이 있다는 것은 다르다. 대부분의 클라이언트는 터널이 올라와 있는 동안 로컬 네트워크 통신을 막을 수 있고, 그 설정은 라우팅의 부산물이 아니라 정책 결정이다. 신뢰할 수 있는 주변 서비스가 설계의 일부라면 경로를 만들어 내지 말고 지원되는 로컬 접근 옵션을 켜라. 기기가 공용 Wi-Fi에 있다면 그 옵션은 꺼 두라.

두 계층은 다르게 실패한다. 차단된 로컬 경로는 경로가 존재해도 시간 초과를 만들고, 겹치는 경로는 잘못된 호스트에서 응답을 만든다. 둘을 구분하는 데 질의 하나면 충분하고 방화벽 변경으로 반나절을 아낄 수 있으며, 포워딩 구성은 strongSwan의 포워딩 노트에 설명되어 있다.

호스트 경로를 쌓지 않고 겹침 고치기

한 주소에 대한 호스트 경로는 겹침을 고치는 것처럼 보이지만 같은 범위의 두 번째 주소가 필요해지는 순간 무너진다. 그런 경로가 스무 개쯤 쌓이면 어느 프리픽스가 권위 있는지 아무도 말할 수 없다. 오래가는 해법은 주소 체계 변경, 중복 범위를 피하는 문서화된 토폴로지, 또는 한쪽 끝에서의 변환이다. 각각은 영원한 유지보수 대신 한 번의 설계 시간을 치른다.

임시 호스트 경로가 정말 필요하다면 나중에 제거할 수 있도록 이유와 담당자, 날짜를 옆에 적어 두라. 그다음 정확한 주소와 서비스, 그리고 공용 목적지를 시험하되, 관계없는 애플리케이션을 조용히 터널에서 빼는 로컬 접근 변경이 원래 결함보다 나쁘다는 점을 기억하라. 로컬 프리픽스와 원격 프리픽스를 따로 적어 두는 습관이 동작하는 로컬 핑을 원격 사무실에 닿는다는 증거로 돌려 쓰는 일을 막는다.