앱이 인터페이스에 바인딩되었나요? 그 앱의 VPN 경로는 기본이 아니다

같은 머신에서 한 앱은 VPN으로 나가고 다른 앱은 나가지 않는데, 두 사용자 모두 아무것도 바꾸지 않았다고 맹세한다. 차이는 대개 앱 스스로 내리는 바인딩 결정이다. 장치에 묶인 소켓, 연결 전에 고른 원본 주소, 또는 자체 라우팅 테이블을 가진 네임스페이스다. 각각은 어느 경로가 적용되는지를 바꾸며, 어느 것도 브라우저의 일반 IP 확인에는 나타나지 않는다.

세 가지 바인딩, 세 가지 영향

장치에 바인딩하는 것과 원본 주소에 바인딩하는 것은 관련된 작업이지만 결과는 다르다. 장치 바인딩은 트래픽이 한 인터페이스로 나가도록 강제하고 그 소켓의 정상 경로 조회를 우회할 수 있다. 원본 주소 바인딩은 여전히 경로 선택을 거친다. 그러나 선택된 원본이 정책 규칙과 일치해 패킷을 다른 곳으로 보낼 수 있다. 이 구분은 규칙이 원본으로 라우팅하기 전까지는 학문적으로 들린다. 그때는 모든 것을 결정한다.

네트워크 네임스페이스는 세 번째 사례다. 자체 인터페이스와 라우팅 테이블을 가지므로 그 안의 앱은 호스트 기본값의 영향을 전혀 받지 않는다. 셋을 같은 것으로 취급하면 첫 시험을 견디지 못하는 자신만만한 설명이 나온다.

앱이 실제로 설정하는 것을 파악하라

경로를 건드리기 전에 앱의 네트워크 구성이나 문서화된 동작을 읽어라. 인터페이스 선택, 원본 주소 필드, 네임스페이스 옵션을 제공한다면 그 설정이 가장 먼저 점검할 대상이다. 그렇지 않다면 바인딩은 내부에 있을 수 있고 추적이나 자체 진단으로만 보일 수 있다.

Linux에서 SO_BINDTODEVICE 같은 소켓 옵션은 문서화된 범위와 권한 요구 사항이 있으며, 권한이 없는 프로세스는 아예 설정하지 못할 수 있다. 이 제약은 유용한 단서다. 옵션을 적용할 수 없다면 앱이 차이의 원인이 아닐 가능성이 크다.

정책 라우팅은 원본을 읽는다

정책 라우팅이 구성되면 규칙이 패킷 원본을 기준으로 테이블을 선택할 수 있다. 따라서 원본 주소를 바인딩한 소켓은 기본 경로가 전혀 건드리지 않는 규칙을 따를 수 있다. 인터페이스가 명시되지 않았더라도 마찬가지다.

앱이 사용하는 것과 같은 주소 체계, 원본, 네임스페이스로 조회를 재현하라. 호스트 네임스페이스의 셸에서 하는 일반 경로 조회는 다른 질문에 답하며, 이 불일치가 작동하는 경로를 고장 난 것처럼 보이게 하는 가장 흔한 이유다.

분할 터널과 보조 프로세스

앱별 분할 터널은 또 한 겹을 더한다. 클라이언트는 앱의 패키지나 프로세스를 일치시킬 수 있고, 자체 소켓을 여는 보조 프로세스는 별개의 대상이다. 런처와 그 백그라운드 서비스는 같은 보이는 이름 아래 서로 다른 연결을 만들 수 있다.

분할 터널 규칙이 실제로 연결하는 프로세스를 포함하는지 확인하라. 앱이 특정 인터페이스에 바인딩되고 VPN 클라이언트가 패키지로 일치한다면, 둘 다 틀리지 않은 채 두 결정이 어긋날 수 있다.

앱 자체의 경로를 시험하라

변경할 때마다 앱에서 새 요청을 실행하라. 원했던 출구를 보여 주는 브라우저는 다른 인터페이스에 바인딩된 다른 프로그램에 대해 동등한 증거가 아니며, 캐시된 연결은 설정을 바꾼 뒤에도 오랫동안 옛 경로를 계속 쓸 수 있다. 새 규칙을 판단하기 전에 옛 세션을 닫아라. 그렇지 않으면 시험이 과거를 측정한다.

Linux 소켓 참조는 SO_BINDTODEVICE와 그 요구 사항을 문서화한다. 먼저 앱 자체의 구성을 읽고, 같은 맥락에서 조회를 재현한 뒤에야 경로와 바인딩 중 무엇을 바꿀지 결정하라.