logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 22-11-2014 00:48:11

laurent1
Membre
Distrib. : Debian 7.6
Noyau : Linux 3.2.0-0-686-pae
Inscription : 22-11-2014

Communication Empathy impossible

Bonjour,

Il m'est impossible de communiquer par la vidéo ou le son via empathy, bien que tous les ports sont ouverts (5687 et 5688 que j'ai changer de 5222 et 5269) en udp et tcp et les clients connectés (il est possible de parler en message texte). L'appel coupe dès que l'appelé décroche.

Je tourne sous une debian 7.6, avec serveur ejabbered.

Mon pare feu est iptables :

#!/bin/bash

iptables -t filter -F
iptables -t filter -X

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 20 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5688 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5688 -j ACCEPT





Cordialement,
Laurent.


Pc sous debian 7.6 => noyau Linux 3.2.0

Serveur debian 7.6 => Linux 3.2.0

Hors ligne

#2 22-11-2014 06:31:42

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : Communication Empathy impossible

Bonjour laurent1,

Afin de rendre plus facile l'entraide sur le forum, il est préférable de mettre son infodistri à jour comme indiqué dans ce délicieux tuto :
Voir le tuto : Trop cool d'indiquer son installation dans son profil !

Bon, ce point choco dans la besace, je t'avoue que je suis pas qualifié pour t'aider sur ton problème et je passe la main... cool

saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#3 22-11-2014 09:45:24

anonyme
Invité

Re : Communication Empathy impossible

Bonjour
en matiere de parefeu je suis nul  smile   (no coment ....... )  mais je vois pas de règle INPUT , ce serait une option ?
et a tu essayer le logiciel sans parefeu et fonctionne t il bien ?

@++

a si pardon pas vu

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT  =>  ici un NEW peut etre (NEW,RELATED,ESTABLISHED )

Dernière modification par anonyme (22-11-2014 09:49:48)

#4 22-11-2014 09:58:04

raleur
Membre
Inscription : 03-10-2014

Re : Communication Empathy impossible

Ces règles sont sur le serveur ou les clients ? Où sont-ils situés les uns par rapport aux autres ?
Sans filtrage, qu'est-ce que ça donne ?

Il vaut mieux montrer que raconter.

Hors ligne

#5 22-11-2014 18:17:51

laurent1
Membre
Distrib. : Debian 7.6
Noyau : Linux 3.2.0-0-686-pae
Inscription : 22-11-2014

Re : Communication Empathy impossible

Bonjour à tous,

Je vient de faire les tests.

J'ai commencer par tout ouvrir sur le serveur et les 2 clients => la connexions passe sans problème.

J'ai ensuite fermer tout les ports par default sur le serveur mais est laissé les ports xmpp (5222 et 5269 par default mais je les ai changer pour 5687 et 5688) et les port essentiels au serveur => la connexion passe

J'ai ensuite essayé sur les clients :

#!/bin/bash

iptables -t filter -F
iptables -t filter -X

iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 20 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5688 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5688 -j ACCEPT



=> la connexion passe

Mais ensuite, après avoir essayé :

#!/bin/bash

iptables -t filter -F
iptables -t filter -X

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 20 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5688 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5688 -j ACCEPT



#!/bin/bash

iptables -t filter -F
iptables -t filter -X

iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 20 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5688 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5688 -j ACCEPT




ou même :

#!/bin/bash

iptables -t filter -F
iptables -t filter -X

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 20 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5688 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5688 -j ACCEPT



La connexion ne passe pas, la sonnerie se fait chez le client appelé dans les 3 cas mais impossible de communiquer.

Pourtant le port c2s - 5687 - (et même s2s - 5688 - qui n'est pas obligatoire) est ouvert en sortie avec ces 3 configs.

J'ai l'impression qu'il manque un port en entré et plus d'un en sortie...

Avant iptables, j'utiliser sur les 2 clients ufw, il suffisait pourtant d'ouvrir en sortie en udp 5687 et cela marcher sans problème.

Cordialement,
Laurent.

Dernière modification par laurent1 (22-11-2014 18:20:32)


Pc sous debian 7.6 => noyau Linux 3.2.0

Serveur debian 7.6 => Linux 3.2.0

Hors ligne

#6 22-11-2014 18:35:56

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : Communication Empathy impossible

Salut,

Je peux toujours pas t'aider mais toi tu peux aider tous sur debian-facile !
Comment ?

Regarde ce tuto pour mettre ton infodistri à jour :
Voir le tuto : Trop cool d'indiquer son installation dans son profil ! cool

saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#7 22-11-2014 19:05:39

sogal
Black Metal Modo
Lieu : Nord Isère
Distrib. : openSUSE Leap 42.3
Noyau : Linux 4.4.76
(G)UI : GNOME
Inscription : 09-05-2013
Site Web

Re : Communication Empathy impossible

Salut,

Cas fonctionnel:

laurent1 a écrit :

iptables -t filter -P INPUT ACCEPT
[...]
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


C'est normal que cela fonctionne car le client accepte non seulement les connexions établies (qui émanent de lui) mais aussi toutes les autres en entrée vers lui.

Cas non fonctionnel, exemple 1:

laurent1 a écrit :

iptables -t filter -P INPUT DROP
[...]
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


Normal que ça ne marche pas, il n'accepte en entrée que les connexion faisant suite à celles que le client lance. Par définition, il n'est pas responsable des connexion faisant suite à un appel, il ne sait pas qui et comment on va l'appeler, ni sur quel port aléatoire (ça part du serveur par les ports que tu as définis mais ça arrive sur le client sur un port aléatoire).

Il te faudrait, sur les clients, une régle du style:

IPTABLES -A INPUT -p tcp --sport 5687 -j ACCEPT


qui fait que les paquets entrants en provenance du port 5687 sont acceptés.

Dans le cas non fonctionnel N°2 même si tu ouvres par défaut tes ports en entrée, tu les restreints ensuite 3 lignes plus bas.
Or, de mémoire, les régles iptables sont appliquées dans l'ordre.

Dernière modification par sogal (22-11-2014 19:08:58)


1485418338.png Hello IT ! Have you tried turning it off and on again ?

Hors ligne

#8 22-11-2014 20:50:12

raleur
Membre
Inscription : 03-10-2014

Re : Communication Empathy impossible

Avertissement : je ne connais rien à jabber ni empathy. Mais je soupçonne que les flux audio/vidéo sont transmis directement entre les deux clients sans passer par le serveur, comme avec le protocole SIP. Dans ce cas, le client destinataire d'un flux doit écouter sur un port donné et les paquets à destination de ce port doivent être acceptés. Une difficulté est que souvent ce port est ouvert dynamiquement et choisi de manière pseudo-aléatoire, comme les ports des connexions de données FTP. A ma connaissance il n'y a pas de module de suivi de connexion de netfilter pour le protocole XMPP qui permettrait de marquer ces paquets comme RELATED. Parfois il est possible de spécifier un port ou une plage de ports à cet usage dans les paramètres de l'application, ce qui permet de restreindre les ports à autoriser dans le pare-feu.

Ce que je fais dans ces cas-là, c'est ajouter une règle LOG à la fin de chaque chaîne dont la politique par défaut est DROP pour voir les paquets bloqués dans les logs du noyau (/var/log/kern.log).

Question : Que signifient c2s - 5687 et s2s - 5688 ?

sogalpunx a écrit :

Normal que ça ne marche pas, il n'accepte en entrée que les connexion faisant suite à celles que le client lance.


Tu interprètes mal cette règle. Elle n'accepte que les paquets entrants appartenant (ESTABLISHED) ou liés (RELATED) à un connexion existante. Rien à voir avec le fait que le client soit ou non à l'origine de la connexion.
Pour rappel, les règles iptables traitent des paquets, pas des connexions.

sogalpunx a écrit :

te faudrait, sur les clients, une régle (...) qui fait que les paquets entrants en provenance du port 5687 sont acceptés.


Autant tout accepter en entrée alors, puisque c'est l'émetteur du paquet qui définit le port source.

sogalpunx a écrit :

Dans le cas non fonctionnel N°2 même si tu ouvres par défaut tes ports en entrée, tu les restreints ensuite 3 lignes plus bas.
Or, de mémoire, les régles iptables sont appliquées dans l'ordre.


Une règle avec la cible ACCEPT ne restreint rien du tout, au contraire.
Les règles d'une chaîne sont appliquées dans l'ordre mais la politique par défaut (-P) de la chaîne n'est appliquée que si le paquet atteint la fin de la chaîne après avoir traversé toutes les règles sans qu'aucune n'ait décidé de son sort.

Je pense que ça ne marche pas dans le cas n° 2 parce que les paquets sont bloqués à l'émission (et dans le cas n° 1 parce qu'ils sont bloqués à la réception).

Dernière modification par raleur (22-11-2014 20:51:42)


Il vaut mieux montrer que raconter.

Hors ligne

#9 22-11-2014 21:36:58

sogal
Black Metal Modo
Lieu : Nord Isère
Distrib. : openSUSE Leap 42.3
Noyau : Linux 4.4.76
(G)UI : GNOME
Inscription : 09-05-2013
Site Web

Re : Communication Empathy impossible

raleur a écrit :

Elle n'accepte que les paquets entrants appartenant (ESTABLISHED) ou liés (RELATED) à un connexion existante. Rien à voir avec le fait que le client soit ou non à l'origine de la connexion.
Pour rappel, les règles iptables traitent des paquets, pas des connexions.


Certes, mais ce cas, qui crée la connexion pour que les paquets liés à celle-ci puisse être acceptés? c'est bien l'appelant dans son cas, le serveur donc, non?

raleur a écrit :


sogalpunx a écrit :
    te faudrait, sur les clients, une régle (...) qui fait que les paquets entrants en provenance du port 5687 sont acceptés.


Autant tout accepter en entrée alors, puisque c'est l'émetteur du paquet qui définit le port source.


L'émetteur du paquet est ici son serveur et il l'a paramétré pour que le port source soit le 5687 et 5688. Je ne comprends pas pourquoi tu dis qu'il pourrait aussi bien tout accepter?

raleur a écrit :

Je pense que ça ne marche pas dans le cas n° 2 parce que les paquets sont bloqués à l'émission (et dans le cas n° 1 parce qu'ils sont bloqués à la réception).


Effectivement, ça aiderait de savoir si dans ses tests il a modifié le pare-feu sur le serveur.


1485418338.png Hello IT ! Have you tried turning it off and on again ?

Hors ligne

#10 22-11-2014 22:19:39

raleur
Membre
Inscription : 03-10-2014

Re : Communication Empathy impossible

qui crée la connexion pour que les paquets liés à celle-ci puisse être acceptés? c'est bien l'appelant dans son cas, le serveur donc, non?


Si tu parles d'une connexion au sens du suivi de connexion de netfilter ("conntrack"), elle est créée par un paquet initial qui a l'état NEW et n'est pas bloqué. Oui, ce sont les paquets qui créent les connexions au sens de conntrack, pas leurs émetteurs. Les émetteurs envoient les paquets. Pas de paquet, pas de connexion. Paquet initial bloqué, pas de connexion. Pas de connexion, pas de paquet dans l'état ESTABLISHED ou RELATED.

Les règles présentées ici ne sont pas basées sur l'adresse source des paquets, donc peu importe que les paquets soient émis par le serveur ou par une autre machine.

L'émetteur du paquet est ici son serveur et il l'a paramétré pour que le port source soit le 5687 et 5688.


Le serveur utilise ce port source pour envoyer des paquets appartenant à une connexion établie par le client sur ce port. Je ne suis pas du tout convaincu qu'il l'utilise aussi à autre chose.

Je ne comprends pas pourquoi tu dis qu'il pourrait aussi bien tout accepter?


Parce qu'avec ta règle il suffirait à n'importe quelle machine d'envoyer un paquet vers n'importe quel port (=service) et il passerait à travers le pare-feu du moment que le port source est celui qui est accepté. C'est précisément pour éviter ce genre de chose qu'on a créé le suivi de connexion, pour accepter les paquets de réponse sans se baser uniquement sur le port source mais sur le fait qu'on a vu un paquet initial correspondant.

Effectivement, ça aiderait de savoir si dans ses tests il a modifié le pare-feu sur le serveur.


Il a écrit que tout fonctionne avec les règles sur le serveur.

Dernière modification par raleur (22-11-2014 22:21:52)


Il vaut mieux montrer que raconter.

Hors ligne

#11 22-11-2014 23:43:52

sogal
Black Metal Modo
Lieu : Nord Isère
Distrib. : openSUSE Leap 42.3
Noyau : Linux 4.4.76
(G)UI : GNOME
Inscription : 09-05-2013
Site Web

Re : Communication Empathy impossible

Ok, merci pour ces éclaircissements smile

1485418338.png Hello IT ! Have you tried turning it off and on again ?

Hors ligne

#12 23-11-2014 01:19:45

laurent1
Membre
Distrib. : Debian 7.6
Noyau : Linux 3.2.0-0-686-pae
Inscription : 22-11-2014

Re : Communication Empathy impossible

Bonjour,

C'est bien cela, sous le protocol xmpp, le serveur n'est là que pour établir la relation entre les clients, mais la communication audio et video se fait directment entre client et la distribution des ports en local est aléatoire.

Parfois il est possible de spécifier un port ou une plage de ports à cet usage dans les paramètres de l'application, ce qui permet de restreindre les ports à autoriser dans le pare-feu.



Je n'ai pas trouver cette option sous empathy.

Ce que je fais dans ces cas-là, c'est ajouter une règle LOG à la fin de chaque chaîne dont la politique par défaut est DROP pour voir les paquets bloqués dans les logs du noyau (/var/log/kern.log).



Mais comment identifier ceux du flux provenant d'empathy ? Et ensuite mettre un script qui réactualiserai les règles iptables en fonction du port choisit ?


Question : Que signifient c2s - 5687 et s2s - 5688 ?



Le port c2s est celui qui permet la connexion du client au serveur, le s2s quant à lui permet la connexion entre 2 serveur xmpp

Cordialemnt,
Laurent.


Pc sous debian 7.6 => noyau Linux 3.2.0

Serveur debian 7.6 => Linux 3.2.0

Hors ligne

#13 23-11-2014 09:55:36

raleur
Membre
Inscription : 03-10-2014

Re : Communication Empathy impossible

Mais comment identifier ceux du flux provenant d'empathy ? Et ensuite mettre un script qui réactualiserai les règles iptables en fonction du port choisit ?


Pour identifier les flux d'empathy, tu arrêtes toute autre activité réseau sur le poste le temps du test et tu ne regardes que les paquets dont la source est le serveur ou le poste avec lequel tu essaies d'ouvrir une communication.

Dans un premier temps le but est d'observer les paquets bloqués lors des tentatives de communication pour vérifier si les ports audio/vidéo sont vraiment aléatoires, certainement pas d'actualiser les règles iptables. Tu ne peux pas juste dire "j'ai vu que j'ai bloqué un paquet sur ce port, je vais laisser passer les suivants". Autant ne rien bloquer.

PS : dans le wiki d'ubuntu-fr, il est suggéré d'autoriser les ports 5800 et 5900. A vérifier.


Il vaut mieux montrer que raconter.

Hors ligne

#14 25-11-2014 17:04:02

laurent1
Membre
Distrib. : Debian 7.6
Noyau : Linux 3.2.0-0-686-pae
Inscription : 22-11-2014

Re : Communication Empathy impossible

Re,

Voilà ce que me donne netstat -launt après avoir stoppé toute activité réseau sauf la communication audio avec empathy (toutes les règles iptables supprimées), avec la communication audio qui passe sans problème :

Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat      
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:40338           0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN    
tcp        0      0 192.168.0.4:54551      AdresseIpDuServeurEjabbered:5800     ESTABLISHED
tcp6       0      0 :::111                  :::*                    LISTEN    
tcp6       0      0 ::1:631                 :::*                    LISTEN    
tcp6       0      0 ::1:25                  :::*                    LISTEN    
tcp6       0      0 :::59719                :::*                    LISTEN    
udp        0      0 192.168.0.4:57612      0.0.0.0:*                          
udp        0      0 127.0.0.1:786           0.0.0.0:*                          
udp        0      0 192.168.0.4:36149      0.0.0.0:*                          
udp        0      0 239.255.255.250:1900    0.0.0.0:*                          
udp        0      0 192.168.0.4:1900       0.0.0.0:*                          
udp        0      0 239.255.255.250:1900    0.0.0.0:*                          
udp        0      0 127.0.0.1:1900          0.0.0.0:*                          
udp        0      0 0.0.0.0:23916           0.0.0.0:*                          
udp        0      0 0.0.0.0:1900            0.0.0.0:*                          
udp        0      0 192.168.0.4:41350      0.0.0.0:*                          
udp        0      0 0.0.0.0:60411           0.0.0.0:*                          
udp        0      0 127.0.0.1:37939         0.0.0.0:*                          
udp        0      0 0.0.0.0:68              0.0.0.0:*                          
udp        0      0 0.0.0.0:111             0.0.0.0:*                          
udp        0      0 0.0.0.0:60603           0.0.0.0:*                          
udp        0      0 0.0.0.0:5353            0.0.0.0:*                          
udp        0      0 0.0.0.0:754             0.0.0.0:*                          
udp6       0      0 :::39178                :::*                              
udp6       0      0 :::37822                :::*                              
udp6       0      0 :::20559                :::*                              
udp6       0      0 :::111                  :::*                              
udp6       0      0 :::5353                 :::*                              
udp6       0      0 :::754                  :::*                              



Cordialement,
Laurent.


Pc sous debian 7.6 => noyau Linux 3.2.0

Serveur debian 7.6 => Linux 3.2.0

Hors ligne

#15 25-11-2014 22:02:00

raleur
Membre
Inscription : 03-10-2014

Re : Communication Empathy impossible

Sans l'option -p, netstat ne dit pas quel programme utilise tel port. De toute façon il ne dit pas non plus pour quel usage. Cela ne remplace pas une capture de paquets ou les logs d'iptables qui seuls pourront montrer les paquets échangés entre deux postes qui communiquent ensemble.

J'observe que la connexion avec le serveur jabber est sur le port 5800, alors que tu disais avoir configuré le port 5687.

Il vaut mieux montrer que raconter.

Hors ligne

#16 04-01-2015 14:47:53

laurent1
Membre
Distrib. : Debian 7.6
Noyau : Linux 3.2.0-0-686-pae
Inscription : 22-11-2014

Re : Communication Empathy impossible

J'observe que la connexion avec le serveur jabber est sur le port 5800, alors que tu disais avoir configuré le port 5687.



Oui. C'était quand j'avais essayé de remettre la configuration par default pendant les réglages (mais le port est actuellement utilisé est bien 5687).

Mais après un tcpdump, il semble que empathy choisit un port, à ce que j'ai pu remarquer dans la plage 30000 à 65000 (pour les clients), en sortie. Il n'a besoin que de cela pour établir la communication.

Avec une règle :

iptables -t filter -A OUTPUT -p udp -m udp --dport 30000:65$
 



cela fonctionne sans problème.

Est-il possible d'un peu plus sécurisé la règle sachant que le client envoie directement les paquets au second client avec lequel il veut communiquer (qui lui aussi fait de même) ?


Pc sous debian 7.6 => noyau Linux 3.2.0

Serveur debian 7.6 => Linux 3.2.0

Hors ligne

#17 04-01-2015 15:24:27

raleur
Membre
Inscription : 03-10-2014

Re : Communication Empathy impossible

A moins de pouvoir réduire la plage de ports utilisables dans la configuration des clients, j'ai peur que non.

Et le port source, il est varie dans le même intervalle ?

La seule chose éventuellement faisable, c'est de n'autoriser l'utilisation de ces ports que vers les adresses des autres machines clientes si elle sont connues à l'avance et fixes.

Dernière modification par raleur (04-01-2015 15:25:36)


Il vaut mieux montrer que raconter.

Hors ligne

Pied de page des forums