Olá! On Wednesday 03 May 2006 09:44, Sulamita Garcia wrote: > Quando tento, por uma máquina cliente com IP 192.168.0.42, acessar o > IP Virtual 192.168.0.50, o attributo InActConn se torna 1, mas o > cliente telnet fica por muito tempo esperando até que dá Connection > timed out.
É provável que, pela combinação de NAT com ICMP Redirect causada pelo redirecionamento de volta pela mesma rede de chegada, o cliente nunca esteja vendo os pacotes de resposta corretos. Acho que o que está se passando na tua rede é: - cliente C manda para redirecionador R - R muda o endereço de destino (NAT) para o do servidor S - R roteia o pacote de volta pela mesma rede, gerando um ICMP Redirect* - o servidor S responde direto pro cliente C, que acha que está falando com R e ignora - o cliente espera um pacote retornando de R que não vem nunca * provavelmente, pelo NAT, este ICMP Redirect também vai conter o endereço errado e o cliente vai ignorá-lo. Um bom tcpdump ajudará a entender. Mas tente não focar apenas nos IPs que achas que deverias ver, tente ver a comunicação geral. Use os headers ethernet para verificar de quem são os pacotes (os IPs podem estar bagunçados pelo NAT). > Rodei um ethereal para ver o que acontecia. Quando não tento realizar > conexões por telnet, mesmo assim quatro pacotes são gerados > frequentemente: > Pacote SYN de 40 (director) para 44 (real server) > Pacote SYN, ACK de 44 para 40 > Pacote ACK de 40 para 44 > Pacote RST, ACK de 40 para 44 Isso é o keepalived verificando se o serviço ainda está de pé. É normal e esperado, dada a tua configuração. > E quando tento realizar conexão por telnet a partir do cliente 42, > tenho, além daqueles pacotes, também estes: > Pacote SYN de 42 para 50 (virtual server) > Pacote SYN de 42 para 44 > > Que tenho feito de errado para isto não dar certo? Acho que precisas desligar o suporte a ICMP Redirection que o kernel faz automaticamente sempre que um pacote é roteado de volta pela mesma placa de rede por onde chegou. Imagine que, se o pacote está voltando pelo mesmo caminho que veio, então é melhor que a máquina que o enviou já acerte o caminho correto diretamente no próximo pacote. Isso acontece direto em redirecionamentos feitos para a mesma sub-rede. Isso explica a segunda conexão direta para o 44. Imagine que o cliente manda um pacote de 42 para 50. 50 nota que o destino, 44, está na mesma rede. 50 avisa o 42, dizendo "ô cara, da próxima vez fala direto com o 44". Como todo bom TCP/IP bem educado ele então repete o SYN, desta vez direto pro 44. E aí o teu cluster não funciona. :) Acredito que nesta configuração, usar NAT só funcionaria se tu fizesses NAT dos dois lados, ou seja, não só mascarar o endereço de destino como sendo o do servidor real, mas também o endereço de origem como sendo o do redirecionador. O melhor mesmo talvez seja fazer Direct Routing, mas acho que mesmo pra isso vais precisar desligar os ICMP Redirects. Espero que ajude! fabio.olive -- ex sed lex awk yacc, e pluribus unix, amem _______________________________________________ Linux-HA mailing list [email protected] http://listas.linuxchix.org.br/mailman/listinfo/linux-ha
