VPN 클라이언트가 추가한 경로를 지웁니까? 정책 테이블을 사용하세요

랩 프린터용 /24 하나가 두 번의 ip route show 호출 사이에 사라지고, 클라이언트 로그는 네트워크가 바뀌었다고만 말합니다. 명령, 프리픽스, 권한에는 아무 문제가 없었습니다. 호스트의 라우팅 모델을 소유한 기업용 클라이언트는 다른 누군가가 그것을 편집할 때마다 그 모델을 다시 주장하므로, 추가한 항목은 침입자로 삭제됩니다. 같은 테이블에서 맞서는 것은 지는 싸움입니다. 해결책은 그 테이블을 두고 경쟁하기를 완전히 그만두고, 예외를 모니터가 절대 보지 않는 곳에 두는 것입니다.

모니터가 사라진 경로를 설명합니다

무언가를 재설계하기 전에 이것을 보여 주세요. 테이블을 읽고, 프리픽스를 추가하고, 몇 초 기다렸다가 다시 읽습니다. 항목이 없고 제거하기 위해 아무것도 입력하지 않았다면, 무언가가 지켜보고 있습니다. 그 행동을 소유한 프로세스를 찾아 경로가 사라지는 순간 전후의 저널을 읽으세요. 보통 같은 서비스가 터널, 패킷 필터, 리졸버 구성을 관리하기 때문입니다. 경로를 유지하려고 그것을 죽이는 것은 다음 재연결에서 후회할 거래입니다.

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

위의 프리픽스와 인터페이스는 자리 표시자입니다. 다른 머신에서 동작하는 예제에서 인터페이스 이름을 복사하는 것이 이 시연이 전혀 아무것도 내놓지 않는 가장 흔한 이유입니다.

두 번째 테이블은 모니터에게 보이지 않습니다

에이전트는 자신이 소유한 테이블만 다시 만듭니다. 예외에 자체 테이블과 일치하는 목적지를 그곳으로 보내는 규칙을 주면 기본 테이블은 절대 바뀌지 않으므로 에이전트가 고칠 것이 없습니다. 이것이 전부입니다. 다른 누군가가 관리하는 경로 네임스페이스 하나와, 오직 당신만 만지는 네임스페이스 하나입니다.

대가는 유지보수입니다. 두 객체는 서로 어긋날 수 있고, 목록에서 규칙의 위치는 그것이 선택하는 테이블 안의 경로만큼 중요합니다.

예외를 만들고 승리하게 하세요

테이블을 만들고, 경로를 설치하고, 해당 목적지에 대해 테이블을 선택하는 규칙을 추가합니다. 우선순위는 당신의 규칙이 클라이언트가 삽입한 규칙보다 먼저 검사될지 나중에 검사될지를 결정하고, 더 늦게 정렬된 규칙에는 결코 도달하지 않으므로 숫자는 장식이 아니라 설계의 일부입니다. 그다음 커널에 실제로 무엇을 할지 물으세요. 이는 설정한 것과 다른 질문입니다.

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get 은 장치와 소스 주소를 포함해 커널이 사용할 경로를 해석합니다. 테이블 식별자를 출력하지 않으므로 ip rule show 와 함께 사용하세요. 어느 테이블이 이겼는지 확인해야 할 때 필요합니다. 둘을 합치면 유일하게 중요한 질문에 답합니다. 그 주소로 가는 트래픽이 의도한 곳에서 나가는가?

같은 아이디어의 다른 형태

목적지로 생각하는 것을 멈추면 패턴이 일반화됩니다. 터널이 기본 경로를 유지하는 동안 로컬 서브넷은 계속 접근 가능하게 둘 수 있습니다. LAN에 연결된 SSH 서버의 응답은 터널로 사라지는 대신 도착한 인터페이스로 나갈 수 있습니다. 인터페이스 기반 규칙은 무선 인터페이스로 들어오는 모든 것을 터널로 밀어 넣고, 호스트 자체가 생성하는 트래픽은 Ethernet에 남길 수 있습니다.

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

마지막 경우는 목적지가 아니라 들어오는 인터페이스와 일치하며, 이는 다른 규칙 유형이자 다른 사고 모델입니다. 전달되는 트래픽에는 net.ipv4.ip_forward 이 활성화되어 있어야 하고, 원격 측은 소스 범위를 되돌려 라우팅하거나 변환해야 합니다. 한 머신의 규칙이 경로의 나머지 절반을 만들어 주지는 않습니다.

규칙을 일회용으로 취급하세요

규칙과 테이블 경로는 메모리에 있습니다. 재연결 후 터널 장치의 이름이 바뀌고, 할당된 주소가 이동하고, 이전 값을 가진 규칙은 조용히 일치하지 않게 됩니다. 변경 전체를 소유한 단일 스크립트에서 다시 적용한 다음, 예외를 신뢰하기 전에 ip rule show, 현재 장치 이름, 새 ip route get 을 실제 목적지에 대해 다시 확인하세요.

아무리 조심해도 두 가지 경계는 남습니다. 클라이언트는 여전히 자체 필터 규칙과 리졸버 구성을 제어하며, 라우팅 예외는 둘 다 덮어쓰지 않습니다. 클라이언트가 정책 규칙까지 삭제한다면 지원되는 경로는 자체 분할 터널 정책이거나 OpenConnect처럼 경로 관리를 허용하는 클라이언트입니다. 모니터를 조용히 만들기 위해 벤더 바이너리를 패치하는 것은 무결성 검사가 붙은 유지보수 약속입니다.

테이블 번호, 우선순위, 목적지를 스크립트 옆의 메모에 적으세요. 그렇지 않으면 다음 사람이 터널을 능가하는 규칙을 발견하고 그 이유를 알 방법이 없습니다.