Re: rinetd

2013-01-31 Por tôpico Linux - Junior Polegato 

Em 30-01-2013 20:38, Caio Ferreira escreveu:

Prezado Junior
Depois que eu removi o software rinet e acrescentei as duas linhas na 
firewall o redirecionamento esta sendo feito.
O squid esta apresentando um problema, mensagem de erro "The request 
or reply is too large.", mas vou dar uma pesquisada na internet sobre 
essa mensagem.

Desde já, obrigado pela ajuda !!


Olá!

Conseguiu fazer funcionar tudo agora? O que fez?

[]'s
 Junior Polegato



--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/510abc98.2010...@juniorpolegato.com.br

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Prezado Junior

Depois que eu removi o software rinet e acrescentei as duas linhas na
firewall o redirecionamento esta sendo feito.

O squid esta apresentando um problema, mensagem de erro "The request or
reply is too large.", mas vou dar uma pesquisada na internet sobre essa
mensagem.

Desde já, obrigado pela ajuda !!

caio abreu ferreira

2013/1/30 Linux - Junior Polegato 

> Em 30-01-2013 17:03, Caio Ferreira escreveu:
>
>> Prezado Junior
>>
>> Novas informações, e parecem ser animadoras.
>> Instalei o firefox na estação (192.168.0.200) e alterei a configuração de
>> conexão três vezes.
>> 1 - apontando o browser da estação para o proxy, 192.168.0.2 e porta 3128
>> Consegui navegar normalmente e os arquivos de log do squid foram
>> alterados.
>> 2 - apontando o browser da estação para o gateway, 192.168.0.1 e porta 80
>> Consegui navegar normalmente e os arquivos de log do squid foram
>> alterados.
>> Consegui navegar normalmente e o arquivos de log do rinetd foi alterado.
>> 3 - não apontei o browser da estação para o gateway(no-proxy)
>> Consegui navegar normalmente e os arquivos de log do squid NÃO foram
>> alterados.
>> Consegui navegar normalmente e o arquivos de log do rinetd NÃO foi
>> alterado.
>> Será que o problema esta no squid?
>>
>
> Ah! Agora entendi o que você quer fazer, o rinetd não serve para isso,
> vai ter que usar iptables mesmo.
>
> O rinetd somente "desvia" o fluxo se você acessar o 192.168.0.1 na porta
> 80 diretamente, se colocar qualquer outro site, não vai rolar.
>
> O propósito do rinetd foi motivado para quando você tem um servidor web,
> por exemplo, em 200.200.200.100 e você muda ele para 200.200.200.200, aí
> até os servidores de DNS se atualizarem com o novo IP, muita requisição
> ainda vai chegar no 200.200.200.100, então você usa o rinetd no
> 200.200.200.100 para redirecionar todas as requisições que chegam a este
> servidor para o servidor novo, entendeu?
>
> O que você quer é que qualquer requisição para qualquer IP na porta de
> destino 80 que chegue ao firewall (192.168.0.1), seja direcionada para o
> squid, porta 3128, no IP 192.168.0.2, correto? O rinetd não faz isso, só
> iptables mesmo.
>
> Retire o rinetd do seu firewall e crie a regra:
>
> (1) iptables -t nat -A PREROUTING -s 192.168.0.0/24 -i ethX -p tcp
> --dport 80 -j DNAT --to 192.168.0.2:3128
>
> Onde ethX é a interface que está com IP 192.168.0.1, ligada na rede
> interna, traduzindo:
>
> (1) Todo pacote IP antes de ser roteado com IP de origem pertencente à
> rede 192.168.0.0/24 e chegou pela interface ethX, protocolo TCP e cuja
> porta de destino for 80, não importando o IP de destino, redireciona este
> pacote para o IP 192.168.0.2 e porta 3128.
>
> Somente (1) pode não ser suficiente pois os pacotes vão para 192.168.0.2
> com IP de origem da mesma rede e vai responder diretamente para o IP da
> rede, contudo este IP esterava uma resposta do IP (servidor web) externo, o
> que a flag transparent do squid pode resolver. No caso de não funcionar,
> precisa de uma segunda regra:
>
> (2) iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.2 -o
> ethX -p tcp --dport 3128 -j SNAT --to 192.168.0.1
>
> Esta diz que todo pacote IP que sair com IP de origem da rede
> 192.168.0.0/24 e destino 192.168.0.2, tcp e porta 3128, deve ir com IP
> 192.168.0.1, assim o squid responde para o 192.168.0.1 que responde para a
> estação.


> []'s
> Junior Polegato
>

Re: rinetd

2013-01-30 Por tôpico Linux - Junior Polegato 

Em 30-01-2013 17:03, Caio Ferreira escreveu:

Prezado Junior
Novas informações, e parecem ser animadoras.
Instalei o firefox na estação (192.168.0.200) e alterei a configuração 
de conexão três vezes.

1 - apontando o browser da estação para o proxy, 192.168.0.2 e porta 3128
Consegui navegar normalmente e os arquivos de log do squid foram 
alterados.

2 - apontando o browser da estação para o gateway, 192.168.0.1 e porta 80
Consegui navegar normalmente e os arquivos de log do squid foram 
alterados.

Consegui navegar normalmente e o arquivos de log do rinetd foi alterado.
3 - não apontei o browser da estação para o gateway(no-proxy)
Consegui navegar normalmente e os arquivos de log do squid NÃO foram 
alterados.
Consegui navegar normalmente e o arquivos de log do rinetd NÃO foi 
alterado.

Será que o problema esta no squid?


Ah! Agora entendi o que você quer fazer, o rinetd não serve para 
isso, vai ter que usar iptables mesmo.


O rinetd somente "desvia" o fluxo se você acessar o 192.168.0.1 na porta 
80 diretamente, se colocar qualquer outro site, não vai rolar.


O propósito do rinetd foi motivado para quando você tem um servidor web, 
por exemplo, em 200.200.200.100 e você muda ele para 200.200.200.200, aí 
até os servidores de DNS se atualizarem com o novo IP, muita requisição 
ainda vai chegar no 200.200.200.100, então você usa o rinetd no 
200.200.200.100 para redirecionar todas as requisições que chegam a este 
servidor para o servidor novo, entendeu?


O que você quer é que qualquer requisição para qualquer IP na porta de 
destino 80 que chegue ao firewall (192.168.0.1), seja direcionada para o 
squid, porta 3128, no IP 192.168.0.2, correto? O rinetd não faz isso, só 
iptables mesmo.


Retire o rinetd do seu firewall e crie a regra:

(1) iptables -t nat -A PREROUTING -s 192.168.0.0/24 -i ethX -p tcp 
--dport 80 -j DNAT --to 192.168.0.2:3128


Onde ethX é a interface que está com IP 192.168.0.1, ligada na rede 
interna, traduzindo:


(1) Todo pacote IP antes de ser roteado com IP de origem pertencente à 
rede 192.168.0.0/24 e chegou pela interface ethX, protocolo TCP e cuja 
porta de destino for 80, não importando o IP de destino, redireciona 
este pacote para o IP 192.168.0.2 e porta 3128.


Somente (1) pode não ser suficiente pois os pacotes vão para 192.168.0.2 
com IP de origem da mesma rede e vai responder diretamente para o IP da 
rede, contudo este IP esterava uma resposta do IP (servidor web) 
externo, o que a flag transparent do squid pode resolver. No caso de não 
funcionar, precisa de uma segunda regra:


(2) iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.2 -o 
ethX -p tcp --dport 3128 -j SNAT --to 192.168.0.1


Esta diz que todo pacote IP que sair com IP de origem da rede 
192.168.0.0/24 e destino 192.168.0.2, tcp e porta 3128, deve ir com IP 
192.168.0.1, assim o squid responde para o 192.168.0.1 que responde para 
a estação.


[]'s
Junior Polegato


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/510977c6.5030...@juniorpolegato.com.br

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Prezado Gabriel

Sim, coloquei. O arquivo de configuração do squid esta assim.

# Port on which connections are redirected
http_port  3128 transparent

cache_dir ufs /var/spool/squid3 100 16 256
cache_mgr root@particula.local
cache_effective_user proxy

# Define the access log format
logformat squid  %ts.%03tu %6tr %>a %Ss/%03>Hs %

> você colocou a opção transparente no squid?
>
>
> Atenciosamente,
> *Gabriel Ricardo*
> Consultor em Tecnologia
> *Cel.:* (41) 8881-7828
> *Skype:* gabriel.nerdworkti
> *Facebook:* facebook.com/nerdworkti
> *Site*: www.nerdworkti.com.br
>
>
> Em 30 de janeiro de 2013 17:03, Caio Ferreira escreveu:
>
> Prezado Junior
>>
>> Novas informações, e parecem ser animadoras.
>>
>> Instalei o firefox na estação (192.168.0.200) e alterei a configuração
>> de conexão três vezes.
>>
>> 1 - apontando o browser da estação para o proxy, 192.168.0.2 e porta 3128
>> Consegui navegar normalmente e os arquivos de log do squid foram
>> alterados.
>>
>> 2 - apontando o browser da estação para o gateway, 192.168.0.1 e porta 80
>> Consegui navegar normalmente e os arquivos de log do squid foram
>> alterados.
>> Consegui navegar normalmente e o arquivos de log do rinetd foi alterado.
>>
>> 3 - não apontei o browser da estação para o gateway(no-proxy)
>> Consegui navegar normalmente e os arquivos de log do squid NÃO foram
>> alterados.
>> Consegui navegar normalmente e o arquivos de log do rinetd NÃO foi
>> alterado.
>>
>> Será que o problema esta no squid?
>>
>> Abraço.
>>
>> 2013/1/30 Caio Ferreira 
>>
>>> Junior
>>>
>>> gateway - 192.168.0.1
>>> proxy - 192.168.0.2
>>> estacao - 192.168.0.200
>>>
>>> A coisa esta começando a ficar interessante.
>>>
>>> Segue abaixo o resultado do comando telnet a partir de uma estação
>>> (192.168.0.200)
>>>
>>> gateway - 192.168.0.1
>>> $ cat /var/log/rinetd.log
>>> 30/Jan/2013:16:19:56192.168.0.200   192.168.0.1 80
>>>  192.168.0.2 31280   0   done-remote-closed
>>>
>>> proxy - 192.168.0.2
>>> $ ls -l /var/log/squid3/
>>> -rw-r- 1 proxy proxy 32461 Jan 30 16:19 cache.log
>>>
>>> Aparentemente o comando telnet esta sendo redirecionado, mas quando eu
>>> acesso qualquer site através do browser modo texto, lynxs ou links, o
>>> resultado não é o mesmo.
>>>
>>> Desde já agradeço pela ajuda
>>>
>>> caio abreu ferreira
>>>
>>> 2013/1/30 Linux - Junior Polegato 
>>>
  Em 30-01-2013 15:32, Caio Ferreira escreveu:

 Prezado Junior Polegato
 # gateway (192.168.0.1)
 tcpdump -i any -nA port 80 - resultado positivo, o comando tcpdump
 capturou pacotes.
 tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump
 não capturou pacotes.
  # proxy (192.168.0.2)
 tcpdump -i any -nA port 80 - resultado negativo, o comando tcpdump não
 capturou pacotes.
 tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump
 não capturou pacotes.
  Basicamente o aplicativo rinetd não esta fazendo o seu trabalho, ele
 não esta redirecionado o conteúdo da porta 80 do gateway (192.168.0.1) para
 a porta 3128 do proxy (192.168.0.2).
 O arquivo rinetd.conf esta assim.
 192.168.0.1 80  192.168.0.2 3128
  Procurei em vários textos na internet e aparentemente esta correto.
  Alguém teria alguma idéia?
 Desde já agradeço pela ajuda.

 Você está testando de qual máquina? Qual o IP desta máquina? Que
 resposta sua máquina tem quanto acessa 192.168.0.1:80 via telnet:

 telnet 192.168.0.1 80
 GET /

 []'s
 Junior Polegato

>>>

Re: rinetd

2013-01-30 Por tôpico Gabriel Ricardo 
você colocou a opção transparente no squid?


Atenciosamente,
*Gabriel Ricardo*
Consultor em Tecnologia
*Cel.:* (41) 8881-7828
*Skype:* gabriel.nerdworkti
*Facebook:* facebook.com/nerdworkti
*Site*: www.nerdworkti.com.br


Em 30 de janeiro de 2013 17:03, Caio Ferreira escreveu:

> Prezado Junior
>
> Novas informações, e parecem ser animadoras.
>
> Instalei o firefox na estação (192.168.0.200) e alterei a configuração de
> conexão três vezes.
>
> 1 - apontando o browser da estação para o proxy, 192.168.0.2 e porta 3128
> Consegui navegar normalmente e os arquivos de log do squid foram alterados.
>
> 2 - apontando o browser da estação para o gateway, 192.168.0.1 e porta 80
> Consegui navegar normalmente e os arquivos de log do squid foram alterados.
> Consegui navegar normalmente e o arquivos de log do rinetd foi alterado.
>
> 3 - não apontei o browser da estação para o gateway(no-proxy)
> Consegui navegar normalmente e os arquivos de log do squid NÃO foram
> alterados.
> Consegui navegar normalmente e o arquivos de log do rinetd NÃO foi
> alterado.
>
> Será que o problema esta no squid?
>
> Abraço.
>
> 2013/1/30 Caio Ferreira 
>
>> Junior
>>
>> gateway - 192.168.0.1
>> proxy - 192.168.0.2
>> estacao - 192.168.0.200
>>
>> A coisa esta começando a ficar interessante.
>>
>> Segue abaixo o resultado do comando telnet a partir de uma estação
>> (192.168.0.200)
>>
>> gateway - 192.168.0.1
>> $ cat /var/log/rinetd.log
>> 30/Jan/2013:16:19:56192.168.0.200   192.168.0.1 80
>>  192.168.0.2 31280   0   done-remote-closed
>>
>> proxy - 192.168.0.2
>> $ ls -l /var/log/squid3/
>> -rw-r- 1 proxy proxy 32461 Jan 30 16:19 cache.log
>>
>> Aparentemente o comando telnet esta sendo redirecionado, mas quando eu
>> acesso qualquer site através do browser modo texto, lynxs ou links, o
>> resultado não é o mesmo.
>>
>> Desde já agradeço pela ajuda
>>
>> caio abreu ferreira
>>
>> 2013/1/30 Linux - Junior Polegato 
>>
>>>  Em 30-01-2013 15:32, Caio Ferreira escreveu:
>>>
>>> Prezado Junior Polegato
>>> # gateway (192.168.0.1)
>>> tcpdump -i any -nA port 80 - resultado positivo, o comando tcpdump
>>> capturou pacotes.
>>> tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump
>>> não capturou pacotes.
>>>  # proxy (192.168.0.2)
>>> tcpdump -i any -nA port 80 - resultado negativo, o comando tcpdump não
>>> capturou pacotes.
>>> tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump
>>> não capturou pacotes.
>>>  Basicamente o aplicativo rinetd não esta fazendo o seu trabalho, ele
>>> não esta redirecionado o conteúdo da porta 80 do gateway (192.168.0.1) para
>>> a porta 3128 do proxy (192.168.0.2).
>>> O arquivo rinetd.conf esta assim.
>>> 192.168.0.1 80  192.168.0.2 3128
>>>  Procurei em vários textos na internet e aparentemente esta correto.
>>>  Alguém teria alguma idéia?
>>> Desde já agradeço pela ajuda.
>>>
>>> Você está testando de qual máquina? Qual o IP desta máquina? Que
>>> resposta sua máquina tem quanto acessa 192.168.0.1:80 via telnet:
>>>
>>> telnet 192.168.0.1 80
>>> GET /
>>>
>>> []'s
>>> Junior Polegato
>>>
>>

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Prezado Junior

Novas informações, e parecem ser animadoras.

Instalei o firefox na estação (192.168.0.200) e alterei a configuração de
conexão três vezes.

1 - apontando o browser da estação para o proxy, 192.168.0.2 e porta 3128
Consegui navegar normalmente e os arquivos de log do squid foram alterados.

2 - apontando o browser da estação para o gateway, 192.168.0.1 e porta 80
Consegui navegar normalmente e os arquivos de log do squid foram alterados.
Consegui navegar normalmente e o arquivos de log do rinetd foi alterado.

3 - não apontei o browser da estação para o gateway(no-proxy)
Consegui navegar normalmente e os arquivos de log do squid NÃO foram
alterados.
Consegui navegar normalmente e o arquivos de log do rinetd NÃO foi alterado.

Será que o problema esta no squid?

Abraço.

2013/1/30 Caio Ferreira 

> Junior
>
> gateway - 192.168.0.1
> proxy - 192.168.0.2
> estacao - 192.168.0.200
>
> A coisa esta começando a ficar interessante.
>
> Segue abaixo o resultado do comando telnet a partir de uma estação
> (192.168.0.200)
>
> gateway - 192.168.0.1
> $ cat /var/log/rinetd.log
> 30/Jan/2013:16:19:56192.168.0.200   192.168.0.1 80
>  192.168.0.2 31280   0   done-remote-closed
>
> proxy - 192.168.0.2
> $ ls -l /var/log/squid3/
> -rw-r- 1 proxy proxy 32461 Jan 30 16:19 cache.log
>
> Aparentemente o comando telnet esta sendo redirecionado, mas quando eu
> acesso qualquer site através do browser modo texto, lynxs ou links, o
> resultado não é o mesmo.
>
> Desde já agradeço pela ajuda
>
> caio abreu ferreira
>
> 2013/1/30 Linux - Junior Polegato 
>
>>  Em 30-01-2013 15:32, Caio Ferreira escreveu:
>>
>> Prezado Junior Polegato
>> # gateway (192.168.0.1)
>> tcpdump -i any -nA port 80 - resultado positivo, o comando tcpdump
>> capturou pacotes.
>> tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump não
>> capturou pacotes.
>>  # proxy (192.168.0.2)
>> tcpdump -i any -nA port 80 - resultado negativo, o comando tcpdump não
>> capturou pacotes.
>> tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump não
>> capturou pacotes.
>>  Basicamente o aplicativo rinetd não esta fazendo o seu trabalho, ele
>> não esta redirecionado o conteúdo da porta 80 do gateway (192.168.0.1) para
>> a porta 3128 do proxy (192.168.0.2).
>> O arquivo rinetd.conf esta assim.
>> 192.168.0.1 80  192.168.0.2 3128
>>  Procurei em vários textos na internet e aparentemente esta correto.
>>  Alguém teria alguma idéia?
>> Desde já agradeço pela ajuda.
>>
>> Você está testando de qual máquina? Qual o IP desta máquina? Que resposta
>> sua máquina tem quanto acessa 192.168.0.1:80 via telnet:
>>
>> telnet 192.168.0.1 80
>> GET /
>>
>> []'s
>> Junior Polegato
>>
>

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Junior

gateway - 192.168.0.1
proxy - 192.168.0.2
estacao - 192.168.0.200

A coisa esta começando a ficar interessante.

Segue abaixo o resultado do comando telnet a partir de uma estação
(192.168.0.200)

gateway - 192.168.0.1
$ cat /var/log/rinetd.log
30/Jan/2013:16:19:56192.168.0.200   192.168.0.1 80  192.168.0.2
31280   0   done-remote-closed

proxy - 192.168.0.2
$ ls -l /var/log/squid3/
-rw-r- 1 proxy proxy 32461 Jan 30 16:19 cache.log

Aparentemente o comando telnet esta sendo redirecionado, mas quando eu
acesso qualquer site através do browser modo texto, lynxs ou links, o
resultado não é o mesmo.

Desde já agradeço pela ajuda

caio abreu ferreira



2013/1/30 Linux - Junior Polegato 

>  Em 30-01-2013 15:32, Caio Ferreira escreveu:
>
> Prezado Junior Polegato
> # gateway (192.168.0.1)
> tcpdump -i any -nA port 80 - resultado positivo, o comando tcpdump
> capturou pacotes.
> tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump não
> capturou pacotes.
>  # proxy (192.168.0.2)
> tcpdump -i any -nA port 80 - resultado negativo, o comando tcpdump não
> capturou pacotes.
> tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump não
> capturou pacotes.
>  Basicamente o aplicativo rinetd não esta fazendo o seu trabalho, ele não
> esta redirecionado o conteúdo da porta 80 do gateway (192.168.0.1) para a
> porta 3128 do proxy (192.168.0.2).
> O arquivo rinetd.conf esta assim.
> 192.168.0.1 80  192.168.0.2 3128
>  Procurei em vários textos na internet e aparentemente esta correto.
>  Alguém teria alguma idéia?
> Desde já agradeço pela ajuda.
>
>
> Você está testando de qual máquina? Qual o IP desta máquina? Que resposta
> sua máquina tem quanto acessa 192.168.0.1:80 via telnet:
>
> telnet 192.168.0.1 80
> GET /
>
> []'s
> Junior Polegato
>
>


-- 
 .''`.   Caio Abreu Ferreira
: :'  :  abreuf...@gmail.com
`. `'`   Debian User
  `-

Re: rinetd

2013-01-30 Por tôpico Linux - Junior Polegato 

Em 30-01-2013 15:32, Caio Ferreira escreveu:

Prezado Junior Polegato
# gateway (192.168.0.1)
tcpdump -i any -nA port 80 - resultado positivo, o comando tcpdump 
capturou pacotes.
tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump 
não capturou pacotes.

# proxy (192.168.0.2)
tcpdump -i any -nA port 80 - resultado negativo, o comando tcpdump não 
capturou pacotes.
tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump 
não capturou pacotes.
Basicamente o aplicativo rinetd não esta fazendo o seu trabalho, ele 
não esta redirecionado o conteúdo da porta 80 do gateway (192.168.0.1) 
para a porta 3128 do proxy (192.168.0.2).

O arquivo rinetd.conf esta assim.
192.168.0.1 80  192.168.0.2 3128
Procurei em vários textos na internet e aparentemente esta correto.
Alguém teria alguma idéia?
Desde já agradeço pela ajuda.


Você está testando de qual máquina? Qual o IP desta máquina? Que 
resposta sua máquina tem quanto acessa 192.168.0.1:80 via telnet:


telnet 192.168.0.1 80
GET /

[]'s
Junior Polegato

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Junior

Você por acaso conseguiu fazer o software funcionar?

caio abreu ferreira

2013/1/30 Linux - Junior Polegato 

>  Em 30-01-2013 14:55, Linux - Junior Polegato escreveu:
>
> Em 30-01-2013 13:49, Caio Ferreira escreveu:
>
> Prezado Junior
> $ sudo netstat -tlnp|grep 80
> tcp0  0 0.0.0.0:80  0.0.0.0:*
> LISTEN  1645/rinetd
>  Não, não tenho nenhum webserver instalado. Durante a instalação, na
> etapa referente ao Tasksel eu desmarquei todas as opções exceto ssh server.
> Fiz uma alteração no arquivo de configuração do rinetd agora esta assim.
>  # bindadressbindportconnectaddress  connectport
> 0.0.0.0 80   192.168.0.2 3128
> 192.168.0.1  80   192.168.0.2 3128
> Executei o comando tcpdump, $ sudo tcpdump port 80, e o resultado acusa a
> utilização da porta 80.
> Alguma idéia?
>
>
> Se está utilizando a porta 80 está correto, uma requisição chega na porta
> 80, o rinetd recebe e repassa para a porta 3128 de 192.168.0.2, não é isso
> que está acontecendo?
> Para ver melhor e toda a informação trafegada use:
> tcpdump -i any -nA port 5060 or 1122
> Troque A por X na linha acima para ver informações mais organizadas e seus
> códigos em hexadecimal.
>
>
> Ops, eu estava usando duas portas aleatórias para testar aqui, no seu caso
> seria:
>
> tcpdump -i any -nA port 80 or 3128
>
> []'s
> Junior Polegato
>

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Prezado Junior Polegato

# gateway (192.168.0.1)
tcpdump -i any -nA port 80 - resultado positivo, o comando tcpdump capturou
pacotes.
tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump não
capturou pacotes.

# proxy (192.168.0.2)
tcpdump -i any -nA port 80 - resultado negativo, o comando tcpdump não
capturou pacotes.
tcpdump -i any -nA port 3128 - resultado negativo, o comando tcpdump não
capturou pacotes.

Basicamente o aplicativo rinetd não esta fazendo o seu trabalho, ele não
esta redirecionado o conteúdo da porta 80 do gateway (192.168.0.1) para a
porta 3128 do proxy (192.168.0.2).

O arquivo rinetd.conf esta assim.

192.168.0.1 80  192.168.0.2 3128

Procurei em vários textos na internet e aparentemente esta correto.

Alguém teria alguma idéia?

Desde já agradeço pela ajuda.

caio abreu ferreira

2013/1/30 Linux - Junior Polegato 

>  Em 30-01-2013 14:55, Linux - Junior Polegato escreveu:
>
> Em 30-01-2013 13:49, Caio Ferreira escreveu:
>
> Prezado Junior
> $ sudo netstat -tlnp|grep 80
> tcp0  0 0.0.0.0:80  0.0.0.0:*
> LISTEN  1645/rinetd
>  Não, não tenho nenhum webserver instalado. Durante a instalação, na
> etapa referente ao Tasksel eu desmarquei todas as opções exceto ssh server.
> Fiz uma alteração no arquivo de configuração do rinetd agora esta assim.
>  # bindadressbindportconnectaddress  connectport
> 0.0.0.0 80   192.168.0.2 3128
> 192.168.0.1  80   192.168.0.2 3128
> Executei o comando tcpdump, $ sudo tcpdump port 80, e o resultado acusa a
> utilização da porta 80.
> Alguma idéia?
>
>
> Se está utilizando a porta 80 está correto, uma requisição chega na porta
> 80, o rinetd recebe e repassa para a porta 3128 de 192.168.0.2, não é isso
> que está acontecendo?
> Para ver melhor e toda a informação trafegada use:
> tcpdump -i any -nA port 5060 or 1122
> Troque A por X na linha acima para ver informações mais organizadas e seus
> códigos em hexadecimal.
>
>
> Ops, eu estava usando duas portas aleatórias para testar aqui, no seu caso
> seria:
>
> tcpdump -i any -nA port 80 or 3128
>
> []'s
> Junior Polegato
>

Re: rinetd

2013-01-30 Por tôpico Linux - Junior Polegato 

Em 30-01-2013 14:55, Linux - Junior Polegato escreveu:

Em 30-01-2013 13:49, Caio Ferreira escreveu:

Prezado Junior
$ sudo netstat -tlnp|grep 80
tcp0  0 0.0.0.0:80  
 0.0.0.0:*   LISTEN  1645/rinetd
Não, não tenho nenhum webserver instalado. Durante a instalação, na 
etapa referente ao Tasksel eu desmarquei todas as opções exceto ssh 
server.

Fiz uma alteração no arquivo de configuração do rinetd agora esta assim.
# bindadressbindportconnectaddress  connectport
0.0.0.0 80   192.168.0.2 3128
192.168.0.1  80   192.168.0.2 3128
Executei o comando tcpdump, $ sudo tcpdump port 80, e o resultado 
acusa a utilização da porta 80.

Alguma idéia?


Se está utilizando a porta 80 está correto, uma requisição chega na 
porta 80, o rinetd recebe e repassa para a porta 3128 de 192.168.0.2, 
não é isso que está acontecendo?

Para ver melhor e toda a informação trafegada use:
tcpdump -i any -nA port 5060 or 1122
Troque A por X na linha acima para ver informações mais organizadas e 
seus códigos em hexadecimal.


Ops, eu estava usando duas portas aleatórias para testar aqui, no seu 
caso seria:


tcpdump -i any -nA port 80 or 3128

[]'s
Junior Polegato

Re: rinetd

2013-01-30 Por tôpico Linux - Junior Polegato 

Em 30-01-2013 13:49, Caio Ferreira escreveu:

Prezado Junior
$ sudo netstat -tlnp|grep 80
tcp0  0 0.0.0.0:80  
 0.0.0.0:*   LISTEN  1645/rinetd
Não, não tenho nenhum webserver instalado. Durante a instalação, na 
etapa referente ao Tasksel eu desmarquei todas as opções exceto ssh 
server.

Fiz uma alteração no arquivo de configuração do rinetd agora esta assim.
# bindadressbindportconnectaddress  connectport
0.0.0.0 80   192.168.0.2 3128
192.168.0.1  80   192.168.0.2 3128
Executei o comando tcpdump, $ sudo tcpdump port 80, e o resultado 
acusa a utilização da porta 80.

Alguma idéia?


Se está utilizando a porta 80 está correto, uma requisição chega na 
porta 80, o rinetd recebe e repassa para a porta 3128 de 192.168.0.2, 
não é isso que está acontecendo?


Para ver melhor e toda a informação trafegada use:
tcpdump -i any -nA port 5060 or 1122

Troque A por X na linha acima para ver informações mais organizadas e 
seus códigos em hexadecimal.


[]'s
Junior Polegato

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Prezado Junior

$ sudo netstat -tlnp|grep 80
tcp0  0 0.0.0.0:80  0.0.0.0:*   LISTEN
 1645/rinetd

Não, não tenho nenhum webserver instalado. Durante a instalação, na etapa
referente ao Tasksel eu desmarquei todas as opções exceto ssh server.

Fiz uma alteração no arquivo de configuração do rinetd agora esta assim.

# bindadressbindportconnectaddress  connectport
0.0.0.0 80   192.168.0.2 3128
192.168.0.1  80   192.168.0.2 3128

Executei o comando tcpdump, $ sudo tcpdump port 80, e o resultado acusa a
utilização da porta 80.

Alguma idéia?

Att.

caio abreu ferreira

2013/1/30 Linux Polegato 

> Não deveria comentar estas linhas, pode te trazer outros problemas. Qual o
> resultado de "netstat -tlnp|grep 80"?
>
> Provavelmente você tem algum serviço já rodando na porta 80, talvez Apache
> ou Lighttp.
>
> Tenta fazer restart depois de configurar o rinetd, "service rinetd restart"
>
> []'s
> Junior Polegato
> Em 30/01/2013 11:46, "Caio Ferreira"  escreveu:
>
> Prezado Junior Polegato
>>
>> Editei o arquivo /etc/services e comentei as linhas
>>
>> #www80/tcp  http# WorldWideWeb HTTP
>> #www80/udp  # HyperText Transfer
>> Protocol
>>
>> mas segundo o que consta do tutorial[1] não é necessário comentar estas
>> linhas.
>>
>> 1-http://www.howtoforge.com/port-forwarding-with-rinetd-on-debian-etch
>>
>> Desde já agradeço pela atenção.
>>
>> caio abreu ferreira
>>
>> 2013/1/30 Linux - Junior Polegato 
>>
>>> Em 30-01-2013 11:08, Caio Ferreira escreveu:
>>>
>>>  Dando uma olhada no arquivo /var/log/syslog encontrei a seguinte
 informação.
 Jan 30 10:54:18 gw rinetd[1901]: couldn't bind to address 192.168.0.200
 port 80 (Cannot assign requested address)
 O IP 192.168.0.200 é o Ip de uma estação.
 Executei o comando "sudo netstat -tap" e tive como resultado o seguinte.
 Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address   Foreign Address
 State   PID/Program name
 tcp 0  0 *:www   *:*
   LISTEN1914/rinetd

>>>
>>> Olá!
>>>
>>> O rinetd é um serviço, na verdade um proxy sem cache, e acho que
>>> não é isso que você quer. No caso o problema está que você não pode iniciar
>>> este serviço na porta 80 por existir um outro serviço rodando nela, confira
>>> com "netstat -tnp | grep 80".
>>>
>>> Melhor fazer usando iptables:
>>>
>>> iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to
>>> 192.168.0.2
>>>
>>> []'s
>>>  Junior Polegato
>>>
>>

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Prezado Junior Polegato

Editei o arquivo /etc/services e comentei as linhas

#www80/tcp  http# WorldWideWeb HTTP
#www80/udp  # HyperText Transfer
Protocol

mas segundo o que consta do tutorial[1] não é necessário comentar estas
linhas.

1-http://www.howtoforge.com/port-forwarding-with-rinetd-on-debian-etch

Desde já agradeço pela atenção.

caio abreu ferreira

2013/1/30 Linux - Junior Polegato 

> Em 30-01-2013 11:08, Caio Ferreira escreveu:
>
>  Dando uma olhada no arquivo /var/log/syslog encontrei a seguinte
>> informação.
>> Jan 30 10:54:18 gw rinetd[1901]: couldn't bind to address 192.168.0.200
>> port 80 (Cannot assign requested address)
>> O IP 192.168.0.200 é o Ip de uma estação.
>> Executei o comando "sudo netstat -tap" e tive como resultado o seguinte.
>> Active Internet connections (servers and established)
>> Proto Recv-Q Send-Q Local Address   Foreign Address State
>>   PID/Program name
>> tcp 0  0 *:www   *:*
>> LISTEN1914/rinetd
>>
>
> Olá!
>
> O rinetd é um serviço, na verdade um proxy sem cache, e acho que
> não é isso que você quer. No caso o problema está que você não pode iniciar
> este serviço na porta 80 por existir um outro serviço rodando nela, confira
> com "netstat -tnp | grep 80".
>
> Melhor fazer usando iptables:
>
> iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to
> 192.168.0.2
>
> []'s
>  Junior Polegato
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-user-portuguese-**requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/**51091E17.8030108@**
> juniorpolegato.com.br
>
>


-- 
 .''`.   Caio Abreu Ferreira
: :'  :  abreuf...@gmail.com
`. `'`   Debian User
  `-

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Prezado Marcos

O problema é que eu não estou utilizando o IPTables para fazer o
redirecionamento de porta, eu estou tentando utilizar o software rinetd. A
firewall esta fazendo somente nat e nada mais.

Att

caio abreu ferreira

2013/1/30 Marcos Carraro 

> Bha, então acredito que não vai funcionar.
>
> Olha aqui a explicação do ELGIO.
>
>
> http://www.vivaolinux.com.br/topico/netfilter-iptables/Redirecionamento-de-portas-2/
>
> Porque tu não configura esse proxy para as estações usando WPAD,
> provavelmente tu estas tentando fazer um um proxy transparente com iptables.
>
> Abraços
>
> *--*
> Att
> Marcos Carraro
> marcoscarraro.blogspot.com
>
>
> Em 30 de janeiro de 2013 11:08, Caio Ferreira escreveu:
>
> Prezado Marcos Carraro
>>
>> Não, o proxy é interno.
>>
>> Eu poderia ter instalado o proxy no mesmo computador do gateway, mas por
>> motivos de segurança instalei o proxy em outro computador.
>>
>> Dando uma olhada no arquivo /var/log/syslog encontrei a seguinte
>> informação.
>>
>> Jan 30 10:54:18 gw rinetd[1901]: couldn't bind to address 192.168.0.200
>> port 80 (Cannot assign requested address)
>>
>> O IP 192.168.0.200 é o Ip de uma estação.
>>
>> Executei o comando "sudo netstat -tap" e tive como resultado o seguinte.
>>
>> Active Internet connections (servers and established)
>> Proto Recv-Q Send-Q Local Address   Foreign Address State
>>   PID/Program name
>> tcp 0  0 *:www   *:*
>> LISTEN1914/rinetd
>>
>> Estou basicamente seguindo o howto do site abaixo.
>>
>> http://www.howtoforge.com/port-forwarding-with-rinetd-on-debian-etch
>>
>> Desde já agradeço pela atenção.
>>
>>
>> 2013/1/30 Marcos Carraro 
>>
>>> Buenas,
>>>
>>> No caso, tu precisa acessar o PROXY de fora da tua rede ou internamente?
>>>
>>> Teria que utilizar um PREROUTING seguindo de um REDIRECT.
>>>
>>> ABraços
>>>
>>> *--*
>>> Att
>>> Marcos Carraro
>>> marcoscarraro.blogspot.com
>>>
>>>
>>> Em 30 de janeiro de 2013 10:45, Caio Ferreira escreveu:
>>>
>>>  Lista

 Procurei na internet por um software que faça redirecionamento de porta
 e encontrei o software rinetd, mas infelizmente estou tendo problemas.

 Instalei o software no gateway da rede e configurei o mesmo para
 redirecionar a porta 80 para um outro computador que será o proxy da rede.
 Para isso fiz o seguinte:

 # /etc/rinetd.com
 0.0.0.0 80  192.168.0.2 3128

 Para fazer um teste em vez de porta 80/3128 coloquei a porta 22/22.
 Desta forma, se por acaso alguém tentasse conectar via ssh no gateway da
 rede, a conexão seria redirecionada para o proxy (192.168.0.2).
 Infelizmente não esta funcionado, a conexão não esta sendo redirecionada
 para o proxy. Imaginei que fosse problema com a firewall, então removi
 todas as regras e deixei somente a opção de forward. A firewall esta assim.

 # /etc/init.d/firewall

 #!/bin/bash
 IPTABLES=/sbin/iptables
 # recover IPs
 ETH0IP=`ifconfig eth0 | grep "inet addr:" | sed 's/.*inet addr://' |
 cut -d ' ' -f 1`
 ETH1IP=`ifconfig eth1 | grep "inet addr:" | sed 's/.*inet addr://' |
 cut -d ' ' -f 1`
 # clean all possible old mess
 $IPTABLES -F
 $IPTABLES -t nat -F
 $IPTABLES -t mangle -F
 # masquerading
 $IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE
 echo 1 > /proc/sys/net/ipv4/ip_forward
 # opening all
 $IPTABLES -P INPUT ACCEPT
 $IPTABLES -P OUTPUT ACCEPT
 $IPTABLES -P FORWARD ACCEPT
 $IPTABLES -t nat -P POSTROUTING ACCEPT
 $IPTABLES -t nat -P PREROUTING ACCEPT
 $IPTABLES -t filter -P FORWARD ACCEPT

 Alguém por acaso teria alguma idéia do que eu estou fazendo de errado?

 Att

>>>

Re: rinetd

2013-01-30 Por tôpico Linux - Junior Polegato 

Em 30-01-2013 11:08, Caio Ferreira escreveu:
Dando uma olhada no arquivo /var/log/syslog encontrei a seguinte 
informação.
Jan 30 10:54:18 gw rinetd[1901]: couldn't bind to address 
192.168.0.200 port 80 (Cannot assign requested address)

O IP 192.168.0.200 é o Ip de uma estação.
Executei o comando "sudo netstat -tap" e tive como resultado o seguinte.
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address 
State   PID/Program name
tcp 0  0 *:www   *:*   
  LISTEN1914/rinetd


Olá!

O rinetd é um serviço, na verdade um proxy sem cache, e acho 
que não é isso que você quer. No caso o problema está que você não pode 
iniciar este serviço na porta 80 por existir um outro serviço rodando 
nela, confira com "netstat -tnp | grep 80".


Melhor fazer usando iptables:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 192.168.0.2

[]'s
 Junior Polegato


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51091e17.8030...@juniorpolegato.com.br

Re: rinetd

2013-01-30 Por tôpico Caio Ferreira 
Prezado Marcos Carraro

Não, o proxy é interno.

Eu poderia ter instalado o proxy no mesmo computador do gateway, mas por
motivos de segurança instalei o proxy em outro computador.

Dando uma olhada no arquivo /var/log/syslog encontrei a seguinte informação.

Jan 30 10:54:18 gw rinetd[1901]: couldn't bind to address 192.168.0.200
port 80 (Cannot assign requested address)

O IP 192.168.0.200 é o Ip de uma estação.

Executei o comando "sudo netstat -tap" e tive como resultado o seguinte.

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State
PID/Program name
tcp 0  0 *:www   *:*
  LISTEN1914/rinetd

Estou basicamente seguindo o howto do site abaixo.

http://www.howtoforge.com/port-forwarding-with-rinetd-on-debian-etch

Desde já agradeço pela atenção.


2013/1/30 Marcos Carraro 

> Buenas,
>
> No caso, tu precisa acessar o PROXY de fora da tua rede ou internamente?
>
> Teria que utilizar um PREROUTING seguindo de um REDIRECT.
>
> ABraços
>
> *--*
> Att
> Marcos Carraro
> marcoscarraro.blogspot.com
>
>
> Em 30 de janeiro de 2013 10:45, Caio Ferreira escreveu:
>
> Lista
>>
>> Procurei na internet por um software que faça redirecionamento de porta e
>> encontrei o software rinetd, mas infelizmente estou tendo problemas.
>>
>> Instalei o software no gateway da rede e configurei o mesmo para
>> redirecionar a porta 80 para um outro computador que será o proxy da rede.
>> Para isso fiz o seguinte:
>>
>> # /etc/rinetd.com
>> 0.0.0.0 80  192.168.0.2 3128
>>
>> Para fazer um teste em vez de porta 80/3128 coloquei a porta 22/22. Desta
>> forma, se por acaso alguém tentasse conectar via ssh no gateway da rede, a
>> conexão seria redirecionada para o proxy (192.168.0.2). Infelizmente não
>> esta funcionado, a conexão não esta sendo redirecionada para o proxy.
>> Imaginei que fosse problema com a firewall, então removi todas as regras e
>> deixei somente a opção de forward. A firewall esta assim.
>>
>> # /etc/init.d/firewall
>>
>> #!/bin/bash
>> IPTABLES=/sbin/iptables
>> # recover IPs
>> ETH0IP=`ifconfig eth0 | grep "inet addr:" | sed 's/.*inet addr://' | cut
>> -d ' ' -f 1`
>> ETH1IP=`ifconfig eth1 | grep "inet addr:" | sed 's/.*inet addr://' | cut
>> -d ' ' -f 1`
>> # clean all possible old mess
>> $IPTABLES -F
>> $IPTABLES -t nat -F
>> $IPTABLES -t mangle -F
>> # masquerading
>> $IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>> echo 1 > /proc/sys/net/ipv4/ip_forward
>> # opening all
>> $IPTABLES -P INPUT ACCEPT
>> $IPTABLES -P OUTPUT ACCEPT
>> $IPTABLES -P FORWARD ACCEPT
>> $IPTABLES -t nat -P POSTROUTING ACCEPT
>> $IPTABLES -t nat -P PREROUTING ACCEPT
>> $IPTABLES -t filter -P FORWARD ACCEPT
>>
>> Alguém por acaso teria alguma idéia do que eu estou fazendo de errado?
>>
>> Att
>>
>

Re: rinetd

2013-01-30 Por tôpico Marcos Carraro 
Buenas,

No caso, tu precisa acessar o PROXY de fora da tua rede ou internamente?

Teria que utilizar um PREROUTING seguindo de um REDIRECT.

ABraços

*--*
Att
Marcos Carraro
marcoscarraro.blogspot.com


Em 30 de janeiro de 2013 10:45, Caio Ferreira escreveu:

> Lista
>
> Procurei na internet por um software que faça redirecionamento de porta e
> encontrei o software rinetd, mas infelizmente estou tendo problemas.
>
> Instalei o software no gateway da rede e configurei o mesmo para
> redirecionar a porta 80 para um outro computador que será o proxy da rede.
> Para isso fiz o seguinte:
>
> # /etc/rinetd.com
> 0.0.0.0 80  192.168.0.2 3128
>
> Para fazer um teste em vez de porta 80/3128 coloquei a porta 22/22. Desta
> forma, se por acaso alguém tentasse conectar via ssh no gateway da rede, a
> conexão seria redirecionada para o proxy (192.168.0.2). Infelizmente não
> esta funcionado, a conexão não esta sendo redirecionada para o proxy.
> Imaginei que fosse problema com a firewall, então removi todas as regras e
> deixei somente a opção de forward. A firewall esta assim.
>
> # /etc/init.d/firewall
>
> #!/bin/bash
> IPTABLES=/sbin/iptables
> # recover IPs
> ETH0IP=`ifconfig eth0 | grep "inet addr:" | sed 's/.*inet addr://' | cut
> -d ' ' -f 1`
> ETH1IP=`ifconfig eth1 | grep "inet addr:" | sed 's/.*inet addr://' | cut
> -d ' ' -f 1`
> # clean all possible old mess
> $IPTABLES -F
> $IPTABLES -t nat -F
> $IPTABLES -t mangle -F
> # masquerading
> $IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> echo 1 > /proc/sys/net/ipv4/ip_forward
> # opening all
> $IPTABLES -P INPUT ACCEPT
> $IPTABLES -P OUTPUT ACCEPT
> $IPTABLES -P FORWARD ACCEPT
> $IPTABLES -t nat -P POSTROUTING ACCEPT
> $IPTABLES -t nat -P PREROUTING ACCEPT
> $IPTABLES -t filter -P FORWARD ACCEPT
>
> Alguém por acaso teria alguma idéia do que eu estou fazendo de errado?
>
> Att
>
> --
>  .''`.   Caio Abreu Ferreira
>  : :'  :  abreuf...@gmail.com
> `. `'`   Debian User
>   `-
>