ProxyCompass 지식 베이스

프록시 인증: IP 허용 목록과 사용자 이름·비밀번호

프록시 인증은 애플리케이션이 프록시 서비스를 사용해도 되는지 확인합니다. 보통 프록시 주소와 포트만 알아서는 부족합니다. 서비스는 접속 가능한 다른 시스템과 허용된 클라이언트를 구분해야 합니다. 이를 통해 구매한 프록시의 사용을 허가한 클라이언트로 제한합니다.

두 가지 일반적인 방법은 서로 다른 근거를 사용합니다. IP 인증은 연결이 어디에서 오는지 확인합니다. 사용자 이름·비밀번호 인증은 애플리케이션이 인증 정보를 보냅니다. 첫 방식은 접속을 네트워크 주소에 연결하고, 두 번째는 애플리케이션이 다른 네트워크로 옮겨도 접속을 유지할 수 있게 합니다. 서비스가 두 조건을 함께 요구할 수도 있습니다.

이 선택은 접속 방식, 사용할 수 있는 애플리케이션, 작업 환경이 바뀔 때의 동작에 영향을 줍니다. 프록시 구성 선택의 별도 요소입니다. 인증은 출구 IP가 데이터센터인지 주거용인지, 고정인지 순환인지를 결정하지 않습니다. 그 IP를 제공하는 서비스를 누가 사용할 수 있는지 결정합니다.

두 인증 방식의 작동 원리

IP 인증: 연결 출발지에 대한 허가

IP 인증에서는 클라이언트 주소를 업체의 허용 목록에 추가합니다. 흔히 화이트리스트 또는 허용 목록이라고 합니다. 연결이 도착하면 프록시는 출발지 IP를 목록과 비교합니다. 일치하고 다른 접속 조건도 충족되면 애플리케이션이 별도의 프록시 사용자 이름과 비밀번호를 보내지 않고 사용할 수 있습니다.

인터넷 프록시에서 해당 주소는 일반적으로 네트워크의 공인 출구 IP입니다. 애플리케이션이 프록시에 도달할 때 사용하는 주소이며, 나중에 프록시가 웹사이트에 보여 주는 출구 IP가 아닙니다. 고정 프록시를 구매한다고 가정용 연결까지 고정되는 것은 아닙니다. 이 주소들은 경로의 다른 부분에 속합니다.

허용된 출발지가 같으면 편리하게 계속 이용할 수 있습니다. 프로그램을 다시 시작하거나 다른 허용 기기가 같은 네트워크로 연결해도 개별 프록시 비밀번호가 필요하지 않습니다. 출구 IP가 바뀌면 기존 허가가 새 주소에 자동으로 적용되지는 않습니다. IP 인증 가이드에서는 올바른 출발지 주소를 찾고 허용 목록을 관리하는 방법을 설명합니다.

사용자 이름과 비밀번호: 애플리케이션이 보내는 허가 정보

이 방식에서는 업체가 프록시 이용용 인증 정보를 발급합니다. 애플리케이션은 지원되는 프록시 프로토콜의 일부로 이를 보냅니다. 브라우저가 사용자에게 입력을 요청할 수도 있고, 스크립트가 로그인 창 없이 설정에서 읽어 보낼 수도 있습니다.

인증 정보만이 유일한 인증 요건이라면 애플리케이션이 네트워크를 옮겨도 접속 권한이 따라갈 수 있습니다. 같은 구성을 새 출발지 IP에서도 계속 사용할 수 있습니다. 작업 실행 위치가 프록시 설정보다 자주 바뀔 때 유용합니다.

이 인증 정보는 프록시와의 연결에 사용됩니다. 자동으로 업체 대시보드의 비밀번호가 되는 것은 아니며 대상 웹사이트에 로그인해 주지도 않습니다. 대상 사이트에는 자체 로그인과 접속 규칙이 적용됩니다. 사용자 이름·비밀번호 인증 가이드에서는 연결 필드, 지원 클라이언트, 인증 정보 형식을 다룹니다.

IP 인증과 사용자 이름·비밀번호 비교

아래는 두 방식을 별도로 비교합니다. 여기서 비밀번호 접속은 추가 IP 제한이 없는 방식을 뜻하며, 결합 접속은 뒤에서 설명합니다.

어느 방식도 서비스의 출구 IP 수를 결정하지 않습니다. 허용된 클라이언트 IP 하나나 인증 정보 한 쌍으로 많은 프록시에 접속할 수 있습니다. 어느 방식도 무제한 연결을 제공하거나 출구 주소를 한 고객만의 전용 주소로 만들지는 않습니다.

애플리케이션과 네트워크에 맞는 선택

먼저 애플리케이션이 제공된 인증 방식을 쓸 수 있는지 확인하세요

프록시 프로토콜을 지원해도 그 프로토콜의 모든 인증 옵션을 지원하는 것은 아닙니다. 주소와 포트 필드만 있다고 사용자 이름과 비밀번호를 보낼 수 있는 것은 아닙니다. 예를 들어 Chrome의 기본 SOCKS5 기능은 SOCKS5 사용자 이름·비밀번호 인증을 지원하지 않습니다. 올바른 인증 정보도 빠진 클라이언트 기능을 대신할 수 없습니다.

필요한 애플리케이션이 프로토콜은 지원하지만 인증 정보를 보내지 못한다면 IP 인증으로 사용할 수 있습니다. 그래도 허용된 출발지 주소가 필요합니다. 그 주소가 자주 바뀐다면 IP 접속으로 인증 정보 문제는 해결해도 출발지 주소 관리는 남습니다. 필요한 인증을 지원하는 클라이언트나 안정적인 네트워크 출구가 필요할 수도 있습니다.

따라서 구매 전에 구체적으로 확인해야 합니다. 이 애플리케이션이 이 프록시 프로토콜과 이 인증 방식을 함께 사용할 수 있나요? 다른 브라우저나 명령줄 도구에서 성공했다고 이 질문까지 해결되는 것은 아닙니다.

그다음 구성에서 무엇이 자주 바뀌는지 살펴보세요

IP 인증은 네트워크 출구가 안정적이고 통제 가능한 작업에 적합합니다. 출구를 허용해 두면 뒤쪽 프로그램이 바뀌어도 새 프로세스마다 프록시 인증 정보를 배포할 필요가 없습니다. 서비스의 접속 설정이 작업에서 사용하는 네트워크에 연결됩니다.

인증 정보는 실행 위치가 바뀌는 작업에 적합합니다. 다른 서버로 작업을 옮기거나 다른 네트워크에서 새 워커가 시작돼도 서비스가 IP 바인딩 없이 인증 정보를 허용하면 출발지마다 목록을 바꿀 필요가 없습니다. 프록시 설정이 애플리케이션과 함께 이동할 수 있습니다.

중요한 것은 기기를 노트북, VPS, 클라우드 서버 중 무엇이라 부르는지가 아니라 공인 출발지가 얼마나 자주 바뀌는지입니다. 노트북도 고정된 사무실 출구 뒤에 있을 수 있고 서버 배포도 여러 공인 주소 사이에서 바뀔 수 있습니다. 실제 연결 경로와 평소 예상되는 변경에 맞춰 선택하세요.

둘 다 가능하다면 유지 관리가 쉬운 방식을 고르세요

누가 설정을 관리할지 고려하세요. 여러 애플리케이션이 공유하는 고정 출구를 통제하는 네트워크 관리자는 출발지 허가 하나로 접속을 관리할 수 있습니다. 환경 사이에 작업을 옮기지만 공인 IP는 통제하지 못하는 개발자라면 IP 바인딩 없는 인증 정보가 더 편할 수 있습니다.

선택에 필요한 추가 자원도 포함하세요. 고정 공인 IP, 허용 목록 추가 항목, 관리형 게이트웨이에 비용이 들 수 있습니다. 비밀번호 접속으로 이를 피할 수도 있지만 필요한 네트워크에서 작동해야 합니다. 실제 서비스 옵션을 비교하세요. 비밀번호가 있다고 프록시가 자동으로 저렴해지는 것은 아닙니다.

결합 인증: IP와 비밀번호

업체는 IP 접속과 비밀번호 접속을 대안으로 제공하거나 함께 요구할 수 있습니다. 서로 다른 구성입니다. 결합 모드에서는 유효한 인증 정보와 함께 허용 주소나 네트워크에서 연결해야 합니다. 올바른 비밀번호만으로도, 허용된 출발지만으로도 부족합니다.

사용자 이름과 비밀번호 필드가 필요한 애플리케이션을 사용하면서 접속 출발지도 제한할 때 적합할 수 있습니다. 복사된 인증 정보가 허용 네트워크 밖에서 쓰이는 것도 제한할 수 있습니다. IP 바인딩 없는 비밀번호 접속처럼 임의의 네트워크 사이를 자유롭게 이동할 수 있는 것은 아닙니다.

ProxyCompass 고정 패키지의 결합 모드는 허용 목록에 추가한 IP와 같은 /24 서브넷에 속하는 공인 클라이언트 IPv4에서 유효한 인증 정보를 받아들입니다. 이 주소들은 앞의 세 숫자가 같습니다. 따라서 목록 항목 하나로 같은 서브넷의 여러 클라이언트 주소가 인증 정보를 사용할 수 있습니다. 구매한 출구 IP가 아니라 서비스에 연결하는 클라이언트에 적용되는 규칙입니다. 위의 사용자 이름·비밀번호 가이드에서 연결 예시를 볼 수 있습니다.

어느 방식이 접속을 더 잘 통제하나요?

IP 인증은 네트워크 출구를 기준으로 접속을 결정합니다. 프록시 주소만 얻은 사람은 승인되지 않은 다른 출발지에서 사용할 수 없습니다. 그러나 같은 허용 IP를 공유한다는 사실만으로 개개인을 식별할 수는 없습니다. 여러 이용자가 같은 공인 주소로 접속하면 IP 검사에는 모두 같은 출발지로 보입니다. 여러 사람이 쓰는 사무실 출구나 인터넷 가입자 사이에 공유되는 공인 주소에서 중요합니다.

사용자 이름·비밀번호 인증은 위치와 별도로 애플리케이션이 제시하는 인증 정보에 접속 권한을 둡니다. 서로 관계없는 네트워크 사이에서 잘 작동합니다. 반대로 유효한 인증 정보가 든 설정을 복사하면 다른 곳에서도 사용할 수 있다는 의미입니다. 업체가 이용자나 작업마다 별도 인증 정보를 제공한다면 더 세밀한 접속 관리가 가능합니다. 모두가 공유하는 비밀번호 하나로는 이런 구분이 생기지 않습니다.

따라서 어느 쪽을 더 확실히 통제할 수 있는지에 따라 선택합니다. 허용된 네트워크 출구 뒤의 시스템 집단인지, 애플리케이션에 제공하는 인증 정보인지입니다. 결합 접속은 두 조건을 모두 요구하므로 유효한 인증 정보가 있어도 사용할 수 있는 위치를 제한합니다.

접속 통제와 암호화는 별개입니다. IP 인증이 트래픽을 암호화하지 않으며 비밀번호가 자동으로 암호화 연결을 만들지도 않습니다. 전송 중 인증 정보를 보호하려면 클라이언트와 프록시 사이의 연결 자체를 보호해야 합니다. 프록시로 HTTPS 웹사이트를 연다는 사실만으로 그 전에 프록시와 암호화 없이 교환한 로그인 정보까지 보호되지는 않습니다.

IP 인증을 쓰면 프록시가 더 빠른가요?

IP 접속은 인증 정보 교환을 생략할 수 있지만 HTTP와 SOCKS의 연결 설정 과정은 다릅니다. SOCKS5의 사용자 이름·비밀번호 인증은 설정 중 요청과 응답을 추가합니다. HTTP 클라이언트는 인증 요구를 기다렸다가 요청을 다시 보내거나 처음부터 적절한 인증 정보를 보낼 수 있습니다. 따라서 비밀번호 접속이 항상 네트워크 왕복을 추가하는 것은 아닙니다.

이 차이는 적은 작업을 위해 새 연결을 반복 생성할 때 가장 크게 작용합니다. 이미 설정된 연결을 재사용하면 영향이 작습니다. 예를 들어 기존 HTTPS 터널로 같은 웹사이트의 페이지를 더 요청할 때 터널 설정에 썼던 프록시 로그인을 반복하지 않습니다. 이는 연결 설정 비용이지 프록시 데이터 전송 속도의 일정한 감소가 아닙니다.

두 방식 모두 구성에 맞는다면 같은 프로토콜, 비슷한 프록시 자원, 실제 연결 패턴으로 비교하세요. 요청마다 새 연결을 여는 테스트와 연결을 재사용하는 테스트는 다른 질문에 답합니다. 이런 비교 없이 특정 인증 방식이 언제나 빠르다는 주장은 서비스 선택에 별 도움이 되지 않습니다.

인증으로 해당 주소가 프록시라는 사실이 드러날 수 있나요?

그럴 수 있습니다. 비밀번호로 무단 이용은 막아도 외부 시스템이 서비스를 알아보게 할 수 있습니다. 예를 들어 검사기가 유효한 인증 정보 없이 HTTP 프록시 주소와 포트에 접속할 수 있습니다. 407 Proxy Authentication Required 응답과 그 안의 Proxy-Authenticate 헤더는 프록시 인증이 필요하다는 사실을 명확히 드러냅니다. 검사기는 그 증거를 받기 위해 비밀번호를 알 필요가 없습니다.

IP 제한 서비스가 알아볼 수 있는 프록시 응답을 보내기 전에 미승인 출발지를 차단한다면 드러나는 정보가 적을 수 있습니다. 그러나 허용 목록만으로 그 동작이 보장되지는 않습니다. 서버가 특징적인 거절 응답을 보낼 수도 있습니다. 비밀번호로 보호된 엔드포인트에도 네트워크 필터링이 있을 수 있습니다. 실제 차이는 외부 연결이 어디까지 도달하며 어떤 응답을 받는지에 있습니다.

검사하는 주소도 중요합니다. 프록시 입구 주소와 출구 IP가 같으면 식별 가능한 응답으로 웹사이트에 보이는 주소를 알아낼 수 있습니다. 서로 다른 출구 IP를 쓰는 게이트웨이는 그 자체를 식별했다고 풀 안의 모든 출구가 식별되는 것은 아닙니다.

일반적인 탐색 중 대상 웹사이트가 프록시의 로그인 요구를 자동으로 받는 것은 아닙니다. 그 교환은 클라이언트와 프록시 사이에서 이루어집니다. 사이트나 탐지 서비스에는 별도 주소 검사 등을 포함한 다른 증거가 필요합니다. 따라서 인증 방식만 바꾼다고 IP가 프록시로 식별되지 않게 하거나 이미 알려진 정보를 없앤다고 약속할 수는 없습니다.