Je viens d'installer un serveur sous Sarge et des clients Windows derrière. J'ai également installé firestarter dessus et j'ai ouvert les ports 137,138,139 et 445 pour Samba. Je pensais que la diffusion du nom Netbios dépendait de ces ports mais apparemment tant que le firewall est actif et malgré ces ports ouverts, mes postes Windows ne résolvent pas le nom de mon serveur (bien que je ne vois aucune connexion bloquée dans firestarter). En revanche, si je désactive le firewall, un ping sur le nom Netbios du serveur fonctionne immédiatement.
Quelqu'un a une idée ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut,
[Remarque : encoder en base64 ne me semble pas une bonne idée]
Julien a écrit :
Je viens d'installer un serveur sous Sarge et des clients Windows derrière. J'ai également installé firestarter dessus et j'ai ouvert les ports 137,138,139 et 445 pour Samba.
En TCP et/ou UDP ? Normalement c'est UDP 137 et 138, TCP 139 et TCP et UDP 445. Tu pourrais fournir le jeu de règles iptables généré (avec iptables-save), éventuellement sur une page web s'il est trop gros pour ne pas encombrer la liste ?
Je pensais que la diffusion du nom Netbios dépendait de ces ports
Oui, au moins d'un d'entre eux. UDP 137 il me semble (netbios-name).
mais apparemment tant que le firewall est actif et malgré ces ports ouverts, mes postes Windows ne résolvent pas le nom de mon serveur (bien que je ne vois aucune connexion bloquée dans firestarter). En revanche, si je désactive le firewall, un ping sur le nom Netbios du serveur fonctionne immédiatement.
Tu peux lancer une capture de trafic avec tcpdump ou ethereal pendant que tu fais un ping sur le nom Netbios du serveur pour voir quel sont les ports impliqués, avec et sans firewall puis comparer pour voir ce qui manque dans le premier cas.
Piste possible : il me semble que les requêtes de résolution de nom Netbios utilisent des broadcasts UDP. Or par construction le suivi d'état de connexion de Nefilter/iptables (ip_conntrack) ne reconnaît pas les paquets unicast émis en réponse à une requête émise en broadcast comme ESTABLISHED car l'adresse source nécessairement unicast des réponses est différente de l'adresse destination broadcast de la requête. Donc si les règles de filtrage en sortie du serveur sont trop strictes, la réponse est bloquée.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut,
[Remarque : encoder en base64 ne me semble pas une bonne idée]
Julien a écrit :
Je viens d'installer un serveur sous Sarge et des clients Windows
derrière. J'ai également installé firestarter dessus et j'ai ouvert
les ports 137,138,139 et 445 pour Samba.
En TCP et/ou UDP ? Normalement c'est UDP 137 et 138, TCP 139 et TCP et
UDP 445.
Tu pourrais fournir le jeu de règles iptables généré (avec
iptables-save), éventuellement sur une page web s'il est trop gros pour
ne pas encombrer la liste ?
Je pensais que la diffusion du nom Netbios dépendait de ces ports
Oui, au moins d'un d'entre eux. UDP 137 il me semble (netbios-name).
mais apparemment tant que le firewall est actif et malgré ces ports
ouverts, mes postes Windows ne résolvent pas le nom de mon serveur
(bien que je ne vois aucune connexion bloquée dans firestarter).
En revanche, si je désactive le firewall, un ping sur le nom Netbios
du serveur fonctionne immédiatement.
Tu peux lancer une capture de trafic avec tcpdump ou ethereal pendant
que tu fais un ping sur le nom Netbios du serveur pour voir quel sont
les ports impliqués, avec et sans firewall puis comparer pour voir ce
qui manque dans le premier cas.
Piste possible : il me semble que les requêtes de résolution de nom
Netbios utilisent des broadcasts UDP. Or par construction le suivi
d'état de connexion de Nefilter/iptables (ip_conntrack) ne reconnaît pas
les paquets unicast émis en réponse à une requête émise en broadcast
comme ESTABLISHED car l'adresse source nécessairement unicast des
réponses est différente de l'adresse destination broadcast de la
requête. Donc si les règles de filtrage en sortie du serveur sont trop
strictes, la réponse est bloquée.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
[Remarque : encoder en base64 ne me semble pas une bonne idée]
Julien a écrit :
Je viens d'installer un serveur sous Sarge et des clients Windows derrière. J'ai également installé firestarter dessus et j'ai ouvert les ports 137,138,139 et 445 pour Samba.
En TCP et/ou UDP ? Normalement c'est UDP 137 et 138, TCP 139 et TCP et UDP 445. Tu pourrais fournir le jeu de règles iptables généré (avec iptables-save), éventuellement sur une page web s'il est trop gros pour ne pas encombrer la liste ?
Je pensais que la diffusion du nom Netbios dépendait de ces ports
Oui, au moins d'un d'entre eux. UDP 137 il me semble (netbios-name).
mais apparemment tant que le firewall est actif et malgré ces ports ouverts, mes postes Windows ne résolvent pas le nom de mon serveur (bien que je ne vois aucune connexion bloquée dans firestarter). En revanche, si je désactive le firewall, un ping sur le nom Netbios du serveur fonctionne immédiatement.
Tu peux lancer une capture de trafic avec tcpdump ou ethereal pendant que tu fais un ping sur le nom Netbios du serveur pour voir quel sont les ports impliqués, avec et sans firewall puis comparer pour voir ce qui manque dans le premier cas.
Piste possible : il me semble que les requêtes de résolution de nom Netbios utilisent des broadcasts UDP. Or par construction le suivi d'état de connexion de Nefilter/iptables (ip_conntrack) ne reconnaît pas les paquets unicast émis en réponse à une requête émise en broadcast comme ESTABLISHED car l'adresse source nécessairement unicast des réponses est différente de l'adresse destination broadcast de la requête. Donc si les règles de filtrage en sortie du serveur sont trop strictes, la réponse est bloquée.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
