Na verdade também não sei porque no debian esta linha se faz necessário ( quando usava conectiva nem sabia que esta regra existia).
Vou me valer do e-mail enviado por outro companheiro da lista: De: Douglas A. Augusto <[EMAIL PROTECTED]> Para: debian-user-portuguese@lists.debian.org Assunto: Re: [resolvido: Problema com MSS] Velox: duas placas de rede e compartilhamento Data: Fri, 20 May 2005 00:17:17 -0300 No dia 19/05/2005 às 14:56, "Douglas A. Augusto" <[EMAIL PROTECTED]> escreveu: Mais uma vez, obrigado àqueles que tentaram me ajudar. O problema era menos trivial, e vou explicar abaixo. Em um compartilhamento (masquerade), o cabeçalho de pacotes TCP que vêm das máquinas na rede é acrescido de alguns bytes para identificar que o pacote é de uma máquina da rede, isto é, aquelas que usam a máquina conectada à internet como gateway. O problema é que alguns provedores (onde estão hospedados os sites) não podem (ou não querem) aceitar um pacote que contenha essas informações extras, fazendo a conexão literalmente parar. Parece-me que os pacotes sobe uma conexão ADSL tendem a ser maiores. Segundo minha experiência, o Google é um dos poucos que lida perfeitamente com esses pacotes "inchados". Depois de muito pesquisar, descobri que há uma maneira de limitar o tamanho "pacotes", restringindo o que é chamado de 'Maximum Segment Size', ou simplesmente MSS. Isso é feito adicionando-se uma regra especial no 'iptables', garantindo que os pacotes TCP, oriundos de máquinas em compartilhamento e com o MSS maior que um valor apropriado, sejam ajustados para o valor correto --o que sobrar de dados é "empacotado" em um outro pacote. A regra que usei foi: iptables -t mangle -A POSTROUTING -p tcp -m tcp --tcp-flags \ SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -o ppp0 Apesar de ter descoberto que o problema era no MSS, tive dificuldades para refinar esta regra, pois muitas referências apontavam algumas diferenças, como: - man iptables: iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu - pppoeconf iptables -o ppp0 --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu Para mim só funcionou com "-t mangle -A POSTROUTING", me baseando em "http://www.hgfelger.de/mss/mss-clamp". Em Ter, 2006-08-15 às 10:15 -0300, Wendell A. Silva escreveu: > Marcos, funcionou. Perfeito. Muito obrigado. > > Aproveitando, você poderia comentar o que a regra abaixo faz e pq em > outras redes não necessitei utilizar ela? > Ou então onde encontro documentação sobre o tema. > > Valeu. > > edmarcos escreveu: > > Esperimenta por esta linha no seu firewall > > > > iptables -t mangle -A POSTROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN > > -j TCPMSS --clamp-mss-to-pmtu > > > > E depois reporte se ajudou. > > > > Em Seg, 2006-08-14 às 15:07 -0300, Wendell A. Silva escreveu: > > > >> Salve! > >> > >> Esse problema é cabeludo. > >> > >> Em duas redes distintas com a mesma configuração de roteamento > >> (iptables), em uma o acesso ao site da UOL funciona corretamente e em > >> outra não. > >> Na rede com problemas toda navegação ocorre sem erros e somente o > >> www.uol.com.br não funciona (Problema muito estranho). > >> > >> Rede problemática: > >> Provedor de Acesso: UOL > >> Conexão: Speedy > >> > >> Rede normal: > >> Conexão Virtua > >> > >> Na duas o roteador é o Debian Sarge. Os testes foram realizados com o > >> roteador configurado para realizar somente NAT. Nenhuma regra de > >> bloqueio foi implementada com o iptables. > >> > >> Abaixo, segue o log do Forward da rede problemática quando se tenta > >> acessar o www.uol.com. > >> Engraçado que ele termina com um RST e para por ai. No log da rede > >> normal o RST não aparece. > >> > >> Quando eu tiro o Linux da rede e faço o NAT diretamente no modem da > >> Telefônica, a conexão funciona perfeitamente. > >> > >> Qualquer ajuda é valida. > >> > >> Obrigado, > >> > >> Wendell > >> > >> ----------------------------------- > >> Aug 14 14:03:42 matrix kernel: INPUTIN=eth0 OUT=ppp0 SRC=192.168.0.128 > >> DST=200.221.2.45 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=43851 DF PROTO=TCP > >> SPT=1454 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 > >> Aug 14 14:03:42 matrix kernel: TESTEIN= OUT=ppp0 SRC=192.168.0.128 > >> DST=200.221.2.45 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=43851 DF PROTO=TCP > >> SPT=1454 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 > >> Aug 14 14:03:45 matrix kernel: INPUTIN=ppp0 OUT=eth0 SRC=200.221.2.45 > >> DST=192.168.0.128 LEN=44 TOS=0x00 PREC=0x00 TTL=253 ID=0 PROTO=TCP > >> SPT=80 DPT=1454 WINDOW=8192 RES=0x00 ACK SYN URGP=0 > >> Aug 14 14:03:45 matrix kernel: INPUTIN=eth0 OUT=ppp0 SRC=192.168.0.128 > >> DST=200.221.2.45 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=43855 DF PROTO=TCP > >> SPT=1454 DPT=80 WINDOW=65535 RES=0x00 ACK URGP=0 > >> Aug 14 14:03:45 matrix kernel: INPUTIN=eth0 OUT=ppp0 SRC=192.168.0.128 > >> DST=200.221.2.45 LEN=465 TOS=0x00 PREC=0x00 TTL=127 ID=43856 DF > >> PROTO=TCP SPT=1454 DPT=80 WINDOW=65535 RES=0x00 ACK PSH URGP=0 > >> Aug 14 14:03:47 matrix kernel: INPUTIN=ppp0 OUT=eth0 SRC=200.221.2.45 > >> DST=192.168.0.128 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=53278 DF PROTO=TCP > >> SPT=80 DPT=1454 WINDOW=6432 RES=0x00 ACK URGP=0 > >> Aug 14 14:04:17 matrix kernel: INPUTIN=ppp0 OUT=eth0 SRC=200.221.2.45 > >> DST=192.168.0.128 LEN=40 TOS=0x00 PREC=0x00 TTL=245 ID=0 PROTO=TCP > >> SPT=80 DPT=1454 WINDOW=0 RES=0x00 RST URGP=0 > >> > >> -------------------------------------------------------------------- > >> > >> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]