BFW Firewall & Router

por **cfhamid** » Sáb Dez 26, 2009 2:12 am

/etc/rc.d/rc.macip

PROBLEM COMMAND DROP

echo -n "Starting mac/ip control... "
iptables -t nat -F MAC
iptables -t nat -A MAC -p tcp -m multiport --dports $WEBADMIN_PORT,$SSH_PORT -d
readconfig /etc/brazilfw/reserve.cfg | while read IP MAC; do
iptables -t nat -A MAC -m mac --mac-source $MAC -s $IP -j RETURN >/dev
done
for LOCALDEVICES in $(getlocaldevices); do
iptables [color=#FF00BF]-t nat -A MAC -i $LOCALDEVICES -j DROP >/dev/null 2>&1[/color]
done

por **mathcardoso** » Sáb Dez 26, 2009 2:40 pm

Meu controle de Mac x IP esta ativado, mas nao funciona, qualquer pessoa que acessa minha rede consegue acesso a internet, aconteceu isso com mais alguem, foi depois de atualizar para a versao .214.

por **El guapo Dan** » Sáb Dez 26, 2009 7:36 pm

El problema MAC x IP es debido a que en esta nueva version de iptables no es posible hacer filtrado con la tabla mac, la solucion es usar la tabla filter.

Una solucion temporal mientras Wosh lanza una version corregida es la siguiente:

Editar el archivo /etc/rc.d/rc.macip:

Código: Selecionar todos: edit /etc/rc.d/rc.macip

En este archivo, sustiruir todas las ocurrecias de nat por filter, así quedaria el archivo con las sustituciones:

Código: Selecionar todos: #!/bin/sh # rc.macip by Washington Rodrigues 2009 # . /lib/system-functions . /etc/brazilfw/brazilfw.cfg [ -z "$WEBADMIN_PORT" ] && WEBADMIN_PORT=8181 [ -z "$SSH_PORT" ] && SSH_PORT=22 if [ "$USE_MAC_CONTROL" != "yes" ]; then iptables -t filter -F MAC >/dev/null 2>&1 exit fi echo -n "Starting mac/ip control... " iptables -t filter -F MAC iptables -t filter -A MAC -p tcp -m multiport --dports $WEBADMIN_PORT,$SSH_PORT -d $(return_default_ip) -j RETURN >/dev/null 2>&1 readconfig /etc/brazilfw/reserve.cfg | while read IP MAC; do iptables -t filter -A MAC -m mac --mac-source $MAC -s $IP -j RETURN >/dev/null 2>&1 done for LOCALDEVICES in $(getlocaldevices); do iptables -t filter -A MAC -i $LOCALDEVICES -j DROP >/dev/null 2>&1 done echo "done"

Guardamos y salimos....

Despues, editar el archivo /etc/rc.d/rc.firewall:

Código: Selecionar todos: edit /etc/rc.d/rc.firewall

En este archivo es necesario crear otras reglas, así quedaria las parte del archivo que nos interesan con las nuevas reglas:

Código: Selecionar todos: [...] iptables -F iptables -t nat -F iptables -t mangle -F iptables -t filter -F #<--------Observe. iptables -X iptables -t nat -X iptables -t filter -X #<--------Observe. iptables -t mangle -X [...] Y... [...] iptables -t nat -N nat-masks iptables -t nat -N port-forward iptables -t nat -N MAC iptables -t filter -N MAC #<--------Observe. iptables -t nat -N tproxy [...]

Guardamos y salimos...

Luego ejecutamos los siguientes comandos en estricto orden:

Código: Selecionar todos: iptables -t nat -F MAC iptables -t filter -N MAC /etc/rc.d/rc.macip

Eso deberia funcionar..., cuando menos conmigo funcionó...

Saludos.
Daniel.

por **woshman** » Sáb Dez 26, 2009 8:24 pm

o MACIP já corrigi, estou utilizando a tabela mangle.
Agora estou no aguardo para ver se alguem acha mais algum problema ou consiga mostrar o porque da lentidão que alguns andam reclamando, para que eu possa corrigir e subir a nova versão.

por **Lano** » Sáb Dez 26, 2009 9:48 pm

Boa noite!

Não sei se ajuda em alguma coisa, mas tenho aqui um enlace que possui servidores BFW3 em cascata, sendo um em cada ponta.

No ponto A tenho um Pentium III de 1Ghz com 512M de memoria. Com dois links em pppoe, fazendo apenas LB/Qmon, e o Bind.

No ponto B tenho um Core 2 Duo de 2Ghz com 1G de memoria. Fazendo Bind/Squi/Qos - sem subredes.

Atualizei os dois servers com a nova versão .214, durante a madruga. Quando amanheceu, depois de algumas horas de trafego na rede, notei lentidão ao abrir paginas.

Liguei minha maquina direto no server do ponto A para descobrir qual dos dois estava vacilando. Realmente o problema já vinha dele mesmo.

Reiniciei e tudo se normalizou, até que se passaram mais algumas horas de navegação e voltou a ficar lento novamente.

Depois de conferir tudo e fazer algumas verificações, notei que o grafico de utilização da CPU mostrava muita oscilação e períodos de alto processamento (na casa dos 90%).

Daí deduzi o seguinte: como só tinha o Bind ativado nesta maquina, achei que com o passar do tempo (por alguma deficiência qualquer) ele estava aumentando a carga de processamento (ao extremo) proporcionalmente ao seu conteúdo absorvido pelo trafego da rede (puro chutágoras).

Como estas maquinas estão em produção (ignorem esta parte), não tive como confirmar esta teoria. Então no desespero, acabei sobreescrevendo os arquivos de sistema (atraves do WinSPC), com a versão anterior .213, mantendo apenas a pasta [config].

Rebootei, e tudo se normalizou.

Caso este depoimento não acrescente nada, estejam a vontade para deletá-lo.... abraços e boas festas.

esqueci de comentar tambem que os graficos de consumo de banda (em pppoe) não estavam sendo "pintados" de forma correta... apareciam apenas breves picos de consumo em períodos aleatórios.

por **Curvello** » Dom Dez 27, 2009 7:37 am

Bom Dia, a todos!
Woshman, realmente esta acontecendo o problema de lentidão na rede depois da atualização para a versão .214.
já parei o squid e nada, ja parei o QOS e nada, continua lento demais.

por **eduarley** » Dom Dez 27, 2009 7:37 am

Lano escreveu:Desculpem, esqueci de comentar tambem que os graficos de consumo de banda (em pppoe) não estavam sendo "pintados" de forma correta... apareciam apenas breves picos de consumo em períodos aleatórios.

Bom dia amigo.

No meu notei o msm problema um certa lendidão depois de um tempo de ligado e so tem load/qmon com 3 link's.
E estes picos no grafico em períodos aleatórios também mas os picos de 500 a 600 MB deixado o grafico impossivel de ver a velocidade correta. !!!

por **sam_fisher** » Dom Dez 27, 2009 12:47 pm

luapufo escreveu:
sam_fisher escreveu:Opa, beleza a todos, Uma Observação!!!!
Depois que eu Atualizei o Meu Servidor de Produção e mais 5 Aqui de Meus Clientes, Observei que a conexão Ficou mais lento no acesso externo....Eles me disseram a mesma coisa... Então não é só comigo isso...
Meus Parabéns woshman, Ficou muito Bom o Seu Trabalho e também os colaboradores.......

por acaso eu preciso fazer algum ajuste no lado interno para poder melhorar a velocidade no acesso externo?
se tem, é no Qos? ou em outra Área? porque no qos eu aumentei a velocidade e parece que ficou a mesma coisa...
vou testar nos outros servidores de meus clientes pra ver coo fica..

voce desabilitou o connlimit pelo qos de cada usuario?

desculpe, o que estava lento era em questão de acessar o SAPW Remotamente (lado exerno)
como estava com Problemas no (Servidor Central www.sapw.com.br) então ficava muito lento pra acessar o SAPW, mais pra acessar o Servidor
BFW ia na boa....Desculpe pela Falta de Informação...
Quanto a copia do brazilfw.gz e version.inf, tinha esquecido de mencionar /boot/linux, foi falta de atenção...
Mais aqui eu tinha regredido pra 213 fazendo estes procedimentos, mais andei revendo alguns arquivos e coloquei pra funcionar como 213. hoje atualizei pra 214 e esta bom também.....só preciso de rever com você a atualização do SAPW pra versão 214......porque o Bloqueio parou de funcionar. parou entre "aspas" alguns funcionam, outros não...

por **julicravo** » Seg Dez 28, 2009 9:01 am

Relatos da versão 214.

Utilizava a versão 213 a 30 dias sem problemas.
Fiz uma instalação do zero, eis problemas encontrados:

1º Lentidão na navegação, WEBADMIN e pelo PUTTY.

OBS1: Desabilitei o QOS e melhorou significativamente.
OBS2: Quando se está fazendo um download muito grande, o ICMP para o servidor fica em torno de 2000 a 3000 ms!!!

2ª CPU: O processador está chegando a 100% (Vai fritar!!!)

3ª Os gráficos do eth1 e eth2 estão loucos...

4ª A Máquina reinicia muita, não é problema de HARDWARE ( check total)

Obrigado a todos!!!

por **sam_fisher** » Seg Dez 28, 2009 10:36 am

Relatos da versão 3.0.214.

Utilizava a versão 3.0.213 a mais de 30 dias Sem nenhum Problema.
Resolvi Fazer update pra versão 3.0.214 aopareceu os seguinter Problemas:

1º Lentidão na navegação no lado externo, ou seja, tentar acessar outro servidor webadmim via internet.
2º O WEBADMIN também ficou lento, mais não tanto como o putty. o PUTTY leva quase 45 segundos para a escrita aparecer.
Eu escrevo um comando e depois de 45 segundos que aparece.

OBS:Tudo isso só quando estou no lado externo. ou seja, Via Internet. tentando Administrar outro Servidor.
pois no servidor local. esta tudo beleza. as conexões no putty e webadmin esta perfeito, mais acessando de fora fica uma carroça.

OBS2: fiz o comando abaixo que você postou woshman: echo "3.0.213" > /etc/version.info
e fiz update pelo webadmin e o sarg voltou a funcionar. estou testando outras coisas pra ver se aparece ou não outros Problemas..

por **julicravo** » Seg Dez 28, 2009 11:05 am

sam_fisher escreveu:Relatos da versão 3.0.214.

Utilizava a versão 3.0.213 a mais de 30 dias Sem nenhum Problema.
Resolvi Fazer update pra versão 3.0.214 aopareceu os seguinter Problemas:

1º Lentidão na navegação no lado externo, ou seja, tentar acessar outro servidor webadmim via internet.
2º O WEBADMIN também ficou lento, mais não tanto como o putty. o PUTTY leva quase 45 segundos para a escrita aparecer.
Eu escrevo um comando e depois de 45 segundos que aparece.

OBS:Tudo isso só quando estou no lado externo. ou seja, Via Internet. tentando Administrar outro Servidor.
pois no servidor local. esta tudo beleza. as conexões no putty e webadmin esta perfeito, mais acessando de fora fica uma carroça.

OBS2: fiz o comando abaixo que você postou woshman: echo "3.0.213" > /etc/version.info
e fiz update pelo webadmin e o sarg voltou a funcionar. estou testando outras coisas pra ver se aparece ou não outros Problemas..

Amigo,

Você utiliza QOS ???

FAz um download de um arquivo grande, e testa o icmp interno para o seu servidor!!

Depois desabilita o qos e testa também!

Abraços

por **julicravo** » Seg Dez 28, 2009 11:43 am

Não sei se isso é normal, mas a tabela mangle ta crescendo:

só utilizo duas portas, não peguei nem a metade...

Chain route-n (1 references)
pkts bytes target prot opt in out source destination
256 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
254 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
254 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
254 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
251 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
251 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
251 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
249 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
249 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
248 132K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff

Reportando os BUGS!!

Fui

por **tberth** » Seg Dez 28, 2009 11:58 am

tberth escreveu:Após atualizar para versão 3.0.214 via webadmin, parou o acesso a internet, ao webadmin, WINSCP e PUTTY...o que fazer?
Agradeço!

RESOLUÇÃO - O meu problema era o arquivo /etc/brazilfw/logical/internet2 que estava com um endereço ip na mesma faixa do bfw, troquei e resolveu o problema!

por **julicravo** » Seg Dez 28, 2009 12:04 pm

Coloquei uma máquina nova na rede,
Ela pegou ip de uma máquina já Amarrada.

brazilfw.cfg: USE_MAC_CONTROL='yes'

no arquivo reserve.cfg está:

192.168.0.18 00:13:20:95:c3:6a # 1001AA

LOGREAD:
Dec 28 11:28:47 brazilfw daemon.info dhcpd: DHCPACK to 192.168.0.18 (00:24:2b:a4:f9:15) via eth0
Dec 28 11:29:50 brazilfw daemon.info dhcpd: DHCPINFORM from 192.168.0.18 via eth0

iptables -t nat -L -n -v:
0 0 RETURN all -- * * 192.168.0.18 0.0.0.0/0 MAC 00:13:20:95:C3:6A

Tudo isso estava funcionando antes, da migração....

Reportando os BUGS!!

por **tberth** » Seg Dez 28, 2009 12:11 pm

tberth escreveu:O Relatório gerado pelo SARG está com um X vermelho ao lado esquerdo de onde mostram os IPS (Gráfico, Data/hora Relatório), antes mostrava uma imagem de um relogio e um gráfico, na versão 3.0.214 está com X!
Alguém sabe o que é?
Obrigado!

RESOLUÇÃO - Resolvi meu problema, copiei os 3 arquivos da pasta /etc/sarg/images
datetime.png
graph.png
sarg-squidguard-block.png

para a pasta /partition/squid-report/images

PROBLEMA RESOLVIDO!!!

por **pruda** » Seg Dez 28, 2009 12:34 pm

POis entao: dia 23 de dezembro, malas prontas pra viajar, fiz a ultima verifacação do bfw3, com umas correções no qmon, pois estava no mod default... nunca vi o bfw tao rapido e estavel..maravilha.. como os links apresentavam o status "ruim", eu mandei um email a tarde pro tecnico pra fazer as devidas correções no bfw, como ele nao me respondeu eu mesmo estudei e fiz as correções desse problema a noite do dia 23, porem não corrigi o email. Resultado: ele atualizou o bfw no dia 24 de manha e no reinicar ja era: squid 100% no hd,( nao limpou a cache antes de atualizar), o processamento 90 a 100%, eu a 500km do meu servidor, vespera de natal, e so retorno dia 2 de janeiro. Ja estou pensando nas faturas que vencem dia 5 e 10, quem vai querer pagar??? Belo presente de natal, ai juntou tudo né, acho que a casualidade não poderia ser maior, pois sai do ceu no dia 23 e fui parar nos infas dia 24 vespera de natal, com feriado prolongado pra sabado e domingo... e outra não adianta reboot, recriar cache squid, reiniciar rede, ja fiz de tudo e o processamento não para. O que resolveu um pouco foi parar o squid , mas mesmo assim ele vai dando zica, ja nao funfa mais como tava antes.Essa atualização no dia 24 foi pra acabar com o natal de qualquer um. Eu quebrei minha proncipal regra: NÃO MEXA NAQUILO QUE ESTA FUNCIONANDO PERFEITAMENTE!!!!!PRINCIPALMENTE QUANDO VOCE VAI VIAJAR!

por **sam_fisher** » Seg Dez 28, 2009 12:43 pm

julicravo escreveu:
sam_fisher escreveu:Relatos da versão 3.0.214.

Utilizava a versão 3.0.213 a mais de 30 dias Sem nenhum Problema.
Resolvi Fazer update pra versão 3.0.214 aopareceu os seguinter Problemas:

1º Lentidão na navegação no lado externo, ou seja, tentar acessar outro servidor webadmim via internet.
2º O WEBADMIN também ficou lento, mais não tanto como o putty. o PUTTY leva quase 45 segundos para a escrita aparecer.
Eu escrevo um comando e depois de 45 segundos que aparece.

OBS:Tudo isso só quando estou no lado externo. ou seja, Via Internet. tentando Administrar outro Servidor.
pois no servidor local. esta tudo beleza. as conexões no putty e webadmin esta perfeito, mais acessando de fora fica uma carroça.

OBS2: fiz o comando abaixo que você postou woshman: echo "3.0.213" > /etc/version.info
e fiz update pelo webadmin e o sarg voltou a funcionar. estou testando outras coisas pra ver se aparece ou não outros Problemas..

Amigo,

Você utiliza QOS ???

FAz um download de um arquivo grande, e testa o icmp interno para o seu servidor!!

Depois desabilita o qos e testa também!

Abraços

mano, com qos habilitado e fazendo download e fazendo ping pra minha sub-rede: meu ip é 176.12.0.2
Resposta de 176.12.0.1: bytes=32 tempo=1360ms TTL=64
Resposta de 176.12.0.1: bytes=32 tempo=2034ms TTL=64
Resposta de 176.12.0.1: bytes=32 tempo=2858ms TTL=64
Resposta de 176.12.0.1: bytes=32 tempo=3464ms TTL=64

Agora com QoS Desabilitado e fazendo o mesmo download e fazendo o ping pra minha sub-rede:
Disparando 176.12.0.1 com 32 bytes de dados:
Resposta de 176.12.0.1: bytes=32 tempo=1ms TTL=64
Resposta de 176.12.0.1: bytes=32 tempo=2ms TTL=64
Resposta de 176.12.0.1: bytes=32 tempo=2ms TTL=64
Resposta de 176.12.0.1: bytes=32 tempo=2ms TTL=64

OBS: Rede Cabeada...

eu uso administração remota o tempo Todo e a versão 214 esta me matando.......
Administro 4 servidores remotamente com SAPW 3.0 em 2 servidores. ta muito lento pra cessar eles..
mais se eu for para uma maquina cliente no lado interno e acessar a internet, funciona beleza. em qualquer um dos 4.
o Problema é só no Lado Externo......to quase fazendo Backups do mysql,sapw, brazilfw
cd /
tar -cvf brazilfw.tar /etc/brazilfw/
tar -cvf mysql.tar /partition/mysql/
tar -cvf sapw.tar /partition/sapw/
mt
cp /mnt/sapw.bfw /sapw.bfw
copiar pelo winscp para a maquina windows. formatar o servidor com a versão 213
e retornar o backup com os comandos:
tar -zxvf brazilfw.tar
tar -zxvf mysql.tar
tar -zxvf sapw.tar
e Continuar tranquilamente até que a versão 214 se torne estavel...
leva 45 segundos pra aparecer o que eu escrevo no Putty...

por **julicravo** » Seg Dez 28, 2009 1:04 pm

Pessoal,

Vamos ter calma nessa hora....

Eu acredito que o problema esteja nas regras do IPTABLES, pois nesse novo KERNEL o iptables mudou a sintaxe de
algumas regras, eu passei por isso...

Vamos ter calma e esperar WOSHMAN, resolver os problemas, o importante e relatar e esperar....

Eu tinha quase que certeza que essa versão com mudança de KERNEL seria perigosa de primeira, mas vamos em frente
pois essa versão 3.0 é MARAVILHOSAAAAAAAAA.

Reportem os problemas mas não critiquem ou reclamem de nada....

Abraços...

por **luapufo** » Ter Dez 29, 2009 6:51 am

pruda escreveu:POis entao: dia 23 de dezembro, malas prontas pra viajar, fiz a ultima verifacação do bfw3, com umas correções no qmon, pois estava no mod default... nunca vi o bfw tao rapido e estavel..maravilha.. como os links apresentavam o status "ruim", eu mandei um email a tarde pro tecnico pra fazer as devidas correções no bfw, como ele nao me respondeu eu mesmo estudei e fiz as correções desse problema a noite do dia 23, porem não corrigi o email. Resultado: ele atualizou o bfw no dia 24 de manha e no reinicar ja era: squid 100% no hd,( nao limpou a cache antes de atualizar), o processamento 90 a 100%, eu a 500km do meu servidor, vespera de natal, e so retorno dia 2 de janeiro. Ja estou pensando nas faturas que vencem dia 5 e 10, quem vai querer pagar??? Belo presente de natal, ai juntou tudo né, acho que a casualidade não poderia ser maior, pois sai do ceu no dia 23 e fui parar nos infas dia 24 vespera de natal, com feriado prolongado pra sabado e domingo... e outra não adianta reboot, recriar cache squid, reiniciar rede, ja fiz de tudo e o processamento não para. O que resolveu um pouco foi parar o squid , mas mesmo assim ele vai dando zica, ja nao funfa mais como tava antes.Essa atualização no dia 24 foi pra acabar com o natal de qualquer um. Eu quebrei minha proncipal regra: NÃO MEXA NAQUILO QUE ESTA FUNCIONANDO PERFEITAMENTE!!!!!PRINCIPALMENTE QUANDO VOCE VAI VIAJAR!

Primeiro
Olha é com muita infelicidade que leio isto, pois os desenvolvedores se matam fazendo o projeto e quando da uma coisa errado, voces dizem isto, o que tenho a te dizer no mesmo tipo de comentarioa que fez:
BEM FEITO
Em nenhum momento, se falou em usar em produção, se usa é por conta e risco.
Eu tenho varios cliente que usam o BFW 3.0, eu mesmo uso e tive problema no dia 24 e tive que ir ao escritorio no dia 25 consertar, mais por isso eu vou condenar os desenvolvedores?
não, né?
vou fazer que sempre fazia antes, antes de atualizar o servidor, vou instalar em uma maquina virtual.
Pruda eu lamento pela sua viajem, mais manere mais quando for criticar, pois o pessoal aqui trabalha de graça e faz com boa vontade e voce passe a seguir as lei de morphy :o!

E mais uma vez
O BFW 3.0, não é para ser usado em produção, pois os mesmo esta em desenvolvimento, quem quiser usar é por sua conta e risco

por **woshman** » Ter Dez 29, 2009 2:52 pm

BrazilFW 3.0.215
direct: http://www.brazilfw.com.br/users/woshma ... azilfw.iso

Código: Selecionar todos: http://www.brazilfw.com.br/users/woshman/bt/brazilfw.iso

update -> via webadmin

UPDATE/NEW

Kernel 2.6.32.2
iproute2 2.6.31
pppd 2.4.5
whois 5.0.0
tcpdump 4.0.0
Webadmin TraceRoute

BUGFIX

Bloqueio de MAC

por **julicravo** » Ter Dez 29, 2009 2:56 pm

Pessoal,

Observando os processos, com o comando TOP, percebi que o QMON estava alto, então matei o processo.

kill -9 PID

O gráfico de CPU decaiu bastante, antes tava lento e agora pelo menos estou navegando normalmente...

Pra quem está com CPU em alta, verifique os processos e veja se existe algum "Desnecessários" para matar...

Estou fazendo de tudo para normalizar...

********************************************************************************************************************************************

Woshman!

Acaabei de atualizar, me parece que resolveu varios problemas...

Ainda estou testando...

Um pequeno detalhe que eu vi na 214 e que na 215 ainda aparece:

Tenho duas portas de saida redirecionada por um link:443 e 5060

Na tabela MAngle aparece as seguintes regras:

[brazilfw]/etc/brazilfw/ports# iptables -t mangle -L route-n -n -v | more

Código: Selecionar todos: Chain route-n (1 references) pkts bytes target prot opt in out source destination 3018 391K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 3003 388K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2985 387K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2967 386K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2954 385K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2930 380K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2902 373K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2888 372K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2868 371K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2846 368K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2830 367K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2808 364K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2761 331K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2740 330K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2724 328K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2709 327K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2690 326K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2669 323K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2652 322K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2638 321K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2621 320K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff 2608 319K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff

Não peguei nem a metade!

Observando com o comando "TOP", é possível ver que, a cada X minutos ele adciona uma linha na tabela MANGLE.

Não sei se isso é normal ou um BUG!!

Obrigado!!

E Estamos aqui para te ajudar!! Ta ficando 100000000!!!

Abraços...

por **woshman** » Ter Dez 29, 2009 3:52 pm

Poste aqui a config do smart-route "route.cfg" para mim simular esse problema.

por **julicravo** » Ter Dez 29, 2009 4:21 pm

[brazilfw]/etc/brazilfw# more route.cfg

Código: Selecionar todos: yes n internet,internet2 port 443 tcp yes n internet,internet2 port 5060 udp #yes n internet,internet2 port 80 tcp #yes n internet2,internet1 source 192.168.0.69

só tem isso!

Abraço....

por **GEFSANTANA** » Ter Dez 29, 2009 7:50 pm

Averiguei que o acesso SSH via WinSCP na transferência de arquivos está sendo limitado pelo QOS. Pois, segundo implementações recentes não deveria seguir as regras de QOS os Acesso ao Webadmin e SSH.
Perdoe-me, caso esteja enganado.
Abraços...

Código: Selecionar todos: Chain imqdown (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN tcp -- * eth0 192.168.0.0/16 0.0.0.0/0 tcp spt:8181 /* LOCALWEBADMIN */ 0 0 RETURN tcp -- * eth0 172.16.0.0/12 0.0.0.0/0 tcp spt:8181 /* LOCALWEBADMIN */ 1601 1409K RETURN tcp -- * eth0 10.0.0.0/8 0.0.0.0/0 tcp spt:8181 /* LOCALWEBADMIN */ 58172 59M RETURN tcp -- * eth0 192.168.0.0/16 0.0.0.0/0 tcp spt:9122 /* LOCALSSH */ 0 0 RETURN tcp -- * eth0 172.16.0.0/12 0.0.0.0/0 tcp spt:9122 /* LOCALSSH */ 0 0 RETURN tcp -- * eth0 10.0.0.0/8 0.0.0.0/0 tcp spt:9122 /* LOCALSSH */ 382K 394M IMQ all -- * eth0 0.0.0.0/0 0.0.0.0/0 IMQ: todev 1 382K 394M IMQ all -- * eth0 0.0.0.0/0 0.0.0.0/0 IMQ: todev 1 382K 394M IMQ all -- * eth0 0.0.0.0/0 0.0.0.0/0 IMQ: todev 1 Chain imqup (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN tcp -- eth0 * 0.0.0.0/0 192.168.0.0/16 tcp dpt:8181 /* LOCALWEBADMIN */ 0 0 RETURN tcp -- eth0 * 0.0.0.0/0 172.16.0.0/12 tcp dpt:8181 /* LOCALWEBADMIN */ 1874 260K RETURN tcp -- eth0 * 0.0.0.0/0 10.0.0.0/8 tcp dpt:8181 /* LOCALWEBADMIN */ 2972 131K RETURN tcp -- eth0 * 0.0.0.0/0 192.168.0.0/16 tcp dpt:9122 /* LOCALSSH */ 0 0 RETURN tcp -- eth0 * 0.0.0.0/0 172.16.0.0/12 tcp dpt:9122 /* LOCALSSH */ 0 0 RETURN tcp -- eth0 * 0.0.0.0/0 10.0.0.0/8 tcp dpt:9122 /* LOCALSSH */ 469K 130M IMQ all -- eth0 * 0.0.0.0/0 0.0.0.0/0 IMQ: todev 0 469K 130M IMQ all -- eth0 * 0.0.0.0/0 0.0.0.0/0 IMQ: todev 0 469K 130M IMQ all -- eth0 * 0.0.0.0/0 0.0.0.0/0 IMQ: todev 0

por **woshman** » Ter Dez 29, 2009 9:41 pm

julicravo escreveu:Estou com Versão 215:

Estou tentando Agendar uma tarefa e não ta funcionando:

1 * * * * /etc/rc.d/rc.route >/dev/null 2>&1

O processo "cronD" está no ar, já restartei o processo, reload e nada!!

Alguém está com o mesmo problema???

Abraços...

Porque agendar o rc.route a cada 1 minuto?

por **julicravo** » Ter Dez 29, 2009 10:59 pm

woshman escreveu:
julicravo escreveu:Estou com Versão 215:

Estou tentando Agendar uma tarefa e não ta funcionando:

1 * * * * /etc/rc.d/rc.route >/dev/null 2>&1

O processo "cronD" está no ar, já restartei o processo, reload e nada!!

Alguém está com o mesmo problema???

Abraços...

Porque agendar o rc.route a cada 1 minuto?

Porque , quando vc executa, ele zera o SMART route e coloca apenas as duas regras que eu criei...

Porta 443, 5060

yes n internet,internet2 port 443 tcp
yes n internet,internet2 port 5060 udp

Ele apaga as trocentas regras repetidas:

[brazilfw]/etc/brazilfw/ports# iptables -t mangle -L route-n -n -v | more
Chain route-n (1 references)
pkts bytes target prot opt in out source destination
3018 391K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
3003 388K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
2985 387K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
2967 386K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff
2954 385K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 MARK xset 0x1/0xffffffff
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 5060 MARK xset 0x1/0xffffffff

por **julicravo** » Ter Dez 29, 2009 11:29 pm

WOSHMAN:

Mais um BUG para você!!!

O DHCP!!

Colocando uma máquina nova na rede, ele pega um ip já amarrado!!

Isso não acontecia na versão 213.

Código: Selecionar todos: Dec 29 22:32:38 brazilfw daemon.info dhcpd: DHCPRELEASE of 192.168.0.109 from 00:1d:7d:4c:15:a2 via eth0 (not found) Dec 29 22:36:54 brazilfw daemon.info dhcpd: DHCPRELEASE of 192.168.0.109 from 00:1d:7d:4c:15:a2 via eth0 (not found) Dec 29 22:51:09 brazilfw daemon.info dhcpd: DHCPDISCOVER from 00:26:82:03:d5:c9 via eth0 Dec 29 22:51:10 brazilfw daemon.info dhcpd: DHCPOFFER on 192.168.0.3 to 00:26:82:03:d5:c9 (prive-8b1030cac) via eth0 Dec 29 22:51:10 brazilfw daemon.info dhcpd: Wrote 0 deleted host decls to leases file. Dec 29 22:51:10 brazilfw daemon.info dhcpd: Wrote 0 new dynamic host decls to leases file. Dec 29 22:51:10 brazilfw daemon.info dhcpd: Wrote 1 leases to leases file. Dec 29 22:51:10 brazilfw daemon.info dhcpd: DHCPREQUEST for 192.168.0.3 (192.168.0.1) from 00:26:82:03:d5:c9 (prive-8b1030cac) via eth0 Dec 29 22:51:10 brazilfw daemon.info dhcpd: DHCPACK on 192.168.0.3 to 00:26:82:03:d5:c9 (prive-8b1030cac) via eth0 Dec 29 22:51:49 brazilfw daemon.info dhcpd: DHCPINFORM from 192.168.0.3 via eth0 Dec 29 22:51:49 brazilfw daemon.info dhcpd: DHCPACK to 192.168.0.3 (00:26:82:03:d5:c9) via eth0

Sendo que esse IP 3 já ta amarrado com outro MAC.

Código: Selecionar todos: 192.168.0.3 00:1c:c0:ce:57:8f #orion

USE_MAC_CONTROL='yes'

ta criando LEASE!!!

Código: Selecionar todos: lease 192.168.0.3 { starts 3 2009/12/30 02:06:25; ends 2 2038/01/19 03:14:06; cltt 3 2009/12/30 02:06:25; binding state active; next binding state free; hardware ethernet 00:26:82:03:d5:c9; uid "\001\000&\202\003\325\311"; client-hostname "prive-8b1030cac";

Abraço!!!

por **woshman** » Qua Dez 30, 2009 12:23 am

Os dois erros acima citados foram corrigidos com exito. (correção sairá na release 3.0.216).

Aguardando mais relatos de bugs.

por **julicravo** » Qua Dez 30, 2009 7:49 am

woshman escreveu:Os dois erros acima citados foram corrigidos com exito. (correção sairá na release 3.0.216).

Aguardando mais relatos de bugs.

E o CRON ?? Está funcionando ?
Pois como Postei, não está funcionando aqui!

Valeu!!
Quando crescer quero ser igual a você!!!

OBRIGADOOOO!!!!

por **woshman** » Qua Dez 30, 2009 1:03 pm

O cron está funcionando sim.

Depois que voce adiciona a regra no /etc/brazilfw/cron.cfg

vc precisa recarregar o serviço:

Código: Selecionar todos: /etc/init.d/cron reload

por **julicravo** » Qua Dez 30, 2009 2:18 pm

woshman escreveu:O cron está funcionando sim.

Depois que voce adiciona a regra no /etc/brazilfw/cron.cfg

vc precisa recarregar o serviço:

Código: Selecionar todos
/etc/init.d/cron reload

woshman, o cron está ativado, já fiz reload, e tudo mais....

8083 root 2028 S crond

cron.cfg
1 * * * * /etc/rc.d/rc.route >/dev/null 2>&1
A cada 1 minuto!!!

No log olha o que aparece:

Dec 30 10:01:01 brazilfw cron.err crond[8083]: USER root pid 12735 cmd /etc/rc.d/rc.route >/dev/null 2>&1
Dec 30 11:01:01 brazilfw cron.err crond[8083]: USER root pid 11907 cmd /etc/rc.d/rc.route >/dev/null 2>&1
Dec 30 12:01:01 brazilfw cron.err crond[8083]: USER root pid 9986 cmd /etc/rc.d/rc.route >/dev/null 2>&1
Dec 30 14:01:01 brazilfw cron.err crond[8083]: USER root pid 4757 cmd /etc/rc.d/rc.route >/dev/null 2>&1

To fazendo algo errado ???
Abraços....

por **GEFSANTANA** » Qua Dez 30, 2009 2:47 pm

julicravo escreveu:
woshman escreveu:O cron está funcionando sim.
Depois que voce adiciona a regra no /etc/brazilfw/cron.cfg

vc precisa recarregar o serviço:
Código: Selecionar todos
/etc/init.d/cron reload

woshman, o cron está ativado, já fiz reload, e tudo mais....
8083 root 2028 S crond

cron.cfg
1 * * * * /etc/rc.d/rc.route >/dev/null 2>&1
A cada 1 minuto!!!

No log olha o que aparece:

Dec 30 10:01:01 brazilfw cron.err crond[8083]: USER root pid 12735 cmd /etc/rc.d/rc.route >/dev/null 2>&1
Dec 30 11:01:01 brazilfw cron.err crond[8083]: USER root pid 11907 cmd /etc/rc.d/rc.route >/dev/null 2>&1
Dec 30 12:01:01 brazilfw cron.err crond[8083]: USER root pid 9986 cmd /etc/rc.d/rc.route >/dev/null 2>&1
Dec 30 14:01:01 brazilfw cron.err crond[8083]: USER root pid 4757 cmd /etc/rc.d/rc.route >/dev/null 2>&1

To fazendo algo errado ???
Abraços....

O correto seria:

Código: Selecionar todos: 0-59/1 * * * * /etc/rc.d/rc.route >/dev/null 2>&1

por **woshman** » Qua Dez 30, 2009 3:41 pm

julicravo escreveu:No log olha o que aparece:
Dec 30 10:01:01 brazilfw cron.err crond[8083]: USER root pid 12735 cmd /etc/rc.d/rc.route >/dev/null 2>&1
Dec 30 11:01:01 brazilfw cron.err crond[8083]: USER root pid 11907 cmd /etc/rc.d/rc.route >/dev/null 2>&1
Dec 30 12:01:01 brazilfw cron.err crond[8083]: USER root pid 9986 cmd /etc/rc.d/rc.route >/dev/null 2>&1
Dec 30 14:01:01 brazilfw cron.err crond[8083]: USER root pid 4757 cmd /etc/rc.d/rc.route >/dev/null 2>&1

Quando aparece isso no log é porque está certo. O Cron retorna como cron.err mesmo.

por **julicravo** » Qua Dez 30, 2009 4:27 pm

GEFSANTANA escreveu:O correto seria:
Código: Selecionar todos
0-59/1 * * * * /etc/rc.d/rc.route >/dev/null 2>&1

A sintaxe é essa mesma...

Valeu SANTANA!!

Abraços....

por **sam_fisher** » Qua Dez 30, 2009 7:46 pm

Ola a Todos, estou com um problema antigo, mais que eu nunca achei nescessário postar.
mais na urgencia depois dos picos de luz que teve aqui e queimou algumas placas de rede, fui obrigado a colocar algumas placas de rede Intel com Suporte PXE e WOL com chipset Intel 82558
FCC ID:EJMNPDALBANNY. aconteceu isso desde a verão 182 mais sempre deixei pra lá, sempre colocava outra no lugar.
na versão atual (215) ela apresentou uma parada de 50 segundos no boot (internet2)
discando via pppoe. Resolvi inverter, colocar como LOCAL. mesma coisa, leva uns 50 segundos
uso o comando ifconfig eth2 e eth0(depois da inversão) e mostra o IP na boa. mais se dou um ping pela rede de um cliente pro servidor, não responde. dhcp não entrega ip pra ninguem. e ainda no boot, aparece erro no IPWatchD
mostrando erro na eth2 (quando era "internet2") e agora na eth0 (local)
e antes do squid aparece erro de sintaxe no IPTABLE falando algo sobre usar FILTER aon inves de ...... não lembro...
desculpe. escrevendo isso na pressa. preciso sair urgente....

RE-EDITADO
o Problema do IPTABLE é por causa do SAPW, Verifiquei no BOOT, é ele. fiquem tranquilo. ta beleza a 215 e agora a 216 também.
desculpe por ter colocado o IPTABLE na lista. não tem Problemas no IPTABLE. Desculpem por ter postado sem uma verificação concreta..

por **woshman** » Qua Dez 30, 2009 8:56 pm

BrazilFW 3.0.216
direct: http://www.brazilfw.com.br/users/woshma ... azilfw.iso

Código: Selecionar todos: http://www.brazilfw.com.br/users/woshman/bt/brazilfw.iso

update -> via webadmin

build-tree {install/update}

Código: Selecionar todos: get-pkg /users/woshman/build-tree

BUGFIX

/etc/rc.d/rc.route (obrigado julicravo)
/etc/init.d/dhcp (obrigado julicravo)

por **reginaldo** » Qua Dez 30, 2009 10:34 pm

TraceRoute - Rastreio de Rota

Apartir da versão 3.0.215 está disponível no WebAdmin o TraceRoute.

Traceroute:

Mecanismo:

O valor Max_ttl
O endereço do gateway
O tempo de ida e volta (round trip) de cada "probe" bem sucedido.

Telas do Traceroute no WebAdmin do BFW 3.0:

por **cfhamid** » Qui Dez 31, 2009 1:39 am

Not Exist "rp-pppoe.so" in pppd 2.4.5 lib directory???

por **Chefe** » Qui Dez 31, 2009 2:03 am

Hoje atualizei da versão 3.0.213 que estava em perfeito funcionamento para a versão 3.0.216...
Até o presente momento estar tudo nos conformes, SQUID, SARG, DANSGUARDIAN, QOS, MAC-IP....
Qualquer anomalia estarei relatando.

Att: Chefe

por **paulojjj** » Qui Dez 31, 2009 11:33 am

Eu estou usando a versão 3.0.216 e reparei que depois que fiz a atualização desde a 3.0.215, o consumo da CPU aumentou muito, o que antes ficava na faixa de 20% a 40% hoje esta 60% a 80%. Gostaria de saber se tem mais alguém nesta mesma situação e se é normal devido alguns serviços terem sidos adicionados nas atualizações, desde já agradeço e desejo a todos um feliz 2010!

BFW Firewall & Router

Quem está online