[FUG-BR] Kerberos no Debian e no FreeBSD:Enormedesapontamentocomo Free
Luiz Otavio O Souza
luiz em visualconnect.com.br
Terça Agosto 26 09:58:32 BRT 2008
----- 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
Mais detalhes sobre a lista de discussão freebsd