sem internet durante o download de torrents - parece relacionado dns

Question

Eu tenho um problema muito peculiar em relação à conexão com a internet durante o download de torrents. Antes de concluir que eu deveria "reduzir o número de conexões abertas e sem usuário", deixe-me dizer que eu fiz isso. (10 conexões semiabertas, 20 usuários, ainda não funciona, e eu não entendo qualquer download acontecendo mais).

Eu também devo dizer que a QoS não deveria ser necessária. geralmente na minha experiência com o download de torrents (no linux / windows nad mac) a conexão à internet era compartilhada entre todos os processos. Aqui parece que torrents estão mastigando toda a largura de banda disponível. (O kernel não deve dividir o tempo entre os processos que solicitam o envio / recebimento de pacotes?)

Finalmente, devo dizer que este problema começou a aparecer depois que eu atualizei para slack 64bit v14 (da versão 13.37).

Assim, o problema real parece estar relacionado com o servidor dns não respondendo uma vez que eu inicio o download com o ktorrent ou rtorrent. E nenhuma página da web carrega mais. torrent será baixado em velocidade razoável, mas nenhum site estará carregando. então "nslookup" e "dig" me dirão que o servidor dns (que está localizado no mesmo pc) não foi encontrado:

nslookup facebook.com
;; connection timed out; no servers could be reached

e

nass@stargaze:~$ dig !$
dig facebook.com
; <<>> DiG 9.9.1-P3 <<>> facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26154
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;facebook.com.                  IN      A

;; Query time: 1125 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug  2 01:14:46 2013
;; MSG SIZE  rcvd: 41

reiniciar o servidor de dns (bind) enquanto o torrent está sendo executado geralmente NÃO corrigirá as coisas, mesmo que às vezes eu tenha visto isso acontecer. parar o dns, excluir todos os arquivos * .jnl que foram gerados e reiniciar parece funcionar, mas, novamente, pode não ser sempre. (Eu não tenho um padrão repetido para este caso). Não posso dizer que encontrei "uma maneira" de recuperar a internet.

• geralmente fechando o ktorrent e esperando por alguns segundos pode até consertar a internet por conta própria.
• Outras vezes, fechar o cliente do ktorrent e reiniciar o servidor de DNS funcionaria mais rápido que o caso anterior.
• às vezes reinicializações repetidas NÃO conseguiam que o DNS voltasse a funcionar (a espera por alguns minutos corrigia o problema)
• recentemente, comecei a parar o nome, excluindo os arquivos * .jnl e reiniciando. Isso teve 100% de sucesso em minhas (apenas 2) tentativas.

o log do firewall, os logs / var / log / messages / e named, não registram nada de estranho.

Eu não usei o tcpdump, wireshark, netstat, então não sei se posso usar essas ferramentas para identificar ... alguma coisa! Alguém poderia ajudar com isso?

Como esse problema parece estar relacionado principalmente ao servidor dns, estou anexando meu arquivo dns e explicando a configuração do meu pc:

então a internet ADSL chega no modem (fornecida pelo provedor, sempre ligada, mesmo quando eu não tenho internet). Modem está conectado a este pc em eth1 onde estou baixando torrents. este pc é minha rede doméstica e servidor de arquivos (e meu desktop quando estou ausente - eu conecto usando nx). Está executando o iptables, dns, & servidores de lula (entre outros). Então, a partir da eth0 deste pc, o switch wifi e intranet são alimentados. O squid está sendo executado em uma configuração transparente, mas não deve interferir no tráfego de torrent, pois isso é feito em portas diferentes (em vez da porta 80).

Então, inicialmente, eu estou anexando o meu named.conf, em uma tentativa de obter feedback sobre ele (talvez alguma configuração logicamente errada que não é pego do webmin chamado verificador de arquivo de configuração - com o qual verifiquei repetidamente o nome. arquivo conf está sintaticamente correto)

named.conf é aqui

Se estiver tudo bem, há alguma maneira que eu possa começar a usar o tcpdump (e qualquer outra ferramenta) sob sua orientação para coletar informações sobre o que pode estar causando isso?

Muito obrigado pela sua ajuda:)

EDIT: meu /etc/resolv.conf se parece com:

domain skails.home
nameserver 127.0.0.1

    

Answer 1

(Shouldn't the kernel be divide time among processes that request to send/receive packages?)

A situação típica de ter Internet lenta ou nula com algo como Bittorrent saturando sua conexão é que o tráfego de entrada no seu upstream (que geralmente é menor do que o downstream na maioria das conexões residenciais) está lotado. Portanto, TCP ACKs de entrada não são recebidos em tempo hábil e o tempo limite de conexões termina e, eventualmente, o seu fim.

Uma coisa que aprendi ao estudar QoS é que não há QoS no tráfego de entrada, porque você não pode controlar o que está sendo enviado para você. Você só pode realmente QoS / dividir / compartilhar o tráfego de saída. Você pode ver a configuração atual do Linux QoS com tc - mas esteja avisado, tc é muito complicado.

É possível que uma única conexão sature sua largura de banda recebida e elimine TCP ACKs recebidos, causando lentidão, quedas, etc. O número de conexões simultâneas realmente não importa.

Você provavelmente precisará definir a quantidade total de largura de banda que o seu programa Bittorrent carrega para um valor abaixo do seu fluxo máximo, como 8Kbit / seg abaixo do que você sabe ser a velocidade do seu upstream. Você também pode querer olhar para o Wondershaper se você sentir vontade de entrar na toca do coelho que é o QoS no Linux.

    

Answer 2

Sua pista é esta linha:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26154

Supondo que resolv.conf contenha apenas 127.0.0.1 , isso indica que o servidor de armazenamento em cache decidiu que os servidores de nome upstream não podem ser acessados ou estão configurados incorretamente. Nesse ponto, o servidor vai desistir da comunicação com esse domínio. Isso significa que o servidor é adicionado à lista de servidores de nomes lame. Isso é diferente do armazenamento em cache negativo , que só se aplica a NXDOMAIN de respostas.

É lógico que uma vez que facebook.com tenha sido determinado como morto, o servidor de nome de armazenamento em cache não vai se preocupar em tentar resolvê-lo por um tempo. Agora você precisa descobrir por que isso está acontecendo.

Vamos supor que você esteja com congestionamento de rede e facebook.com não esteja no cache.

• named tentará percorrer sua lista de encaminhadores até encontrar um servidor de nomes que responda com algo diferente de REFUSED para esse registro. NXDOMAIN e SERVFAIL respostas que serão aceitas. Mesmo se os outros servidores tivessem respondido de forma diferente, tudo o que o seu servidor se preocupa é se um registro está ou não em cache, e a primeira resposta válida que ele obtém.
• Quando encontrar uma resposta, ela será armazenada em cache. Para melhor ou pior.
• A falha em obter uma resposta de qualquer um deles também será considerada um SERVFAIL .

Para seu teste específico, a consulta e a resposta seriam pequenas. O UDP não tem a sobrecarga de sessão associada ao TCP. Para obter uma resposta de SERVFAIL ...

• A primeira resposta válida que você recebeu foi SERVFAIL para esse domínio.
• Todos os forwarders estavam inacessíveis. Você não conseguiu uma resposta de todos eles.

A única maneira de saber o que está acontecendo com certeza seria iniciar uma captura de pacotes, depois reiniciar seu servidor de nomes e analisar os pacotes. Um de seus encaminhadores pode estar com problemas e retornar SERVFAIL com frequência, ou seu congestionamento é tão grande que oito pequenas pesquisas de DNS em toda a sua lista de encaminhadores falham.