Resumo

  • Como UDP não tem uma negociação de conexão, o proxy não consegue saber se o destino é alcançável no momento em que abre o socket. A RFC 9298 manda responder sem esperar um pacote remoto.
  • O sucesso do CONNECT-UDP informa que o proxy abriu um socket para o alvo solicitado e está disposto a encaminhar cargas UDP. Não informa que o alvo recebeu, respondeu, autenticou-se ou aceitou uma operação.
  • David Schinazi escreveu uma fronteira de observação que pode melhorar redes e automação: autorização, DNS, socket, movimento de datagramas e resultado da aplicação precisam continuar sendo recibos separados.

O silêncio não cabe em um único indicador

Uma conexão TCP que não completa a negociação oferece um sinal relativamente claro para o intermediário. No UDP, o outro lado pode permanecer em silêncio por muitos motivos sem que exista uma etapa universal capaz de explicar qual deles ocorreu.

É nesse terreno que a RFC 9298 define CONNECT-UDP. O cliente recebe uma configuração com um URI Template absoluto e coloca target_host e target_port na solicitação. O proxy extrai os valores, verifica o pedido e abre um socket UDP na direção indicada. O transporte do conteúdo usa HTTP Datagrams e o Capsule Protocol da RFC 9297, adaptando o início do túnel à versão de HTTP em uso.

Abrir o socket não chama uma negociação remota. É uma operação do sistema do proxy. O host de destino pode estar fora do ar, descartar silenciosamente, não ter uma aplicação naquela porta ou aceitar somente mensagens que ainda não chegaram. Por isso, a RFC afirma que o proxy não tem como saber se o destino é alcançável e deve responder antes de receber qualquer pacote dele.

O texto chama de bem-sucedida a resposta que indica a abertura do socket para o alvo pedido e a disposição de retransmitir cargas UDP. Esse enunciado é suficiente para iniciar o trabalho do túnel. Ele não é um atestado do destino.

Uma tela que transforma esse evento em “serviço remoto saudável” não está simplificando apenas a interface. Está adicionando uma afirmação que nenhum ator produziu.

A origem do tráfego muda antes de a aplicação falar

Há outra razão para separar o aceite do proxy do resultado no alvo. Para o destino, o tráfego costuma chegar com o endereço do proxy. Isso altera a atribuição de abuso e pode interagir mal com sistemas que confiam no IP de origem.

A RFC 9298 recomenda autenticar os usuários do serviço e impedir destinos vulneráveis, inclusive endereços do próprio proxy, loopback, link-local, multicast e broadcast. Uma máquina que aceita mudanças administrativas vindas de uma rede local não deve se tornar alcançável para clientes externos apenas porque o proxy passa a parecer a origem. O tipo destination_ip_prohibited, definido no vocabulário da RFC 9209, pode explicar a rejeição.

Assim, o primeiro fato que merece registro não é disponibilidade. É autorização: quem, ou qual classe de cliente, recebeu permissão para usar qual alvo; sob qual política; com qual limite de pacotes, bytes ou sockets. O proxy consegue testemunhar essa decisão porque ela lhe pertence.

O alvo, por sua vez, possui outra política. Um túnel autorizado não implica que a aplicação concordou em conversar. Manter essas duas decisões separadas evita transformar poder de encaminhamento em consentimento remoto.

Resolver um nome não localiza um serviço vivo

Quando o alvo é um nome DNS, a RFC exige que o proxy resolva o nome antes de responder. Se houver erro, a solicitação deve ser rejeitada e pode carregar Proxy-Status, por exemplo com dns_error.

Esse requisito entrega uma informação real: em certo instante, o resolvedor obteve certo endereço. Para que ela continue útil, o recibo deve guardar o nome de entrada, o conjunto retornado, o endereço escolhido, a família IP, o horário e o uso de cache. O socket precisa registrar separadamente o par ao qual foi associado.

O motivo é temporal. Um nome pode mudar enquanto o socket existente continua apontando para o resultado anterior. Também pode resolver perfeitamente para uma máquina que não executa o serviço esperado. A frase “DNS funcionou” não deve se expandir para “o destino está disponível”.

Erros de destino da RFC 9209, como indisponível ou não roteável, ajudam quando o intermediário realmente possui essa informação. A ausência de erro continua ambígua. ICMP pode ser bloqueado; um firewall pode simplesmente jogar fora; a aplicação pode receber e não responder.

O silêncio, portanto, é um estado observado, não uma conclusão.

O socket filtra rede; o protocolo interno confirma identidade

Com um socket UDP conectado, o kernel pode entregar apenas datagramas que correspondam ao 5-tuple esperado. Se usar socket não conectado, o proxy precisa validar o IP e a porta de origem e descartar qualquer pacote diferente.

Essa regra evita que uma fonte aleatória se apresente como retorno do alvo. Mesmo assim, IP e porta não formam uma identidade de aplicação. Um pacote correspondente pode ser repetido, inválido, malicioso ou pertencer a uma etapa que ainda não autenticou o par.

É o protocolo interno que define a evidência mais forte. Uma negociação QUIC autenticada, uma resposta DNS correlacionada ou uma confirmação de negócio têm significados próprios. O túnel não deve tentar unificá-los.

A vida do socket acompanha o stream da solicitação HTTP. Enquanto o stream permanece aberto, o proxy mantém o socket. Se o sistema operacional sinaliza que ele não serve mais—um ICMP Destination Unreachable pode fazer isso—o stream deve ser fechado. A inatividade também pode encerrar ambos, embora a RFC recomende não usar menos de dois minutos.

Criar e fechar são eventos verificáveis. Permanecer aberto significa apenas que nenhuma condição observada encerrou o estado local. Não é uma medição contínua da aplicação remota.

Entre o aceite e a entrega há descartes permitidos

No formato da RFC 9298, Context ID zero leva o conteúdo UDP. Outros IDs reservam espaço para extensões dentro de cada solicitação. A ordenação pode fazer um datagrama chegar antes de o contexto ser conhecido. O receptor pode descartá-lo silenciosamente ou mantê-lo por pouco tempo. Se chegar antes da própria solicitação, o tratamento também pode ser descarte ou espera curta.

O cliente pode começar a enviar de modo otimista, antes da resposta CONNECT-UDP. Isso reduz latência em casos favoráveis, mas os primeiros pacotes podem não ser processados se o pedido falhar ou se o proxy não os armazenar.

O tamanho cria mais uma diferença. Uma carga UDP com Context ID zero não passa de 65.527 bytes. A MTU do caminho costuma ser menor. Como o proxy não deve introduzir fragmentação IP, um HTTP Datagram grande demais pode ser descartado sem aviso.

Um túnel aceito pode, assim, transportar alguns datagramas e perder outros sem nunca produzir uma confirmação da aplicação. Contadores por direção, motivo de descarte, primeiro e último pacote e bytes observados descrevem esse comportamento. Eles não substituem o recibo do protocolo interno.

A contribuição de Schinazi está na precisão

David Schinazi aparece como autor da RFC 9298, publicada em agosto de 2022 no Standards Track do IETF. O perfil escrito do Datatracker capturado em 2 de setembro de 2026 o apresenta como engenheiro principal sênior e gestor no Google, trabalhando sobretudo com Privacy Proxy, MASQUE e OHTTP. O mesmo texto registra atuações anteriores em QUIC, Chrome Networking e tecnologias de rede da Apple. Cargos, afiliação e número de RFCs são fatos datados e podem mudar.

O retrato oficial do IETF fornece a referência visual pública, não evidência sobre um serviço. A arquitetura ao redor também é coletiva. A RFC 9297 tem Schinazi e Lucas Pardue como autores. A RFC 9484 reúne cinco autores, amplia a família para proxy de IP e atualiza o registro do URI conhecido masque. O grupo MASQUE é trabalho comunitário do IETF.

O ponto desta pessoa, portanto, não é atribuir a Schinazi todo o ecossistema. É observar uma escolha de escrita: declarar o que a implementação realmente sabe e deixar o restante sem certificado.

A Running-Code Primacy de Heng Lu pede exatamente esse limite. O sistema ganha autoridade por executar uma função verificável, não por carregar um rótulo de protocolo. Minimum Initial Specification complementa a leitura: o mecanismo comum estabelece o mínimo para interoperar; autenticação, confirmação e consequência continuam perto da aplicação que as entende.

Um mapa de recibos que acompanha o pacote

Uma implantação pode montar cinco trilhas. A primeira registra autenticação do cliente, política de destino e decisão. A segunda registra resolução, se houver nome. A terceira registra socket, endereço local de saída, modo conectado ou não, par e encerramento.

A quarta trilha mede datagramas. Separa saída e entrada, tamanho, descartes por MTU, Context ID desconhecido, limite de buffer, origem incompatível e sinais do sistema. É possível fazer isso sem guardar conteúdo sensível.

A quinta pertence à aplicação interna. Ela registra identidade autenticada, negociação, correspondência de pedido e resposta, erro, timeout e regra de repetição. Somente esse nível pode definir se “o destino respondeu” equivale a um resultado útil.

O painel deixa de oferecer um veredito prematuro e passa a mostrar progresso: proxy autorizado; DNS resolvido; socket aberto; saída vista; retorno visto; par autenticado; operação aceita. Cada etapa tem dono e horário.

Pronto para encaminhar não é pronto no outro lado

Um único estado verde parece eficiente. Entretanto, se o roteamento automático aprende que resposta HTTP é sucesso da aplicação, ele passa a favorecer proxies que aceitam rápido, mesmo quando o caminho entrega mal. Se a análise de incidentes perde os motivos de descarte, culpa o alvo por um problema de MTU. Se a conformidade chama filtragem de 5-tuple de autenticação, relata uma proteção que o protocolo interno não forneceu.

A RFC 9298 evita esses exageros na origem. O proxy pode afirmar que aceitou e abriu. O resolvedor pode afirmar qual endereço retornou. O sistema pode afirmar quando o socket mudou. Os contadores podem afirmar onde houve movimento. A aplicação pode afirmar o resultado.

O túnel que fica pronto antes de ouvir o destino não é uma promessa quebrada. É uma promessa bem delimitada. A falha aparece quando a operação decide que a voz do proxy também vale como voz de quem ainda não respondeu.

Fontes