+ Responder ao Tópico



  1. #1

    Padrão Forward Sem NAT!!!

    Pessoal,

    Estou tentando colocar o Tproxy para funcionar, mas tenho algumas dúvidas:

    Pretendo colocá-lo numa máquina com Linux ENTRE os meus clientes e o roteador (onde também faço controle de banda)... É possível instalar o squid com Tproxy numa máquina que não seja o roteador dos clientes, ou seja, não possui os aliases do gateway dos clientes? Se possível, qual a melhor forma para fazer isso, seria configurando uma bridge nas placas de rede dessa máquina??

    É que eu preciso fazer com que os IP´s dos clientes não sejam mascarados quando chegarem ao controle de banda, para que possa fazer com que esteja no proxy ir a toda velocidade para os clientes...

    Qualquer sugestão será bem-vinda...

  2. #2

    Padrão

    ela precisa ser o gateway dos clientes, senao ela "separa" os pacotes..

    outra coisa.. NAO pode fazer nat.. se vc tiver alguma regra que faz nat.. da crash no kernel..



  3. #3

    Padrão

    Citação Postado originalmente por _AGM_ Ver Post
    Pessoal,

    ...para que possa fazer com que esteja no proxy ir a toda velocidade para os clientes...
    quanto a velocidade total procure no google sobre o ZPH (Zero Penalty Hit), patch aplicado no squid e alteração feita no htb para que o que está no proxy vá a toda velocidade para o cliente.

    segue alguns links:
    Linux: Squid + HTB Tools - Cache indo a FULL! [Artigo]
    https://under-linux.org/wiki/index.p...quid-cachefull
    aqui voce acha o ZPH - Squid-cache Zero Penalty Hit patch
    baixa a versao do squid em conformidade com a versao do zph - squid : Optimising Web Delivery

  4. #4

    Padrão

    Neon,

    Já testei o ZPH com o HTB, mas depois que comecei a usar o Mikrotik para controle de banda, nunca mais pensei em usar outra solução, pois é muito fácil de configurar, e tenho um monte de recursos nele que não sei se saberia implementar em outra distro Linux...

    Alexandre, se eu tivesse apenas IP´s válidos nos meus clientes, esta solução seria excelente, pois não faço NAT com os clientes com IP válido... Mas como ficaria essa solução no caso de meus clientes terem também IP Inválido? Tem como eu repassar os pacotes desses clientes com IP Inválido, somente redirecionando o tráfego da porta 80 para a porta do proxy? Tem como fazer isso sem precisar que essa máquina seja o gateway deles???

    Penso em fazer algo assim:

    Clientes > Proxy (TProxy) > Controle de Banda por IP > Link Internet

    Se você ou outra pessoa tiver essa solução implementada e puder fazer para mim, mande uma mensagem privada para combinarmos o $$$, ok???

    [] a todos.



  5. #5

    Padrão

    o tproxy nao funciona com NAT.. se vc fizer NAT da crash no kernel (kernel panic)... e o servidor trava.. ja tentei varias vezes.. com diversas versoes do tproxy e kernel.. mas nenhuma funcionou...

  6. #6

    Padrão

    Citação Postado originalmente por alexandrecorrea Ver Post
    o tproxy nao funciona com NAT.. se vc fizer NAT da crash no kernel (kernel panic)... e o servidor trava.. ja tentei varias vezes.. com diversas versoes do tproxy e kernel.. mas nenhuma funcionou...
    Entaum isso quer dizer que ele só funciona mesmo quando os clientes tem IP válido??? Que pena, pois pensei em fazer um diferencial na minha rede, liberando a velocidade de download do que estiver no meu proxy... Mesmo assim, obrigado..



  7. #7

    Padrão

    voce deve estar confundindo as coisas..

    a função do tproxy eh apenas fazer com que o ip REAL do cliente chegue no destino...

    na situação normal, o ip que CHEGA no destino é o ip do PROXY... usando o tproxy, o ip que chega direto ao destino é o ip do cliente...

    entao, é necessario que todos TENHAM ip valido !

    o sistema q voce quer (download full) chama-se zph, mas esta descontinuado !!

  8. #8

    Padrão

    Não estou confundindo não... Era isso mesmo que eu pensava do TProxy, mas achei que ele poderia fazer isso com meus clientes com IP Inválido também, pois eu deixaria o controle de banda a ser feito entre o proxy e a internet, e não entre os clientes e o proxy...



  9. #9

    Padrão

    Citação Postado originalmente por _AGM_ Ver Post
    Já testei o ZPH com o HTB, mas depois que comecei a usar o Mikrotik para controle de banda, nunca mais pensei em usar outra solução, pois é muito fácil de configurar, e tenho um monte de recursos nele que não sei se saberia implementar em outra distro Linux...
    cara, te juro que nao gostei do controle de banda do mikrotik, acho que é mais porque prefiro centralizar tudo, eu uso mk nas minhas torres mas apenas para autenticacao, bridge e ter performance. Pois é muito melhor que simples radios.

    sobre passar ip valido pelo squid vou encontrar uma solucao pra vc.

    so me responda uma coisa, no seu cliente o ip é valido ou vc so redireciona o trafego de um ip valido para o ip local dele?

  10. #10

    Padrão

    Citação Postado originalmente por neon Ver Post
    cara, te juro que nao gostei do controle de banda do mikrotik, acho que é mais porque prefiro centralizar tudo, eu uso mk nas minhas torres mas apenas para autenticacao, bridge e ter performance. Pois é muito melhor que simples radios.

    sobre passar ip valido pelo squid vou encontrar uma solucao pra vc.

    so me responda uma coisa, no seu cliente o ip é valido ou vc so redireciona o trafego de um ip valido para o ip local dele?
    Na verdade, eu tenho clientes com IP Válido (configurados diretamente no cliente) e também com IP Inválido... Como já disse, minha intenção era de fazer com que os clientes baixassem o que já estivesse em cache do squid sem controle de banda, mas o que não estivesse no cache, bem como todo o tráfego restante (de outras portas) fosse aplicado o controle de banda, que é feito numa outra máquina, entre o proxy e o link de internet... Mas para isso o micro do controle de banda deveria receber as requisições como se as mesmas estivessem partindo diretamente do cliente, e não sendo mascaradas pelo proxy...

    ...



  11. #11

    Padrão

    Citação Postado originalmente por _AGM_ Ver Post
    Na verdade, eu tenho clientes com IP Válido (configurados diretamente no cliente) e também com IP Inválido... Como já disse, minha intenção era de fazer com que os clientes baixassem o que já estivesse em cache do squid sem controle de banda, mas o que não estivesse no cache, bem como todo o tráfego restante (de outras portas) fosse aplicado o controle de banda, que é feito numa outra máquina, entre o proxy e o link de internet... Mas para isso o micro do controle de banda deveria receber as requisições como se as mesmas estivessem partindo diretamente do cliente, e não sendo mascaradas pelo proxy...
    certo, posso lhe dar uma sugestão, nao sei até onde será útil.

    1 - seus clientes com ips validos, coloque um ip invalido nele e faça nat 1-para-1 no ip dele.
    suponha que o ip valido seja 200.200.200.200 e o ip invalido 192.168.0.200.
    no iptables faça..
    # o trafego de 192.168.0.200 sair como 200.200.200.200
    iptables -t nat -A PREROUTING -s 192.168.0.200 -j SNAT --to 200.200.200.200
    # trafego destinado a 200.200.200.200 redirecionar para 192.168.0.200
    iptables -t nat -A PREROUTING -d 200.200.200.200 -j DNAT --to 192.168.0.200

    2 - e faça seu cliente, mesmo com ip invalido passar pelo squid normalmente
    # acl do cliente
    acl cliente200 src 192.168.0.200
    # forçar a saida do cliente com o ip 200.200.200.200
    tcp_outgoing_address 200.200.200.200 cliente200
    http_access allow cliente200

    3 - crie um alias ao ip 200.200.200.200 na sua eth de internet. para poder o squid usar tcp_outgoing_address

    4 - libere o forward dos ips.
    iptables -A FORWARD -d 200.200.200.200 -j ACCEPT
    iptables -A FORWARD -d 192.168.0.200 -j ACCEPT
    iptables -A FORWARD -s 200.200.200.200 -j ACCEPT
    iptables -A FORWARD -s 192.168.0.200 -j ACCEPT


    conclusao:
    seu cliente entra no squid com ip invalido e sai com o ip desejado.
    e seu cliente passar pelo firewall com ip invalido e sai com o ip desejado.

    sobre o cache full, pode usar o zph como citado anteriormente

    ou faz SNAT no mikrotik, que o webcache do mikrotik usa cachefull tb. so nao sei se tem a possibilidade de fazer tcp_outgoing_address no mk.

    nao custa tentar ajudar.

  12. #12

    Padrão

    na verdade o proxy nao precisa saber o ip dos seus clientes para fazer isso ai... o gateway recebe o pacote ve se eh do cache.. se for envia pro destino (cliente) sem velocidade (o gateway neste caso SABE quem eh o cliente)...



  13. #13

    Padrão

    Citação Postado originalmente por alexandrecorrea Ver Post
    na verdade o proxy nao precisa saber o ip dos seus clientes para fazer isso ai... o gateway recebe o pacote ve se eh do cache.. se for envia pro destino (cliente) sem velocidade (o gateway neste caso SABE quem eh o cliente)...
    nao entedi sobre o que diz dizer com "pra fazer isso ai..."

    se for sobre o alias do ip...

    caso nao queira que o pacote passe pelo squid, nao precisa criar o alias mesmo nao. o gw (gateway) realmente sabe qual o cliente (ele marca os pacotes do FORWARD).

    agora se for passar os ips validos/invalidos pelo squid (sem tproxy) vai precisar criar o alias sim.

    porque para o squid poder mudar a origem, ele (o squid) tem q pode usar o ip e para isso vc precisa ter o referido ip na sua máquina do proxy, senao o squid dá o seguinte erro:

    commBind: Cannot bind socket FD 38 to 200.200.200.200:0: (99) Cannot assign request address

    que significa que o squid nao consegiu atribuir o endereço especificado na variavel tcp_outgoing_address porque o mesmo nao pertence a máquina do proxy.

    agora se tiver uma solução mais facil, passe pra nós.

    assim eu aplico no meu cenário tb.

    até.

  14. #14

    Padrão

    o tproxy+squid precisam rodar no GATEWAY



  15. #15

    Padrão

    Neon,

    Vou testar a sua dica aqui e depois posto os resultados... Se funcionar, já ajuda bastante quanto ao excesso de conexões partindo do mesmo IP... Sites como o Google.com.br, por exemplo, estão dando problema aqui por causa do excesso de conexões do mesmo IP... Assim, poderia definir grupos de clientes a saírem cada um com um IP diferente...

  16. #16

    Padrão

    Citação Postado originalmente por _AGM_ Ver Post
    Vou testar a sua dica aqui e depois posto os resultados... Se funcionar, já ajuda bastante quanto ao excesso de conexões partindo do mesmo IP... Sites como o Google.com.br, por exemplo, estão dando problema aqui por causa do excesso de conexões do mesmo IP... Assim, poderia definir grupos de clientes a saírem cada um com um IP diferente...
    dica,

    já que vc usa mk, usa o limite de conexoes do mk para resolver este problema.



  17. #17

    Padrão

    Neon,

    Tentei aplicar a sua dica, mas quando executo a regra:
    iptables -t nat -A PREROUTING -s 10.10.216.2 -j SNAT --to 200.200.200.200

    (com os ip´s corretos, é claro), dá a seguinte mensagem de erro:
    iptables: Unknown error 4294967295

    Sendo que o IP do meu cliente é 10.10.216.2/30 e o alias 10.10.216.1/30 está criado na eth1, e o IP válido 200.200.200.200 está criado como alias na minha eth0...

    Tens alguma dica se essa regra está correta???

  18. #18

    Padrão

    SNAT vc usa na POSTROUTING
    DNAT vc usa na PREROUTING

    _AGM_ sobre os dwl, por enquanto nao posso fechar...



  19. #19

    Padrão

    Citação Postado originalmente por alexandrecorrea Ver Post
    _AGM_ sobre os dwl, por enquanto nao posso fechar...
    DWL??? Desculpa, mas não estou recordando do que se trata....

  20. #20

    Padrão

    Citação Postado originalmente por alexandrecorrea Ver Post
    SNAT vc usa na POSTROUTING
    DNAT vc usa na PREROUTING
    AGM,

    deverá usar a seguinte regra para seu cliente:
    iptables -t nat -A POSTROUTING -s 10.10.216.2 -j SNAT --to 200.200.200.200

    POSTROUTING no lugar de PREROUTING