Повреждение загрузок при возобновлении загрузки из-за перенаправления провайдера

У меня есть Bsnl Bradband соединение в Индии.

Всякий раз, когда я включаю маршрутизатор и открываю любую ссылку в первый раз, она перенаправляется на страницу http://mail.bsnl.in/. Это может быть способом продвижения их почтовой службы. Широкополосный сервис плохой со многими пропаданиями сигнала, особенно в сезон дождей. Всякий раз, когда происходит сбой сигнала и сбрасывается соединение, происходит такое перенаправление веб-страницы.

И перенаправление не ограничивается браузером. Я использую Linux дистрибутив и делаю apt-get update && apt-get upgrade часто. Когда соединение восстанавливается, частичные загрузки должны быть восстановлены при повторном подключении. Но поскольку перенаправление происходит по всей системе, загружаемые файлы перенаправляются и перезаписываются небольшим html-файлом с html-заголовками и ссылкой, содержащей mail.bsnl.in.

Я получил много больших файлов, поврежденных таким образом. Как я могу предотвратить это?

Источник

2 ответа

nKn, возможно, был более пессимистичным, чем нужно. Он серьезно воспринял ваш комментарий

И перенаправление не ограничивается браузером. Я использую дистрибутив linux и часто выполняю обновление apt-get && apt-get. Когда соединение восстанавливается, частичные загрузки должны быть восстановлены при повторном подключении.

Причина, по которой это вряд ли актуально, заключается в том, что apt-get связывается с сайтом http, т.е. сайтом с портом 80: это отрывок из моего файла `/etc/apt/sources.list}:

 deb http://us.archive.ubuntu.com/ubuntu/ trusty main restricted
 deb-src http://us.archive.ubuntu.com/ubuntu/ trusty main restricted
 deb http://us.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
 deb-src http://us.archive.ubuntu.com/ubuntu/ trusty-updates main restricted

который показывает именно это.

Это важно, потому что это означает, что не все порты и / или протоколы должны быть перехвачены вашим провайдером. Причина, по которой я говорю это, заключается в том, что это является очень тяжелым бременем для их инфраструктуры.

Что обычно делается для того, чтобы сохранить объем трафика для анализа управляемым, это перехватывать запросы DNS, которые предшествуют большинству попыток связи по очевидным причинам. Их брандмауэр может идентифицировать запросы DNS на основе либо порта, либо протокола, либо, скорее всего, обоих.

Есть способ обойти это, и это использовать dnscrypt, очень ценный инструмент, предоставляемый OpenDNS. На веб-странице есть ссылки на версии пакета для Windows и MacOS, а для Linux вы найдете его в репозитории вашего дистрибутива.

Преимущество dnscrypt заключается в том, что он использует нестандартный порт и шифрует связь с вашим DNS-сервером, так что брандмауэры не могут определить характер вашей попытки подключения. Вы можете свободно выбирать свои DNS-серверы, они предоставляют несколько опций, помимо их собственных, OpenDNS.

Это может или не может работать, но это, безусловно, стоит попробовать.

Причина, по которой он может не работать, заключается в том, что ваш интернет-провайдер может установить таймер, чтобы, если ваша линия находилась в режиме ожидания дольше, чем фиксированное количество времени, тогда все коммуникации блокировались, независимо от порта / протокола и так далее. Это было бы очень агрессивным шагом, но некоторые интернет-провайдеры не привыкли к компетентным пользователям.

В этом случае вы можете написать простой сценарий оболочки, myping.sh, содержащий следующие строки,

 #!/bin/bash
 ping -c1 8.8.8.8

сделать его исполняемым,

 chmod 755 myping.sh

и он будет выполняться автоматически каждую минуту, добавив эту строку

  * * * * * /path/to/myping.sh

в ваш crontab с помощью команды:

   crontab -e

Это потребует тривиальной полосы пропускания и будет поддерживать ваше соединение постоянно.

Источник

К сожалению, я боюсь, что вы ничего не можете сделать в этом случае. Использование прокси-сервера, TOR, пересылка запросов на другой сервер, смена DNS-серверов и т. Д. Не помогут, поскольку самым первым прыжком в вашем запросе будет ваш провайдер, поэтому вы не можете изменить поведение первого запроса при переподключении.

"Бедняк" и очень элементарный обходной путь будет иметь сценарий в коробке Linux, который будет делать wget на какой-то сайт (например, http://www.google.com) каждую минуту и ​​пересылать результат /dev/nullпоэтому, если ваша ссылка отключится и снова подключится, вы просто заметите перенаправление в течение первой минуты, иначе вы ничего не заметите.

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

Источник
Другие вопросы по тегам