Respostas SOCKS5 no .NET 7+: tratar leituras TCP parciais

Leia o prefixo fixo da resposta ao comando SOCKS5 e o sufixo dependente do ATYP sem depender dos limites de escrita TCP do servidor.

Um servidor SOCKS5 escreve quatro bytes separadamente, e o cliente só funciona depois que essas escritas são combinadas. Combiná-las pode mudar o timing, mas o TCP continua sem prometer uma leitura por escrita.

O cliente precisa de um analisador de resposta. Após a seleção de método e qualquer autenticação necessária, uma resposta de comando SOCKS5 começa com quatro bytes: versão, resultado, byte reservado e tipo de endereço. O comprimento restante depende desse tipo de endereço.

Um analisador para .NET 7+ que só precise consumir uma resposta CONNECT bem-sucedida pode usar:

static async Task ReadConnectReply(Stream stream, CancellationToken ct)
{
    byte[] prefix = new byte[4];
    await stream.ReadExactlyAsync(prefix, ct);
    if (prefix[0] != 5 || prefix[2] != 0)
        throw new IOException("Invalid SOCKS5 reply");
    if (prefix[1] != 0)
        throw new IOException($"SOCKS5 request failed: {prefix[1]}");

    int remaining;
    switch (prefix[3])
    {
        case 1: remaining = 4 + 2; break;
        case 4: remaining = 16 + 2; break;
        case 3:
            byte[] length = new byte[1];
            await stream.ReadExactlyAsync(length, ct);
            remaining = length[0] + 2;
            break;
        default:
            throw new IOException("Unknown SOCKS5 address type");
    }
    await stream.ReadExactlyAsync(new byte[remaining], ct);
}

Os dois últimos bytes são a porta vinculada. IPv4 requer quatro bytes; IPv6 requer dezesseis; um endereço de domínio carrega um byte de comprimento antes do nome.

Forneça um token de cancelamento com o prazo de negociação pretendido. ReadExactlyAsync trata leituras individuais mais curtas e lança uma exceção quando o fluxo termina antes do comprimento solicitado. Em caso de falha, descarte a conexão falha pelo caminho de limpeza do proprietário.

Em caso de sucesso, pare no limite da resposta. Os bytes seguintes pertencem ao protocolo de destino. Uma leitura especulativa maior deve preservar os bytes excedentes em vez de descartar o início do fluxo da aplicação.

Artigos relacionados