Qual VPN funciona com listas brancas de IP de clientes brasileiros? O que importa é voltar com o mesmo endereço

A mensagem do cliente parecia simples: “Me manda seu IP público que eu libero o acesso.”

Eu trabalhava remotamente para uma empresa brasileira e precisava entrar num painel que não ficava aberto para qualquer endereço da internet. O time de TI mantinha uma lista de IPs permitidos.

Abri um verificador. Copiei meu endereço.

Mandei. Alguns minutos depois, o cliente respondeu:

“Liberado.” Entrei no painel.

Funcionou. No dia seguinte, abri o notebook em outra rede.

Acesso negado. Minha primeira reação foi culpar o portal. Depois percebi que meu IP tinha mudado.

Foi aí que pensei que bastaria usar um VPN brasileiro. Escolhi Brasil, mandei o novo endereço para o cliente e pedi que adicionassem aquele IP à lista.

Funcionou novamente. Até eu desconectar o VPN e entrar outra vez.

Outro IP. Nesse momento ficou claro que eu não precisava apenas de Brasil.

Precisava de Brasil com o mesmo endereço amanhã.

Uma lista branca não quer saber apenas o país

Quando um sistema trabalha com allowlist de IP, a regra é bastante literal.

O administrador cadastra um endereço — ou uma faixa — e permite conexões vindas dali. A documentação da Cloudflare descreve esse mesmo cenário ao explicar por que serviços que dependem de allowlisting podem precisar de endereços de saída dedicados e estáticos.

Para o cliente, portanto, não adiantava eu aparecer hoje com um IP de São Paulo e amanhã com outro IP igualmente brasileiro.

Os dois eram Brasil. Mas só um estava autorizado.

Essa diferença mudou completamente minha busca. Eu já não queria:

“um VPN com muitos servidores brasileiros.” Eu queria:

“uma conexão que me devolva o mesmo IP brasileiro sempre que eu trabalhar para esse cliente.”

Meu primeiro VPN funcionava — até a próxima reconexão

A primeira tentativa parecia perfeitamente razoável. Usei um provedor grande, selecionei Brasil e confirmei o IP.

Enviei o endereço ao cliente. O time de TI cadastrou.

Entrei. Tudo certo.

Na manhã seguinte, reconectei ao Brasil e recebi outra saída. O portal voltou a me bloquear.

Era aí que o benefício normal de uma rede compartilhada se transformava em problema. Eu podia continuar chegando ao Brasil, mas não necessariamente pelo endereço que o cliente tinha autorizado.

Essa fricção também aparece na rotina de profissionais remotos: basta o cliente permitir apenas um IP para cada mudança virar outro pedido ao time de TI.

Depois da segunda solicitação, eu já sabia que não queria fazer uma terceira. Precisava de previsibilidade.

Foi aí que IP dedicado deixou de parecer um extra

Até então, eu via Dedicated IP como um daqueles recursos opcionais escondidos no final da página de preços.

Para uma allowlist, ele deixou de parecer opcional.

A Surfshark oferece atualmente Dedicated IP em São Paulo. O endereço fica reservado para o usuário e permanece o mesmo entre reconexões.

Foi esse comportamento que testei. Copiei o endereço dedicado.

Enviei ao cliente. O time de TI colocou o IP na lista.

Entrei no portal. Depois desconectei.

Reconectei. Mesmo IP.

Troquei o Wi-Fi pelo hotspot do telefone. Mesmo IP de saída.

Fechei o notebook e voltei mais tarde. Mesmo endereço.

Pela primeira vez, a parte mais importante do teste aconteceu fora do VPN: eu não precisei mandar outra mensagem ao cliente.

Era esse o resultado que eu estava procurando desde o início.

Para uma equipe, o mesmo problema fica ainda mais claro

Depois disso, comecei a pensar no que aconteceria se não fosse apenas eu.

Imagine cinco pessoas trabalhando com sistemas de clientes brasileiros, cada um exigindo IP previamente autorizado.

Nesse cenário, administrar endereços variáveis deixa de ser uma inconveniência individual e vira trabalho para duas equipes de TI.

É por isso que soluções empresariais tratam o endereço de saída como parte da infraestrutura.

O Proton VPN for Business documenta o uso de servidores dedicados com IPs estáticos justamente para allowlisting e oferece servidor dedicado em São Paulo.

A lógica fica muito mais limpa: equipe → VPN → IP brasileiro estático → sistema do cliente.

O endereço é conhecido antes do acesso. O cliente cadastra uma vez.

A equipe continua usando aquela saída. Para esse problema específico, estabilidade vale mais do que uma lista enorme de servidores públicos.

Foi também onde a OnlydogVPN ganhou um papel diferente

Eu já usava a app menor em outras situações porque prefiro a lógica baseada na tarefa: menos escolha de infraestrutura, menos configuração e menos tempo administrando VPN.

Por isso, naturalmente testei se poderia usar a conexão brasileira também para o portal. Ela conseguia me dar a rota brasileira que eu queria para usos comuns.

Mas uma allowlist literal exige outra coisa: o cliente precisa cadastrar previamente um endereço que continuará sendo o mesmo.

Hoje, o serviço não anuncia um IP brasileiro dedicado como recurso. Isso significa que eu não usaria a rota compartilhada para prometer a um cliente:

“este será meu endereço permanente.” Mas isso também delimitou melhor o papel de cada ferramenta.

Para o sistema com allowlist, eu mantive o IP dedicado.

Para Wi-Fi de hotel, aeroporto, streaming, navegação e outras situações em que eu queria conectar sem administrar servidores, a app menor continuou sendo a opção que eu preferia abrir.

Em vez de tentar obrigar uma única VPN a resolver dois problemas diferentes, passei a usar cada uma onde sua arquitetura fazia mais sentido.

Eu quase tentei economizar usando sempre o mesmo servidor compartilhado

Havia ainda uma alternativa tentadora. Escolher sempre o mesmo servidor público brasileiro.

Copiar aquele IP. Pedir ao cliente para liberá-lo.

Enquanto o endereço permanecesse igual, funcionaria. Mas aí eu estaria construindo uma regra permanente do cliente sobre algo que não era permanente para mim.

Servidores públicos podem mudar de endereço ou disponibilidade. A própria Proton distingue essa consistência ocasional de um IP realmente dedicado.

Para navegação comum, eu aceitaria essa flexibilidade. Para uma allowlist corporativa, não.

Se o cliente transformou meu IP numa credencial de rede, eu queria que meu VPN tratasse aquele endereço com a mesma seriedade.

Foi aí que parei de procurar atalhos.

O melhor teste levou menos de cinco minutos

Depois disso, meu teste para qualquer VPN usado com clientes brasileiros ficou simples. Conecto.

Consulto o IP. Desconecto.

Reconecto. Consulto novamente.

Troco do Wi-Fi para o hotspot. Consulto outra vez.

Para uma allowlist que exige endereço fixo, os resultados precisam continuar iguais.

Não consigo observar eventuais regras internas adicionais que cada cliente aplique além da própria lista de IPs, mas essa parte do requisito é objetiva: se o endereço autorizado mudou, a conexão já não corresponde à regra cadastrada.

Esse teste também evita uma situação pouco profissional. Você manda um IP.

O cliente altera a segurança. No dia seguinte você pede outro.

Dois dias depois, outro.

O problema deixa de parecer “VPN” e começa a parecer que você está fazendo o cliente administrar sua conexão por você.

Então, qual VPN funciona com listas brancas de IP de clientes brasileiros?

Se “lista branca” significa realmente “o cliente cadastrará seu endereço e recusará os demais”, eu escolheria uma solução com IP brasileiro dedicado ou saída estática.

Para uso individual, a Surfshark oferece Dedicated IP em São Paulo. Para uma equipe, o Proton VPN for Business oferece servidores dedicados com IP estático e suporte explícito a allowlisting.

Eu não usaria uma rota compartilhada da OnlydogVPN^↗ para substituir esse requisito enquanto não houver IP brasileiro dedicado anunciado.

Mas continuaria preferindo a app menor para boa parte do resto da rotina justamente porque ela não me obriga a administrar infraestrutura que não preciso administrar.

Essa separação tornou minha escolha mais simples. Eu comecei procurando uma VPN que “funcionasse com clientes brasileiros”.

Descobri que o Brasil era apenas metade da exigência.

Quando o cliente colocou meu endereço numa lista branca, a conexão certa não era a que conseguia chegar ao Brasil — era a que conseguia voltar ao mesmo endereço brasileiro no dia seguinte.