Forum Linux.général hostapd et iptables.

Posté par  . Licence CC By‑SA.
0
19
mar.
2014

Bonjour,

je cherche à offrir un accès wifi à des terminaux qui n'ont que ça comme moyen de connexion dans un environnement où il n'y a pas de Wifi.

J'ai trouvé un dongle USB wifi qui fonctionne bien avec hostapd, et j'ai pour l'instant un système presque fonctionnel avec un bridge.

Les terminaux wifi obtiennent leur IP du même routeur que le mien, voient donc le proxy, et peuvent utiliser http. Ils voient également mon poste "access point" sur lequel ils peuvent se connecter en SSH.

Ce qu'il me manque, c'est la connexion dans l'autre sens. J'aimerais au minimum pouvoir accéder depuis mon "access point" aux terminaux (en ssh), voire même depuis n'importe quel autre poste vers les terminaux wifi.
J'ai bien ajouté une route pour chaque terminal wifi, mais il n'y a que le ping qui passe (même pas le traceroute).

Est-ce seulement possible?

Si c'est le cas, je détaillerai ma configuration.

Merci par avance, et désolé si ma question est vraiment idiote.

  • # bridge ou nat ?

    Posté par  . Évalué à 4.

    si tu as vraiment fait un bridge, il n'y a pas de filtre entre les machines locales et les machines wifi
    elles sont sur le meme reseau (meme plan d'adressage)

    il n'y a donc pas de routage à faire, et si le ping passe, le reste devrait aussi.

    ce qu'il peut arriver c'est qu'il y ait du 'client isolation' qui empeche les clients wifi de se connecter entre eux.
    à voir si y a une option pour desactiver ca dans hostapd

    • [^] # Re: bridge ou nat ?

      Posté par  . Évalué à 3.

      Si tu n'a pas ajouté d'option ap_isolate, hostapd n'isole pas les clients.

  • # Poste ta configuration.

    Posté par  . Évalué à 4.

    Poste ta configuration, parce que normalement, ça devrai déjà marcher. Si tu fait un bridge (niveau 2, donc avec une option bridge= dans hostapd, et ton interface filaire dans le même bridge), alors n'importe quel autre poste devrai pouvoir contacter tes clients. Si ce n'est pas le cas, c'est sans doute un problème de routage chez les clients/postes, mais à priori, si les terminaux obtiennent leur IP depuis le même routeur que les autres, ils devraient avoir le même préfixe.

    Après, il reste le point d'accès. Un bridge n'a normalement pas besoin d'une adresse IP ou de tables de routage ou de règles iptables (qui seront de toute façon ignorées, pour un bridge, faut utiliser ebtables).

    Si tu veux quand même que ton AP ai une IP et puisse communiquer avec les terminaux, il faut qu'il fasse du DHCP sur le bridge (et pas sur les interfaces qui font partie du bridge). Il devrai alors pouvoir communiquer avec toutes les machines du réseau, terminaux comme les autres postes.

    Une des erreurs que j'ai déjà fait quand je mettait en place un bridge, c'est d'avoir des adresses IP et/ou des règles de routage sur des interfaces qui font partie du bridge, plutôt que sur le bridge lui-même.

  • # Çà fonctionne presque

    Posté par  . Évalué à 1.

    Bonsoir et merci à tous.

    J'ai un peu avancé, j'arrive à contacter depuis ma machine "point d'accès" un des terminaux connecté dessus.
    Le bridge br0 obtient bien son IP (en 10.x.x.x) depuis le même routeur, l'eth0 n'a pas d'IP.
    Le dongle usb wifi est par contre en IP fixe 192.168.50.1.

    J'essayerai demain de contacter le terminal wifi depuis un autre poste en 10.x.x.x.

    Merci encore.

    • [^] # Re: Çà fonctionne presque

      Posté par  . Évalué à 3.

      Vire l'adresse IP fixe sur le dongle wifi: Elle ne sert strictement à rien, surtout si les autres machines n'ont pas de route pour cette adresse.

    • [^] # Re: Çà fonctionne presque

      Posté par  . Évalué à 3.

      c'est peut-etre ca qui fout la merde.

      ton dongle wifi ne devrait pas avoir d'adresse IP,
      par contre il doit etre inseré dans le bridge

  • # IP dongle enlevée

    Posté par  . Évalué à 1.

    Bonjour,
    un ping depuis une autre machine du réseau ne fonctionne pas vers les terminaux wifi (Impossible de joindre l'hôte de destination).

    J'ai bien enlevé l'IP pour le dongle. J'ai maintenant:

    br0       Link encap:Ethernet  HWaddr 00:0f:0f:0f:0f:0f  
              inet adr:10.xx.xx.xx  Bcast:10.xx.xx.xx  Masque:255.255.248.0
              adr inet6: fe0f::0f0f:0f0f:0f0f:0f0f/64 Scope:Lien
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              Packets reçus:27180 erreurs:0 :0 overruns:0 frame:0
              TX packets:2998 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 lg file transmission:0 
              Octets reçus:6304581 (6.3 MB) Octets transmis:397674 (397.6 KB)
    
    eth0      Link encap:Ethernet  HWaddr 0e:0e:0e:0e:0e:0e  
              adr inet6: 0e0e::0e0e:0e0e:0e0e:0e0e/64 Scope:Lien
              UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
              Packets reçus:203030 erreurs:0 :58 overruns:0 frame:0
              TX packets:63446 errors:136 dropped:0 overruns:0 carrier:136
              collisions:1519 lg file transmission:1000 
              Octets reçus:142794982 (142.7 MB) Octets transmis:7906675 (7.9 MB)
              Interruption:20 Mémoire:d4800000-d4820000 
    
    lo        Link encap:Boucle locale  
              inet adr:127.0.0.1  Masque:255.0.0.0
              adr inet6: ::1/128 Scope:Hôte
              UP LOOPBACK RUNNING  MTU:65536  Metric:1
              Packets reçus:6423 erreurs:0 :0 overruns:0 frame:0
              TX packets:6423 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 lg file transmission:0 
              Octets reçus:978300 (978.3 KB) Octets transmis:978300 (978.3 KB)
    
    mon.wlan1 Link encap:UNSPEC  HWaddr 00-0F-0F-0F-0F-0F-0F-0F-00-00-00-00-00-00-00-00  
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              Packets reçus:7012 erreurs:0 :0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 lg file transmission:1000 
              Octets reçus:1359700 (1.3 MB) Octets transmis:0 (0.0 B)
    
    wlan1     Link encap:Ethernet  HWaddr 00:0f:0f:0f:0f:0f  
              adr inet6: 0f0f::0f0f:0f0f:0f0f:0f0f/64 Scope:Lien
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              Packets reçus:817 erreurs:0 :0 overruns:0 frame:0
              TX packets:22774 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 lg file transmission:1000 
              Octets reçus:58344 (58.3 KB) Octets transmis:3505251 (3.5 MB)
    
    • [^] # Re: IP dongle enlevée

      Posté par  . Évalué à 4.

      Sous linux, ifconfig (tout comme route, netstat, vlanconfig, ect …) est complètement déprécié, depuis le noyau 2.4 au moins. Utilise ip à la place. Pour voir tes ip et tes interfaces, utilise ip a (abréviation de ip address) La sortie est plus courte et donne plus d'informations utiles (rien à faire de l'irq de ta carte réseau filaire). Pour ta table de routage, utilise ip r (abréviation de ip route).

      (et j'en déduit à la présence de mon.wlan1 que ta version d'hostapd et/ou de ton noyau est peut-être un poil ancienne)

  • # ip -a, versions, etc...

    Posté par  . Évalué à 1. Dernière modification le 21 mars 2014 à 17:40.

    Désolé, je suis un vrai dinosaure de l'informatique, j'en étais resté au ifconfig.

    Ma version d'hostapd est hostapd 1:1.0-3ubuntu2.1.
    Mon noyau est un 3.11.0-19-generic d'Ubuntu.
    ip -a me donne:

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
        link/ether [...] brd [...]
        inet6 [...]/64 scope link 
           valid_lft forever preferred_lft forever
    3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN qlen 1000
        link/ether [...] brd [...]
    4: br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
        link/ether [...] brd [...]
        inet 10.xx.xx.xx/21 brd 10.xx.xx.255 scope global br0
           valid_lft forever preferred_lft forever
        inet6 [...]/64 scope link 
           valid_lft forever preferred_lft forever
    5: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP qlen 1000
        link/ether [...] brd [...]
        inet6 [...]/64 scope link 
           valid_lft forever preferred_lft forever
    6: mon.wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN qlen 1000
        link/ieee802.11/radiotap [...] brd [...]
    

    ip r me donne:

    default via 10.xx.xx.1 dev br0 
    10.xx.xx.0/21 dev br0  proto kernel  scope link  src 10.xx.xx.xx 
    

    Je vais compiler une version plus récente d'hostapd.

    J'arrive toujours à contacter les autres postes ethernet depuis le terminal Wifi (ssh), mais dans l'autre sens, ça reste bouché.

    Y aurait-il une restriction à enlever dans iptables? Ou alors ma carte Ethernet ne râle pas mais ne passe pas pour autant en promiscuous? J'imagine (mal?) que dans ce cas, le bridge ne serait fonctionnel dans aucun sens?

    Il faudrait peut-être que je trace les paquets à destination du terminal Wifi, pour voir s'ils passent vraiment sur eth0?

    Merci.

    • [^] # Re: ip -a, versions, etc...

      Posté par  . Évalué à 1.

      Autre mise à jour.

      Depuis un poste relié par ethernet, un ping vers le terminal wifi répond en timeout.

      Si j'arrête ufw sur l'access point, j'obtiens un "host is down". Il y aura sans doute de la configuration de ce côté là.

      • [^] # Re: ip -a, versions, etc...

        Posté par  . Évalué à 3.

        iptables n'intervient pas dans les bridges. Il intervient uniquement pour les communications IP entre l'AP et le reste du monde.

        ufw bloque peut-être des choses avec arptables et/ou ebtables, mais sinon rien ne devrai changer.

        Par contre, ce que je trouve troublant, c'est que les terminaux puisse faire du SSH vers un autre hôte du réseau: ça veut dire qu'ils ont une communication bi-directionelle avec cette machine, pourtant elle ne peut pas les contacter. Il n'y aurai pas un firewall planqué dans le switch/routeur ou un firewall logiciel sur les terminaux ?

        • [^] # Re: ip -a, versions, etc...

          Posté par  . Évalué à 1.

          Pour le firewall logiciel, j'en doute. Je fais mes tests avec un terminal Android.
          Mon AP est une Ubuntu 13.10.

          Merci.

  • # une copie des fichiers de configuration des cartes reseaux ?

    Posté par  . Évalué à 3.

    tu as quoi dans tes fichiers de configuration des interfaces reseaux ?
    sous debian like c'est /etc/network/interfaces

  • # /etc/network/interfaces

    Posté par  . Évalué à 1.

    /etc/network/interfaces contient:

    auto lo br0
            iface lo inet loopback
    
            auto wlan0 
            # wireless wlan1
            allow-hotplug wlan1
            iface wlan1 inet manual
    
            # Setup bridge
            iface br0 inet static
                bridge_ports wlan1 eth1
                address 192.168.1.11
                netmask 255.255.255.0
                network 192.168.1.0
                gateway 192.168.1.2
                dns-nameservers 192.168.1.2
    

    Il doit y avoir des erreurs, car le réseau est en 10.x.x.x.
    Merci.

    • [^] # Re: /etc/network/interfaces

      Posté par  . Évalué à 3.

      2 cartes wifi wlan0 et wlan1 ?

      et 2 cartes reseaux filaires (vu que tu veux faire le bridge sur eth1) ?

      et aussi pourquoi y a une IP posée sur le bridge, qui est censé masquer les cartes reseaux et faire passer les choses de maniere presque transparente entre les 2 cartes

      • [^] # Re: /etc/network/interfaces

        Posté par  . Évalué à 1.

        Deux "cartes" Wifi, oui. wlan0, je n'en ai pas besoin, elle ne gère pas le mode AP, et wlan1, dongle Wifi.

        Une seule carte réseau filaire. La config dans /etc/network/interfaces vient de je ne sais quoi.

        J'ai bien essayé de nettoyer tout ça, mais plus rien ne fonctionne depuis (je sais, ça devait arriver avec mon niveau de compréhension).

        • [^] # Re: /etc/network/interfaces

          Posté par  . Évalué à 3.

          donc il te faut reprendre l'abcédaire, et comprendre ce que tu copies/colles.

          au mieux tu vas avoir 3 cartes
          2 wifi (wlan0, wlan1) et 1 filaire (eth0)

          desactive la wlan0 pour ne pas pas qu'elle vienne mettre le bordel dans les communications reseaux.

          ensuite monte ton bridge entre wlan1 (le dongle wifi qui gere hostapd) et eth0

          • [^] # Re: /etc/network/interfaces

            Posté par  . Évalué à 1.

            Absolument, les tâtonnements ne me mènent pas bien loin.

            Je m'y (copie) colle.

            • [^] # Re: /etc/network/interfaces

              Posté par  . Évalué à 1.

              Ah, et au cas où ça jouerait un rôle, je suis (pour l'instant) sur une Ubuntu 13.10 desktop, et pas serveur. :-(
              Il y a peut-être des interactions entre le network manager et le /etc/network/interfaces ?

              • [^] # Re: /etc/network/interfaces

                Posté par  . Évalué à 3.

                à ce moment là, pourquoi ne pas simplement activer le partage de connexion à partir du network-manager ?

                • [^] # Re: /etc/network/interfaces

                  Posté par  . Évalué à 1.

                  En fait, je "prépare" le terrain pour basculer sur une machine en Ubuntu serveur… avec mon Ubuntu desktop.

                  • [^] # Re: /etc/network/interfaces

                    Posté par  . Évalué à 2.

                    à ce moment là, travaille avec des machines virtuelles.

                    une machine avec une carte sur ton vrai reseau, et une deuxieme carte sur le reseau interne aux VMs (et avec lesquelles tu feras ton fameux bridge)

                    une 2e machine qui se connectera à la premiere et devra obtenir une IP de ton vrai reseau, de maniere transparente.

Suivre le flux des commentaires

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