Est-ce que youtube refuse les VPN?

Pause Café
#1

Bonjour,

on m’a toujours dit (par des publicités) qu’avec un VPN, on pouvait avoir accès au contenu web non accessible dans son pays mais accessible depuis un VPN à l’étranger.

Je n’utilise pas de vpn, j’utilise juste « ssh proxy socks5 », càd un tunnel chiffré entre mon poste client et le vps (qui sert de proxy, localisé en France), mais lorsque j’essaye de lire la vidéo youtube https://www.youtube.com/watch?v=pQaG0ay957M, youtube m’affiche ceci :

**VPN/Proxy détecté**

Pour continuer, désactivez votre VPN/proxy. Ainsi, YouTube pourra rechercher les meilleurs contenus.[En savoir plus](https://support.google.com/youtube/answer/12358806?hl=fr)

Du coup, je ne peux pas lire la vidéo. Alors, je me demande si en utilisant un vrai VPN (comme NordVPN par exemple) j’obtiendrai le même message ?

Par contre, si je n’utilise pas de proxy, mais juste mon client (en France), je peux lire la vidéo.

Qu’en pensez-vous ?

#2

Un VPN et un proxy ce n’est pas la même chose.
Donc c’est normal que ce soit détecté quand tu passe à travers un proxy.

#3

Proxy socks5 (sur serveur OVHvia ssh):
image
VPN (via un serveur OVH):
image

dans tous les cas, youtube t’enquiquine. En revanche un VPN via chez moi ou un proxy Socks5 via chez moi ne pose pas de souci (je l’ai fait en utilisant la 5G pour me connecter à un serveur autohébergé.
Bref, je pense que c’est un filtrage par IP/ En revanche je suis sur qu’il y a qques années, cette restriction n’existait pas. Si ils interdisent les VPNs, ça va faire plaisir aux regimes autoritaires

1 J'aime
#4

Non. Car cela signifierait qu’ils connaissent toutes les IPs des VPN? impossible.
Par contre, la façon dont sont traités les paquets et leur contenu peuvent permettre d’identifier la connexion comme un VPN ou un proxy.

#5

Oui, mais comment expliquer que si le VPN est chez moi ça passe, ou si il est sur un serveur de chez OVH, ça ne passe plus (avec exactement la même configuration), idem pour le proxy socks5. Fais l’expérience, si tu as une explication autre je prend. Sinon il suffit pour eux de regarder les reverse DNS

#6

Si le VPN est chez toi ça passe? ce n’est pas clair.

1 - ou est le poste de travail, n’importe où sauf chez toi? ou chez toi?
2 - Cas 1: le VPN est chez toi, mais le poste de travail ne l’est pas?
3- Cas 2: le VPN est chez OVH mais le poste de travail est chez toi ou ailleurs?

Car si la configuration VPN est la même , je doute que les configuration OS soit rigoureusement les mêmes, et c’est sans parle des infrastructures de sorties (ta box pour chez toi, l’infrastructure OVH pour ton VPS).
D’autant que le type d’interconnexion d’un VPS/OVH est radicalement différente de cette que l’on a chez soit.

#7

Connexion via 5G lorsque j’ai fait le test, le poste de travail est donc extérieur

Les 2 VPNs sont des openvpn sous debian bookworm. Et tout de même, si je résume:
VPN:

  • Refus chez OVH
  • accepté chez moi (adresse chez free)
  • accepté chez une adresse dsl-dyn.isp.belgacom.be (raspberry PI bulleye)

Sur le proxy sockjs5, je peux faire bcp plus de tests:

  • Refus sur une IP OVH range 37.187.118.0-37.187.119.255
  • accepté via chez moi
  • accepté sur une IP de evxonline.net
  • Refus sur une IP OVH range 51.91.48.0-51.91.49.255
  • accepté sur une IP Education Nationale Range: 129.199.0.0 - 129.199.255.255
  • Refus sur un serveur OVH range 94.23.16.0-94.23.31.255
  • accepté sur une adresse du réseau dsl-dyn.isp.belgacom.be (raspberry PI bulleye)

J’ai regardé les captures tcpdump en direct et sur le VPN OVH, ainsi que le VPN raspberry belge, je n’ai vu aucune différence dans les connexions, enfin dans les headers transmis par apache, à part
REMOTE_ADDR, REMOTE_PORT et UNIQUE_ID, tout est identique.

#8

S’il y avait le moindre filtrage par youtube des adresses IP OVH, ça se saurait.
Je pense que ça vient de tes configurations. D’autant que tes tcpdump devraient être en sortie d’OVH et en sortie de de free et en sortie de tes autres tests, ou alors à l’entrée de youtube, mais ce n’est pas vraiment faisable.
Il y a eu des blocages par IP notamment avec yt-dlp pour des usages un peu trop excessifs (téléchargement important par exemple); mais pas de façon permanente.

#9

Encore une fois c’est la même configuration, ces machines, notamment celle de belgique, qui est celle d’un ami m’ayant demandé de faire un VPN, j’ai recopié exactement les mêmes fichiers de configuration en modifiant juste les IP. Par ailleurs, j’ai les captures réseaux de chacune des connexions (directes et via VPN), je ne vois aucune différence. Je peux te les passer si tu veux les étudier. Personellement ma déduction ne vient que d’une chose: Tout ce qui vient de serveur OVH est refusé (ubuntu bionic, debian bookworm (2 fois) , ubuntu focal), les autres sont acceptés (debian bookworm, debian bullseye, debian jessie, …), de plus les comportements proxy socks5 coincident avec les comportements VPN et enfin les headers de la connexions ne changent pas.
Si tu as une explication autre que par l’IP, je suis preneur, en tout cas, ça ne vient pas des configurations des VPNs et en tout cas pas celles de ssh.
OVH est un gros pourvoyeur de serveurs, que youtube empêche les serveurs de récupérer les flux de vidéos pour les servir à leur propre compte me parait plausible.

#10

comment fais tu pour tes tcpdumps?
pour le contenu des paquets, youtube étant le serveur, il peut donc l’analyser (ne serait-ce qu’avec un WAF).
De plus ton histoire de proxy peut aussi avoir un impact.

Youtube surveille étroitement les connexion qui sont faites- sur ses serveurs.

#11

Peut-être que youtube compare 2 adresses ip pour voir si elles sont éloignées géographiquement mais rapprochées dans le temps.

Exemple : je consulte youtube en étant connecté à mon compte google, sans utiliser de vpn, mais en utilisant ma box française (donc ip géolocalisée à Paris en France).

Puis « 5 minutes plus tard », j’utilise un vpn allemand (donc ip géolocalisé à Berlin en Allemagne) pour aller à nouveau sur youtube.

Google remarque que ces 2 adresses ip sont très éloignées géographiquement, mais très proche dans le temps : c’est impossible qu’un utilisateur fait le trajet Paris-Berlin en train, à pied, en avion, en 5 minutes pour aller sur youtube, donc google en déduit que l’utilisateur utilise un proxy ou un vpn.

De plus, il parait que ça dépend des chaines youtube, car il y a des chaines youtube qui n’acceptent pas les vpn (surtout les chaines sportives comme la formule 1, les jeux olympique) et d’autres qui acceptent.

#12

J’ai fait une requête sur un serveur à moi sur lequel j’ai fait une capture tcpdump et dont la page appelée m’affiche les variables diverses (l’environnement)

La seule technologie que je connais qui permettrait de remonter à l’IP originale est le WebRTC mais cela utilise le port 3478 en UDP, or je n’ai rien vu de passer sur ce port. Le site

permet de voir si le navigateur laisse fuiter cette info. (pas le cas chez moi)
Tu vois autre chose comme technique?
En interrogeant chatGPT, j’ai obtenu ça comme réponse:

1 J'aime