Base de conhecimento da ProxyCompass
Autenticação de proxy: lista de IPs permitidos ou nome de usuário e senha?
A autenticação de proxy verifica se sua aplicação pode usar um serviço de proxy. Saber o endereço e a porta do proxy geralmente não basta: o serviço também precisa distinguir os clientes permitidos de outros sistemas que conseguem acessá-lo. Isso restringe o uso dos proxies comprados aos clientes que você autoriza.
Os dois métodos comuns usam evidências diferentes. Na autenticação por IP, o proxy verifica de onde vem a conexão. Na autenticação com nome de usuário e senha, a aplicação fornece credenciais. O primeiro método vincula o acesso a um endereço de rede; o segundo pode permitir que a aplicação mantenha o acesso ao mudar para outra rede. Um serviço também pode exigir as duas condições ao mesmo tempo.
Essa escolha afeta a forma de conexão, as aplicações que você pode usar e o que acontece quando seu ambiente de trabalho muda. Ela é uma parte específica da escolha de uma configuração de proxy: a autenticação não determina se o IP de saída é de datacenter ou residencial, estático ou rotativo. Ela determina quem pode usar o serviço que fornece esse IP.
Como funcionam os dois métodos de autenticação
Autenticação por IP: permissão para uma origem de conexão
Na autenticação por IP, você adiciona um endereço do cliente à lista de IPs permitidos do provedor, frequentemente chamada de whitelist ou allowlist. Quando chega uma conexão, o proxy compara o IP de origem com essa lista. Se houver correspondência e as outras condições de acesso do serviço forem atendidas, a aplicação poderá usar o proxy sem enviar um nome de usuário e uma senha de proxy separados.
Para um proxy na internet, o endereço relevante normalmente é o IP público de saída da sua rede. É o endereço a partir do qual sua aplicação chega ao proxy, e não o IP de saída que o proxy apresenta depois aos sites. Comprar um proxy estático não torna estática sua conexão de casa: esses endereços pertencem a partes diferentes do percurso.
Assim, o acesso continua prático enquanto a origem permitida permanece igual. Um programa pode ser reiniciado ou outro dispositivo permitido pode se conectar por essa rede sem precisar de uma senha de proxy própria. Se o IP de saída mudar, a permissão antiga não abrangerá automaticamente o novo endereço. O guia de autenticação por IP explica como identificar o endereço de origem correto e gerenciar sua lista de IPs permitidos.
Nome de usuário e senha: permissão fornecida pela aplicação
Na autenticação com nome de usuário e senha, o provedor emite credenciais para usar o proxy. A aplicação as envia como parte do protocolo de proxy compatível. Um navegador pode pedir que o usuário as digite; um script pode fornecê-las a partir da configuração, sem exibir uma janela de login.
Quando as credenciais são o único requisito de autenticação, o acesso pode acompanhar a aplicação entre redes. A mesma configuração que já funciona pode continuar se conectando a partir de um novo IP de origem. Isso é útil quando o local de execução de uma tarefa muda com mais frequência do que suas configurações de proxy.
As credenciais pertencem à conexão com o proxy. Elas não são automaticamente a senha do painel do provedor e não fazem login no site de destino. Esse site continua aplicando suas próprias regras de login e acesso. O guia de autenticação com nome de usuário e senha aborda os campos de conexão, os clientes compatíveis e os formatos das credenciais.
Autenticação por IP versus nome de usuário e senha
A comparação abaixo descreve os dois métodos separadamente. Aqui, acesso por senha significa acesso sem restrição adicional de IP; o acesso combinado é explicado mais adiante.
| O que muda na prática | Autenticação por IP | Nome de usuário e senha |
|---|---|---|
| Base do acesso | Uma conexão deve chegar de um IP de origem permitido. | A aplicação deve fornecer credenciais de proxy válidas. |
| Configurações da aplicação | Não são necessárias credenciais de proxy, mas ainda é preciso usar o protocolo, o endereço e a porta corretos do proxy. | A aplicação deve ser compatível com a troca de credenciais do proxy. |
| Mudança para outra rede | A nova origem já deve estar permitida ou ser adicionada à lista. | As mesmas credenciais podem funcionar na nova rede. |
| Várias aplicações | As aplicações que usam a mesma saída de rede permitida compartilham a permissão desse IP. | Cada aplicação deve enviar credenciais aceitas pelo serviço; várias aplicações podem usar o mesmo par, se isso for permitido. |
| O que o vazamento de um endereço de proxy revela | O endereço e a porta, por si só, não atendem à verificação do IP de origem a partir de uma rede não aprovada. | Uma configuração completa com credenciais válidas pode conceder acesso a partir de outra rede. |
| O que você mantém | Os endereços de origem permitidos e os caminhos de rede que os usam. | As credenciais e as aplicações configuradas para enviá-las. |
Nenhum dos métodos determina o número de IPs de saída do serviço. Um IP de cliente permitido ou um conjunto de credenciais pode dar acesso a muitos proxies. Nenhum deles dá a esses proxies conexões ilimitadas ou torna seus endereços de saída exclusivos de um cliente.
Como escolher para sua aplicação e sua rede
Primeiro, verifique se a aplicação consegue usar o método oferecido
Um programa pode ser compatível com um protocolo de proxy sem oferecer todas as opções de autenticação desse protocolo. Campos de endereço e porta, por si só, não demonstram que o programa consegue enviar nome de usuário e senha. Por exemplo, a compatibilidade nativa do Chrome com SOCKS5 não inclui autenticação SOCKS5 com nome de usuário e senha. Credenciais corretas não superam essa capacidade ausente no cliente.
Se a aplicação necessária for compatível com o protocolo oferecido, mas não conseguir enviar suas credenciais, a autenticação por IP pode fornecer uma forma viável de acesso. Isso ainda exige um endereço de origem permitido. Quando esse endereço muda com frequência, passar para o acesso por IP resolve o problema das credenciais, mas mantém o problema do endereço de origem a ser gerenciado. Talvez você precise de um cliente compatível com a autenticação necessária ou de uma saída de rede estável.
A verificação útil antes da compra é, portanto, específica: esta aplicação consegue usar este protocolo de proxy com este método de autenticação? O sucesso em outro navegador ou em uma ferramenta de linha de comando não responde a essa pergunta.
Depois, considere o que costuma mudar na sua configuração
A autenticação por IP é adequada a uma tarefa cuja saída de rede é estável e controlada. Depois que essa saída é permitida, trocar o programa que a utiliza não exige distribuir credenciais de proxy a cada novo processo. As configurações de acesso do serviço continuam vinculadas à rede usada pela tarefa.
As credenciais são adequadas a uma tarefa cujo local de execução muda. Se uma tarefa for transferida para outro servidor ou novos processos de trabalho forem iniciados em redes diferentes, o acesso não exigirá uma alteração separada na lista de IPs permitidos para cada origem, desde que o serviço aceite credenciais sem vínculo com IP. A configuração do proxy pode acompanhar a aplicação.
A distinção importante é a frequência com que a origem de saída muda, e não se você chama a máquina de notebook, VPS ou servidor em nuvem. Um notebook pode permanecer atrás de uma saída fixa do escritório; uma implantação de servidores pode alternar entre endereços públicos. Escolha com base no caminho real da conexão e nas mudanças esperadas durante o trabalho normal.
Se os dois métodos funcionarem, escolha a configuração mais simples de manter
Considere quem manterá as configurações. Um administrador de rede que controla uma saída fixa compartilhada por várias aplicações pode gerenciar o acesso por meio de uma única permissão de origem. Um desenvolvedor que transfere tarefas entre ambientes, mas não consegue controlar seus IPs públicos, pode achar mais fácil manter credenciais sem vínculo com IP.
Inclua os recursos extras exigidos pela escolha. Um IP público fixo, entradas adicionais na lista de IPs permitidos ou um gateway gerenciado podem ter custo. O acesso por senha pode evitar esses custos, mas somente se funcionar a partir das redes necessárias. Compare as opções reais do serviço; a presença de uma senha, por si só, não torna um proxy mais barato.
Autenticação combinada: IP e senha
Um provedor pode oferecer o acesso por IP e o acesso por senha como alternativas ou exigir os dois juntos. São configurações diferentes. No modo combinado, credenciais válidas só são aceitas quando a conexão também vem de um endereço ou de uma rede permitidos. Apenas uma senha correta não basta, e apenas uma origem permitida também não basta.
Isso pode ser adequado a aplicações que exigem campos de nome de usuário e senha, mantendo uma restrição sobre a origem do acesso. Também pode limitar o uso de credenciais copiadas fora da rede permitida. Não oferece a mesma liberdade de transitar entre quaisquer redes que o acesso por senha sem vínculo com IP.
Nos pacotes estáticos da ProxyCompass, o modo combinado aceita credenciais válidas de endereços IPv4 públicos de clientes na mesma sub-rede /24 de um IP adicionado à whitelist. Esses endereços têm os mesmos três primeiros números. Assim, vários endereços de clientes nessa sub-rede podem usar as credenciais por meio de uma única entrada na whitelist. Essa regra diz respeito aos clientes que se conectam ao serviço, e não aos IPs de saída comprados. O guia de nome de usuário e senha indicado acima mostra os exemplos de conexão.
Qual método oferece melhor controle de acesso?
A autenticação por IP coloca a decisão de acesso na saída da rede. Alguém que obtiver apenas o endereço do proxy não poderá usá-lo de uma origem diferente, não aprovada. Mas o proxy não consegue identificar pessoas individualmente apenas porque elas compartilham um IP permitido. Se vários usuários chegam ao proxy pelo mesmo endereço público, a verificação de IP vê a mesma origem para todos. Isso é relevante para saídas compartilhadas de escritórios e endereços públicos compartilhados entre assinantes de internet.
A autenticação com nome de usuário e senha coloca a permissão em credenciais que as aplicações podem apresentar independentemente da localização. Isso funciona bem em redes sem relação entre si. Também significa que uma configuração copiada com credenciais válidas pode continuar utilizável em outro lugar. Quando um provedor oferece credenciais separadas para usuários ou tarefas diferentes, elas podem permitir um gerenciamento de acesso mais detalhado; uma senha compartilhada por todos não cria essa separação.
A escolha depende, portanto, do que você controla com mais segurança: o grupo de sistemas atrás de uma saída de rede permitida ou as credenciais fornecidas às aplicações. O acesso combinado exige as duas condições, restringindo os locais de onde até mesmo credenciais válidas podem ser usadas.
Controle de acesso e criptografia são questões separadas. A autenticação por IP não criptografa o tráfego, e uma senha não cria automaticamente uma conexão criptografada. Proteger as credenciais em trânsito exige proteção na própria conexão entre o cliente e o proxy. Abrir um site HTTPS por um proxy, por si só, não protege uma troca anterior de login não criptografada com esse proxy.
A autenticação por IP torna um proxy mais rápido?
O acesso por IP pode evitar uma troca de credenciais, mas o estabelecimento da conexão difere entre HTTP e SOCKS. No SOCKS5, a autenticação com nome de usuário e senha adiciona uma solicitação e uma resposta durante o estabelecimento da conexão. No HTTP, um cliente pode esperar um desafio de autenticação e repetir a solicitação ou enviar as credenciais adequadas desde o início. Portanto, o acesso por senha nem sempre adiciona uma ida e volta pela rede.
Essa diferença é mais relevante quando uma tarefa cria repetidamente novas conexões para pequenas quantidades de trabalho. Ela é menos relevante quando conexões já estabelecidas são reutilizadas. Por exemplo, solicitar mais páginas do mesmo site por um túnel HTTPS existente não repete o login no proxy usado para estabelecer esse túnel. Esse é um custo de estabelecimento da conexão, e não uma redução fixa na velocidade de transferência de dados do proxy.
Se os dois métodos forem adequados à sua configuração, compare-os com o mesmo protocolo, recursos de proxy semelhantes e seu padrão real de conexão. Um teste que abre uma conexão nova a cada solicitação responde a uma pergunta diferente de um teste que reutiliza conexões. Sem essa comparação, afirmar que um método de autenticação é sempre mais rápido ajuda pouco a escolher um serviço.
A autenticação pode revelar que um endereço opera um proxy?
Sim. Uma senha pode impedir o uso não autorizado e, ainda assim, permitir que um sistema externo reconheça o serviço. Por exemplo, uma ferramenta de verificação pode contatar o endereço e a porta de um proxy HTTP sem credenciais válidas. Uma resposta 407 Proxy Authentication Required, com o cabeçalho Proxy-Authenticate, identifica explicitamente uma exigência de autenticação de proxy. A ferramenta não precisa saber a senha para receber essa evidência.
Um serviço restrito por IP pode revelar menos se bloquear uma origem não aprovada antes de retornar uma resposta reconhecível de proxy. Mas uma lista de IPs permitidos, por si só, não garante esse comportamento: o servidor pode retornar uma recusa característica. Um ponto de conexão protegido por senha também pode ter filtragem de rede. A diferença relevante é o que uma conexão externa consegue alcançar e qual resposta recebe.
O endereço verificado também importa. Quando o endereço de entrada do proxy e seu IP de saída são iguais, uma resposta reconhecível pode identificar o endereço que os sites veem. Com um gateway que usa IPs de saída diferentes, identificar o gateway, por si só, não identifica todas as saídas do seu pool.
O site de destino não recebe automaticamente o desafio de login do proxy durante a navegação normal: essa troca ocorre entre o cliente e o proxy. Um site ou seu serviço de detecção precisaria de outras evidências, que poderiam incluir uma verificação separada do endereço. Portanto, trocar apenas a autenticação não pode prometer tornar um IP irreconhecível como proxy nem remover informações já conhecidas sobre ele.