[FUG-BR] Kerberos no Debian e no FreeBSD:Enormedesapontamentocomo Free

[Luiz Otavio O Souza]

----- Original Message ----- 

Victor.... ola amigo

Bem, veja bem cara, eu entendo seu desapontamento eu nao conseguir o
que quer com o FreeBSD, mas, vamos aos fatos:

* Se existe no linux mas nao no freebsd, eh pq algum developer de
linux sentiu a necessidade e desenvolvou.
* Portanto, se nao existe (ainda) no freebsd, eh pq nao sentiram tanta
necessidade assim
* Agora, se vc sentiu essa necessidade, manda bala no desenvolvimento,
nao precisa fazer sozinho, entra em contato com a galera q tem o mesmo
interesse

2008/8/25 Victor <victor_volpe em bol.com.br>:
> Infelizmente não. Eles apenas redirecionam, não "mascaram". O tproxy
> funciona pois é um diff pro Kernel do Linux aonde ele faz um tipo de 
> spoof.
>
>
> --
> Atenciosamente,
> Victor Gustavo Volpe
-------------------------

Victor e Mario,

O tproxy do squid usa NAT para fazer o que faz, assim o servidor pode 
multiplexar as requisições do cliente real e do squid no IP do cliente sem o 
risco de haver conflitos (o squid utilizar um par IP/porta que o cliente 
também esta utilizando).

Por isso todo o trafego (a classe IP dos clientes) tem que passar pelo 
servidor com o squid/tproxy, para que esse NAT posso funcionar a contento.

O Squid faz o seguinte, cria um novo socket e pede que o kernel faça o 
source nat dessa conexão para o IP do cliente, simples porém eficiente. 
Foram criadas apenas as funções no kernel que o squid utiliza para amarrar 
um novo socket a um IP para origem da conexão. Fora isso o linux conta com 
uma rotina de nat no kernel que parece ser mais evoluida que a nossa 
libalias.

No FreeBSD o nat é feito via libalias ou via kernel (libalias too), mas os 
dados que vão ser nateados precisam vir através do divert, então o cenário é 
um pouco diferente do linux.

A solução para o FreeBSD na minha opnião pode ser feita com base na libalias 
(que precisará de regras no firewall para funcionar - divert), mas 
funcionaria.

A solução pode ser +/- assim:

Uma parte do natd precisa ser portada para o squid e rodar em uma segunda 
thread (aqui começam os problemas... não sei como o squid se comportaria 
adicionando outra thread).

Assim o squid rodaria duas threads, a principal aonde o squid funciona e 
outra para rodar o libalias (userland) para fazer o tproxy. Como isso 
funciona? simples:

Qaundo o squid abrir uma conexão ele envia uma mensagem para a thread do 
libalias/tproxy informando o par IP/PORTA de origem da conexão e o IP a ser 
utilizado no nat (IP do cliente).

A thread do libalias/tproxy de posse dessa informação faz a configuração 
dinamica para atender a essa unica conexão (bem como os pacotes que 
voltarão).

Uma regra no firewall também será necessária (básica) para passar todos os 
pacotes pela porta de divert utilizada pela thread libaliad/tproxy.

Outra possibilidade seria criar alguma outra forma de comunicar a libalias 
padrão de cada NAT utilizado pelo squid e dai não precisariamos de adicionar 
outra thread, nem o código da libaliad no squid, mas a comunicação 
inter-processos pode ser dificil de ser implementada (principalmente em 
servidores de alta demanda).

Se alguem quiser trocar mais idéias...

[]'s
-luiz