Se você já usou proxies antes, provavelmente conhece o whitelisting de IP: você registra o endereço do seu servidor com o provedor, e qualquer conexão vinda desse endereço é permitida sem credenciais. É um modelo comum, e pessoas que vêm de outros produtos costumam procurar essa configuração.
A resposta direta para o gateway residencial é que não existe whitelist de IP. A autenticação é feita por usuário e senha em cada requisição, e as credenciais são o único mecanismo de autenticação. Essa é uma escolha de design deliberada, não uma funcionalidade ausente, e vale a pena entender o porquê, pois isso muda a forma como você protege o acesso. O whitelisting existe em outros pontos da linha de produtos, em proxies ISP e em planos legados baseados em porta, e isso cobre como configurá-lo nesses casos.
Por que o gateway residencial usa credenciais em vez disso
O produto residencial é um único endpoint, p.shifter.io:443, onde toda a segmentação de destino fica dentro do nome de usuário. Uma requisição para uma saída nos EUA com sessão fixa usa o mesmo host e porta que uma requisição para uma saída rotativa na Alemanha; apenas a string do nome de usuário muda. Esse design tem uma consequência para a autenticação: a credencial já carrega informações por requisição, então ela precisa estar presente em toda requisição de qualquer forma.
A autenticação por credenciais também é consideravelmente mais portátil, o que importa mais do que parece à primeira vista. O whitelisting vincula o acesso a um endereço de saída fixo, e boa parte da infraestrutura moderna não tem um. Containers recebem novos endereços quando são reagendados, grupos de autoscaling adicionam e removem nós, funções serverless saem por um espaço de endereços compartilhado que muda sem aviso, executores de CI são efêmeros, e um desenvolvedor em um laptop ou em uma conexão doméstica tem um endereço dinâmico que pode mudar de um dia para o outro. Sob whitelisting, cada um desses casos vira um chamado de suporte. Com credenciais em um gerenciador de segredos, a mesma configuração funciona a partir de um laptop, de um container, de um job de CI e de um cluster de produção sem que ninguém precise registrar nada.
Então, se você veio procurando a configuração de whitelist em proxies residenciais, o que deve configurar em vez disso é o gerenciamento de credenciais, abordado a seguir.
Onde o whitelisting se aplica
Dois produtos usam autenticação por IP de origem, e se o whitelisting for um requisito obrigatório para você, são esses os que deve observar.
Proxies ISP suportam dois modos de autenticação, e você escolhe um por plano no painel. No modo de IP de origem autorizado, você registra o endereço do seu servidor e depois se conecta aos seus IPs fixos na porta 1337 sem nenhuma credencial. No modo usuário e senha, você se conecta de qualquer lugar com credenciais, uma linha por IP. O trade-off é exatamente o descrito acima: o whitelisting mantém as credenciais totalmente fora do seu código, ao custo de só funcionar a partir de endereços registrados. Proxies ISP são um produto diferente do residencial rotativo, com endereços estáticos fixos em vez de um pool rotativo, então, se você está escolhendo entre eles, a comparação está em ISP versus proxies residenciais e o que são proxies residenciais estáticos.
Planos legados de lista de portas autenticam apenas por IP de origem. Cada porta na sua alocação tem seu próprio subdomínio, e você registra o endereço do seu servidor na whitelist pelo painel, ou gerencia a lista pela API de gerenciamento legada, e então se conecta a qualquer porta da sua lista. Se você está em um desses planos, o whitelisting não é opcional, é o único mecanismo de autenticação. O contexto sobre por que o setor deixou de usar esse modelo está em por que a era por porta acabou.
Configurando uma whitelist em proxies ISP
A mecânica é direta, mas dois detalhes causam a maioria das falhas.
Primeiro, registre seu endereço de saída (egress), não um endereço local. O endereço que importa é o endereço público de onde seu tráfego chega, que não é o seu endereço de LAN, não é o endereço interno do seu container, e não é o que o ifconfig mostra na máquina. Determine-o a partir da máquina que fará as requisições de fato:
# run this ON the server that will connect to the proxies
curl -s https://ipinfo.io/ipSe sua infraestrutura sai por um gateway NAT ou um load balancer, esse endereço compartilhado é o que deve ser registrado, e vale a pena confirmar que ele é estável em vez de atribuído dinamicamente.
Segundo, escolha o modo de autenticação de forma deliberada no painel em ISP Proxies, porque os dois modos são alternativas, não um sistema em camadas. Uma vez no modo de IP de origem autorizado, você se conecta sem credenciais:
# authorized source IP mode: no username or password
curl -x 185.199.108.153:1337 https://ipinfo.io/jsonSe isso retornar um erro e você tiver certeza de que o endereço está registrado, as causas mais comuns são: seu endereço de saída mudou, você registrou um endereço IPv4 enquanto seu tráfego sai por IPv6 (ou o inverso), ou as requisições estão vindo de um nó diferente daquele a partir do qual você testou.
O trade-off, dito com clareza
O whitelisting remove segredos do seu código e da sua configuração, o que é genuinamente valioso: nada para vazar em um repositório, nada para rotacionar, nada para acabar em um log. Sua fraqueza é que ele falha no momento em que seu endereço de saída muda, e não consegue suportar acesso a partir de qualquer lugar que não tenha um endereço estável.
A autenticação por credenciais é portátil e funciona em qualquer ambiente, mas as credenciais são um segredo que agora é seu, o que significa que elas pertencem a um gerenciador de segredos, não ao código-fonte, e precisam de um plano de rotação.
Nenhum dos dois é inerentemente mais seguro. Eles falham de formas diferentes, e a escolha certa depende de se sua infraestrutura tem saída estável.
Protegendo credenciais residenciais, já que não há whitelist
Se você está no gateway residencial, esta é a seção que substitui o whitelisting para você.
Mantenha as credenciais fora do controle de versão e fora das imagens de container, e carregue-as a partir de variáveis de ambiente apoiadas por um gerenciador de segredos. Use credenciais separadas por ambiente sempre que possível, para que um valor de desenvolvimento vazado não exponha a produção. Trate a rotação como uma implantação, não como um clique no painel: atualize o gerenciador de segredos primeiro, faça o rollout dos clientes, depois rotacione o valor antigo, porque todo cliente que ainda estiver com a senha anterior começará a retornar 407 no momento em que ela mudar, o que é a versão mais comum de problema autoinfligido abordada em corrigindo erros 407 e de credenciais.
Depois, controle o outro lado. Mesmo sem um whitelist do lado do provedor, você pode restringir quais dos seus próprios sistemas alcançam o gateway usando regras de egress comuns, políticas de rede ou um security group, de forma que uma credencial vazada seja menos útil fora da sua infraestrutura. E monitore o uso de banda, porque consumo inexplicado é o sinal de que uma credencial escapou, o que é mais fácil de identificar quando você tem uma linha de base a partir do seu próprio monitoramento de pipeline.
Erros comuns
Registrar um endereço privado, como um valor 10.x ou 192.168.x, que nunca poderá corresponder, já que apenas o endereço de saída público é visível para o provedor. Colocar um laptop ou conexão doméstica na whitelist e se surpreender quando ele para de funcionar depois que a reinicialização de um roteador reatribui o endereço. Esquecer que o autoscaling adiciona nós atrás de endereços diferentes. Registrar IPv4 enquanto o tráfego de fato sai por IPv6. E supor que uma entrada de whitelist em um produto cobre outro: uma whitelist de proxy ISP não tem nenhum efeito sobre o gateway residencial, que continuará exigindo credenciais.
Conclusão
Não há whitelist de IP no gateway residencial, e isso é por design: a segmentação de destino fica no nome de usuário, então as credenciais estão presentes em toda requisição de qualquer forma, e a autenticação por credenciais continua funcionando em containers, autoscaling, CI e conexões dinâmicas, situações em que uma whitelist quebraria. Se você precisa especificamente de autenticação por IP de origem, os proxies ISP oferecem isso como um dos dois modos selecionáveis, e os planos legados de lista de portas o usam exclusivamente, e em ambos os casos o que deve ser registrado é o seu endereço de saída público, não algo local. No residencial, substitua o whitelisting por um gerenciamento disciplinado de credenciais: gerenciador de segredos, valores por ambiente, um procedimento de rotação que atualize os clientes antes de invalidar a senha antiga, além de controles de egress e monitoramento de uso do seu lado.
A referência completa de autenticação para cada produto está na documentação de autenticação, e os detalhes específicos do gateway estão em gateway e autenticação. O produto em si é proxies residenciais, um único endpoint e um único par de credenciais para todos os países e modos de sessão, com preços por GB.