Douglas A. Augusto wrote:
No dia 19/05/2005 �s 14:56,
"Douglas A. Augusto" <[EMAIL PROTECTED]> escreveu:
Tenho aqui em casa uma m�quina com o Velox instalado (eth1-ppp0) e uma
pequena rede local (192.168.0.0) atrav�s da interface eth0 (endere�ada
como 192.168.0.2), de modo que a m�quina com Velox funciona como
gateway.
A conex�o funciona muito bem para a m�quina Velox, mas nas m�quinas da
rede curiosamente s� consigo "pingar" e acessar via ssh m�quinas
remotas. N�o posso por exemplo acessar uma p�gina web, dar 'apt-get
update', ou coisas afins.
Cheguei a pensar que o vil�o seria o firewall, mas isso se repete ao
deix�-lo desligado (liberado).
Para deixar a hist�ria mais esquisita ainda, via web, consigo acessar
apenas o site do Google. Para os outros sites os nomes s�o resolvidos,
e at� parece que carregar�o, mas p�ra em: "Aguardando resposta de..."
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.
Isso � um 'problema' antigo e cl�ssico - pelo que entendo do que vc
explica tem a ver com o MTU (maximun transfer unit ou algo do tipo).
No caso da rede ethernet � 1500 bytes, mas o pppoe (que � usado em redes
ADSL) 'rouba' alguns desses 1500 bytes pra ele, assim sobram menos que
os tradicionais 1500 bytes pra um usu�rio. O micro que autentica no
pppoe j� se acerta sozinho, mas roteia solenemente pacotes maiores,
fragmentando-os. Veja mais detalhes abaixo...
No fundo, pelo que eu estou vendo, vc fez as regras de compartilhamento
na m�o, certo? Pq n�o usar uma ferramenta que automatiza o processo?
Segundo minha experi�ncia, o
Google � um dos poucos que lida perfeitamente com esses pacotes
"inchados".
Essa eu n�o entendi... quem lida com os pacotes � o gateway, n�o o
servidor web...
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.
[...]
Para mim s� funcionou com "-t mangle -A POSTROUTING", me baseando em
"http://www.hgfelger.de/mss/mss-clamp";.
Veja s� a man page do iptables, ela descreve bem o problema:
[...]
TCPMSS
This target allows to alter the MSS value of TCP SYN packets, to
control the maximum size for that connection (usually limiting it to
your outgoing interface's MTU minus 40). Of course, it can only be used
in conjunction with -p tcp.
This target is used to overcome criminally braindead ISPs or servers
which block ICMP Fragmentation Needed packets. The symptoms of this
problem are that everything works fine from your Linux
firewall/router, but machines behind it can never exchange large packets:
1) Web browsers connect, then hang with no data received.
2) Small mail works fine, but large emails hang.
3) ssh works fine, but scp hangs after initial handshaking.
Workaround: activate this option and add a rule to your firewall
configuration like:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
