5

Мой местный жилищный интернет-провайдер только что изменил свою политику, и они, похоже, блокируют работу маршрутизаторов 1.

Моя настройка (которая работает в течение года):

[ISP router (in the residence, out of my reach)] -- My DD-WRT router -- PC

-- : RJ45 cable connection

На данный момент он перестал работать. После некоторых испытаний вот что я узнал:

  • Соединение роутера с ПК кажется нормальным (я могу получить доступ к его веб-интерфейсу и через SSH)
  • Соединение роутер-провайдер кажется нормальным (с помощью SSH-подключения к моему роутеру я могу пропинговать 8.8.8.8/8.8.4.4)
  • PC-Router-ISP соединение не работает (не может даже пинговать 8.8.8.8/8.8.4.4)

Я хотел бы понять, может ли интернет-провайдер блокировать соединения таким образом, и есть ли способ избежать этого 2.

1 Это изменение, по-видимому, не позволяет людям использовать более одного устройства одновременно.Это произвольное правило, которое никогда не было объявлено. Они могут осуществить это только потому, что у меня есть студенческая монополия.

2 Я не думаю, что это было бы несанкционированным, так как я никогда не подписывал никаких ToS или должен был принять какое-либо EULA. В тот день, когда я переехал, я подключил свой маршрутизатор, и с тех пор он работал.Я плачу за аренду, а моя резиденция оплачивает интернет-провайдер, следовательно, монополия.

Подробности о моей настройке

Я использую DD-WRT на его стандартной конфигурации шлюза. Кажется, что это NAT один-ко-многим, так как этот сайт говорит, что:

Чтобы отключить NAT и по-прежнему использовать его в качестве маршрута / брандмауэра, вы можете изменить режим работы на «Маршрутизатор» вместо «Шлюз» (находится в разделе «Расширенная маршрутизация»).

И на этой вики-странице DD-WRT объясняется, как настроить один-к-одному NAT, поэтому моей конфигурацией по умолчанию должен быть один-ко-многим NAT.

Это правильно? Если это уже так, сможет ли мой провайдер как-то определить, использую ли я прямое соединение или нет? Я думал, что ручная установка TTL пакетов от их маршрутизатора до 1 будет иметь такой эффект, но я не уверен.

Редактировать: Может быть, я неправильно понимаю, но TTL может быть виновником. Вот результат ping 8.8.8.8:

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.

Однако я никогда не обращал на это внимания. Может ли это быть нормальным? В противном случае, я могу сказать DD-WRT увеличить его?

1 ответ1

5

Оказывается, что действительно 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 - это мошенничество), только чтобы зарядить ее вдвое дороже, это очень плохой ход.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .