UDP Associate SOCKS5, preciso de uma opinião

[void_brain_void]

Olá,

Estou escrevendo um servidor socks e estou colocando suporte ao UDP associate, para validar o aplicativo estou usando um cliente socks chamado csocks, ele até que funciona bem, contudo o UDP parece implementado de forma errada, preciso da opinião de alguém que manje desse protocolo, seguinte:

O UDP associate até onde sei (segundo a rfc1928), funciona da seguinte forma:

O cliente envia um pacote informando endereço e porta udp do servidor externo (servidor de aplicação) para o socks server.

O socks server, aceitando a conexão, envia a porta udp que ele sorteou para usar e o seu endereço ou outro endereço ip, que corresponderá ao relayer UDP.

Nisso, com o canal UDP "estabelecido" (pois é UDP), o cliente deve enviar pacotes UDP num formato tal para a porta que O SERVER SORTEOU no IP que ele enviou no reply junto com a porta.

Correto?

O problema é que esse tal csocks, estupidamente manda para a porta do servidor de aplicação, ou seja, o server não está escutando ali, nunca pegará. O louco é que esse csocks se diz RFC compliant. Mandei e-mail para o autor, ele não respondeu... Eu até corrigi o código do cara, mas... Estou louco ou realmente há problema com esse cliente socks?

Falou!
[]'s

[J.Augusto]

W.Richard Stevens
Bill Fenner
Andrew M.Rudoff

Programação de rede Unix ISBN.: 85-363-0470-7

Apis para sochets de rede Volume 1 terceira edição Bookman

Void, tá re-inventando a roda :-) ?

[void_brain_void]

Sempre o J. Augusto me respondendo...

Valeu pela dica do livro � um dos livros que est�o na deque (hehehe) dos que quero ler, mas nada vai al�m da RFC, se n�o entender por ela, foobar.

ok, mas acho que n�o me expliquei bem:

csocks n�o � uma api, � um aplicativo que intercepta as chamadas da api de sockets originais do SO pelas dele.

Via pre_loading e etc...

Utilizando ele: csocks nc -u 192.168.0.1 70

Isso por exemplo, faz todo o trabalho de direcionar o tr�fego gerado para o socks server.

csocks � na verdade um shell script que com umas mandracarias carrega a .so dele e faz o trabalho (ou pelo menos tenta....)

A api usada para desenvolver esses dois aplicativos foi obviamente a boa e velha BSD sockets que o W. Stevens discorre sobre no livro referido. O que estava querendo � trocar informa��o com algu�m que j� tenha lido a rfc ou tivesse experi�ncia nos internals desse protocolo e se eu estivesse equivocado, essa pessoa me ajudaria aclarar as ideias.

Sim eu adoro reinventar a roda, ler rfc, isso d� uma no��o mais profunda embora tire a sanidade em certos momentos... Se dissesse que fiz um DNS server minimalista totalmente fora do padr�o BIND, voc� me chamaria de louco?? :)

De qualquer forma valeu!

[Guzpido Krush]

dá uma olhada no RFC3089
traduzi o q interessa:

5.1 Considerações acerca do mecanismo SOCKS nativo
As características do mecanismo de gateway IPv6/IPv4 baseado em SOCKS
são herdadas do próprio mecanismo nativo SOCKS. Portanto, considerações acerca do
mecanismo SOCKS nativo são discutidas nesta seção.

O protocolo SOCKSv5 é composto de três comandos (CONNECT, BIND e UDP ASSOCIATE).
Todos destes três comandos se aplicam ao mecanismo de gateway IPv6/IPv4.

Este documento está descrito assumindo o uso mormente do comando CONNECT,
já que este é o principal e mais usado frequentemente do mecanismo SOCKS.
Uma vez que o comando CONNECT não possui claros pontos fracos, poderemos utilizá-lo livremente sem considerações.
Os outros ( BIND e UDP ASSOCIATE) tem os seguintes pontos fracos; então devemos
considerá-los ao implementar o mecanismo.
O comando BIND é basicamente designado para suportar encontros (rendezvous) de canais-reversos das aplicações como FTP. O uso geral do comando BIND pode causar problemas.

O comando UDP ASSOCIATE é basicamente designado para aplicações simples UDP (ex: archie). Não é geral o suficiente para suportar uma vasta classe de aplicações que usam tanto TCP quanto UDP;

Kitamura Informational [Page 9]

RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001

dai RFC1928 em si:

UDP ASSOCIATE
A requisição UDP ASSOCIATE é usada pra estabelecer a associação inerente
ao processo de retransmissão do UDP para lidar com datagramas UDP.
Os campos DST.ADDR e DST.PORT contém o ENDEREÇO e a PORTA que o cliente
espera usar para onde enviar datagramas UDP para a associação.
O servidor PODE usar esta informação para limitar a associação.
Se o cliente não está em posse da informação ao tempo da requisição UDP ASSOCIATE,
o cliente DEVE usar um número de porta e endereço repleto de zeros.

Uma associação UDP termina quando a conexão TCP através da qual a requisição UDP ASSOCIATE chegou termina.

Em resposta a uma requisição UDP ASSOCIATE, os campos BND.PORT e o BND.ADDR
indicam o número de porta/endereço onde o cliente DEVE mandar mensagens de requisições UDP para serem RETRANSMITIDAS (relayed).

Veja se isso esclarece algo da sua implementação, senão, poste código pliz. Bora fuçar rs!

[J.Augusto]

Void

A Arquitetura do código tem um algorítimo já resolvido, ou seja, qualquer Bug que surja será um problema mais profundo, algo nas bibliotecas usadas, não na lógica do Algol.

As APIs já são soluções implementadas e refinadas ao máximo, tão exautivamente testadas ao longo de tantos trabalhos... Não seria inteligente re-escrever alguma modificando para melhorar o que não se melhora :-D

Não tenho dúvidas que o código que você utilizou é muito parecido ao do livro, por isto citei ele, pois, no final de tudo a lógica leva a um algorítimo muito parecido, lembre-se que o ótimo é inimigo do bom, e cuidado ao chegar no limiar da linguagem... Ela está muito proxima ao que os dispositivos físicos podem nos dar...

Subindo um pouco mais para o S.O. Não creio que o empecílio esteja no teu Server mas no script que tem o corpo de execução da camada do sistema operacional, que tal re-escrever o que vc quer sem ser com script mas com uma pequena rotina nem que seja em C++ ? Ou mesmo em PhP dependendo de onde isto esteja rodando... Se falei alguma bobagem fineza me corriga :-)

Ou, divida a tarefa do script em mais núcleos do teu UCP do tipo uns dois rodando ao mesmo tempo com afinidades de nucleos diferentes... Bem que não sei que S.O. você está usando mas é uma alternativa de perfomance mais dedicada caso esta máquina não se preocupe com mais nada na vida...

No mais nem ligue que minhas soluçõe não são muito convencionais não...

Abração :-)

[void_brain_void]

Fala Guzpido Krush & J. Augusto, valeu pelos replys. Acabei descobrindo que o netcat usa write() e o c�digo do cliente socks n�o tratava chamadas write, s� recv() e send(), acho que isso talvez se encaixe no trecho que traduziu: "O comando UDP ASSOCIATE � basicamente designado para aplica��es simples UDP (ex: archie). N�o � geral o suficiente para suportar uma vasta classe de aplica��es que usam tanto TCP quanto UDP;".

O lynx � a mesma coisa, acho que optam por write ao inv�s de send e read ao inv�s de recv para o aplicativo ser facilmente portado at� para caixa de sapato. No caso de UDP sendto, recvfrom.

Eu acabei fazendo algum workaround no c�digo do cara para funcionar, mas considerando que ele nem respondeu, eu nem vou enviar... hehe... Realmente acho que estava bem equivocado o c�digo dele...

Pois �, eu estou agora partindo para testes fora do loopback e tem acontecido erros estranhos, mas que j� suspeito do que seja. Meus testes fora do loopback ainda s�o modestos, limitei a uma rede ponto-a-ponto, o problema � quando acesso uma p�gina no apache com muitas imagens, o texto chega legal mas as imagens corrompem na maioria das vezes, se acesso ftp pelo browser ou pelo console vai tranq�ilo. Suspeito que o problema seja pelo servidor socks e o apache estarem na mesma m�quina, pois o linux n�o calcula certo �s vezes o checksum para pacotes que n�o fluir�o pela rede, se bem que o pacote que repasso vai ser recalculado, mas vai saber. Acho que � isso pois quando acesso via socks server em A o servidor apache de B em B (B manda a requisi��o para A pela p�gina que est� em B), as imagens n�o corrompem. Seria realmente isso? Tem alguma forma de for�ar o kernel do linux calcular certo checksums de pacotes locais?

Colis�o eu sei que n�o ocorre, pelo menos ifconfig n�o contabiliza nada.

Escrever a rotina � at� uma op��o, mas o problema � que se implemento algo errado na rotina, acabo validando errado o server, por isso que testar com outros softwares e scripts seria bom. Eu usei para implementar o socks4 somente firefox e depois esse csocks pelo fato do firefox n�o "bindar" apenas esse aplicativo gerava o bind. O problema todo � que socks5 o firefox n�o usa autentica��o nenhuma e para implement�-lo usei inicialmente o csocks e depois o proxychains, mas chamada bind do socks s� o csocks faz, acho que corretamente...

Escrever software � at� f�cil o dif�cil � validar, ver se o que vc escreve faz realmente sentido.

Depois que tiver um c�digo mais apresent�vel posto sim o aplicativo para quem quiser testar. Aproveitando o ensejo, acho que o pessoal do f�rum deveria juntar e come�ar colocar aplica��es, scripts e etc no istf, criar uma se��o para isso seria legal, fora que ajuda divulgar o grupo e � bacana.