ProxyChains가 가로채는 것과 그냥 두는 것
ProxyChains는 실행한 프로그램 안의 라이브러리 호출을 가로챕니다. maps, strace, 요청 하나로 TCP 범위를 확인하고, DNS나 UDP도 따라간다고 가정하지 마세요.
ProxyChains-NG는 터널을 만들지 않습니다. 실행하는 단 하나의 프로그램 안에서 네트워크 관련 libc 호출을 바꾸는 라이브러리를 미리 불러오므로, 경계는 프로세스 안의 호출이지 기기 전체의 경로가 아닙니다. 이 차이가 성공한 테스트가 실제로 무엇을 증명하는지를 결정합니다. 체인을 거쳐 동작하는 curl 는 가로챈 호출 하나를 확인할 뿐, 이름 해석이나 UDP, 모든 자식 프로세스가 같은 경로를 따랐다는 뜻은 아닙니다. 아래 절차는 세 단계로 범위를 확인한 뒤 훅이 닿지 못하는 것을 나열합니다.
미리 불러오기가 연결에 닿는 방식
시작할 때 런처는 libproxychains 를 LD_PRELOAD 에 넣은 다음 대상 프로그램을 실행합니다. 라이브러리는 실제 libc 심볼을 해석하고 connect 과 getaddrinfo 같은 함수를 자체 버전으로 바꿉니다. 그 심볼을 지나는 호출은 설정 파일의 SOCKS 또는 HTTP 프록시로 다시 쓰입니다. 다른 경로를 택하는 호출은 훅을 만나지 않으며, 그래서 보장은 호출 단위이지 기기 단위가 아닙니다.
동적 링크된 프로그램만 참여하고, 안전한 실행 아래의 setuid 바이너리는 미리 불러오기를 완전히 무시합니다. 자식 프로세스는 환경을 물려받지만, 런처가 그것을 유지하는 동안만 그렇습니다.
그 프로세스에 라이브러리가 올라와 있는지 확인하세요
요청을 시작하고, 그것을 띄운 셸이 아니라 살아 있는 프로세스를 살펴보세요. maps 파일은 현재 프로세스에 매핑된 모든 공유 객체를 보여 줍니다.
proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps일치하면 훅된 라이브러리가 있다는 것이 확인되지만, 그것은 필요조건이지 충분조건이 아닙니다. 빈 결과는 보통 런처보다 먼저 시작된 인스턴스에 URL을 넘긴 브라우저처럼 다른 프로세스를 보았다는 뜻입니다. 다른 것을 쫓기 전에 ldd 로 바이너리가 동적 링크인지 확인하세요, 정적 빌드는 미리 불러오기를 아예 적재할 수 없습니다. 그다음 런처가 실제로 사용한 설정의 프록시 목록을 읽으세요, 오래된 경로나 닫힌 포트는 동작하는 훅과 동작하지 않는 체인을 만듭니다.
프로세스를 떠나는 연결을 추적하세요
라이브러리의 존재는 모든 호출이 다시 쓰였다는 것을 증명하지 않으므로 시스템 호출을 따라가세요. 추적기 아래에서 요청 하나를 실행하고 소켓이 실제로 어디로 갔는지 읽으세요.
strace -f -e trace=connect -o /tmp/pc.trace proxychains4 -q curl -sS https://example.com/ -o /dev/null
grep -o "sin_port=htons([0-9]*)" /tmp/pc.trace | sort -u추적에는 여러분의 프록시 엔드포인트로 가는 연결만 보여야 하고, 포트는 설정 파일의 항목과 일치해야 합니다. 대상 사이트의 목적지 주소가 추적에 그대로 나타난다면 그 호출은 훅을 우회한 것이며, 바로 그것이 찾던 발견입니다. 파일 이름을 믿는 대신 포트 번호를 프록시 목록과 비교하세요, 다른 프로젝트에서 남은 설정은 조용한 직접 접속의 흔한 원인입니다. 추적은 승인 기록을 위해 남겨 두세요, 몇 초면 끝나고 범위에 관한 논쟁을 정리합니다.
훅이 덮지 못하는 것을 정하세요
proxychains-ng 프로젝트는 리디렉션을 TCP로 제한하고, 스크립트와 백그라운드 프로세스, 불러온 모듈이 주 프로그램과 다르게 동작할 수 있다고 경고합니다. UDP와 ICMP는 이 메커니즘 밖에 있으므로 그것에 의존하는 모든 것은 자체 지원 경로가 필요합니다. DNS는 proxy_dns 설정과 애플리케이션 자체 리졸버의 동작을 따르므로, HTTPS 요청 하나가 성공해도 이름 해석에 대해서는 아무것도 알려 주지 않습니다. 인증서 검증도 제자리에 두세요, 프록시를 통해 서버에 닿는 것은 신원 검사를 끌 이유가 아닙니다.
직접 폴백이 불가능해야 한다면, 네트워크 네임스페이스나 방화벽 규칙, VPN 처럼 트래픽 자체를 제어하는 강제 경계를 라이브러리 훅과 분리해 사용하세요. 훅은 특정 프로그램을 위한 호환 도구이지 kill switch가 아닙니다. 프로그램, 정확한 명령, 추적에서 본 프록시 포트, DNS가 원격에서 해석되었는지를 기록하세요, 이 네 가지 사실이 검증된 범위와 희망의 범위를 가릅니다.