VPN 라우트 캐시가 변경 사항을 숨기고 있나요? 세 가지를 확인하세요

변경이 적용되지 않을 때 라우트 캐시를 비우는 것이 첫 본능이지만, 최신 Linux에서는 헛수고입니다: 전역 IPv4 라우트 캐시는 몇 년 전 제거되었으므로 ip route show cache는 아무것도 출력하지 않고 지울 것도 없습니다. 당신을 속이는 상태는 한 계층 위에 있습니다: 소켓, NAT 매핑, 리졸버, 또는 이전 프로필을 다시 적용한 네트워크 관리자입니다. 세 가지 질문이 그 경우를 구분합니다: 잘못된 경로가 새 흐름에서 오는지 오래된 연결에서 오는지, 플랫폼이 라우트를 캐시하는지, 상태가 라우팅에 있는지 그 위에 있는지. 인터페이스를 재설정하기 전에 답하세요.

확인 하나: 오래된 경로가 새 흐름에서 오나요?

설정된 연결은 생성될 때의 라우트를 유지합니다. 그래서 터널을 통한 SSH 세션은 라우팅 테이블 변경에서 살아남고 새 세션은 즉시 새 경로를 택하며, «변경이 아무것도 하지 않았다»가 흔히 «오래된 소켓이 여전히 붙들고 있다»를 뜻하는 것도 같은 이유입니다. 이미 열려 있는 창이 아니라 새 프로세스로 테스트하세요.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

마지막 명령은 새 연결이 실제로 도달한 주소를 출력하며, 상태 창을 믿지 않고 실제 경로를 보는 가장 싼 방법입니다. namespace나 인터페이스가 사용했어야 할 소스 주소와 비교하세요.

새 흐름이 올바른 경로를 택하고 오래된 흐름이 회복되지 않으면 라우팅을 보는 것을 멈추세요. 경로는 옳았고 세션은 오래되었습니다.

확인 둘: 플랫폼이 라우트 캐시를 유지하나요?

Linux에서 답은 아니오입니다, 대부분의 안내서가 의미하는 뜻에서는. 버릴 전역 목적지 캐시가 없고, 선택된 라우트를 담는 소켓 단위 항목은 소켓과 함께 해제됩니다. ip-route 매뉴얼의 캐시 절은 역사적 동작을 설명할 뿐, 현재 커널에서 비울 수 있는 것을 설명하지 않습니다.

다른 플랫폼은 다르며, 조언을 복사하는 것이 바로 여기서 어긋납니다. Windows는 netsh interface ip delete destinationcache로 지울 수 있는 목적지 캐시를 유지합니다. BSD와 macOS는 route -n get를 통해 목적지별 조회를 제공하며, 각자의 일정에 따라 캐시가 만료됩니다. 그중 하나에서 동작하는 명령은 Linux에서 아무것도 하지 않으므로, 같은 수정이 시도하는 사람의 절반에게 실패하는 것처럼 보입니다.

NAT나 conntrack 테이블은 라우트 캐시가 아니지만 같은 증상을 만듭니다. 변경 전에 변환된 흐름은 그 변환을 유지하며, conntrack -L는 라우팅 정책이 훨씬 지난 뒤에도 그것을 보여 줍니다. 그것은 오래된 상태이지만 라우트를 지워도 그것에는 닿지 않습니다.

확인 셋: 상태가 라우팅에 있나요, 그 위에 있나요?

다른 무엇을 읽기 전에 현재 조회를 읽으세요: 목적지에 대해 ip route get, 그다음 from와 소스 주소를 붙인 같은 명령, 그다음 ip rule show. 이 셋이 의도와 맞으면 라우팅은 고칠 계층이 아니며, 오래된 관측은 다른 곳에서 온 것입니다.

흔한 용의자 셋이 라우팅 위에 앉아 있습니다. 네트워크 관리자는 삭제한 지 몇 초 만에 저장된 프로필에서 라우트를 다시 설치할 수 있어 변경이 되돌아간 것처럼 보입니다; 테이블을 다시 편집하기 전에 nmcli connection show --active와 유닛 상태를 확인하세요. 리졸버 캐시는 오래된 주소를 돌려주며, 캐시를 우회하는 도구로 같은 이름을 질의할 때까지 라우팅 실패처럼 보입니다. 애플리케이션의 연결 풀은 오래된 목적지로 가는 동작하는 소켓을 유지하고 커널에 새 결정을 요청하지 않습니다.

세 답에서 무엇을 결론지을 수 있나

답을 모으면 수리는 대개 스스로 말해 줍니다. 라우트 캐시가 없는 플랫폼에서 새 흐름이 잘못된 경로를 택한다면 정책이 정말로 잘못된 것입니다, 그러니 터널이 설치한 규칙과 테이블을 읽으세요. 오래된 세션이 멈춰 있는 동안 새 흐름이 올바른 경로를 택한다면 문제는 애플리케이션이나 소켓입니다. 두 경우 모두 라우트가 올바른데 관측이 깨졌다면 상태는 라우팅 위에 있습니다.

일반적인 새로 고침에 저항하세요. 네트워크 스택을 다시 시작하거나 기본 라우트가 터널인 머신에서 모든 라우트를 지우면 고치려고 쓰는 바로 그 연결이 끊길 수 있고, 어느 계층이 실패했는지 알려 줄 증거도 파괴됩니다.

정말 무언가를 지워야 한다면 진단에 맞는 가장 작은 것만 지우세요: 한 프로세스의 소켓, conntrack 항목 하나, 리졸버 캐시. 그다음 같은 새 흐름 테스트를 반복하고 무엇이 바뀌었는지 적으세요.

메모에서 세 상태를 분리해 두세요

저장된 구성, 현재 조회, 관측된 흐름은 서로 다른 세 가지 사실입니다, 그리고 그것들을 «캐시»로 합치는 것이 결함을 재현하기 어렵게 만듭니다. 라우트를 소유한 프로필이나 유닛, ip route get의 출력, 실제 연결의 소스와 목적지를 적으세요.

옆에 플랫폼과 클라이언트 버전을 기록하세요, Windows 목적지 캐시를 지우는 수정은 Linux 호스트에 적용되는 수정이 아니며 둘 사이에서 복사된 절차는 잘못된 교훈을 가르치기 때문입니다. 문제를 다른 사람에게 넘길 때 그 세 줄이 있으면 추측 대신 실패 상태를 재현할 수 있습니다.