2 votes

Corruption de téléchargements résumables due à une redirection ISP

J'ai une connexion à large bande Bsnl en Inde.

Chaque fois que j'allume le routeur et que j'ouvre cualquier la première fois, elle est redirigée vers mail.bsnl.in page. Cela pourrait être un moyen de promouvoir leur service de messagerie. Le service haut débit est médiocre, avec de nombreuses coupures de signal, surtout pendant la saison des pluies. Chaque fois qu'une perte de signal se produit et que la connexion est rétablie, une telle redirection de page Web se produit.

Et la redirection n'est pas limitée au navigateur. J'utilise une distro linux et je fais apt-get update && apt-get upgrade fréquemment. Lorsque la connexion est rétablie, les téléchargements partiels sont censés pouvoir être repris lors de la reconnexion. Mais comme la redirection se produit à l'échelle du système, les téléchargements sont redirigés et sont écrasés par un petit fichier html avec des en-têtes html et un lien contenant mail.bsnl.in.

J'ai eu beaucoup de gros fichiers corrompus de cette façon. Comment puis-je éviter cela ?

1voto

MariusMatutiae Points 45233

NKn mai ont été plus pessimistes que nécessaire. Il a pris au sérieux votre commentaire selon lequel

Et la redirection n'est pas limitée au navigateur. J'utilise une distro linux et je fais fréquemment apt-get update && apt-get upgrade. Lorsque la connexion est réinitialisée, les téléchargements partiels sont censés pouvoir être repris lors de la reconnexion.

La raison pour laquelle il est peu probable que cela soit pertinent est que apt-get contacte un site http, c'est-à-dire un site sur le port 80 : c'est un extrait de mon fichier `/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

qui montre exactement cela.

Ceci est important car cela signifie que tous les ports et/ou protocoles ne sont pas tous besoin de être intercepté par votre FAI. La raison pour laquelle je dis cela est que faire cela est une charge très lourde pour les fournisseurs d'accès. leur l'infrastructure.

Ce qui est généralement fait pour que la quantité de trafic à analyser reste gérable est d'intercepter les requêtes DNS, qui précèdent la plupart des tentatives de communication, pour des raisons évidentes. Leur pare-feu peut identifier les requêtes DNS en fonction du port ou du protocole, ou, plus probablement, des deux.

Il y a un moyen de contourner ce problème, et c'est d'utiliser dnscrypt un outil très précieux fourni par OpenDNS . La page Web contient des liens pour les versions Windows et MacOS du paquet, tandis que pour Linux vous le trouverez dans les dépôts de votre distro.

L'avantage de dnscrypt est qu'il utilise un port non standard et qu'il crypte la communication avec votre serveur DNS, afin que les pare-feu ne puissent pas identifier la nature de votre tentative de connexion. Vous pouvez choisir librement vos serveurs DNS, ils offrent plusieurs options en plus du leur, OpenDNS.

Ce site mai o ne peut pas mais cela vaut certainement la peine d'essayer.

La raison pour laquelle il pourrait no est que votre fournisseur d'accès à Internet a peut-être configuré une minuterie, de sorte que, si votre ligne est silencieuse pendant une période déterminée, le système d'alarme est activé. tous les communications sont bloquées, quel que soit le port/protocole, et ainsi de suite. Il s'agirait d'une mesure très agressive, mais certains fournisseurs d'accès à Internet ne sont pas habitués à des utilisateurs compétents.

Ce que vous pouvez faire dans ce cas est d'écrire un simple Shell Shell, myping.sh contenant les lignes suivantes,

 #!/bin/bash
 ping -c1 8.8.8.8

le rendre exécutable,

 chmod 755 myping.sh

et faire en sorte qu'il s'exécute automatiquement toutes les minutes en ajoutant cette ligne

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

à votre crontab, au moyen de la commande :

   crontab -e

Cela consommera une quantité insignifiante de bande passante et maintiendra votre connexion en permanence.

0voto

nKn Points 5401

Malheureusement, je crains que vous ne puissiez pas faire grand-chose dans ce cas. L'utilisation d'un proxy, de TOR, la redirection des requêtes vers un serveur différent, la modification de vos serveurs DNS, etc., ne vous aideront pas, car le tout premier saut de votre requête sera celui de votre FAI, et vous ne pourrez donc pas modifier le comportement de la première requête lors d'une reconnexion.

Une solution de contournement très rudimentaire serait d'avoir un script dans une boîte linux qui ferait une wget vers un site web (par exemple, http://www.google.com ) toutes les minutes et transmet le résultat à /dev/null Ainsi, si votre lien se déconnecte et se reconnecte, vous remarquerez la redirection dans la première minute, sinon vous ne remarquerez rien.

Il existe d'autres solutions évidentes, comme se plaindre auprès de votre fournisseur d'accès à Internet pour un tel comportement ou changer de fournisseur d'accès, mais cette dernière solution dépend de votre situation.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X