Forum Linux.général Problème de port filtered sous Ubuntu 8.04

Posté par  .
Étiquettes :
0
7
mai
2008
Salut à tous !
Je viens de me rendre compte d'un truc sous Hardy. Je n'arrive plus à faire marcher une webradio diffusé à l'aide du couple MPD/Icecast.
En fait, en local, tout marche parfaitement, j'arrive à écouter sur http://localhost:8000/mpd.ogg.
Par contre, dés que j'essaye de faire sur un PC distant, http://"mon ip publique":8000/mpd.ogg, ca marche pas.
J'ai donc vérifier l'ouverture des ports sur ma box internet, pas de problème de ce côté là (sous Windows, aucun problème avec les mêmes ports)
Avec firestarter, j'avais explicitement configuré l'ouverture du port 8000. Aucun problème par là non plus.
Ce qui est bizarre, c'est que le port 8000 semble être ouvert, mais seulement pour le réseau local. C'est à dire, lorsque mpd et icecast sont actifs, j'ai ça dans les connexions actives de Firestarter :
cf http://www.hiboox.com/lang-fr/image.php?img=hbdsnp31.jpg

Pour le port 6600 de MPD, il est normal d'avoir 127.0.0.1 vers 127.0.0.1, par contre, je comprends pas pourquoi j'ai ça avec le port 8000...
De plus un autre truc bizarre obtenu avec nmap :
Scan sur localhost (donc 127.0.0.1)
nmap -p8000 localhost
Interesting ports on localhost (127.0.0.1):
PORT STATE SERVICE
8000/tcp open http-alt

Scan sur l'adresse publique :
nmap -p8000 `monip
PORT STATE SERVICE
8000/tcp filtered http-alt
Le port est filtered, même lorsque je désactive le pare-feu à l'aide de Firestarter.

Il doit y avoir une autre couche de blocage à prendre en compte je pense...
Quelqu'un aurait une idée ?

Merci

  • # plus d'infos

    Posté par  . Évalué à 1.

    netstat -an | grep -v unix | grep LISTEN
    devrait te lister les ports ouverts et en "ecoute" (LISTEN) de ta machine

    ca devrait deja te permettre de savoir sur quel adresse le port 8000 est en ecoute.

    cela devrait logiquement (et vu ton besoin) etre au moins
    - soit 0.0.0.0:8000 (soit TOUTES les ips, port 8000)
    - soit 127.0.0.1:8000 (uniquement le localhost port 80000) et IP_LAN:8000 (ton ip locale pour 8000)

    • [^] # Re: plus d'infos

      Posté par  . Évalué à 1.

      J'ai bien la ligne
      tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN

      Merci
      @++

  • # Quelques détails en plus

    Posté par  . Évalué à 1.

    Voici quelques détails en plus
    - La version de MPD est compilée à partir des sources svn. Cela dit, je ne pense pas que le problème vienne de là, étant donné qu'en local, le son marche.

    -Un truc aussi que je me demandais, on peut bien utiliser l'adresse http://`mon_ip_publique`:8000/mpd.ogg même si l'on est sur une machine derrière cette adresse publique ?
    Il me semble que ca marchait avant, mais je voudrais en être sûr...
    Car en fait, lorsque je dis que je teste de l'extérieur, j'entends par là que j'utilise explicitement l'adresse IP publique dans l'adresse du flux à lire...

    • [^] # Re: Quelques détails en plus

      Posté par  . Évalué à 2.

      donne nous ton adr publique, on testera pour toi... };)

      • [^] # Re: Quelques détails en plus

        Posté par  . Évalué à 1.

        Le problème, c'est que je diffuse pas 24/24...donc ca va pas être facile.
        J'essayerai de tenter depuis une autre machine quand je pourrai ;)

    • [^] # Re: Quelques détails en plus

      Posté par  . Évalué à 1.

      Bon apparemment, on ne peut pas accéder de l'intérieur du réseau à l'adresse IP publique...
      D'après ce post sur les forums d'ubuntu http://ubuntuforums.org/showthread.php?t=772125&highligh(...)


      Are you trying to can your public address from inside a router? That cannot be done - the router won't NAT a connection that comes from the inside to the inside. You'll have to ue an external service like grc shields-up to scan your public address.


      ET effectivement, lorsque j'essaye sur GRC, le port 8000 est bien ouvert...
      Reste à tester sur une machine distante

  • # Autre chose

    Posté par  . Évalué à 1.

    Une autre curiosité aussi. Lorsque je fais
    lsof -i:8000
    Voilà le résultat :

    COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
    icecast2 32535 icecast2 0u IPv4 275940 TCP localhost:8000->localhost:43293 (ESTABLISHED)
    icecast2 32535 icecast2 4u IPv4 275787 TCP *:8000 (LISTEN)
    mpd 32575 mpd 7u IPv4 275939 TCP localhost:43293->localhost:8000 (ESTABLISHED)


    Le 43293 est juste un port aléatoire qui change (après redémarrage de icecast et de mpd).
    On se rend compte quand même là qu'il y a un bouclage pas trop normal, non ? localhost:8000 > localhost:43293> localhost:8000

    Bizarre...

  • # Pareil

    Posté par  . Évalué à 1.

    Bon bah j'ai testé de l'extérieur c'est pareil !
    Mais le problème vient surement de Icecast qui n'arrive pas à ouvrir correctement le port 8000 qui reste filtered vu de l'extérieur.
    Alors que si j'utilise deluge par exemple avec le port 8000, là ca marche...Et le test d'ouverture du port fonctionne aussi là

    • [^] # Re: Pareil

      Posté par  . Évalué à 1.

      Nan, en fait j'ai dit une bêtise, dans tous les cas le port est filtered d'après nmap sur l'adresse publique....
      Rien à faire

    • [^] # Re: Pareil

      Posté par  . Évalué à 1.

      Bon il se passe des trucs vraiment bizarre mais je crois que j'arrive à cibler un peu plus le problème :
      J'ai testé avec Waste le port 1337 en tant que serveur, et là aucun problème la connexion s'établit bien de l'extérieur.
      Donc le problème vient uniquement de l'attribution du port 8000.

      En se connectant depuis un autre ordinateur, je me suis rendu compte qu'est apparu furtivement dans les connexions actives de firestarter, la bonne entrée, c'est à dire source : ip distante, destination : ip privée locale, port : 8000. Mais la connexion durait pas...pourtant dans les règles de firestarter, 8000 est bien autorisé pour tout le monde.
      Mais en fait, c'est là que je me rend compte que la ligne contenant 127.0.0.1:
      http://www.hiboox.com/lang-fr/image.php?img=hbdsnp31.jpg
      est active en permanence, dés l'activation de Icecast. Le fait qu'elle soit présente lorsqu'une autre connexion, de l'extérieur elle, se fait doit poser problème, d'où la faible durée de vie...

      • [^] # Re: Pareil

        Posté par  . Évalué à 1.

        En fait, le problème vient d'Icecast je pense finalement. Etant donné que le port 1337 lorsqu'il est ouvert avec Waste, possède exactement les mêmes caractéristiques que le port 8000 (même retour dans nmap, même règles iptables, etc...).
        Donc Icecast doit se planter quelque part dans la gestion du réseau.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.