O roteador Linux freqüentemente descarta conexões

1

Até alguns meses atrás, minha área de trabalho Linux servia como roteador para minha rede doméstica e tudo estava bem.

Depois, configuro uma pequena máquina Linux para atuar como um roteador independente e, desde então, tenho muitas conexões interrompidas.

Erros como este são frequentes (este durante uma sessão de rsync):

Write failed: Broken pipe
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (1576 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]

Minhas sessões de mensagens instantâneas são desconectadas e reconectadas com frequência. As sessões SSH caem e, às vezes, as páginas da web não são carregadas.

É sempre uma conexão ativa que é eliminada (ao contrário dos problemas que estabelecem novas conexões). E é mais frequente quando minha conexão com a Internet está ocupada - em termos de número de conexões ativas, não em termos de largura de banda. Por exemplo, a execução do bittorrent torna o problema muito pior, mas o download ou o upload de um único arquivo grande que consome 100% da minha largura de banda não parece acionar o problema. Eu sempre posso me reconectar imediatamente (embora a nova conexão também caia em breve também).

Eu tenho uma conexão de modem a cabo de 8mbit (ha! yeah right!) da Telecable (uma das maiores empresas de cabo no México). Eu teria assumido que era um problema com o serviço deles, exceto que não tenho o problema quando não estou usando o roteador.

Portanto, parece bastante óbvio para mim que estou atingindo algum tipo de limite de "conexões máximas" em meu roteador Linux

Eu experimentei problemas semelhantes no passado, em sistemas muito ocupados, e aumentar o netconn_max (ou o equivalente em kernels mais antigos) sempre resolveu o problema. Mas desta vez isso não parece ser o problema. Isto é imediatamente depois de ter experimentado uma série de desconexões:

/proc/sys/net/ipv4/netfilter/ip_conntrack_max: 48324
/proc/sys/net/ipv4/netfilter/ip_conntrack_count: 75

Por que vale a pena, a saída de 'iptables -L -t nat':

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere            multiport dports 6881:6999 to:10.0.3.5
DNAT       udp  --  anywhere             anywhere            multiport dports 6881:6999 to:10.0.3.5
DNAT       tcp  --  anywhere             anywhere            tcp dpt:4380 to:10.0.3.12
DNAT       udp  --  anywhere             anywhere            udp dpt:4380 to:10.0.3.12
DNAT       tcp  --  anywhere             anywhere            tcp dpt:49181 to:10.0.3.12
DNAT       udp  --  anywhere             anywhere            udp dpt:49181 to:10.0.3.12

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

O que mais preciso verificar?

Editar: Carregue a média e o uso de memória, conforme solicitado:

            total       used       free     shared    buffers     cached
Mem:           755        747          8          0        154        504
-/+ buffers/cache:         88        667
Swap:         1903          0       1903

 18:32:19 up 4 days, 19:53,  2 users,  load average: 0.00, 0.00, 0.00

Eu também esqueci de incluir originalmente a saída uname -a :

Linux reep 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686 GNU/Linux
    
por Flimzy 06.07.2011 / 01:18

1 resposta

0

Curiosamente, uma das coisas que o seu 'router' faz é masquerade / NAT (se eu estiver lendo isso corretamente).

Se o seu modem a cabo normalmente realiza essa tarefa, sua capacidade de lidar com conexões de saída pode ser afetada pelo fato de que tudo no outro lado do seu 'roteador' (entre aspas porque faz mais do que apenas rotear) tem o mesmo IP endereço enquanto o roteador estiver ligado. Em outras palavras, se ele tiver um bucket por host para conexões, ou se seu tratamento interno de conexões simplesmente não puder lidar com um grande número de conexões de um único host, o roteador do modem a cabo poderá estar sobrecarregado.

Uma maneira de testar isso seria configurar seu roteador para simplesmente enviar pacotes para o roteador do modem a cabo, em vez de fazer o disfarce / NAT. Isso significa configurar uma rota padrão e dizer ao kernel para encaminhar pacotes (se bem me lembro). Se estou certo, o problema deve desaparecer novamente.

    
por 06.07.2011 / 06:27