Последние несколько месяцев я борюсь с регулярными перебоями в работе интернета, которые затрагивают все устройства в моей локальной сети, заставляя меня выключать и включать кабельный модем. Сегодня я заметил, что могу воспроизвести эту проблему — или похожую с такими же симптомами — установив игру с Battle.net от Blizzard.
Речь идет не только о насыщении моей пропускной способности, поскольку
- сама загрузка также останавливается,
- это также происходит при ограничении скорости загрузки,
- и проблема не решается автоматически при приостановке загрузки — помогает только перезапуск модема.
Чтобы точно узнать, когда мое интернет-соединение прерывается, я запускаю простуюping 8.8.8.8 на отдельном ноутбуке Linux (кстати, я использую Arch), подключенном к той же сети, — но я все равно могу продолжать пинговать, даже когда у меня отключается интернет! Только при остановке работающегопинг, и перезапускаю его, но больше не получаю никаких ответов.
Я немного озадачен таким поведением. Я также пробовал бегать ping 8.8.8.8и watch -n1 ping -c 1 8.8.8.8бок о бок - в то время как непрерывно бегущийпингпроцесс продолжает работать,пингпроцесс регулярно перезапускаетсясмотретьперестает работать, как только пропадает интернет.
Как это возможно? Похоже, что "активные сеансы ping" не затронуты моим отключением. Но с ping, использующим ICMP на уровне 3, я не понимаю, почему существует разница между сохранениемпингбег, в отличие от попытки начать всё заново.
Увидев, что загрузки Battle.net также вызывают эту проблему, я сразу же заподозрил что-то, связанное со слишком большим количеством P2P-соединений, засоряющих мой маршрутизатор. Но я также не уверен, использует ли Battle.net P2P на самом деле, и не вижу ничего подозрительного на своем маршрутизаторе относительно активных соединений (~3000–4000 соединений из 15360 максимум), использования памяти или чего-то подобного.
К сожалению, я не могу посмотреть на показатели моего кабельного модема, так как мой интернет-провайдер не предоставляет надлежащего интерфейса — именно поэтому я использую его в режиме моста.
Есть ли какое-то объяснение такому поведению?
Редактировать: Я взглянул на сообщения ICMP с помощью Wireshark: единственное заметное различие между эхо-запросами ICMP, получающими ответ, и теми, на которые он не приходит:
- идентификатор ICMP привязан к процессу; запросы от работающегопингимеют тот же идентификатор, запросы от перезапуска пинга получают новый
- порядковый номер увеличивается для каждого запроса, отправленного работающимпинг, но для перезапуска установлено значение 1
Это вполне ожидаемое поведение, и оно мне ничем не помогает — в конце концов, почему это должно приводить к тому, что запросы будут обрабатываться по-разному?
решение1
Как это возможно? Похоже, что "активные сеансы ping" не затронуты моим отключением. Но с ping, использующим ICMP на уровне 3, я не понимаю, почему существует разница между сохранением ping в рабочем состоянии и новым запуском.
Даже для протоколов, не имеющих явного состояния, таких как UDP и ICMP Echo, ваш маршрутизатор все равно должен сохранять свое собственное состояние для своих функций брандмауэра и NAT. (Например, он отслеживает сопоставления NAT, чтобы знать, какому внутреннему хосту возвращать пакеты Echo Reply.) Для таких протоколов любой первый отправленный вами пакет устанавливает состояние; тайм-аут после бездействия приводит к его удалению.
Как и в случае с TCP, таблица состояний запоминает порты источника-назначения потока пакетов UDP или единичный "идентификатор запроса" потока эхо-сигналов ICMP. Хотя у ICMP нет номеров портов, у запросов эхо-сигналов есть идентификатор, который служит той же цели — отличать потоки друг от друга. (Если вы посмотрите на захват пакетов в Wireshark, вы увидите это.) Это означает, что каждый новый pingвызов приводит к добавлению новой записи состояния.
(Для практического примера: если вы это сделаете, то conntrack -Lсможете увидеть состояния, отслеживаемые брандмауэром iptables/nftables вашего компьютера, который по сути совпадает с тем, что большинство домашних маршрутизаторов используют внутри. Обратите внимание на idполе состояний ICMP Echo.)
Итак, из вашего описания проблемы действительно следует, что таблица состояний маршрутизатора заполняется из-за слишком большого количества «соединений», а его прошивка была настроена так, чтобы не принимать новые состояния, вместо того чтобы позволять им выталкивать старые. (Справедливости ради, ядуматьэто поведение Linux conntrack по умолчанию?)
Также может быть, что проблемный маршрутизатор имеет ошибку, которая не позволяет ему работать.очисткасостояний, и его память просто заполняется до перезагрузки; особенно если маршрутизатор выгружает NAT на аппаратное ускорение и если эта выгрузка сломала удаление состояний. (Я бы совершенно не удивился, если бы это было так, и интернет-провайдер просто запрограммировал его на перезагрузку раз в неделю, что было бы «достаточно хорошо» для обычных пользователей.)
Battle.net в настоящее время не использует P2P, это просто HTTP из CDN (хотя раньше он был основан на BitTorrent), но онделаетсоздают относительно большое количество параллельных HTTP-загрузок и, безусловно, могут способствовать возникновению проблемы.
Наконец, как уже упоминалось в комментариях, этовозможный(хотя я не уверен, насколько это вероятно), что брандмауэр вашего маршрутизатора теряет все правила фильтрации и/или NAT. Это имело бы смысл для устройства на базе Linux — действительно, iptables автоматически обрабатывает NAT для существующих состояний, поэтому если исходящее правило SNAT или MASQUERADE будет удалено по какой-то причине, это предотвратит создание новых подключений, но существующие продолжат работать (они продолжат подвергаться NAT в соответствии с информацией, уже сохраненной в состоянии).
Если вы не нашли способа решить эту проблему, то, скорее всего, обходным путем станет VPN — весь VPN-туннель считается всего лишь одним состоянием, насколько его видит ваш маршрутизатор.