Liste de trackers Torrent UDP

Lorsque vous utilisez un client torrent pour télécharger l’image ISO d’une distribution Linux par exemple, vous avez le choix d’utiliser des trackers TCP (liés au protocole Http) ou UDP. L’intérêt de l’UDP est qu’il est un mode non connecté ! Par voie de conséquence, la HADOPI peut difficilement établir que vous étiez connecté. ;+) C’est dur de prouver juridiquement qu’une personne est en train de télécharger alors qu’elle n’est pas connectée au serveur, hein ? Normalement, pour une ISO Linux, vous ne devriez pas être inquiété.

La liste de trackers Torrent UDP validés

Je viens de m’assurer sous qBittorent de la validité des trackers suivants :

udp://151.80.120.114:2710/announce
udp://182.176.139.129:6969/announce
udp://5.79.249.77:6969/announce
udp://5.79.83.193:6969/announce
udp://62.138.0.158:6969/announce
udp://9.rarbg.com:2710/announce
udp://9.rarbg.com:2750/announce
udp://9.rarbg.com:2770/announce
udp://9.rarbg.com:2780/announce
udp://9.rarbg.me:2710/announce
udp://9.rarbg.me:2730/announce
udp://9.rarbg.me:2750/announce
udp://9.rarbg.me:2780/announce
udp://9.rarbg.to:2710/announce
udp://9.rarbg.to:2730/announce
udp://9.rarbg.to:2740/announce
udp://9.rarbg.to:2790/announce
udp://91.218.230.81:6969/announce
udp://bt.xxx-tracker.com:2710/announce
udp://eddie4.nl:6969/announce
udp://inferno.demonoid.ph:3389/announce
udp://inferno.demonoid.pw:3391/announce
udp://inferno.demonoid.pw:3418/announce
udp://ipv4.tracker.harry.lu:80/announce
udp://mgtracker.org:2710/announce
udp://mgtracker.org:6969/announce
udp://open.stealth.si:80/announce
udp://opentrackr.org:1337/announce
udp://p4p.arenabg.ch:1337
udp://p4p.arenabg.ch:1337/announce
udp://p4p.arenabg.com:1337
udp://p4p.arenabg.com:1337/announce
udp://pubt.in:2710/announce
udp://retracker.coltel.ru:2710/announce
udp://sandrotorde.de:1337/announce
udp://shadowshq.eddie4.nl:6969/announce
udp://shadowshq.yi.org:6969/announce
udp://thetracker.org:80
udp://thetracker.org:80/announce
udp://tracker.christianbro.pw:6969/announce
udp://tracker.coppersurfer.tk:6969
udp://tracker.coppersurfer.tk:6969/announce
udp://tracker.coppersurfer.tk:80
udp://tracker.coppersurfer.tk:80/announce
udp://tracker.cypherpunks.ru:6969/announce
udp://tracker.eddie4.nl:6969/announce
udp://tracker.internetwarriors.net:1337/announce
udp://tracker.justseed.it:1337/announce
udp://tracker.leechers-paradise.org:6969
udp://tracker.leechers-paradise.org:6969/announce
udp://tracker.mg64.net:2710/announce
udp://tracker.mg64.net:6969/announce
udp://tracker.mgtracker.org:2710/announce
udp://tracker.open-internet.nl:6969/announce
udp://tracker.opentrackr.org:1337/announce
udp://tracker.pirateparty.gr:6969/announce
udp://tracker.tiny-vps.com:6969/announce
udp://tracker.torrent.eu.org:451
udp://tracker.torrent.eu.org:451/announce
udp://tracker.vanitycore.co:6969/announce
udp://www.eddie4.nl:6969/announce
udp://zephir.monocul.us:6969/announce

Paramétrage dans qBittorrent

Dans qBittorrent, allez dans Outils > Options et copiez/collez la liste ci-dessus dans Bittorrent > Ajouter automatiquement ces trackers aux nouveaux téléchargements.

Liste de trackers Torrent UDP

N’oubliez pas, avec le pare-feu (wf.msc) sous Windows, de bloquer les protocoles TCP/ICMP/IGMP pour le logiciel qBittorent, que ce soit en entrant ou en sortant. Faute de quoi vous en serez quitte pour un mail de notre HADOPI nationale ! ;+) Sur Linux, vous pouvez tenter quelque chose de similaire avec AppArmor sous Ubuntu ou Mint, ou en utilisant les common groups avec Iptables.

DNS menteurs

Vous devez disposer de DNS autres que ceux de votre FAI et qui ne mentent pas !

Internet  / BitTorrent Hadopi P2P qBittorrent Torrent Trackers Torrent UDP 

Commentaires

udp://tobn.org:6969/announce

udp://tracker.zond.org:80
udp://tracker.zond.org:80/announce

TCP (liés au protocole Http)

TCP –> Layer 3
http –> Layer 7

Du coup je ne comprend pas trop cette phrase

@bubble

Oui, en effet, j’aurais dû dire : http pour le tcp.

j’essaie avec utorrent 3 mais ça marche pas!
le FAI bloque les torrents (il parait)

http://www.paroles.comuf.com

@André

Pub ???

udp://castradio.net:6969/announce

@bubble
Laisses il s’est planté, il faisait surement allusion au téléchargement direct.

Pour mieux piger la nuance :
Quand tu DL sur un site un .zip => TCP (DL direct). Paquet envoyé et vérifié.
Quand tu mattes une vidéo youtube => UDP (Stream). Paquet envoyé à l’arrache, plus de perte mais plus rapide.

udp://open.demonii.com:1337/announce = problème de certificat ou faille Poodle.Bref crypto hash failed

Bonjour
Merci
fonctionne avec uTorrent 2.2

49-3.be
French.Site torrent sympa généraliste.
Rapide ,fluide ,sécurisé,
Venez comme vous êtes
Nous accueillons tout le monde
Vous avez des fichiers à partager avec la communauté, nous sommes preneurs.
Sur demande nous formerons les membres qui souhaitent uploader.
http://49-3.be/index.php

« C’est dur de prouver juridiquement qu’une personne est en train de télécharger alors qu’elle n’est pas connectée au serveur, hein ?  »

Qu’importe que vous soyez en mode connecté ou pas :
Les datagrammes qui circulent entre votre terminal et le serveurs sont une preuve puisqu’il y a le datagramme IP, l’@ source et l’@ destination.
Le mode connecté n’apporte fondamentalement que l’ordonnancement des datagrammes en plus de la fiabilisation de la communication (pas de perte de data ni duplication).

Non, la preuve ne réside pas au niveau du tracker.

La preuve s’établit lorsqu’il est avéré que ce que l’on télécharge de chez vous est bien le fichier visé.

Pour traquer les contrevenants, il suffit donc de disposer d’un client bittorrent qui télécharge des oeuvres surveillées. Pendant ce temps, le client bittorrent modifié pour la cause scrupte les peers qui vous fournient des morceaux du fichier. Il suffit alors de filtrer cette liste de peers par rapport à leur emplacement géographique.

@dani

Et puis, il y a la réalité.

Hafopi n’a rien à voir avec TCP ou UDP. C’est le fait de partager un fichier faisant partie de leur liste qui est surveiller.

@setop

Comment fait-t-on pour savoir qu’une personne s’est connectée en UDP ?

@Denis > Le tracker conserve en permanence une liste des clients qui partagent le fichier. C’est ce qui permet à un nouveau client de savoir à qui il doit demander des morceaux du fichier. Même s’il n’y a pas de communication en mode « connecté » au niveau transport avec un client, le client communique bien régulièrement avec le tracker (pour lui indiquer les fichiers qu’il a en partage et en téléchargement, ainsi que les portions dont il dispose quand le fichier n’est pas complet) et le tracker conserve ça dans sa base de données pour le renvoyer à ceux qui veulent télécharger des morceaux de fichiers.

Au niveau de l’Hadopi (ou plutôt des sociétés qui se chargent de traquer les utilisateurs de P2P et remontent ensuite leurs données à l’Hadopi), pour caractériser qu’une IP partage un fichier, il suffit :
1) que cette IP soit connue du tracker => c’est le cas pour les IP publiques (éventuellement l’IP de sortie pour ceux qui passent par un VPN) de TOUS ceux qui sont en train de télécharger le fichier, puisqu’en BT le partage est obligatoire,
2) que la société parvienne à télécharger une portion du fichier depuis cette IP (un blocage des IP utilisées par ces sociétés suffit à empêcher la réalisation de cette deuxième condition… mais ces IP changent régulièrement).

Qu’on passe par TCP ou par UDP pour les échanges avec le tracker ne changera strictement rien à ces deux points.

TL;DR : on peut être « connecté » au tracker au niveau de la couche applicative sans pour autant être « connecté » au niveau de la couche transport.

Et au passage, l’Hadopi n’en a rien à foutre de savoir si l’utilisateur s’est « connecté » ou non à un tracker. Tout ce qui compte, c’est qu’un bout du fichier ait pu être téléchargé à partir de son IP. Quelqu’un qui se connecterait à un tracker BT tout en n’ayant aucun bloc de fichier en partage ne serait pas inquiété.

@LFS

Comment, juridiquement, prouver que tu es connecté en UDP, sachant qu’il n’y a aucun contrôle de connexion ? Je ne vais pas me répéter. Ca commence même un peu à me lasser.

« Comment, juridiquement, prouver que tu es connecté en UDP, sachant qu’il n’y a aucun contrôle de connexion ? »
Il n’y a pas juridiquement à prouver que tu es « connecté » au tracker au niveau de la couche transport.

Il y a juste à prouver qu’on a réussi à télécharger un morceau quelconque du fichier à partir de ton IP. Ça suffit à prouver que tu partages le fichier en question.

Et ça, ça ne nécessite pas de passer par une session de transport connectée. Ça nécessite juste de connaitre l’IP du partageur et son port d’écoute. Information qui sont connues du tracker.

À partir du moment où tu partages, tu peux te faire repérer. C’est pas plus compliqué que ça.

S’il suffisait de passer par UDP pour ne rien risquer, ça ferait très longtemps que ça se saurait et que tous les sites recommanderaient de le faire…

J’ajouterais d’ailleurs que le fait que tu te sois connecté au tracker en TCP n’est pas non plus une preuve que tu partages le fichier.

Ceux qui traquent les P2Pistes, tout ce qu’ils ont c’est la liste des clients que leur communique le tracker (liste qui contient aussi bien les gens qui ont communiqué avec le tracker en UDP que ceux qui ont communiqué en TCP). Si la présence d’une IP dans cette liste suffisait à caractériser l’infraction, il serait très facile pour les gestionnaires de tracker d’injecter dans ces listes 90% d’adresses bidons pour rendre des listes totalement inexploitables juridiquement en noyant l’information.

C’est pour ça que le point qui est retenu, ce n’est pas le fait que l’IP soit référencée par le tracker, mais le fait qu’on arrive à télécharger une portion du fichier à partir de cette IP. Là, pas possible d’injecter des IP bidons pour noyer l’information.

Et avec ça, on peut même se faire chopper sans jamais avoir contacté un tracker. Parce que les sociétés de chasse au P2Pistes peuvent obtenir l’IP d’un partageur autrement qu’auprès d’un tracker (DHT et échange de sources entre clients), et dès lors qu’ils arrivent à initier le téléchargement depuis cette IP, c’est bon pour eux.

@LFS

Etre verbeux ne change rien à la réalité. Et puis, il y a ceux qui croient… Tu crois à ce que tu veux.

« Le rôle de ce protocole est de permettre la transmission de données (sous forme de datagrammes) de manière très simple entre deux entités, chacune étant définie par une adresse IP et un numéro de port. Aucune communication préalable n’est requise pour établir la connexion, au contraire de TCP (qui utilise le procédé de handshaking). UDP utilise un mode de transmission sans connexion. »

Source : https://fr.wikipedia.org/wiki/User_Datagram_Protocol

Je connais très bien la définition de l’UDP hein. Mais c’est hors sujet pour ce qui est de la surveillance des échanges P2P par TMG et cie.

Le principe de la surveillance du P2P, c’est que celui qui surveille demande au tracker la liste de ceux qui partagent un certain fichier (comme le ferait n’importe quel client voulant télécharger ce fichier). Le tracker répond avec la liste de tous les clients connus, c’est-à-dire tous les clients qui se sont enregistrés auprès de lui pour lui indiquer qu’ils ont tout ou partie de ce fichier. Et que cet enregistrement ce soit via une communication en UDP ou en TCP, ça ne change strictement rien. Cette liste contient l’IP et le port d’écoute du client.

Ensuite, le surveilleur va essayer de télécharger des portions de ce fichier auprès des IP qui lui a communiqué le tracker. S’il arrive à télécharger un fichier, l’IP, le port et l’heure sont enregistrés pour identification.

Bref, le fait que la communication entre un client donné et le tracker se soit fait en UDP ou en TCP ne change STRICTEMENT rien. Celui qui surveille ne voit de toute façon pas cette communication (pour ça, il faudrait qu’il espionne la communication entre le client et le tracker, ce qui ne fait pas partie des habilitations de l’Hadopi, et encore moins des sociétés privées qui assurent la surveillance pour le compte des ayants droits), et il ne peut même pas savoir si elle a eu lieu en TCP ou en UDP. Tout ce que le surveilleur sait, c’est que quand il a demandé au tracker une liste de gens qui ont le fichier qu’il recherche, l’IP de ce client était dans la liste.

Hors VPN, la seule protection viable contre cette surveillance, c’est de connaître les adresses IP de ces surveilleurs pour les bloquer au niveau de son firewall. Ainsi, quand elles tenteront d’initier un téléchargement, elles se retrouveront bloquées, et elles n’auront donc pas de preuve que le fichier était bien en partage (la liste d’IP du tracker pourrait très bien contenir des faux clients, donc il faut avoir initié le téléchargement pour prouver le partage, la présence de l’IP dans la liste ne suffit pas).

Regardez un peu comment votre client P2P fonctionne. Vous devez-bien voir que des gens parviennent à télécharger des fichiers que vous partagez, même quand vous passez par de l’UDP. Ce qui implique forcément que ces gens connaissent votre IP publique et votre port d’écoute (c’est le principe de base du P2P, la communication se fait directement entre utilisateurs, donc il y a connaissance des IP publiques mutuelles). Et si ces gens peuvent avoir votre IP et votre port d’écoute, n’importe quelle société surveillant les fichiers que vous partagez peut l’avoir aussi.

@LFS

Je persiste et je signe !

Laisser un commentaire

(requis)

(requis)