Resumo

  • UDP ASSOCIATE nascia em uma conversa TCP que já havia negociado um método e terminava quando essa conversa se encerrava; o fluxo governava a vida do contexto, não transportava os dados UDP.
  • Endpoint de relay, IP de origem esperado, destino de cada datagrama, método de proteção e estado de fragmentos permaneciam alegações diferentes. Nenhuma delas era recibo de identidade ou entrega final.

A associação começava no plano de controle

Antes de enviar UDP, o cliente estabelecia TCP com o servidor SOCKS, oferecia métodos de autenticação e concluía a troca exigida pelo método escolhido. Só então apresentava CONNECT, BIND ou UDP ASSOCIATE.

Essa ordem é importante. O primeiro datagrama visto na porta do relay não criava a relação. A criação vinha de uma decisão anterior, ligada a uma conexão, a um método e à política local do servidor.

O RFC 1928, publicado em março de 1996, também definiu a extinção: a associação UDP termina quando termina a conexão TCP pela qual chegou o pedido. O relay poderia continuar online, e pacotes poderiam continuar chegando, mas o vínculo que lhes dava autoridade já não existia.

TCP não virou caminho para os payloads. UDP continuou sujeito a perda, duplicação e reordenação. O fluxo carregava o pedido e mantinha um limite de estado que o protocolo sem conexão não conseguia expressar sozinho.

Zeros não significavam acesso universal

No pedido, o cliente podia informar o endereço e a porta que esperava usar para enviar datagramas. O servidor podia empregar os valores para limitar a associação. Se o cliente ainda não soubesse seu endpoint, deveria enviar endereço e porta iguais a zero.

O zero declarava ausência de informação, não ausência de controle. Cabia ao servidor obter uma origem efetiva a partir da conexão, da observação e da configuração. Transformar zeros em wildcard irrestrito seria uma escolha de implementação, não uma autorização concedida pelo RFC.

Na resposta, BND.ADDR e BND.PORT indicavam onde o cliente deveria depositar os pedidos UDP. Um servidor multihomed poderia devolver endereço diferente daquele usado pela conexão TCP. O valor era o ingresso do relay, e não o destino remoto.

Assim, uma única operação envolvia pelo menos três pares: endpoint TCP do servidor, endpoint UDP retornado e endereço/porta do destino em cada datagrama. Guardar apenas “IP do proxy” elimina a distinção entre alcançar o controle, alcançar o relay e alcançar a aplicação final.

Cada pacote levava sua própria intenção

O cabeçalho UDP de SOCKS5 incluía campo reservado, FRAG, tipo de endereço, destino, porta e dados. Uma associação podia servir a vários destinos; a política era aplicada pacote a pacote.

Quando chegava uma resposta remota, o relay a encapsulava com a mesma gramática. O cliente recebia o endereço e a porta de origem observados pelo intermediário. Era informação necessária para correlação, mas não uma assinatura do remetente.

O relay sabia se aceitou o envelope, qual política aplicou e se tentou enviar. Não sabia sozinho se a rota entregou, se o programa remoto consumiu o conteúdo ou se produziu o efeito pretendido. Um reply acrescentava outra observação; ainda não transformava toda a cadeia em execução exatamente uma vez.

Depois do fim de TCP, um cliente podia conservar BND.ADDR no cache. Enviar uma mensagem sintaticamente válida para o endpoint antigo não recriava a associação. Conhecer o endereço não era possuir uma capacidade duradoura.

O IP de origem protegia uma borda, não nomeava uma pessoa

O relay deveria receber do servidor SOCKS o IP esperado do cliente e descartar silenciosamente datagramas que viessem de outra origem. A regra dificultava que um host externo injetasse tráfego em contexto alheio.

Seu significado terminava aí. Um IP pode representar vários dispositivos ou usuários atrás de NAT, vários processos no mesmo host e uma identidade móvel que acaba de trocar de rede. Ele prova qual atributo o relay comparou, não quem operava o aplicativo.

A autenticação vinha do método escolhido. O RFC 1929 definiu username/password, mas transportava as credenciais em claro na subnegociação e alertava contra seu uso onde houvesse captura de tráfego. O RFC 1961 definiu GSS-API, com autenticação e níveis negociados de integridade e confidencialidade opcional por mensagem.

Portanto, “SOCKS5 habilitado” não descrevia uma propriedade de segurança única. Operação e auditoria precisavam registrar método, resultado e proteção real. O filtro de origem também não completava campos de autenticação que o método não forneceu.

FRAG podia desaparecer por desenho

No envelope SOCKS, FRAG=0 identificava um datagrama independente. Valores de 1 a 127 indicavam posição em uma sequência, e o bit alto marcava o final. Era fragmentação do protocolo de relay, não o fragment offset de IP.

Implementar reassembly era opcional. Um sistema sem suporte tinha de descartar qualquer FRAG diferente de zero. Um sistema com suporte mantinha fila e temporizador; ao expirar, abandonava os fragmentos. Um novo número inferior ao maior já processado também reiniciava a fila. O temporizador não podia ser menor que cinco segundos, e a recomendação era evitar fragmentar sempre que possível.

Não havia ACK ou promessa de retransmissão. Uma fila completa permitia reconstruir um payload localmente; não comprovava o envio posterior. A possibilidade explícita de abandonar fragmentos mantinha o custo e a autoridade desse estado limitados.

Por isso, métricas precisam distinguir source mismatch, FRAG não suportado, retrocesso de sequência, timeout, recusa de destino e perda após a saída. Uma falha vista pela aplicação pode ter ocorrido em qualquer dessas fronteiras.

O fim de TCP revogava em vez de adivinhar

Um idle timeout ajuda a liberar memória, mas o silêncio não diz se o cliente morreu. Manter o relay enquanto houver pacotes enfrenta o problema oposto: atividade mostra conhecimento do endpoint, não continuidade do principal autenticado.

A conexão TCP era uma peça de estado que o próprio servidor podia observar. Enquanto existia, método, pedido e entrada UDP podiam permanecer vinculados. Quando desaparecia, a norma preferia nova negociação a uma extensão implícita.

Essa opção tinha custo operacional. Um defeito breve em TCP interrompia UDP saudável; mobilidade invalidava controle e origem; manter o socket consumia recursos. Mas o ponto de quebra era verificável e a recuperação era explícita. Um relay órfão, renovado por tráfego sem proveniência suficiente, produziria uma continuidade mais conveniente e muito menos defensável.

A ponte IPv6/IPv4 continuou sendo relay de aplicação

O documento Informational RFC 3089 descreveu em 2001 um gateway baseado em SOCKS para IPv6 e IPv4. Ele terminava comunicações nos dois lados na camada de aplicação e podia delegar DNS a uma máquina dual stack quando o software antigo não conseguia armazenar endereços IPv6.

O mecanismo herdou os comandos SOCKS, inclusive UDP ASSOCIATE, sem se transformar em roteamento IP. Nome solicitado, resultado DNS, associação de controle e dados relayados continuavam separados.

A conquista histórica foi uma coordenação mínima: uma gramática comum dizia o que o cliente podia pedir; o relay mantinha autoridade para decidir localmente; cada camada preservava sua própria evidência. Interoperabilidade não exigia que o intermediário recebesse poder para narrar o caminho inteiro.

Fontes