VPN 없이 프록시 IP 돌리기: 출구가 보는 것
VPN 없이 프록시 출구를 돌리세요: HTTP 프록시가 읽을 수 있는 것, 끈적한 세션이 깨진 상태를 막는 방식, 정책에서 설명할 수 있는 출구 선택.
프록시 로테이션과 VPN은 서로 다른 계층에서 공인 주소를 바꾸며, 그 차이가 무엇이 새는지를 결정합니다. VPN은 모든 패킷을 터널로 옮기므로 대상이 보는 출발지 주소는 터널의 끝점입니다. 프록시는 네트워크 계층 위에 자리하며, 프록시를 통해 보낸 요청만 출구에서 보이고 기기 위의 다른 모든 것은 실제 주소를 유지합니다. 이 분리를 제대로 하면 로테이션은 체크박스에서 설계 결정이 됩니다.
공인 주소는 실제로 어디에서 오는가
대상이 보는 주소는 당신의 트래픽이 마지막으로 나간 곳이며, 가정용 연결에서는 라우터에 있는 통신사 주소이지 기기가 가진 무언가가 아닙니다. 라우터를 다시 시작하면 같은 임대가 돌아올 수 있고 MAC 주소를 바꾸면 때때로 새것이 생기지만, 둘 다 국가 선택기를 주지는 않습니다. VPN은 IP 계층에서 출발지 주소를 바꾸므로 DNS와 백그라운드 업데이트를 포함한 기기의 모든 패킷이 터널 끝점에서 나갑니다. 프록시는 한 계층 위에서 동작하며 요청을 받아 대상으로 자기 연결을 열고, 그 요청만 출구에서 보입니다. 기기의 다른 모든 것은 여전히 실제 주소를 씁니다.
이 분리가 대부분의 놀라움을 설명합니다. 프록시를 향한 브라우저 확장은 브라우저가 보내는 것만 바꾸고 다른 것은 바꾸지 않으므로, 같은 호스트의 두 번째 애플리케이션은 여전히 원래 주소를 흘립니다. 시스템 전체 VPN은 반대의 실패 모드로, 로컬에 두고 싶었던 트래픽까지 덮고 클라이언트가 그렇게 설정된 경우에만 닫힙니다. 둘 중에서 고르는 것은 어떤 트래픽이 움직여야 하는지를 고르는 일입니다.
그다음 로테이션은 선택한 계층에 적용됩니다. 프록시라면 로테이션은 다음 요청이 다른 출구를 쓴다는 뜻입니다. VPN이라면 터널을 허물고 다시 세우는 뜻이며, 더 느리고 눈에 보이는 재연결로 나타납니다.
HTTP 프록시가 읽을 수 있는 것과 없는 것
평문 HTTP에서 프록시는 요청 줄의 절대 URI, 모든 헤더와 본문을 봅니다. 그 모두를 기록하고 어느 부분이든 다시 쓸 수 있으며, 무료 프록시가 응답에 스크립트를 주입하는 것은 프로토콜이 허용하는 일을 그대로 하는 것입니다. 인증에는 Proxy-Authorization을 사용하며, 자격 증명이 없거나 틀리면 연결 오류가 아니라 407 Proxy Authentication Required 을 반환합니다.
HTTPS에서는 클라이언트가 CONNECT host:port 을 보내고 프록시는 원시 터널을 열며, 그 뒤에는 암호화된 바이트를 봅니다. 프록시는 여전히 CONNECT 줄에서, 보통은 TLS 핸드셰이크의 SNI 필드에서 호스트 이름을 알므로 페이로드가 남지 않아도 호스트 이름 수준 기록은 남습니다. 페이로드를 읽으려면 클라이언트가 신뢰하는 인증서로 TLS를 종료해야 하며, 그것은 다른 위험을 가진 다른 제품입니다. 그리고 HTTP 시맨틱스 명세 는 CONNECT를 터널 요청으로 정의하며, 출구가 무엇을 볼 수 있고 없는지에 대한 올바른 사고 모델입니다.
curl -v -x http://proxy.example.net:8080 https://example.com 2>&1 | grep -E 'CONNECT|Proxy-'
상세 출력은 어떤 TLS 트래픽보다도 먼저 CONNECT 줄을 보여 주며, 그 순간 프록시가 목적지를 알게 됩니다. 407로 응답하는 프록시는 터널을 연 적이 없으므로 다른 TLS 설정으로 다시 시도해도 도움이 되지 않습니다.
로테이션의 세분성이 무엇이 깨지는지를 결정합니다
매 요청마다 돌리는 것은 가장 안전해 보이면서 가장 많이 깨뜨리는 설정입니다. 쿠키, CSRF 토큰, 서버 측 세션은 하나의 신원에 묶여 있고, 로그인과 다음 호출 사이에 바뀌는 신원은 대상에게 세션 탈취처럼 보입니다. 많은 제공자가 프록시 사용자 이름에 세션을 인코딩해 끈적한 세션을 제공하므로, 선택한 창 동안 출구가 고정됩니다.
세분성은 작업에서 고르고 제공자의 기본값에서 고르지 마세요. 독립 페이지를 가져오는 크롤러는 요청마다 돌 수 있지만, 결제 흐름이나 인증된 API는 전체 흐름 동안 하나의 출구를 유지해야 합니다. 아래 두 호출은 끈적한 사용자 이름과 단순한 회전 엔드포인트를 보여 주며, socks5h 스킴은 이름을 로컬이 아니라 프록시에서 해석합니다.
curl -sS -x http://user-session-a1b2:[email protected]:8080 https://ifconfig.me
curl -sS -x socks5h://127.0.0.1:1080 https://ifconfig.me
로컬 DNS는 조용한 누출입니다. 클라이언트가 연결 전에 이름을 해석하면 HTTP 요청이 다른 곳에서 나가도 리졸버는 방문하는 모든 호스트를 압니다. 그리고 socks5h 형태와 프록시 측 해석이 그것을 피하며, 그것을 쓰는 데는 아무 비용도 들지 않습니다.
대상은 주소 외에 무엇을 분류하는가
주소 평판은 여러 입력 중 하나입니다. 대상은 ASN과 그 데이터 센터 또는 주거 라벨, 클라이언트의 TLS 지문, HTTP/2 설정, 헤더 순서, 요청 빈도, 탐색의 형태를 결합합니다. 헤드리스 브라우저가 이끄는 주거 출구는 실제 세션이 이끄는 데이터 센터 출구가 통과하는 곳에서 실패할 수 있습니다.
출구 유형은 트래픽에 대해 정직하게 무엇을 주장할 수 있는지를 정하며, 각각 다른 비용을 수반합니다.
| Exit type | What the target sees | Main cost |
|---|---|---|
| Datacenter proxy | Hosting ASN, cheap, often pre-blocked | Low reputation, easy to detect |
| Residential network | A consumer ISP address belonging to someone else | Consent and terms-of-service exposure |
| Mobile carrier | A carrier NAT address shared by many subscribers | Price, plus shared blame for abuse |
| Your own cloud egress | An address you are accountable for | Recognisable, but defensible |
공유 출구는 중립적이지 않습니다. 그 주소에서 도는 다른 모든 것은 같은 평판 통에 들어가고, 다른 임차인이 이미 태운 주소는 당신의 첫 요청이 읽히기 전에 실패합니다.
정책에서 설명할 수 있는 출구를 고르세요
유용한 질문은 주소를 어떻게 숨기느냐가 아니라 그곳에서 나가는 트래픽에 누가 책임이 있느냐입니다. 작업마다의 자체 클라우드 출구, 데이터 처리 계약과 공개된 보존 기간을 갖춘 계약 제공자, 작업마다 하나의 신원을 가진 자체 호스팅 VPN은 모두 한 문장으로 설명할 수 있습니다. 무료 목록은 아니며, 운영자에게 당신에 대한 의무가 없고 기록할 동기만 있기 때문입니다.
자체 속도 한도를 대상이 견디는 수준보다 낮게 유지하고, 작업에 필요한 필드만 모아 실수를 작게 유지하세요. 차단을 피하려고 더 빨리 돌리면 보통 그것을 일으킨 요청 빈도가 올라갑니다.
작성하세요 선택한 출구, 그 로테이션 창, 그 소유자를 첫 실행 전에 작업 구성에. 차단이 오면 그 메모가 출구를 바꿀지 행동을 바꿀지 알려 줍니다.