NetGuard의 SOCKS 모드는 TCP만 다루며 모든 프로토콜이 아니다

NetGuard는 트래픽을 필터링하기 위해 Android의 VPN 인터페이스를 차지하며 지원되는 연결을 SOCKS 엔드포인트로 넘길 수 있습니다. 이 두 사실은 흔히 “휴대폰이 VPN에 있다”로 읽히지만, 그것은 이 메커니즘이 뒷받침하지 않는 결론입니다. 필터는 패킷을 본다는 점과 달리 프록시는 실제로 넘겨받은 연결만 봅니다. 이 두 문장 사이에 커버리지라는 질문 전체가 있습니다.

업스트림 프로젝트의 FAQ는 단일 서비스 제한과 SOCKS 옵션을 모두 문서화합니다. 옵션의 존재는 허용된 모든 패킷이 그것을 쓴다는 증거가 아니며, 커버리지 질문은 바로 이 간극에서 나옵니다.

하나의 앱 안에 있는 두 개의 전달 경로

구현의 TCP 쪽에는 SOCKS 연결 처리가 있어 허용된 TCP 연결은 프록시와 협상해 그를 통해 전달될 수 있습니다. UDP 쪽에는 별도의 소켓 경로가 있고, 그 송수신 처리는 이 TCP 협상에 의존하지 않습니다. 그래서 필터가 허용한 데이터그램은 프록시를 전혀 거치지 않고 일반 네트워크에 도달할 수 있습니다. 이 점에서 앱의 결함은 없으며, 두 경로가 구현하는 것이 바로 그것입니다.

이 구분에는 사람들이 양방향으로 잘못 말하는 결과가 따릅니다. 모든 UDP 패킷을 유출이라고 부르는 것은, 거부된 데이터그램은 결코 나가지 않기 때문에 차단 규칙을 무시합니다. 전체 구성을 VPN이라고 부르는 것은, 일부 트래픽은 실제로 프록시 없이 나가기 때문에 허용된 직접 경로를 무시합니다. 당신이 가진 것은 부분적 프록시가 있는 필터링된 기기이며, 정직한 설명은 라벨이 아니라 행렬입니다.

UDP를 광고하는 것은 구현하는 것이 아니다

UDP 지원을 주장하는 SOCKS 서버는 휴대폰의 앱에 그에 맞는 클라이언트 측 처리를 더하지 않습니다. 프로토콜의 이론적 기능과 설치된 빌드의 동작은 다른 주제이며, 당신의 트래픽을 설명하는 것은 후자뿐입니다.

실제로 실행하는 버전과 구성을 확인한 다음 무해한 데이터그램 흐름을 시험하고 그것이 프록시에 나타나는지 관찰하십시오. 그 밖의 것은 기능 목록에서 나온 추론이며, 기능 목록은 코드 경로가 아니라 의도를 설명합니다.

DNS는 세 번째 경로이지 세부 사항이 아니다

이름 해석은 행렬에 자기 가지를 더합니다. 로컬 DNS 포워더, 일반 UDP 질의, 프록시가 직접 해석하는 목적지 호스트 이름, 브라우저 안의 암호화된 리졸버는 네 가지 서로 다른 구성입니다. 이들은 질의를 누가 보는지와 어떤 네트워크 경로가 그것을 나르는지에서 다르며, 이들을 섞으면 나머지에 대해 아무것도 증명하지 못하는 시험이 됩니다.

무엇을 원하는지 의식적으로 결정하십시오. 이름이 터널을 통해 해석되어야 한다는 요구라면 브라우저 설정만으로는 그것을 제공하지 못하며, 호스트 이름을 스스로 해석하는 프록시는 실제로 처리하는 연결에 대해서만 답을 바꿉니다.

프록시 전송은 자동으로 사적이지 않다

순수 SOCKS는 휴대폰에서 프록시로 가는 암호화된 링크가 아니며, 엔드포인트가 다른 보호된 경로로 도달된다면 그 경로와 그 실패 정책을 명시해야 합니다. 개방 네트워크로의 폴백은 경고 없이 사적 구성을 공적 구성으로 바꿉니다. 프록시 자체의 인증도 중요하며, 공유 기기에서 열린 리스너는 아무도 책임지지 않는 서비스입니다.

프로필 간 구성도 같은 검토가 필요합니다. 업무 프로필 VPN은 자기 경로를 쓰는 트래픽만 보호하며, 개인 프로필 방화벽과 업무 터널의 공존은 방화벽의 이후 연결이 그 터널에 도달한다는 것을 증명하지 않습니다. 두 프로필이 협력한다고 가정하지 말고 도달성과 인증을 확인하십시오.

페이지 로드가 아니라 행렬로 커버리지를 감사하라

승인된 평가를 위해 관심 있는 각 부류를 대표하는 무해한 예, 즉 필요한 TCP, 허용된 UDP, 두 주소 체계의 DNS를 고르십시오. 각각에 대해 프록시되었는지, 차단되었는지, 직접 전송되었는지 기록하십시오. 그 하나의 표가 산출물이며, 로드된 페이지의 스크린샷보다 훨씬 유용합니다.

선택한 모든 애플리케이션 트래픽이 원격 터널을 통과해야 한다는 요구라면, 결합된 필터링과 터널링을 명시적으로 지원하는 구현을 고르십시오. TCP만 있는 프록시 구성은 다른 트래픽을 잊지 말고 의도적으로 처리한다는 조건에서 더 좁은 작업에 계속 유용합니다.