[FUG-BR] Testando...
Prezados Este é um teste para ver se a lista ainda está ativa: há algum tempo eu não tenho recebido emails. Um abraço Edu -- Eduardo Lemos de Sa Professor Titular Dep. Quimica da Universidade Federal do Paraná fone: +55(41)3361-3300 fax: +55(41)3361-3186 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Testando Lusca no FreeBSD 8.0-RELEASE-p2
Em Mon, 19 Apr 2010 22:21:32 -0300 Marcelo Gondim gon...@linuxinfo.com.br, conhecido consumidor/usuário de drogas (Windows e BigMac com Coke) escreveu: graaande marcelo gondim. Sempre procurando o inusitado, né? (rs) E ao invés de abrir a página requisitada, exibia uma página de erro do Lusca. qual a mensagem? Alguém já passou por isso e sabe como resolver? Tentei de tudo :D mas ainda não descobri. Nem que seja alguma doc, howto, faq rsrsrsrs Qualquer coisa pra eu sair desse erro. Rsrsrs bão... não conheço o microtik então posso estar errado, mas enfim, palpite qualquer um serve :) do que entendi, sem me estender muito, é que o seu proxy está colocado mais ou menos assim: . /[proxy] |Internet|-[gateway] . \[LAN] então alguma máquina (em LAN) envia a solicitação ao gateway que encaminha para o proxy; êste então faz o seu trabalho e, quando não tem nada armazenado solicita saida ao gateway. é possível que vc esteja em LOOP: o proxy solicita ao gateway que envia para o proxy. Normalmente, quando vc faz o proxy transparente desse modo, vc define (no gateway) que aquilo que vier do proxy seja enviado direto para a Internet. Básicamente, suas regras de fwll devem colocar mais ou menos assim: tudo o que vier da rede minha_rede/24 EXCETO proxy_host/32 vai para o proxy_host/32 ou então avalie ANTES da regra de proxy, colocando mais ou menos assim: se oriundo de proxy_host/32 vai direto pra Internet [após essa, vem a regra de proxy transparente] avalie tudo com o tcpdump/wireshark. flames /dev/null -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 154 Não uso drogas - 100% Miko$hit-free As pessoas fazem coisas horríveis por dinheiro, até trabalhar - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Testando Lusca no FreeBSD 8.0-RELEASE-p2
Voce tem que fazer uma modificação no codigo fonte do lusca, para ele
poder rodar com o usuario root.
No codigo fonte do lusca edite o arquivo src/main.c, comente essa parte
de if, para que ele não verifique se esta rodando como root.
if (geteuid() == 0) {
debug(0, 0) (Squid is not safe to run as root! If you must\n);
debug(0, 0) (start Squid as root, then you must configure\n);
debug(0, 0) (it to run as a non-priveledged user with the\n);
debug(0, 0) ('cache_effective_user' option in the config file.\n);
fatal(Don't run Squid as root, set 'cache_effective_user'!);
}
Se voce estiver usando a ultima versão do lusca no ports, voce so
precisa fazer essa alteração citada acima, caso contrario, voce tambem
tem que fazer isso:
No arquivo libiapp/comm_ips_freebsd.c, substitua aonde tem IP_NONLOCALOK
para IP_BINDANY.
Depois no squid.conf
cache_effective_user root
cache_effective_group wheel
Pra mim funcionou assim, mas esse seu exemplo é seu ambiente de trabalho
ou voce esta fazendo testes? pois com essa classe invalida não tem
sentido usar T-PROXY.
On Mon, 2010-04-19 at 22:21 -0300, Marcelo Gondim wrote:
Buenas lista,
Esses dias resolvi montar um ambiente aqui pra testes pois estou querendo
implementar um Lusca/Squid com FreeBSD 8 usando o TProxy e assim o cliente
sair com seu próprio IP pelo Proxy. Antes disso fiz funcionar um Lusca
transparente em um FreeBSD 8 como bridge redirecionando os acessos pro Proxy
via PF porque com o ipfw não consegui mas não testei muito. :) perdi um bom
tempo porque estou mais acostumado com o Netfilter/IPTables. Esse ambiente
de bridge o servidor de teste estava com 2 interfaces de rede. Lógico :)
Nesse ambiente transparente o usuário não sabia da existência do Proxy e
ainda pude fazer algumas regras de Firewall. Ficou show de bola!
A conf que fiz como bridge, sendo 192.168.10.171 o IP do servidor Proxy
Lusca Transparent:
/etc/rc.conf
cloned_interfaces=bridge0
ifconfig_bridge0=inet 192.168.10.171 netmask 255.255.255.0 addm re0 addm
em0 up
ifconfig_re0=up
ifconfig_em0=up
defaultrouter=192.168.10.254
hostname=proxy.localdomain.net
keymap=br275.iso.acc
sshd_enable=YES
squid_enable=YES
pf_enable=YES
pf_rules=/etc/pf.conf
/etc/pf.conf
rdr pass on bridge0 inet proto tcp from any to any port 80 - 192.168.10.171
port 3128
No kernel adicionei:
device pf
device pflog
device pfsync
device if_bridge
Se for usar o squid31 do ports ainda precisei fazer isso. O lusca não
precisei:
===
chgrp squid /dev/pf
chmod 660 /dev/pf
no squid.conf:
==
http_port 192.168.10.171:3128 transparent
Foi importante usar o IP ao invés de 127.0.0.1, porque não funcionou de
outro jeito. :)
Aí da minha estação(192.168.10.177) saía um cabo que entrava numa interface
do proxy e do proxy outro cabo no meu router Mikrotik e o gateway da estação
era o 192.168.10.254.
Essa solução ficou perfeita pra bridge transparent mas não consegui fazer
com tproxy. Então mudei o ambiente de teste.
Nesse novo ambiente o servidor FreeBSD tinha apenas 1 interface de rede e
nesse caso usei o ipfw fwd para direcionar as requisições para o Proxy, sem
a bridge. Minha configuração ficou assim:
/etc/rc.conf
ifconfig_re0=inet 192.168.10.171 netmask 255.255.255.0 up
defaultrouter=192.168.10.254
hostname=proxy.localdomain.net
keymap=br275.iso.acc
sshd_enable=YES
squid_enable=YES
firewall_enable=YES
firewall_script=/etc/rc.ipfw
/etc/rc.ipfw
#!/bin/sh
fw=/sbin/ipfw
rede_interna=192.168.10.0/24
ifi=re0
#
$fw -f flush
#
# Liberando rede da Caixa Econômica Federal do Proxy
$fw add fwd 192.168.10.254 all from $rede_interna to 200.201.160.0/20 80 in
via $ifi
#
$fw add fwd 127.0.0.1,3128 tcp from $rede_interna to any 80 in via $ifi
/etc/sysctl.conf
net.inet.ip.forwarding=1
No kernel usei essa conf:
=
options IPFIREWALL
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT
options DUMMYNET
options HZ=1000
options LIBALIAS
squid.conf:
===
http_port 3128 transparent
Coloquei o gateway da minha estação sendo o 192.168.10.171 e funcionou
perfeitamente o modo transparent do Proxy. Aí fiz o seguinte para tentar
usar o tproxy:
No squid.conf mudei para:
=
http_port 3128 transparent tproxy
No mikrotik router 192.168.10.254 criei as seguintes regras:
add comment=Proxy disabled=no distance=1 dst-address=0.0.0.0/0
gateway=192.168.10.171 routing-mark=proxy scope=30 target-scope=10
add action=mark-routing chain=prerouting comment=Proxy IN disabled=no
src-port=80 in-interface=ether1 new-routing-mark=proxy
[FUG-BR] Testando Lusca no FreeBSD 8.0-RELEASE-p2
Buenas lista, Esses dias resolvi montar um ambiente aqui pra testes pois estou querendo implementar um Lusca/Squid com FreeBSD 8 usando o TProxy e assim o cliente sair com seu próprio IP pelo Proxy. Antes disso fiz funcionar um Lusca transparente em um FreeBSD 8 como bridge redirecionando os acessos pro Proxy via PF porque com o ipfw não consegui mas não testei muito. :) perdi um bom tempo porque estou mais acostumado com o Netfilter/IPTables. Esse ambiente de bridge o servidor de teste estava com 2 interfaces de rede. Lógico :) Nesse ambiente transparente o usuário não sabia da existência do Proxy e ainda pude fazer algumas regras de Firewall. Ficou show de bola! A conf que fiz como bridge, sendo 192.168.10.171 o IP do servidor Proxy Lusca Transparent: /etc/rc.conf cloned_interfaces=bridge0 ifconfig_bridge0=inet 192.168.10.171 netmask 255.255.255.0 addm re0 addm em0 up ifconfig_re0=up ifconfig_em0=up defaultrouter=192.168.10.254 hostname=proxy.localdomain.net keymap=br275.iso.acc sshd_enable=YES squid_enable=YES pf_enable=YES pf_rules=/etc/pf.conf /etc/pf.conf rdr pass on bridge0 inet proto tcp from any to any port 80 - 192.168.10.171 port 3128 No kernel adicionei: device pf device pflog device pfsync device if_bridge Se for usar o squid31 do ports ainda precisei fazer isso. O lusca não precisei: === chgrp squid /dev/pf chmod 660 /dev/pf no squid.conf: == http_port 192.168.10.171:3128 transparent Foi importante usar o IP ao invés de 127.0.0.1, porque não funcionou de outro jeito. :) Aí da minha estação(192.168.10.177) saía um cabo que entrava numa interface do proxy e do proxy outro cabo no meu router Mikrotik e o gateway da estação era o 192.168.10.254. Essa solução ficou perfeita pra bridge transparent mas não consegui fazer com tproxy. Então mudei o ambiente de teste. Nesse novo ambiente o servidor FreeBSD tinha apenas 1 interface de rede e nesse caso usei o ipfw fwd para direcionar as requisições para o Proxy, sem a bridge. Minha configuração ficou assim: /etc/rc.conf ifconfig_re0=inet 192.168.10.171 netmask 255.255.255.0 up defaultrouter=192.168.10.254 hostname=proxy.localdomain.net keymap=br275.iso.acc sshd_enable=YES squid_enable=YES firewall_enable=YES firewall_script=/etc/rc.ipfw /etc/rc.ipfw #!/bin/sh fw=/sbin/ipfw rede_interna=192.168.10.0/24 ifi=re0 # $fw -f flush # # Liberando rede da Caixa Econômica Federal do Proxy $fw add fwd 192.168.10.254 all from $rede_interna to 200.201.160.0/20 80 in via $ifi # $fw add fwd 127.0.0.1,3128 tcp from $rede_interna to any 80 in via $ifi /etc/sysctl.conf net.inet.ip.forwarding=1 No kernel usei essa conf: = options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options DUMMYNET options HZ=1000 options LIBALIAS squid.conf: === http_port 3128 transparent Coloquei o gateway da minha estação sendo o 192.168.10.171 e funcionou perfeitamente o modo transparent do Proxy. Aí fiz o seguinte para tentar usar o tproxy: No squid.conf mudei para: = http_port 3128 transparent tproxy No mikrotik router 192.168.10.254 criei as seguintes regras: add comment=Proxy disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.10.171 routing-mark=proxy scope=30 target-scope=10 add action=mark-routing chain=prerouting comment=Proxy IN disabled=no src-port=80 in-interface=ether1 new-routing-mark=proxy passthrough=yes protocol=tcp dst-address=192.168.10.0/24 Obs.: ether1 é a interface de fora da Internet e a ether2 a interface da rede interna. No rc.ipfw as regras ficaram assim no final do arquivo: === $fw add fwd 127.0.0.1,3128 tcp from $rede_interna to any 80 in via $ifi $fw add fwd 127.0.0.1,3128 tcp from any 80 to $rede_interna in via $ifi E mesmo assim o tproxy não funcionou. No cache.log acusava o seguinte erro: 2010/04/19 11:03:00| comm_fdopen6: FD 21: TPROXY comm_ips_bind_rem() failed: errno 1 ((1) Operation not permitted) 2010/04/19 11:03:01| comm_fdopen6: FD 23: TPROXY comm_ips_bind_rem() failed: errno 1 ((1) Operation not permitted) 2010/04/19 11:03:02| comm_fdopen6: FD 24: TPROXY comm_ips_bind_rem() failed: errno 1 ((1) Operation not permitted) 2010/04/19 11:03:02| comm_fdopen6: FD 26: TPROXY comm_ips_bind_rem() failed: errno 1 ((1) Operation not permitted) 2010/04/19 11:03:02| comm_fdopen6: FD 28: TPROXY comm_ips_bind_rem() failed: errno 1 ((1) Operation not permitted) 2010/04/19 11:03:02| comm_fdopen6: FD 30: TPROXY comm_ips_bind_rem() failed: errno 1 ((1) Operation not permitted) E ao invés de abrir a página requisitada, exibia uma página de erro do Lusca. Alguém já passou por isso e sabe
[FUG-BR] Testando IPFW NAT
Novamente, vamos la. Passei a utilizar o PF mesmo para fazer o NAT, pois com o IPFW não consegui. Regras de nat do PF: lan_net = 192.168.17.0/24 ext_if1 = re0 ext_if2 = rl1 ext_gw1 = 192.168.28.1 ext_gw2 = 192.168.29.1 nat on $ext_if1 from $lan_net to ! $lan_net - 192.168.28.2 nat on $ext_if2 from $lan_net to ! $lan_net - 192.168.29.2 O nat funciona, consigo pingar o IP dos dois modem's ADSL (192.168.28.1 e 192.168.29.1) Configurei as duas rotas com o setfib 0 e 1 setfib 0 route add default 192.168.28.1 e setfib 1 route add default 192.168.29.1 Com o comando setfib 0 ping registro.br recebo respostas. Com o comando setfib 1 ping www.terra.com.br também recebo respotas. Bom, apartir daí comecei os testes marcando os pacotes icmp para sair pelo gw2, o que ocorreu com sucesso. Conforme mostrado abaixo: ipfw add 55 setfib 1 icmp from any to any # tcpdump -i rl1 -n -p icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on rl1, link-type EN10MB (Ethernet), capture size 96 bytes 18:44:19.060237 IP 192.168.27.1 200.160.2.3: ICMP echo request, id 9659, seq 37033, length 40 18:44:19.184044 IP 200.160.2.3 192.168.27.1: ICMP echo reply, id 9659, seq 37033, length 40 18:44:20.060250 IP 192.168.27.1 200.160.2.3: ICMP echo request, id 9659, seq 37034, length 40 18:44:20.175981 IP 200.160.2.3 192.168.27.1: ICMP echo reply, id 9659, seq 37034, length 40 Os outros pacotes saem todos pelo gw1, sem executar nenhuma regra para que façam isso, depois do sucesso com o teste de ping criei uma regra para jogar a porta 80 pra cima do gw2, (ipfw add 50 setfib 1 all from 192.168.17.0/24 to any 80 in via rl0) isso não funcionou. Nem mesmo se eu fizer ipfw add 55 setfib 1 tcp from any to any 80 não funciona. O ipfw possui algum esquema de logar os pacotes tipo o pass log do PF? Alguém sabe como utilizar? Será que continuo fazendo alguma coisa errada? Como eu já disse no post de ontem, no PF eu consigo fazer mas tenho um firewall em produção com uma quantia enorme de regras no IPFW, este firewall faz uma bridge para algumas redes de IPs publicos e Nat para duas redes de IPs privados, com controle de banda, etc... tudo no IPFW. Sem condições de migrar totalmente para o PF (com bastante esforço seria possivel), mas como tempo não não brota em árvore, por enquanto tem que ficar no IPFW mesmo. Desculpem a insistencia no assunto, mas é de meu interesse resolver este problema e não sei mais onde procurar. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Testando ipfw nat
Boa tarde Pessoal. Estou testando o ipfw com o nat habilitado no kernel e está funcionando, alguém está também testando ??? Ou usando em produção??? Eu publiquei algumas regras para o NAT e redirecionamento de portas que eu precisava fazer para substituir o NATD : http://tiagonux.blogspot.com/2008/12/natd-j-era-agora-ipfw-nat-no-freebsd.html Estou pesquisando para o ipfw + nat fazer balanceamento de entrada e saída, alguém que tenha algo já rodando por favor publique pois não temos muita documentação a respeito com o ipfw + nat. att Tiago Eu fiz alguns testes Tiago, quando tentei utilizar em produção tive alguns problemas no redirecionamento de portas (se ainda me lembro bem), não tive tempo para analisar o problema e acabei voltando para o natd. Agora estou com o mesmo problema no natd :) Mas na verdade estou respondendo sobre o balanceamento... atualize para o 7_STABLE (pelo menos) e utilize a opção ROUTETABLES=X (X igual ao número de conexões/gateways que você tem). Veja o log referente a esse commit no /usr/src/UPDATING: 20080724: I have MFC'd in code to support multiple routing tables. see the man pages setfib(1) and setfib(2). This is a backwards compatible version, but to make use of it you need to compile your kernel with options ROUTETABLES=2 (or more up to 16). Eu compilei o(s) kernel(s) testado(s) aqui com ROUTETABLES=4 mas todos estão com 2 links. Com isso você pode por dois (ou quantos você configurar até o máximo de 16) default gateways (um para cada conexão) e fazer o seu roteamento sem fwd, route-to, etc, etc :) Da mesma maneira que no ipfw nat, a documentação não é o forte dessa solução por enquanto, por outro lado... funciona (e bem) ! :) Balanceamento no freebsd agora é feito com estilo ;) Abraços, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Testando ipfw nat
Boa tarde Pessoal. Estou testando o ipfw com o nat habilitado no kernel e está funcionando, alguém está também testando ??? Ou usando em produção??? Eu publiquei algumas regras para o NAT e redirecionamento de portas que eu precisava fazer para substituir o NATD : http://tiagonux.blogspot.com/2008/12/natd-j-era-agora-ipfw-nat-no-freebsd.html Estou pesquisando para o ipfw + nat fazer balanceamento de entrada e saída, alguém que tenha algo já rodando por favor publique pois não temos muita documentação a respeito com o ipfw + nat. att Tiago - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
