OVH Cloud OVH Cloud

Livebox Play un enfer

31 réponses
Avatar
Setup.exe
Bonsoir

Je cherche de l'aide pour ouvrir une plage de ports sur une livebox :
trois jours que je suis dessus, pas moyen.

merci d'avance

julien

10 réponses

1 2 3 4
Avatar
Setup.exe
Le 13/01/2019 à 09:38, Pascal Hambourg a écrit :
Il est donc plus pratique de demander d'ouvrir à son player ce genre
d'adresse : http://90.49.213.254:8001/maradio.mp3 (depuis le PC où
l'on travaille, donc celui même qui envoie le flux) et si ça marche on
sait que ça marche sur le net.

Non, ce n'est pas une garantie.
La box ne va pas convertir en local, ce flux.

En fait si.
Elle va prendre le flux en passant par l'internet.

Non. Le rebouclage est fait dans la box.

Je suis fort surpris de l'apprendre. En effet, j’héberge à domicile au
moins deux webradios, et depuis des lustres quand je veux écouter ces
flux je prends soin d'utiliser l'adresse d'écoute en mettant l'adresse
locale dans mon lecteur et non celle avec mon IP publique, afin
d'alléger le trafic et la bande passante chez moi.
Quel outil pourrait me permettre de vérifier qu'en utilisant l' IP
publique de l'adresse radio, (à partir du réseau local où elle hébergée
donc) le flux ne passe pas par le net et se convertit en flux local ?
Exemple : adresse publique radio : http://fieldmice.free.fr/Line_In.pls
La même en local : http://192.168.1.5:8002/line_in.mp3
Avatar
Setup.exe
Le 13/01/2019 à 10:39, Pascal Hambourg a écrit :
Inutile de revenir dessus, on a bien compris que l'OP a été induit en
erreur par le résultat négatif d'une méthode de test qui ne fonctionnait
pas avec sa box.

C'est exactement ça.
Du coup j'ai retrouvé espoir.
On peut juste souligner le risque à faire des généralisations en
fonction de son expérience du genre "ça marche avec telle box donc ça
marche avec toutes les box".

Oui, sauf que depuis 2001 j'ai toujours procédé comme ça, ça fait tout
de même une grosse généralité. Je dépanne des clients ou amis / famille
en VNC depuis cette date, je monte des flux audio d'un peu partout
depuis cette date, ma méthode avait toujours fonctionné jusqu'à lors.
Même si là, les faits vous donnent raison.Et qu'en effet, un test à
partir d'un PC distant est le meilleur test.
Avatar
Setup.exe
Le 13/01/2019 à 09:30, pehache a écrit :
Le 12/01/2019 à 19:30, Setup.exe a écrit :
Le 12/01/2019 à 19:02, denis.paris a écrit :
Le 12/01/2019 à 17:56, Setup.exe a écrit :
Le 12/01/2019 à 17:17, Didier a écrit :
Le 12/01/2019 à 16:17, Setup.exe a écrit :
En fait ça marche depuis l'extérieur mais pas depuis cet ordi lui
même, comme j'ai expliqué avant Ce qui fait que mes tests en usant
de cette méthode n'étaient pas fiables non plus.
Partout ailleurs ce type de test est bon : pour savoir si mon VNC
fonctionne, je rentre l'ip publique dans mon client VNC et la
fenêtre du mot de passe s'affiche. Ici : non.

Bjr,
je crois (à confirmer) que ça ne marche jamais, de faire un accès
par
l'IP publique à partir d'un PC du LAN. Tu dois faire le test à
partir
d'internet, par l'accès WAN.
Didier.

Je suis formel pour dire que ça marche toujours, puisque je fais comme
ça depuis des années, y compris avec des Livebox.

Que ça "marche" ou non, le besoin que tu exprimes est atypique:
- si une machine de ton réseau offre un service sur un certain port, la
redirection depuis Internet fonctionne, comme tu as fini par l'admettre
ci-dessus.
- si tu veux utiliser ce service depuis ton réseau, par exemple d'une
autre machine, tu dois utiliser l'adresse locale (en 192.x.x.x)
=> le besoin d'utiliser une adresse publique en "sortant" puis en
"ré-entrant" sur ton même réseau local est juste une lubie, AMA, car il
faut nécessairement que la box procède à des substitutions d'adresses
dont tu ne connais le mécanisme exact, ça doit dépendre en effet du FAI
et de la table de routage qu'il décide de mettre en place.
Donc franchement, je ne vois pas pourquoi tu te prends la tête au point
d'en devenir fou. Exprime ton besoin *réel* et pas seulement un caprice,
et on pourra peut-être te conseiller.

Le besoin réel est au départ ouvrir une plage de ports sur la Livebox
Play, tout simplement (de 8000 à 8005)
Quant à mon besoin étrange, c'était au départ juste une remarque, pas
une nécessité. Quand on monte un stream audio (un VNC c'est pareil), le
tester en local ne prouve pas que l'acc!s est bon depuis internet.
Il est donc plus pratique de demander d'ouvrir à son player ce genre
d'adresse : http://90.49.213.254:8001/maradio.mp3 (depuis le PC où l'on
travaille, donc celui même qui envoie le flux) et si ça marche on sait
que ça marche sur le net. La box ne va pas convertir en local, ce flux.
Elle va prendre le flux en passant par l'internet. Et donc on sait que
ça fonctionne. J'ai fait beaucoup d'install de ce type et ça a toujours
fonctionné.

Quand la box gère le loopback, rien ne passe par internet à part
l'interrogation du DNS (si l'URL demandée est un domaine). Pour s'en
convaincre il suffit de faire un ping : le temps d'aller/retour est typique
du LAN.

Ok. Merci pour cette réponse simple et claire.
Avatar
Pascal Hambourg
Le 13/01/2019 à 11:45, Setup.exe a écrit :
Le 13/01/2019 à 09:38, Pascal Hambourg a écrit :
Non. Le rebouclage est fait dans la box.

Je suis fort surpris de l'apprendre. En effet, j’héberge à domicile au
moins deux webradios, et depuis des lustres quand je veux écouter ces
flux je prends soin d'utiliser l'adresse d'écoute en mettant l'adresse
locale dans mon lecteur et non celle avec mon IP publique, afin
d'alléger le trafic et la bande passante chez moi.
Quel outil pourrait me permettre de vérifier qu'en utilisant l' IP
publique de l'adresse radio, (à partir du réseau local où elle hébergée
donc) le flux ne passe pas par le net et se convertit en flux local ?

Il faudrait mesurer le débit ou la latence de la communication. Si on
mesure des valeurs impossibles à atteindre sur la liaison internet, la
conclusion est claire. Pour mesurer la latence, on peut utiliser un
logiciel de capture de trafic comme wireshark.
Exemple : adresse publique radio : http://fieldmice.free.fr/Line_In.pls
La même en local : http://192.168.1.5:8002/line_in.mp3

Ah non, ce n'est pas la même chose. Le premier URL correspond à un
serveur de pages perso de FAI, pas à une box. C'est la playlist renvoyée
par le serveur qui contient l'URL du MP3 avec, je suppose, l'adresse
publique de la box. Au passage, ça tombe pile dans le cas que j'avais
exposé en réponse à Denis :
"La page du site web extérieur qui contient l'URL sur laquelle on clique
pour accéder au service ne sait pas si on est sur le réseau local ou à
l'extérieur."
Si tu veux comparer, il faut prendre l'URL contenu dans la playlist.
Avatar
Setup.exe
Le 13/01/2019 à 15:35, Pascal Hambourg a écrit :
Si tu veux comparer, il faut prendre l'URL contenu dans la playlist.

Qu'on passe par la gâchette playliste ou pas, dans tous les cas cette
adresse utilise bien l'ip publique non ? y'a un intermédiaire de plus
cependant, oui (le PC qui héberge la page che Free)
Avatar
Pascal Hambourg
Le 13/01/2019 à 16:14, Setup.exe a écrit :
Le 13/01/2019 à 15:35, Pascal Hambourg a écrit :
Si tu veux comparer, il faut prendre l'URL contenu dans la playlist.

Qu'on passe par la gâchette playliste ou pas, dans tous les cas cette
adresse utilise bien l'ip publique non ? y'a un intermédiaire de plus
cependant, oui (le PC qui héberge la page che Free)

Si tu fais des tests de latence et de débit sur l'URL de la playlist, tu
n'auras pas du tout le même résultat qu'avec l'URL public de la radio.
Avatar
denis.paris
Le 13/01/2019 à 10:39, Pascal Hambourg a écrit :
Le 13/01/2019 à 10:18, denis.paris a écrit :
Un exemple: j'ai un serveur VPN sur mon réseau et je veux tester son
fonctionnement depuis un poste de mon réseau local. Alors oui je peux
peut-être récupérer une adresse en 10.x.x.x en sus de la 192.x,

Comment ça, récupérer une adresse en 10.x.x.x, pour quoi faire ?
mais bonjour la redirection des flux!

Peux-tu développer car je ne vois pas pù tu veux en venir ?

Quand je travaillais de chez moi pour accéder au réseau de mon
entreprise, suite à la connexion VPN j'arrivais sur un réseau 10.x, qui
était routé ensuite sur les différents réseaux des clients que nous
gérions. Je suppose donc que cette pratique est courante, cela permet de
séparer / contrôler les flux entre les administrateurs système selon
qu'ils se connectent en interne ou depuis l'extérieur.
Donc quand je dis "récupérer une adresse en 10." c'est un raccourci, ça
veut dire simplement dire que le serveur VPN a authentifié le client
avec sa clé.
Mais ce n'est pas le sujet, n'est-ce pas! Donc je ne développerai pas
davantage... ;)
Avatar
pehache
Le 13/01/2019 à 09:43, Pascal Hambourg a écrit :
[Copie et suivi en charte dans fr.comp.reseaux.ip]
Le 13/01/2019 à 09:30, pehache a écrit :
Quand la box gère le loopback, rien ne passe par internet à part
l'interrogation du DNS (si l'URL demandée est un domaine). Pour s'en
convaincre il suffit de faire un ping : le temps d'aller/retour est
typique
du LAN.

Ça existe sur les box, la redirection du ping (autrement que dans le cas
de mise en place d'une "DMZ" globale) ?
Le ping (ICMP) n'est pas pris en charge par une redirection de port TCP
ou UDP.

Euh... je ne sais pas ! Je sais juste que quand depuis mon LAN je fais un
ping sur le nom de domaine qui pointe sur l'IP publique de ma box (box qui
gère le loopback), j'obtiens les mêmes temps d'A/R que ceux du ping sur
l'IP locale (0.5ms)
En fait statistiquement c'est un micro-poil plus long avec le nom de
domaine, mais l'écart est trop faible pour être explicable par un transit
sur internet.
iMac:bin ******$ ping mondomaine.fr
PING ********.fr (xx.xx.xx.xx): 56 data bytes
64 bytes from xx.xx.xx.xx: icmp_seq=0 ttld time=0.408 ms
64 bytes from xx.xx.xx.xx: icmp_seq=1 ttld time=0.460 ms
64 bytes from xx.xx.xx.xx: icmp_seq=2 ttld time=0.543 ms
64 bytes from xx.xx.xx.xx: icmp_seq=3 ttld time=0.893 ms
64 bytes from xx.xx.xx.xx: icmp_seq=4 ttld time=0.535 ms
64 bytes from xx.xx.xx.xx: icmp_seq=5 ttld time=0.495 ms
64 bytes from xx.xx.xx.xx: icmp_seq=6 ttld time=0.532 ms
64 bytes from xx.xx.xx.xx: icmp_seq=7 ttld time=0.493 ms
64 bytes from xx.xx.xx.xx: icmp_seq=8 ttld time=0.527 ms
64 bytes from xx.xx.xx.xx: icmp_seq=9 ttld time=0.507 ms
^C
--- mondomaine.fr ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.408/0.539/0.893/0.124 ms
iMac:bin ******$
iMac:bin ******$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttld time=0.463 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttld time=0.469 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttld time=0.471 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttld time=0.439 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttld time=0.412 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttld time=0.503 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttld time=0.486 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttld time=0.508 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttld time=0.426 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttld time=0.467 ms
^C
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.412/0.464/0.508/0.030 ms
Avatar
Setup.exe
Le 12/01/2019 à 19:21, Eric Masson a écrit :
"denis.paris" writes:
'Lut,
Que ça "marche" ou non, le besoin que tu exprimes est atypique:

Pas tant que cela, le nat loopback existe depuis des lustres sur Linux
et peut répondre au besoin légitime de paramétrer une machine pour
accéder à un service indépendamment de la localisation de celle-ci.
Orange en fait publicité sur certaines de ses LB :
https://assistance.orange.fr/livebox-modem/toutes-les-livebox-et-modems/installer-et-utiliser/piloter-et-parametrer-votre-materiel/le-parametrage-avance-reseau-nat-pat-ip/dns/livebox-4-le-loopback_243342-785338
Mais apparemment, la Play ne supporte pas la fonctionnalité.
https://communaute.orange.fr/t5/ma-connexion/NAT-loopback-sur-un-LiveBox-Play/td-p/1022666
Mais comme l'a rappelé Pascal, cela n'a pas grand chose à voir avec
Ethernet.
fu2: fr.comp.reseaux.ip

Merci à tous pour vos réponses.
J'y suis retourné hier et je pensais que ce serait facile désormais mais
non. Désolé mais l'interface est tordue, et ces gens chez Orange ne sont
pas foutus de fournir un véritable guide, pas à pas, clair, où l'on soit
certain d'arriver à ses fins.
La section "Pare Feu" est vraiment la pire, mais ce n'est pas la seule.
Comme cette phrase dans l'onglet NAT "assurez vous de ne pas avoir
filtré ces ports dans le pare feu" : ça veut dire quoi ? Faut pas les
ouvrir alors ?? Dans le cas inverse, pourquoi on les bloquerait si c'est
pour les ouvrir dans le NAT ?? Que veut dire "filtrer" franchement ?
Je me retrouve avec le port 8001 qui est inexplicablement ouvert alors
que je n'ai de cesse d'avoir entré une plage : de 8000 à 8005. J'ai tout
essayé dans tous les sens. Rien à faire.
Avatar
pehache
Le 14/01/2019 à 14:13, Setup.exe a écrit :
Merci à tous pour vos réponses.
J'y suis retourné hier et je pensais que ce serait facile désormais mais
non. Désolé mais l'interface est tordue, et ces gens chez Orange ne sont
pas foutus de fournir un véritable guide, pas à pas, clair, où l'on soit
certain d'arriver à ses fins.

En même une box est un truc grand-public, il ne faut en général pas
s'attendre à un interface très technique...
La section "Pare Feu" est vraiment la pire, mais ce n'est pas la seule.
Comme cette phrase dans l'onglet NAT "assurez vous de ne pas avoir
filtré ces ports dans le pare feu" : ça veut dire quoi ? Faut pas les
ouvrir alors ? ? Dans le cas inverse, pourquoi on les bloquerait si c'est
pour les ouvrir dans le NAT ? ? Que veut dire "filtrer" franchement ?

Ils veulent peut-être (sans doute) parler du pare-feu de la machine vers
laquelle le port est redirigé ?
Je me retrouve avec le port 8001 qui est inexplicablement ouvert alors
que je n'ai de cesse d'avoir entré une plage : de 8000 à 8005. J'ai tout
essayé dans tous les sens. Rien à faire.

Euh... Que le port 8001 soit ouvert si tu as entré la plage 8000-8005
c'est normal, non ?
1 2 3 4