삭제한 VPN 경로가 다시 연결 후 돌아오는 이유

직접 삭제한 경로가 다음 재연결 후 다시 돌아오고, 테이블은 이전과 똑같아 보입니다. 이것은 라우팅 버그가 아니라 구성이나 연결 수명 주기 동작에서 무언가가 항목을 다시 만듭니다. 대부분의 런북은 활성 테이블에서 멈추기 때문에 삭제가 일 분 동안 작동하는 것처럼 보이다가 실패합니다. 소유자를 식별하고, 그것을 변경하고, 재연결에서 증명하세요.

경로를 설치한 주체

수정이 아니라 후보 목록부터 시작하세요. VPN 프로필이 자체 경로를 가질 수 있고, 서버가 연결 시점에 경로를 push할 수 있으며, 네트워크 관리자 프로필이 경로를 선언할 수 있고, 부팅 단위나 스크립트가 경로를 추가할 수 있으며, IPsec 구현은 협상한 트래픽 선택자에 대한 경로를 설치합니다. 정책 라우팅 규칙도 트래픽을 완전히 다른 테이블로 리디렉션할 수 있습니다.

타이밍은 구성 고고학보다 그들을 더 빨리 구분합니다. 인터페이스가 올라오는 순간 나타나는 항목은 클라이언트의 것이고, 일 초 후에 도착하는 항목은 보통 서버 push에서 온 것이며, 부팅 시 존재하는 항목은 저장된 구성의 것입니다. 연결, 연결 해제, 재부팅 전후로 테이블을 기록하면 패턴이 소유자를 알려줍니다. 서비스가 재시작될 때만 돌아오는 경로는 VPN이 아니라 단위를 가리킵니다.

편집하기 전에 테이블 읽기

저장된 파일 대신 커널 자체의 뷰를 보세요. 프로토콜 열은 각 항목을 무엇이 설치했는지 보여줍니다:

ip route show
ip route show table all
ip rule show

프로토콜 필드, 메트릭, 테이블 번호는 정적 항목, 커널이 만든 항목, 데몬이 추가한 것 중 무엇을 보고 있는지 알려줍니다. 규칙 목록이 중요한 이유는 조회가 기본 테이블을 완전히 벗어날 수 있고, 그러면 그곳의 편집이 디버깅 중인 애플리케이션에 보이지 않기 때문입니다. 줄을 왼쪽에서 오른쪽으로 읽으세요: 목적지, 게이트웨이, 장치, 프로토콜, 메트릭.

그런 다음 커널에 실제로 어떤 경로를 사용할지 물어보세요. 보호된 주소는 공용 주소보다 더 나은 탐침입니다:

ip route get 10.20.5.7

증상이 아니라 소유자를 바꾸세요

소유자를 알게 되면 변경은 그 소유자에게 속합니다. 클라이언트 프로필에서 경로를 제거하고, 서버의 push 경로를 수정하거나, 메트릭으로 이기는 경쟁적인 영구 경로를 추가하는 대신 네트워크 관리자 연결을 편집하세요. 서로 싸우는 두 규칙은 나중에 아무도 설명할 수 없는 테이블을 만듭니다.

엔드포인트 제외를 유지하세요. VPN 서버 자체의 공용 주소를 물리 게이트웨이를 통해 보내는 호스트 경로가 외부 터널 패킷을 계속 흐르게 합니다; 삭제하면 터널이 스스로를 운반하려고 합니다. 분할 터널 프로필에서는 터널을 우회해야 하는 로컬 서브넷에도 같은 주의가 적용됩니다.

다시 연결하고 두 경로를 모두 확인하세요

다시 연결한 다음 한 번에 두 목적지를 모두 확인하세요. 보호된 주소와 제외된 엔드포인트는 서로 다른 질문에 답합니다:

ip route get 10.20.5.7
ip route get 198.51.100.20

첫 번째는 터널 인터페이스를 통해, 두 번째는 물리 게이트웨이를 통해 해석되어야 합니다. 둘 다 터널을 통해 해석되면 제외가 빠진 것이고, 둘 다 아니라면 프로필 변경이 적용되지 않았고 생각한 것과 다른 소유자를 보고 있는 것입니다.

경로의 목적, 소유자, 얼마나 오래 유지되어야 하는지 적어 두세요. 그 메모가 다음 사람이 같은 삭제와 재연결 주기를 반복하지 않게 막습니다.