Portas bloqueadas
Um provedor de proxies pode proibir conexões com determinadas portas de rede. Ele pode permitir a navegação na web e recusar conexões com as portas usadas para enviar e-mails. O proxy continua aceitando a conexão do cliente, mas não estabelece a conexão solicitada com o servidor de e-mail.
As restrições de portas são um dos limites de uso dos proxies que determinam quais tarefas um serviço pode atender. Para entender seu efeito, é preciso distinguir a conexão com o proxy da conexão que o proxy faz em seu nome.
Qual porta está sendo bloqueada?
Uma porta de rede é um número usado para distinguir serviços em um endereço de rede. O mesmo servidor pode aceitar conexões web em uma porta e conexões com outra aplicação em uma porta diferente. Uma aplicação precisa do endereço do servidor, da porta adequada e do transporte que ele usa: TCP ou UDP.
Uma conexão por proxy tem dois destinos separados. Primeiro, sua aplicação se conecta ao proxy no endereço e na porta fornecidos pelo provedor. Depois, ela pede ao proxy que alcance o servidor de destino no endereço e na porta desse servidor. A porta nas configurações do proxy pertence à primeira etapa; uma restrição de porta de destino se aplica à segunda.
Por exemplo, um programa pode se conectar a proxy.example:1080 e solicitar portal.example:443. O mesmo ponto de entrada do proxy também pode receber uma solicitação para mail.example:587. Se o provedor permitir a primeira porta de destino e bloquear a segunda, a conexão web poderá funcionar enquanto a conexão de e-mail será recusada.
Essas restrições dizem respeito às conexões de saída do proxy com serviços externos. Permitir uma conexão desse tipo não dá a uma aplicação no seu computador uma porta de entrada que outros usuários da internet possam alcançar. O encaminhamento de portas de entrada é uma capacidade separada.
Por que os provedores restringem portas
O motivo mais claro é evitar o abuso de um serviço específico. O acesso direto a servidores de e-mail pode ser usado para campanhas de spam. Denúncias e listas de bloqueios de remetentes afetam os endereços IP que transportam o tráfego, de modo que as consequências podem ir além do cliente que enviou as mensagens. Um provedor pode reduzir esse risco recusando conexões com portas usadas para enviar e-mails antes que qualquer mensagem seja transmitida.
Considerações semelhantes podem se aplicar a serviços de administração remota, compartilhamento de arquivos ou bancos de dados. Um provedor pode restringir o acesso a portas associadas a esses serviços para reduzir tentativas de login sem autorização e outros ataques. A restrição se aplica à própria conexão: um administrador legítimo também pode ficar impossibilitado de alcançar seu próprio servidor por aquele produto.
A regra nem sempre vem do vendedor de proxies. Uma empresa de hospedagem ou um operador de rede pode filtrar conexões de saída da infraestrutura usada pelo proxy. A permissão no software do próprio proxy não pode se sobrepor a uma restrição imposta mais adiante na rota.
Um filtro de portas é uma medida ampla. Ele pode interromper o tráfego indesejado sem examinar cada mensagem ou decidir se cada operação individual é legítima, mas também limita aplicações úteis que precisam da mesma porta. Essa escolha explica por que um provedor pode manter uma porta fechada mesmo para um cliente pagante com uma tarefa razoável.
Como funcionam as regras de acesso a portas
Existem duas abordagens básicas. Uma lista de bloqueios informa as portas que os clientes não podem usar; as outras conexões são avaliadas segundo as demais regras do serviço. Uma lista de permissões funciona no sentido oposto: o provedor permite um conjunto específico de portas e rejeita o restante. Nesse segundo modelo, uma aplicação web normal em uma porta não padrão pode ficar indisponível simplesmente porque sua porta não faz parte do conjunto permitido.
Uma regra pode abranger uma porta em todos os endereços externos ou combinar a porta com um destino específico. Os provedores também podem aplicar regras diferentes a produtos ou usos aprovados diferentes. Por isso, o acesso por uma rede não comprova as permissões de outro produto vendido pela mesma empresa.
O proxy não precisa descriptografar o tráfego da aplicação para aplicar uma regra de porta de destino. Em uma solicitação HTTP CONNECT, o cliente fornece o host e a porta de destino. O SOCKS5 também transporta o destino solicitado em sua solicitação de conexão. O proxy pode rejeitar essa solicitação antes que uma sessão protegida com o servidor de destino comece.
O tráfego TCP e o UDP que usam o mesmo número de porta podem ser permitidos ou bloqueados separadamente. Uma conexão bem-sucedida com a porta TCP 443 não comprova que a porta UDP 443 está disponível. Também existe outra possibilidade: o produto de proxy selecionado pode não transportar UDP de forma alguma. Nesse caso, a limitação diz respeito ao transporte, e não a uma porta UDP específica.
Um número de porta isolado também não comprova o que uma aplicação está fazendo. Serviços podem funcionar em portas não padrão, e um número permitido não torna aceitável todo uso dele. Os provedores podem combinar filtros de portas com restrições de destinos e regras sobre a própria atividade.
O que isso muda para as aplicações
As aplicações usam conexões para funções específicas. Um teste no navegador verifica a conexão web que ele faz; não exercita todas as conexões de que outro programa pode precisar. Os exemplos a seguir mostram como uma restrição de porta pode afetar um serviço que funciona nos demais aspectos.
| Conexão | Portas usadas neste exemplo | Efeito de uma restrição |
|---|---|---|
| Acesso web por TCP | 443 | A página não pode ser obtida por essa conexão. |
| Envio de e-mails | TCP 25 para entrega entre servidores; TCP 465 ou 587 para envio por uma aplicação de e-mail | O envio direto de e-mails pela conexão afetada fica indisponível. |
| FTP passivo | TCP 21 para comandos e uma porta separada informada pelo servidor para dados | O login pode funcionar enquanto a listagem de diretórios ou a transferência de arquivos falha. |
| Uma aplicação web em uma porta personalizada | Por exemplo, TCP 8443 | A aplicação pode ficar inacessível mesmo quando sites na porta TCP 443 funcionam. |
O e-mail ilustra essa distinção muito bem. Uma aplicação de e-mail envia mensagens de saída a um servidor de e-mail, normalmente pela porta 587 ou 465. A porta 465 começa com criptografia TLS; a porta 587 costuma usar STARTTLS para estabelecer a criptografia. Uma restrição de porta pode impedir qualquer uma dessas conexões antes de a mensagem ser enviada. A criptografia protege a troca, mas não remove a regra de acesso do provedor.
Em uma interface de webmail, o navegador se comunica com um site por HTTPS, e o serviço de e-mail cuida da entrega. O navegador não está pedindo ao proxy que estabeleça aquela mesma conexão SMTP. Portanto, uma caixa de e-mail na web pode continuar utilizável enquanto o acesso SMTP está bloqueado. Receber e-mails em uma aplicação separada é outra conexão: o acesso IMAP ou POP deve ser considerado separadamente do envio.
O FTP mostra por que testar apenas o login pode deixar um problema passar despercebido. No modo passivo, o cliente primeiro envia comandos por uma conexão e depois se conecta a uma porta especificada pelo servidor para transferir dados. Se a segunda conexão for restrita, a autenticação poderá funcionar enquanto a lista de arquivos ou o download falha. Aplicações com conexões separadas para login, voz ou troca de arquivos podem apresentar falhas parciais semelhantes.
Por que mudar as configurações do proxy pode não ajudar
Mudar a porta de entrada nas configurações do proxy altera onde sua aplicação contata o proxy. Isso não muda a porta de destino solicitada para o serviço externo. Se o provedor oferecer um ponto de entrada na porta 443, conectar-se ali ainda deixa uma solicitação para a porta 587 do servidor de e-mail sujeita à restrição de portas de e-mail.
Mudar de um proxy HTTP para SOCKS5 pode resolver um problema de compatibilidade quando a aplicação precisa de uma capacidade compatível com o novo método de conexão. Isso, por si só, não cancela as regras do provedor. O SOCKS5 define como solicitar conexões TCP e encaminhamento UDP; o serviço decide quais dessas solicitações aceitará.
Substituir um IP de saída também mantém uma restrição que vale para todo o produto. Uma rota diferente pode se comportar de outra forma quando uma rede externa específica causa a falha, mas a rotação não é uma forma de remover uma regra que se aplica ao produto inteiro. Mais IPs ou uma franquia de tráfego maior também não mudam essa permissão.
Como identificar uma restrição de porta
A evidência mais útil é uma resposta explícita do provedor informando que a porta de destino solicitada não é permitida. Uma mensagem genérica de acesso negado é menos precisa. Por exemplo, a resposta SOCKS5 para uma solicitação rejeitada pelo conjunto de regras identifica uma recusa por política, mas não informa qual regra a causou. Um tempo limite excedido ou uma redefinição de conexão, isoladamente, é uma evidência ainda mais fraca.
O servidor de destino pode não ter um serviço escutando naquela porta, aceitar apenas determinados endereços de origem ou estar temporariamente indisponível. A aplicação também pode estar usando o protocolo errado ou enviando parte do tráfego fora do proxy configurado. Verificar uma solicitação web bem-sucedida não permite distinguir essas causas de uma restrição que afeta outra conexão.
Para uma solicitação útil ao suporte, informe o produto de proxy, o nome de host ou IP de destino, sua porta, TCP ou UDP, a aplicação e o erro exato com o horário da tentativa. Esses detalhes permitem ao suporte verificar a conexão relevante, em vez de apenas confirmar que o proxy está on-line. Para uma compra planejada, as mesmas informações ajudam a determinar se o produto oferece suporte à tarefa.
Quando o provedor permite exceções, a aprovação deve identificar o destino e o uso necessários. Algumas restrições permanecem definitivas ou vêm de uma infraestrutura que o provedor não controla. A pergunta útil é se a conexão específica pode ser atendida pelas regras do serviço; um pedido para “abrir todas as portas” deixa tanto o requisito quanto os limites pouco claros.