VPN 라우트 테이블이 알려 주는 것과 알려 주지 못하는 것

연결하고 라우트 목록을 실행하면 들어 본 적 없는 서브넷이 터널을 가리키는 것을 봅니다. 그 줄은 한 가지를 정확히 말하고 여러 가지는 전혀 말하지 않습니다. 이 머신이 그 프리픽스로 패킷을 어떻게 전달하는지만 기록하며, 그곳에 어떤 호스트가 있는지는 아무것도, 계정이 무엇에 도달할 수 있는지도 아무것도 알려 주지 않습니다. 올바르게 읽는 데는 일 분이면 충분하지만, 목록처럼 읽는 습관을 버리는 데는 훨씬 오래 걸립니다.

테이블을 로컬 지침으로 읽기

라우트는 로컬 커널이 보유한 포워딩 지침으로, 이 프리픽스에는 이 인터페이스와 이 다음 홉을 사용하라는 뜻입니다. 프리픽스 길이가 지침의 구체성을 결정하고, 가장 긴 일치가 이깁니다. 그 규칙에는 권한도, 서비스 상태도, 원격 토폴로지도 언급되지 않습니다.

정책 규칙은 테이블을 조회하기 전에 개입할 수 있습니다, 그래서 라우트가 존재하더라도 특정 패킷이 사용하는 라우트가 아닐 수 있습니다. 규칙을 테이블과 함께 읽고, 그다음 커널에 특정 목적지에 어떤 경로를 선택할지 물어보세요. 한 주소에 대한 답은 한 페이지의 프리픽스보다 가치가 있으며, 클라이언트가 적용한 마크, 네임스페이스, 인터페이스 바인딩을 반영하는 유일한 답입니다.

넓은 프리픽스는 목록이 아닙니다

터널을 통해 라우팅된 /16은 만 육천 개의 도달 가능한 호스트를 뜻하지 않으며, 기본 라우트는 그보다도 적습니다. 무엇이 응답하는지는 서버가, 무엇이 허용되는지는 방화벽이, 무엇이 승인되는지는 계정이 결정합니다.

좁은 테이블에는 반대 함정이 있으며, 없는 프리픽스는 목적지가 다른 경로로 도달 가능하다는 뜻일 수도 있고, 단순히 전혀 라우팅되지 않았다는 뜻일 수도 있습니다. 그 두 경우는 시험해 보기 전까지 똑같아 보입니다. 테이블은 VPN에 무엇이 있어야 하는지에 대한 기대가 아니라, 사용하라고 들은 리소스와 비교하세요.

항목은 어디에서 오는가

라우트는 적어도 네 곳에서 옵니다. 구성 파일, 연결 설정 중 라우트를 푸시하는 서버, 인터페이스를 소유한 네트워크 관리자, 그리고 장애 대응 중 명령을 입력하는 사람이며, 각각 수명도 소유자도 다릅니다.

장애 중에 입력한 라우트는 재부팅 시 사라지는 라우트이며 어느 누구의 문서에도 남지 않습니다. 서버가 푸시하는 라우트는 서버가 바뀌면 바뀌므로, 설명되지 않는 새 프리픽스는 클라이언트 변경 후가 아니라 게이트웨이 업데이트 후에 나타나는 경우가 많습니다. ip-route 매뉴얼은 플래그를 읽어야 할 때 테이블과 필드 구문을 문서화합니다.

서비스 계약과 라우트를 대조하세요

유용한 비교는 테이블과 약속받은 서비스 사이입니다. 이름, 주소 범위, 포트, 소유자이며, 이 네 가지를 프리픽스 옆에 적으면 간극이 보입니다.

ip route show table all dev tun0
ip route get 10.20.5.9
ip rule show

프리픽스가 있는데도 서비스가 실패하면 테이블은 제 역할을 다한 것이고 문제는 이름 해석, 반대편 방화벽, 또는 올바른 그룹이 없는 계정 등 다른 곳에 있습니다. 프리픽스가 없으면 무엇을 입력할지가 아니라 누가 제공했어야 하는지가 질문입니다. 두 답 중 어느 것이든 다음에 물어볼 팀을 지목하며, 그것이 라우트 테이블을 읽는 유일한 유용한 결과입니다. 터미널을 닫기 전에 그 이름을 적어 두세요.

모든 변경의 전과 후를 날짜와 인터페이스와 함께 기록하세요. 라우트 테이블은 한 머신의 한 순간을 찍은 스냅샷이며, 누군가 언제 찍었는지 적어 두어야 비로소 증거가 됩니다.