기본 경로를 수정하기 전에 Linux 정책 라우팅을 확인하세요

VPN 호스트가 한 인터페이스에서 응답하면서 터널로 응답을 되돌려 보내기를 거부하고, 기본 경로는 정상으로 보입니다. 바로 그 지점에서 메인 테이블이 이야기의 전부가 아니게 됩니다. Linux는 정책 규칙으로 패킷마다 라우팅 테이블을 선택할 수 있으며, VPN이 그중 하나를 설치했을 수 있습니다. 기본 경로를 건드리기 전에 규칙을 읽으세요.

순서가 중요합니다: 규칙이 먼저, 그다음 각 규칙이 선택하는 테이블입니다.

우선순위 순서로 규칙 읽기

다음을 실행하고 ip rule show 위에서 아래로 읽으세요. 우선순위 번호가 평가 순서를 결정하며, 더 낮은 번호가 먼저 검사됩니다. 32766의 기본 규칙은 보통 마지막으로 중요한 규칙입니다. 목록이 길면 변경하기 전에 파일로 저장하세요.

각 규칙에 대해 우선순위, 일치 조건(출발지, 마크, 인터페이스 또는 목적지), 참조하는 테이블을 기록하세요. 쓸 만한 테이블이 없는 규칙은 막다른 길이지 경로가 아닙니다.

IPv6에도 같은 작업을 하세요: ip -6 rule show. IPv4 계열에만 있는 정책은 다른 계열을 메인 테이블에 그대로 둡니다.

각 규칙이 선택하는 테이블 읽기

다음을 사용하세요: ip route show table <name or number> 참조된 각 테이블에 대해. 그 경로를 예상하는 인터페이스와 다음 홉과 비교하세요. 비어 있거나 불완전한 테이블은 메인 테이블이 설명할 수 없는 실패를 설명합니다.

메인 테이블에 여전히 기본 경로가 있을 수 있으며, 그것은 괜찮습니다. 규칙이 흐름을 먼저 51820 테이블로 보내면, 그 패킷에는 메인 기본 경로가 무관합니다.

번호가 낯설면 그 안에서 테이블 이름을 찾아보세요: /etc/iproute2/rt_tables. 그 조회는 몇 초 걸리고 긴 우회를 막아 줍니다.

누가 규칙을 설치했는지 찾기

NetworkManager, wg-quick 및 기타 스크립트는 규칙을 동적으로 설치할 수 있습니다. 실행 중에 하나를 삭제하면 다음 재연결에서 되돌려질 수 있습니다. 경쟁하는 규칙을 추가하기 전에 관리자의 구성을 확인하세요.

예를 들어 wg-quick은 터널의 허용 주소에 대해 표시된 규칙과 테이블을 추가합니다. 그 주소로 가는 트래픽이 메인 기본 경로를 우회하는 이유가 바로 그 규칙입니다. 구성을 바꾸지 않고 규칙을 제거하면, 다음 up에서 복원됩니다.

검토하는 동안 엔드포인트의 외부 경로와 관리 접근을 보존하세요. 출력을 단순화하려고 운영 중인 원격 게이트웨이에서 모든 규칙을 비우지 마세요. 변경을 견디는 관리 세션도 테스트의 일부입니다.

중요한 출발지 컨텍스트 테스트하기

일반적인 ip route get 은 애플리케이션 흐름과 다른 질문에 답합니다. 실제 패킷이 지나는 경로를 보려면 출발지 주소와, VPN이 사용한다면 마크를 추가하세요. 같은 출발지 컨텍스트로 포함된 목적지와 제외된 목적지를 테스트하세요. 호스트가 듀얼 스택이면 IPv6에도 반복하세요.

승인된 수정 후에는 같은 두 조회를 다시 실행해 비교하세요. 의도한 규칙, 테이블, 그리고 그 규칙이 재시작을 얼마나 견디는지 기록하세요. 다음 서비스 재시작을 신비가 아니라 설명 가능하게 만드는 것이 그 기록입니다. ip-rule 매뉴얼 페이지 는 일치 선택자와 테이블 구문을 설명합니다.