Linux에서 VPN이 푸시한 경로와 정적 경로를 구분하는 방법

터널이 올라오면 노트북에 프리픽스가 나타나므로 VPN이 설치한 것처럼 느껴집니다. 그럴 수도 있지만 같은 결과는 연결 시 실행되는 클라이언트 스크립트, 서브넷을 나열하는 연결 프로필, 또는 처음부터 있었고 인터페이스가 생긴 뒤에야 작동하기 시작한 정적 경로에서도 나올 수 있습니다. 출처를 잘못 고르면 정리할 때마다 경로가 다시 생기고 다음 사람이 같은 수정을 반복합니다. 아래 순서는 무엇이든 바꾸기 전에 이 셋을 분리합니다.

1단계: 프리픽스를 설치하는 메커니즘의 이름을 붙이기

프로토콜마다 도달 가능성을 제공하는 방식이 다르며, 이 모두를 광고라고 부르면 차이가 가려집니다. OpenVPN 서버는 제어 채널로 경로 지시를 푸시하고 pull 필터가 막지 않으면 클라이언트가 설치합니다. WireGuard 구성은 허용된 프리픽스를 로컬에 나열하며, 클라이언트는 이를 암호화 키 라우팅과 자신이 추가하는 경로 모두에 사용합니다. IPsec 터널은 피어와 트래픽 선택자를 합의하고 커널은 그 선택자에서 경로를 설치합니다.

어떤 표를 읽기 전에 여러분의 터널이 그중 무엇을 쓰는지 확인하십시오. 연결 시 푸시된 경로는 라우팅 프로토콜의 광고가 아니며 프리픽스가 원격 끝 너머에서 도달 가능하다고 약속하지도 않습니다. 수정이 어디에 속하는지를 결정하므로 프리픽스 옆에 메커니즘을 적어 두십시오.

2단계: 한 번의 연결에 걸쳐 표 비교하기

터널을 내린 상태에서 기본 표를 저장하고, 올린 뒤 다시 저장하고, 두 캡처를 비교하십시오. 나타난 것은 연결 수명 주기에 속하고 남은 것은 로컬 구성에 속합니다.

ip route show table main > /tmp/route-down.txt 로 캡처하고 연결한 뒤 다시 캡처하십시오. 사이트가 IPv6를 쓰면 ip -6 route 에 대해서도 같은 작업을 하십시오. 거기서 빠진 프리픽스는 라우팅과 무관해 보이는 장애를 만듭니다.

3단계: 존재 여부가 아니라 메트릭 읽기

같은 프리픽스에 대한 두 항목이 공존할 수 있고 커널은 더 낮은 메트릭을 고릅니다. 메트릭 50의 정적 경로는 둘 다 보이더라도 100의 푸시된 경로를 계속 이깁니다. 그래서 '경로가 있다'와 '트래픽이 그것을 쓴다'는 다른 진술입니다.

ip route get 10.20.5.7 로 커널에 직접 물어보고 그것이 보고하는 인터페이스를 읽으십시오. 표에 터널 경로가 있는데 트래픽이 물리 어댑터로 나간다면 메트릭이나 프리픽스 길이가 설명하지 VPN 클라이언트가 아닙니다. 터널 뒤에 있다고 아는 호스트와 그렇지 않다고 아는 호스트에 대해 조회를 반복하면 분할이 의도대로 동작하는지 드러납니다.

4단계: 터널보다 오래 사는 항목 찾기

정적 경로는 설계상 연결 끊김을 견디며 오래된 항목은 바로 거기서 나옵니다. 더 이상 없는 인터페이스를 가리키는 영구 경로는 서브넷을 조용히 삼킬 수 있고, 재사용된 인터페이스 이름을 가리키는 경로는 재부팅 후 사설 트래픽을 잘못된 문으로 내보낼 수 있습니다.

영구 쪽은 배포판이 사용하는 곳에서 확인하십시오. systemd-networkd 단위, NetworkManager 프로필, 또는 클라이언트의 up 디렉터리에 있는 스크립트일 수 있습니다. ip route del 로 살아 있는 표를 고치는 것은 다음 연결까지만 유지됩니다. 그 삭제는 수리가 아니라 가설의 시험으로 다루십시오.

원격 끝이 잘못된 범위를 제공한다면 모든 것을 필터링하는 대신 운영자에게 제기하십시오. 푸시된 설정을 모두 버리면 프로필이 의존하는 DNS와 분할 터널 정책도 버리게 됩니다.

5단계: 클라이언트를 탓하기 전에 반환 경로 확인하기

사이트 간 연결이나 터널 뒤 서브넷의 경우 원격 쪽에 클라이언트 주소로 돌아가는 경로와 게이트웨이의 포워딩 활성화가 필요합니다. 한 방향 경로는 클라이언트 라우팅 버그와 똑같이 보입니다. 다만 핸드셰이크와 나가는 패킷은 둘 다 성공합니다.

역경로 필터링은 Linux 게이트웨이에 두 번째 함정을 더합니다. 경로가 예상하는 것과 다른 인터페이스로 도착한 응답은 엄격 모드에서 버려지며, 두 사업자를 거치는 비대칭 경로가 이를 확실히 유발합니다. 필터링이 원인인지는 클라이언트가 아니라 게이트웨이의 드롭 카운터가 알려 줍니다.

6단계: ping이 아니라 자원을 시험하기

고른 경로가 올바르면 실제 자원을 열고 반환 트래픽을 확인하십시오. ping 응답은 한 방향의 경로를 증명할 뿐 서비스에 대해서는 아무것도 아니며, 캐시된 연결에 응답하는 서비스는 더더욱 아닙니다.

그다음 다시 연결한 뒤 전체 점검을 반복하십시오. 이 순서의 가치는 다음 연결이 무엇을 할지 예측한다는 데 있으며, 그래서 비교와 메트릭이 모두 티켓에 들어갑니다.