нет интернета при загрузке торрентов - похоже днс связано

Question

У меня очень специфическая проблема с интернет-соединением при загрузке торрентов. Прежде чем вы решите, что я должен «уменьшить количество наполовину открытых и пользовательских соединений», позвольте мне сказать, что я это сделал (10 наполовину открытых соединений, 20 пользователей, это все еще не работает, и я не получаю никаких загрузка продолжается больше).

Я также должен сказать, что QoS не должно быть необходимым. обычно в моем опыте с загрузкой торрентов (в linux/windows nad mac) подключение к Интернету было общим для всех процессов. Здесь кажется, что торренты жуют всю доступную пропускную способность. (Разве ядро не должно делить время между процессами, которые запрашивают отправку / получение пакетов?)

Наконец, я должен сказать, что эта проблема начала появляться после того, как я обновил Slack до 64bit v14 (с v13.37).

Таким образом, реальная проблема, похоже, связана с тем, что DNS-сервер не отвечает, как только я начинаю загрузку с помощью ktorrent или rtorrent. И больше не загружаются веб-страницы. Торрент будет загружаться с разумной скоростью, но ни один веб-сайт не будет загружаться. поэтому "nslookup" и "dig" скажут мне, что сервер DNS (который расположен на том же компьютере) не был найден:

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

а также

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

перезапуск DNS-сервера (bind) во время работы торрента обычно НЕ БУДЕТ исправлять ситуацию, хотя иногда я видел, как это происходит. Остановка DNS, удаление любых файлов * .jnl, которые были сгенерированы и перезапуск, кажется, работает, но, опять же, это может происходить не всегда. (У меня нет повторяющегося паттерна для этого случая). Я не могу сказать, что нашел "способ" вернуть Интернет.

• обычно закрытие торрента и ожидание в течение нескольких секунд может даже исправить интернет самостоятельно.
• В других случаях закрытие клиента ktorrent и перезапуск DNS-сервера будет работать быстрее, чем в предыдущем случае.
• иногда повторные перезапуски НЕ приводили бы к тому, что днс снова работал (но ожидание нескольких минут исправило бы проблему)
• Недавно я начал останавливать named, удаляя файлы * .jnl и перезапуская его. Это имело 100% успех в моих (только 2) испытаниях.

Журнал брандмауэра, /var /log /messages / и named, не регистрирует ничего странного.

Я не использовал tcpdump, wireshark, netstat, поэтому я не знаю, смогу ли я использовать эти инструменты для определения ... чего-то! Может ли кто-нибудь помочь с этим?

Поскольку эта проблема, по-видимому, связана, прежде всего, с DNS-сервером, я добавляю свой DNS-файл и объясняю abit конфигурации моего компьютера:

Таким образом, ADSL интернет приходит в модем (предоставляется провайдером, всегда включен, даже когда у меня нет интернета). Модем подключен к этому компьютеру по eth1, где я скачиваю торренты. Этот компьютер является моей домашней сетью и файловым сервером (и моим рабочим столом, когда меня нет - я подключаюсь с помощью nx). Он работает на серверах iptables, dns и squid (среди прочих). Затем из eth0 этого компьютера подается Wi-Fi и интранет-коммутатор. Squid работает в прозрачной конфигурации, но он не должен мешать торрент-трафику, поскольку это делается на разных портах (а не на порте 80).

Итак, изначально я прилагаю свой named.conf, пытаясь получить отзыв о нем (возможно, какой-то логически ошибочный конфиг, который не перехватывается из веб-проверки именованного файла конфигурации), с помощью которого я неоднократно проверял, что файл named.conf синтаксически правильный)

named.conf здесь

Если это нормально, могу ли я как-нибудь начать использовать tcpdump (и любой другой инструмент) под вашим руководством для сбора информации о том, что может быть причиной этого?

Большое спасибо за вашу помощь :)

РЕДАКТИРОВАТЬ: мой /etc/resolv.conf выглядит так:

domain skails.home
nameserver 127.0.0.1

Answer 1

Ваша подсказка - эта строка:

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

Предполагая, что resolv.conf содержит только 127.0.0.1 , это говорит о том, что сервер кэширования решил, что вышестоящие серверы имен не могут быть доступны или неправильно настроены. В этот момент сервер собирается отказаться от общения с этим доменом. Это означает, что сервер добавлен в список хромых серверов имен. Это отличается от отрицательного кэширования , которое применяется только к ответам NXDOMAIN .

Само собой разумеется, что, как только facebook.com будет определен как мертвый, кеширующий сервер имен не будет пытаться решить его некоторое время. Теперь вы должны выяснить, почему это происходит.

Предположим, вы испытываете перегрузку сети, а facebook.com не находится в кеше.

• named будет пытаться циклически перебирать ваш список серверов пересылки, пока не найдет сервер имен, который ответит чем-то отличным от REFUSED для этой записи. Ответы NXDOMAIN и SERVFAIL которые он примет. Даже если бы другие серверы ответили бы по-разному, все, что вас интересует, это то, находится ли запись в кэше, и первый действительный ответ, который она получает.
• Как только он найдет ответ, он будет кеширован. Для лучшего или худшего.
• Невозможность получить ответ от кого-либо из них также будет считаться SERVFAIL .

Для вашего конкретного теста запрос и ответ будут небольшими. У UDP нет накладных расходов, связанных с TCP. Чтобы получить ответ от SERVFAIL ...

• Первый действительный ответ, который вы получили, был SERVFAIL для этого домена.
• Все экспедиторы были недоступны. Вы не получили ответ от всех из них.

Единственный способ точно узнать, что происходит, - начать перехват пакета, затем перезапустить сервер имен и проанализировать пакеты. Один из ваших серверов пересылки может быть неисправен и часто возвращает SERVFAIL , или ваша перегрузка настолько сильна, что восемь крошечных DNS-запросов по всему списку серверов пересылки не удаются.

Answer 2

(Разве ядро не должно делить время между процессами, которые запрашивают отправку / получение пакетов?)

Типичная ситуация с медленным Интернетом или отсутствием Интернета с чем-то вроде Bittorrent, насыщающего ваше соединение, состоит в том, что входящий трафик в вашем восходящем канале (который обычно ниже, чем ваш нисходящий поток в большинстве жилых соединений) вытесняется. Таким образом, входящие TCP ACK не принимаются своевременно, и время ожидания соединения заканчивается, а затем, в конечном итоге, ваш конец.

Из изучения QoS я узнал одну вещь: во входящем трафике не существует QoS, потому что вы не можете контролировать то, что вам отправляют. Вы можете только реально QoS/ разделить / разделить исходящий трафик. Вы можете увидеть текущую конфигурацию QoS в Linux с помощью tc но имейте в виду , что tc очень сложен.

Возможно, что одно соединение может насытить вашу входящую пропускную способность и вытеснить входящие TCP ACK, вызывая замедления, пропадание и т.д. Количество одновременных соединений не имеет большого значения.

Вам, вероятно, нужно установить общую пропускную способность, которую ваша программа Bittorrent загружает, чуть ниже максимальной скорости восходящего потока, например, на 8 Кбит / с ниже, чем, как вы знаете, скорость вашего восходящего потока. Вы также можете захотеть заглянуть в Wondershaper, если вам хочется пройти по кроличьей норе, которая является QoS в Linux.