VPN과 프록시: 각각 무엇을 다루고 무엇을 다루지 않는가

VPN과 포워드 프록시는 모두 웹사이트가 보는 주소를 바꾸며, 대부분의 비교는 거기서 끝납니다. 설정을 결정하는 차이는 적용 범위입니다. 포워드 프록시는 앱이 스스로 사용하기로 선택하는 중개자이며, 웹사이트 앞에 서는 리버스 프록시와는 다릅니다. 반면 VPN은 운영체제가 터널로 라우팅하는 모든 것을 옮깁니다. 암호화, DNS 처리, 장애 시 동작은 모두 이 구분에서 나옵니다. 다음 다섯 가지 점검을 순서대로 수행하고, 처음 실패하는 항목이 실제로 필요한 도구를 알려 줄 것입니다.

그 중개자는 어떤 앱을 다루는가?

브라우저 프록시 확장은 해당 브라우저 프로필에만 적용됩니다. 메일 클라이언트, 패키지 관리자, 두 번째 브라우저는 각자의 설정을 계속 사용하며, 일부 앱은 시스템 프록시 변수를 완전히 무시합니다. VPN은 라우팅 테이블이 터널로 보내는 것을 다루며, 이는 경로와 클라이언트 정책에 따라 모든 앱일 수도, 분할 터널의 일부일 수도 있습니다.

한 번의 페이지 로드에서 일반화하지 말고 중요한 앱을 시험하세요. curl https://ifconfig.me는 환경의 프록시 변수를 따르지만, 데스크톱 앱은 따르지 않을 수 있습니다. Windows에서는 netsh winhttp show proxy가 서비스가 사용하는 WinHTTP 프록시를 출력하며, 이는 브라우저 설정과 다른 설정입니다.

그 홉은 암호화되는가, TLS는 어디서 끝나는가?

프록시 프로토콜은 만남의 장소이지 보장이 아닙니다. SOCKS5는 TCP를 암호화하지 않고 전달하고, 평문 HTTP 프록시는 요청 줄과 헤더를 그대로 나릅니다. 프록시를 통한 HTTPS는 CONNECT를 사용하므로 TLS 세션은 프록시가 아니라 목적지에서 끝납니다. 프록시 서버와 터널링에 관한 MDN 안내서가 프로토콜 측에서 그 차이를 설명합니다.

VPN은 기기와 그 엔드포인트 사이 구간을 암호화합니다. 엔드포인트 너머에서는 다른 네트워크와 같은 규칙이 적용되므로, 터널만으로는 평문 HTTP로 자격 증명을 보내는 앱을 보호하지 못합니다. 두 설계 모두 로그인된 계정, 쿠키, 브라우저 지문을 숨기지 않습니다.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

자세한 출력은 curl이 443 포트로 CONNECT를 보냈는지, 전체 URL로 일반 GET을 보냈는지 보여 줍니다. socks5h://에서는 호스트 이름이 SOCKS5 요청 안에서 프록시에 전달되고, 프록시는 읽을 수 없는 TLS를 중계하므로 이름과 바이트 수만 봅니다. http:// 프록시를 통하면 https:// URL은 CONNECT이므로 그 프록시도 목적지 이름과 양은 보지만 요청이나 응답 본문은 보지 못합니다.

어느 리졸버가 이름을 보는가?

이름 해석은 요청이 나가기 전에 로컬에서 일어날 수도, 프록시에서 원격으로 일어날 수도 있습니다. curl에서는 socks5h://가 호스트 이름을 프록시로 보내고, socks5://는 먼저 로컬에서 해석합니다. 브라우저 프록시 설정에도 비슷한 DNS 옵션이 있으며, PAC 파일은 호스트마다 다른 경로를 선택할 수 있습니다.

두 프로토콜은 설정 오류 없이도 프록시를 우회할 수 있습니다. WebRTC는 STUN으로 후보를 모으고, QUIC는 HTTP/3를 UDP 위에서 실행하는데 TCP 프록시는 이를 나를 수 없습니다. UDP 443이 차단되어 있으면 브라우저는 TCP로 되돌아가므로, HTTP/3를 프록시 경로 안에 두는 확실한 방법은 브라우저 플래그가 아니라 호스트 방화벽(네트워크 전체라면 라우터)에서 UDP 443을 차단하는 것입니다.

리졸버는 노트북의 관점이 아니라 목적지의 관점에서 확인하세요. 프록시의 출구 주소로 도착했지만 이름이 로컬에서 해석된 요청은 여전히 로컬 리졸버에게 어떤 사이트를 방문하는지 알려 줍니다.

중개자가 실패하면 어떻게 되는가?

명시적 프록시는 닫힌 방식으로 실패하며, 프록시 프로세스를 멈추면 브라우저나 앱은 직접 나가지 않고 연결 오류를 반환합니다. 열린 방식으로 실패하는 것은 PAC와 WPAD 설정입니다. 스크립트를 가져올 수 없으면 클라이언트는 DIRECT로 돌아가고 사이트는 다시 실제 주소를 봅니다. VPN은 클라이언트와 킬 스위치 또는 방화벽 규칙의 활성 여부에 따라 열린 방식으로도 닫힌 방식으로도 실패할 수 있습니다.

실패 사례를 일부러 시험하세요. 프록시 서비스를 멈추고 다시 로드하여, 직접 로드 대신 오류 페이지가 나오면 PAC URL을 도달할 수 없는 호스트로 지정해 폴백을 확인합니다. 그래도 평소 경로로 페이지가 로드된다면 그 프록시는 자체 장애에 대한 보호를 전혀 제공하지 않으며, 의존하기 전에 알아야 할 성질입니다.

순서가 사이트가 보는 것을 결정합니다. 아웃바운드가 VPN을 거치는 프록시는 사이트에 VPN 엔드포인트 주소를 보여 줍니다. 프록시를 터널 밖에 두면(원격 호스트의 프록시로 VPN) 사이트는 대신 그 프록시의 출구 주소를 봅니다. 어느 쪽이든 두 홉은 서로 다른 것을 기록할 수 있습니다.

다섯 가지 점검, 순서대로

아래 체크리스트가 판단 전체를 한곳에 모은 것입니다. 적용 범위를 맨 앞에 두는 이유는 대부분의 불일치를 없애기 때문입니다. 다뤄야 할 앱이 설정을 존중하지 않으면 목록 뒤쪽의 무엇도 그것을 구하지 못합니다.

다음으로 변경을 일으킨 앱으로 결과를 확인하세요. 설정한 브라우저에서 페이지를 로드하고, 같은 페이지를 curl로 가져와, 각각이 보고하는 주소를 비교합니다. 서로 다르다면 확장 프로그램, PAC 규칙, 앱 수준 재정의 중 하나가 아직 작동 중이며, 터널 조정으로는 고칠 수 없습니다.

무엇을 설정했는지, 즉 어떤 앱이 프록시를 쓰는지, DNS가 로컬인지 원격인지, UDP가 차단되었는지, 장애 시 동작은 무엇인지 기록하세요. 이 작은 목록이 다음 비교를 가능하게 합니다. “IP가 바뀌었다”만으로는 이 다섯 가지 점검 중 무엇이 통과했는지 알 수 없었기 때문입니다.