Free TV sur ordi - Multiposte

ricardo · Février 20, 2016, 7:27pm

Deux problèmes pour voir la TV sur l’ordi via VLC (le “multiposte” de Free)
Je commence par le 1er et on verra ensuite pour le second :
Quels ports doivent être “ouverts” dans le parefeu
Si je bloque mon “iptables”, j’ai image et son (pour l’image, pas parfaite mais on verra ensuite)
Si je valide mon parefeu, je n’ai ni image, ni son.
Voici mon iptables-save (le 8080, je viens de le rajouter mais sans plus de succès)

[quote]*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i eth1 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -p udp -m udp --dport 31336 -j ACCEPT
-A INPUT -s 212.27.38.253/32 -d 88.181.42.135/32 -p udp -m state --state NEW,RELATED,ESTABLISHED,UNTRACKED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
COMMIT

Completed on Mon Apr 27 12:20:34 2009

Generated by iptables-save v1.4.3.2 on Mon Apr 27 12:20:34 2009

*nat
REROUTING ACCEPT [0:0]
OSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

Completed on Mon Apr 27 12:20:34 2009

Generated by iptables-save v1.4.3.2 on Mon Apr 27 12:20:34 2009

*mangle
REROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
OSTROUTING ACCEPT [0:0]
COMMIT

Completed on Mon Apr 27 12:20:34 2009

Generated by iptables-save v1.4.3.2 on Mon Apr 27 12:20:34 2009

*raw
REROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
[/quote]

phenix75 · Février 20, 2016, 7:27pm

Pour voir la télé sur ordi j’ai dû rajouter l’autorisation sur les ports compris dans une plage entre 1024 et 65535 venant de l’adresse ip 212.27.38.253 :

[quote]#Multiposte
iptables -A INPUT -i eth0 -p udp -s 212.27.38.253 --dport 1024:65535 -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -d 212.27.38.253 --sport 1024:65535 -j ACCEPT[/quote]

ricardo · Février 20, 2016, 7:27pm

Je vais essayer ça tout de suite et je reviens ici en ‘edit’.

EDIT :
avant d’essayer, j’ai revérifié mes règles et je pense qu’avec cette ligne, je suis couvert comme tu le dis :

MAIS … je viens de me rendre compte que je suis maintenant sur une Sid 64 bits et j’ai recopié mon iptables de la Sid 32 bits.
Est-ce que ces
212.27.38.253/32 -d 88.181.42.135/32
ne devraient pas être changés en 64

AslAn · Février 20, 2016, 7:27pm

Je ne suis pas sur mais je pense que le “/32” serait plutôt pour le masque de sous réseau 255.255.255.255, nan?

fran.b · Février 20, 2016, 7:27pm

Pour le freeplayer, j’ai mis

iptables -A INPUT -s 212.27.38.253 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
le /32 désigne le nombre de bits significatifs:

212.27.38.253/32 = 212.27.38.253
212.27.38.252/31 = 212.27.38.252 ou 212.27.38.253
212.27.38.0/24 = 212.27.38.0 -> 212.27.38.255
etc.

Pas sur qu’il y ait que de l’udp mais bon… Pour le reste, c’est la machine client qui initie la connexion donc ça devrait être bon.

ricardo · Février 20, 2016, 7:27pm

Ben tout essayé :
–la ligne de fran.b
–les deux lignes de phenix
même après reboute, négatif.
Je coupe mon parefeu, même sans rebouter, ça marche : image et son.
C’est bien la preuve que quelque chose coince dans mes règles, non
MAIS QUOI

Je précise que je suis sous Sid en 64 bits avec un noyau ‘2.6.29-1-amd64’ version 2.6.29-3

RE-voici mes règles :

[code]*filter
:INPUT DROP [126:6388]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2456:326390]
-A INPUT -i eth1 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -p udp -m udp --dport 31336:31337 -j ACCEPT
-A INPUT -s 212.27.38.253/32 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 212.27.38.253/32 -i eth0 -p udp -m udp --dport 1024:65535 -j ACCEPT
-A INPUT -s 212.27.38.253/32 -d 88.181.42.135/32 -p udp -m state --state NEW,RELATED,ESTABLISHED,UNTRACKED -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
-A OUTPUT -d 212.27.38.253/32 -o eth0 -p udp -m udp --sport 1024:65535 -j ACCEPT
COMMIT

Completed on Mon Apr 27 18:38:03 2009

Generated by iptables-save v1.4.3.2 on Mon Apr 27 18:38:03 2009

*nat
:PREROUTING ACCEPT [3:2508]
:POSTROUTING ACCEPT [8:480]
:OUTPUT ACCEPT [249:15340]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

Completed on Mon Apr 27 18:38:03 2009

Generated by iptables-save v1.4.3.2 on Mon Apr 27 18:38:03 2009

*mangle
:PREROUTING ACCEPT [172609:232701828]
:INPUT ACCEPT [172607:232700676]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2533:332550]
:POSTROUTING ACCEPT [2659:338938]
COMMIT

Completed on Mon Apr 27 18:38:03 2009

Generated by iptables-save v1.4.3.2 on Mon Apr 27 18:38:03 2009

*raw
:PREROUTING ACCEPT [172609:232701828]
:OUTPUT ACCEPT [2533:332550]
COMMIT
[/code]

phenix75 · Février 20, 2016, 7:27pm

Je viens d’essayer chez moi avec la ligne à fran en replacement de mes 2 lignes ça marche, j’ai essayé ta ligne :[quote]iptables -A INPUT -s 212.27.38.253/32 -d 88.181.42.135/32 -p udp -m state --state NEW,RELATED,ESTABLISHED,UNTRACKED -j ACCEPT [/quote] et là ça marche pas, cette ligne pose peut-être problème.

EDIT : dans les 2 lignes que je t’ai proposées plus haut, je viens de me rendre compte que ton interface est eth1,et non eth0 comme moi, il aurait fallu remplacer eth0 par eth1.

ricardo · Février 20, 2016, 7:27pm

Là, je suis entrain de tester sur une Lenny en 64 et j’“upgrade” . Sitôt fini, je teste sur cette Lenny et je reviens ici en EDIT.

EDIT :
Ok sur la Lenny en 64 bits.
Ce soir, j’essaie sur la Sid car ce n’est pas la même version de VLC
ici, sous Lenny, que ce soit la 32 ou la 64, c’est
noyau = 2.6.26-2
VLC = 2.8.6-h+lenny2

À ce soir … enfin … cette nuit :smt002

ricardo · Février 20, 2016, 7:27pm

Ben non, sur la Sid, y veut pas
même avec ces règles :

[code]*filter
:INPUT DROP [114:5237]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2420:305819]
-A INPUT -i eth1 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -p udp -m udp --dport 31336:31337 -j ACCEPT
-A INPUT -s 212.27.38.253/32 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
COMMIT

Completed on Tue Apr 28 00:27:16 2009

Generated by iptables-save v1.4.3.2 on Tue Apr 28 00:27:16 2009

*nat
:PREROUTING ACCEPT [2:2712]
:POSTROUTING ACCEPT [9:540]
:OUTPUT ACCEPT [254:15475]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

Completed on Tue Apr 28 00:27:16 2009

Generated by iptables-save v1.4.3.2 on Tue Apr 28 00:27:16 2009

*mangle
:PREROUTING ACCEPT [137710:185410329]
:INPUT ACCEPT [137710:185410329]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2421:305959]
:POSTROUTING ACCEPT [2536:311336]
COMMIT

Completed on Tue Apr 28 00:27:16 2009

Generated by iptables-save v1.4.3.2 on Tue Apr 28 00:27:16 2009

*raw
:PREROUTING ACCEPT [137710:185410329]
:OUTPUT ACCEPT [2421:305959]
COMMIT
[/code]

Ça, c’est la version du paquet .deb que l’on trouve sur la Sid :

fran.b · Février 20, 2016, 7:27pm

Il ne veut pas y compris sans le parefeu?

Sinon, tu fais la chose suivante:

Tu coupes le parefeu
Tu remets le parefeu
Tu lances ton freeplayer
Tu fais

iptables -L -v

Tu auras le nombre de paquets ayant été concerné par les règles. À priori tu sauyras quelle règle te contrarie. Au besoin, met la sortie qu’on puisse voir.

ricardo · Février 20, 2016, 7:27pm

Si, comme expliqué plus haut, SANS parefeu, ça fonctionne.
Il s’agit donc bien d’une couille dans ce dernier au niveau des règles.
J’essaie ton truc après midi.

ricardo · Février 20, 2016, 7:27pm

Contrôlé que ça fonctionne bien avec le parefeu 'clean’
Sitôt remis, négatif
voici le résultat de ta commande, que je ne sais pas interpréter, sinon que les seuls ayant l’air d’être concernés sont les deux “RELATED, etc.” :

[code]Dell-sid:/home/ricardo# iptables -L -v
Chain INPUT (policy DROP 7 packets, 273 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – eth1 any anywhere anywhere
60 49376 ACCEPT all – any any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT all – lo any anywhere anywhere
0 0 ACCEPT icmp – any any anywhere anywhere
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ftp-data
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ftp
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ssh
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:www
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ipp
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:bootps
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:bootps
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:http-alt
6231 8449K ACCEPT all – any any freeplayer.freebox.fr anywhere state NEW,RELATED,ESTABLISHED
0 0 ACCEPT udp – any any anywhere anywhere udp dpts:31336:31339

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – any eth0 anywhere anywhere

Chain OUTPUT (policy ACCEPT 75 packets, 5016 bytes)
pkts bytes target prot opt in out source destination
[/code]

EDIT :
à tous hasards, voici le iptables concerné :

-A INPUT -i eth1 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -p tcp -m tcp --dport 20 -j ACCEPT -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A INPUT -p tcp -m tcp --dport 67 -j ACCEPT -A INPUT -p udp -m udp --dport 67 -j ACCEPT -A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT -A INPUT -s 212.27.38.253/32 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A INPUT -p udp -m udp --dport 31336:31339 -j ACCEPT

ricardo · Février 20, 2016, 7:27pm

J’ai trouvé quelque chose en comparant avec ma Sid sur le P4 (en 32).
Le problème était le même : sans parefeu = OK ; avec parefeu = niet.
J’ai bricolé deux ou trois trucs et ça fonctionne AVEC parefeu.
Je vais essayer de transposer exactement les mêmes règles sur cette Sid 64 du portable et je reviens donner le résultat en EDIT ici.

PascalHambourg · Février 20, 2016, 7:27pm

Alors, je reviens sur ce forum, et sur quoi je tombe ? Ricardo, c’est quoi ce jeu de règles iptables pourri ? C’EST QUOI ?

Sans règle qui accepte le trafic dans l’autre sens, c’est un intérêt très limité. S’il n’y a pas de machine qui accède à internet via celle-ci, alors cette règle est superflue. S’il y en a une, elle ne doit pas avoir accès à grand chose vu que les réponses sont bloquées.

Comme il ne manque qu’INVALID à la liste d’états et qu’un paquet UDP ne peut pas être dans l’état INVALID, la correspondance ‘state’ est superflue.
88.181.42.135, c’est vraiment l’adresse IP d’eth0 ?

DHCP utilise uniquement UDP, pas TCP.

Sinon, concernant ton problème, pour savoir ce qui coince tu ajoutes une règle LOG en fin de chaîne et tu regardes ce qui est bloqué dans les logs du noyau.

ricardo · Février 20, 2016, 7:27pm

que tu m’expliques mes conneries (qui ne viennent pas toutes de moi, demande à ton pote François ), je veux bien mais que tu m’engueule, pas d’accord, tout le monde n’a pas tes compétences en matière de parefeu. :smt002

[code]-A FORWARD -o eth0 -j ACCEPT

Sans règle qui accepte le trafic dans l’autre sens, c’est un intérêt très limité. S’il n’y a pas de machine qui accède à internet via celle-ci, alors cette règle est superflue. S’il y en a une, elle ne doit pas avoir accès à grand chose vu que les réponses sont bloquées.[/code]
Je ne me souviens plus qui m’a conseillé cette ligne mais je peux seulement préciser que j’ai deux machines reliées par une freebox comme routeur et qui communiquent entre-elles en sshfs et avec rsync.
Si tu me confirmes que je peux enlever cette ligne, je le fais.
Je passerai à la suite de tes remarques après réponse à cette première.

PascalHambourg · Février 20, 2016, 7:27pm

Pour que ce soit bien clair : tu as deux machines reliées directement (ou via un switch, un hub, en wifi) à la Freebox configurée en mode routeur, et non une machine A reliée d’une part à la Freebox configurée en mode normal (half-bridge, non routeur) et d’autre part à une autre machine B pour laquelle elle joue le rôle de passerelle ?

Dans ce cas,

la règle FORWARD est sans objet puisque la machine A n’est pas un routeur ;
les machines ont des adresses privées 192.168.x.y, par conséquent la règle “spéciale freeplayer” avec l’option -d 88.181.42.135 ne peut pas marcher. Moi je virerais ce -d qui ne sert pas à grand chose de toute façon.

ricardo · Février 20, 2016, 7:27pm

Bon, je vais tenir compte de tes remarques.
1/ Je suis d’accord avec ton analyse et je crois me souvenir maintenant que cette règle Forward avait été créée quand j’avais deux machines reliées filairement, dont une était seule reliée à la freebox.
2/ je ne vire que le ‘-d’ ou je vire toute la ligne
suite aux remarques du message précédent :

[code]
Code:
-A INPUT -s 212.27.38.253/32 -d 88.181.42.135/32 -p udp -m state --state NEW,RELATED,ESTABLISHED,UNTRACKED -j ACCEPT

Comme il ne manque qu’INVALID à la liste d’états et qu’un paquet UDP ne peut pas être dans l’état INVALID, la correspondance ‘state’ est superflue.
88.181.42.135, c’est vraiment l’adresse IP d’eth0 ?[/code]

Cette ligne a été enlevée entre-temps et remplacée par :

-A INPUT -s 212.27.38.253/32 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPTconseillé par François.

Oui, c’est vraiment mon adresse IP et sur eth0, ainsi que sur wlan0 (tant pis, je me dévoile mais étant donné qu’on peut trouver ça facilement … :smt002 )

PascalHambourg · Février 20, 2016, 7:27pm

C’est pas clair ton affaire. Ta Freebox est en mode “bridge” (non routeur) ou en mode bridge ? C’est quoi wlan0 ?

A part ça, tu peux virer les options -d et -m, ou prendre la règle de François. Si ça coince toujours, ajoute une règle de LOG pour y voir plus clair.

ricardo · Février 20, 2016, 7:27pm

[quote=“PascalHambourg”]C’est pas clair ton affaire. Ta Freebox est en mode “bridge” (non routeur) ou en mode bridge ? C’est quoi wlan0 ?

A part ça, tu peux virer les options -d et -m, ou prendre la règle de François. Si ça coince toujours, ajoute une règle de LOG pour y voir plus clair.

Ma Freebox est en mode routeur, les deux machines sont chacune reliées en ethernet sur les ports de la freebox V5.
De ce fait, elles communiquent entre-elles, via la freebox avec des IP internes (192.168.0.10 = machine 1 … —.11 = machine 2 …, —.12 = wifi machine 1) Le tout déclaré sur mon compte Free comme IP fixe.
Mon IP fixe extérieure étant 88.181.42.135.
De plus, le portable (machine 1) est aussi relié en wifi (wlan0)
J’ai tout viré et ça coince topujours je vais donc ajouter la ligne LOG et je reviens.

ricardo · Février 20, 2016, 7:27pm

Voici donc mes nouvelles règles, quoi faire avec LOG de plus *filter :INPUT DROP [35:1981] :FORWARD DROP [0:0] :OUTPUT ACCEPT [2239:321099] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -p tcp -m tcp --dport 20 -j ACCEPT -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A INPUT -s 212.27.38.253/32 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A INPUT -p udp -m udp --dport 31336 -j ACCEPT -A INPUT -j LOG COMMIT