Re: Problemas em roteamento com o Linux
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
<douglas.augusto@pop.com.br>
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" <douglas.augusto@pop.com.br> 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
> >>
> >> --------------------------------------------------------------------
> >>
> >>
Reply to: