Оказывается, что действительно TTL был причиной проблемы! Вот ответ в стиле FAQ, который, надеюсь, будет более полезным для других людей.
Почему мое соединение работает только через прямой кабель, а не через роутер? Мой роутер не работает должным образом?
Если ваша ситуация похожа на мою, роутер работал (и работает) просто отлично. Проблема в том, что мой провайдер только что реализовал регулирование TTL.
Что такое дросселирование TTL?
Регулирование TTL состоит в установке TTL (времени жизни) IP-пакетов на 1, чтобы предотвратить использование маршрутизаторов: все пакеты из WAN (Internet) отбрасываются до достижения ПК (потому что их TTL становится 0) ,
Как я могу обнаружить дросселирование TTL?
При подключении с использованием прямого кабеля (который должен работать нормально), попробуйте пропинговать любой сервер, желательно по IP, чтобы избежать проблем с DNS. Общедоступный DNS-сервер Google легко запомнить, поэтому я часто делаю:
ping 8.8.8.8
Результат будет содержать поле ttl (или TTL в Windows):
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=1 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=1 time=3.52 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=1 time=21.1 ms
В этом примере TTL равен ровно 1. Шансы на то, что это произойдет на практике без регулирования TTL, практически равны нулю. ttl=1 - это индикатор того, что ваш TTL регулируется.
Как обойти дросселирование TTL?
Вам необходимо настроить маршрутизатор так, чтобы он изменял TTL входящих пакетов, увеличивая его до более высокого значения (скажем, 64), чтобы пакеты не отбрасывались до прибытия на устройства, подключенные к вашему маршрутизатору.
К сожалению, конкретные детали будут зависеть от каждого роутера / прошивки. В моем маршрутизаторе был установлен DD-WRT, поэтому я использовал правила iptables для его настройки.
После различных попыток мне удалось определить правило, которое работало для меня, но каждая версия прошивки может отличаться! Возможно, вам придется попробовать несколько комбинаций, прежде чем найти тот, который работает.
Общие советы по настройке DD-WRT iptables для отмены регулирования TTL
- Если вы можете, используйте командную строку SSH для подключения к маршрутизатору. Это быстрее и дает вам обратную связь о неправильных командах;
- Возможно, вам придется понять синтаксис iptables, чтобы исправить команду, чтобы она работала для вас;
- Я до сих пор не понимаю этого достаточно, и я устал от попыток, поэтому я просто остановился на первом, который сработал, хотя, скорее всего, он не самый лучший.
Вот команды, которые я добавил в мой сценарий запуска DD-WRT:
iptables -v -t mangle -A OUTPUT -j TTL --ttl-set 60
iptables -v -t mangle -A PREROUTING -j TTL --ttl-set 63
Они почти наверняка не правы на каком-то уровне, но важными частями являются:
- всегда используйте
-v для получения подробного вывода; неверные команды будут указаны;
- избегать использования
-n (для числовых значений, т. е. для вывода по IP); Несмотря на то, что эта опция упоминается на странице Iptables DD-WRT, эта опция, по-видимому, отсутствует в моей версии DD-WRT, что приводит к тихой ошибке. Я только заметил это, повторив $? после команды, которая привела к 255 вместо 0. Удаление этой опции позволило мне увидеть сообщения об ошибках;
- для быстрого тестирования без работающего подключения к Интернету на ПК вы можете разрешить выполнение команды
ping на ПК на консоли, в то время как вы пытаетесь использовать команды iptables на другой консоли. По умолчанию мой маршрутизатор отвечал с ttl=64 , но когда я получил работающее правило, я сразу увидел, что ping возвращается с новым значением (следовательно, почему я не использовал 64 в моем примере) при использовании цепочки OUTPUT (в противном случае , это не обязательно для фактического подключения к Интернету);
- некоторые люди упоминают сеть
PREROUTING , другие упоминают INPUT . Я не уверен в разнице, но PREROUTING кажется, работал лучше для меня.
К сожалению, это все еще не идеально: примерно каждый час мое соединение сбрасывается, поэтому мне приходится вручную обновлять правило iptables.
Примечание: я почти ничего не знаю о iptables , поэтому любые предложения по улучшению правил приветствуются (я буду тестировать и обновлять их соответственно).
Windows/Mac Интернет-общий доступ
Если вы используете компьютер под управлением Windows/Mac в качестве маршрутизатора (например, используете свой ПК / ноутбук для совместного использования подключения к Интернету с другими устройствами), программное обеспечение, такое как Connectify (начиная с версии 7.1, согласно их веб-сайту), также позволяет обходить TTL-регулирование.
Connectify вызывает эту настройку, избегая ограничений Hotel/NAT. Он активен по умолчанию, что объясняет, почему не так много людей жалуются на регулирование TTL в Интернете: пользователи Windows в основном используют Connectify, не спрашивая, почему он работает. Это, однако, объясняет, почему стандартный общий доступ к Интернету в Windows может не работать из коробки.
И в заключение ...
Должен ли я чувствовать себя плохо, избегая регулирования TTL?
Вероятно, нет, особенно если ваш интернет-провайдер, как и мой, (1) уже регулирует пропускную способность, (2) вводит регулирование TTL, даже не объявляя об этом, и (3) явно заинтересован только в обмане своих пользователей, а не в улучшении сервиса. Исключить стандартную функцию искусственно и с помощью "обмана" (фальсификация TTL - это мошенничество), только чтобы зарядить ее вдвое дороже, это очень плохой ход.
