Hello.
J'essaye de configurer un ordinateur en tant que point d'accès Wifi et d'y faire fonctionner un serveur Web.
Si j'arrive à faire fonctionner le point d'accès, à m'y connecter et à obtenir une adresse IP, impossible de joindre le serveur web depuis un ordinateur connecté au point d'accès.
Ce même serveur web est parfaitement joignable si on y accède via l'interface ethernet de l'ordinateur hôte plutôt que par le point d'accès Wifi.
Le serveur web n'a pas de limitation quand au réseau source des requêtes HTTP.
Quand j'essaye de contacter le serveur web avec curl, j'ai une simple erreur :
Connecting to 10.42.0.1:8000… failed: Connection refused.
Du coté de l'ordinateur où fonctionne le serveur web, j'ai regardé les journaux du serveur web ainsi que ceux du système, aucune information sur une tentative de connexion.
Pour la partie point d'accès Wifi, j'utilise NetworkManager et pour le serveur DHCP j'utilise dhcpd. Quand au serveur web, j'ai testé avec Apache ainsi qu'avec le serveur de Python.
Après plusieurs recherches sur le web, je n'ai absolument rien trouvé.
Quelqu'un aurait une idée ?
Merci par avance.
# dhcpd?
Posté par ted (site web personnel) . Évalué à 3. Dernière modification le 30 janvier 2022 à 08:51.
Si je comprends bien, tu configures le point d'accès à travers l'interface graphique de Network Manager. Dans ce cas il se chargera aussi de donner une adresse IP aux clients, pas besoin d'utiliser dhcpd.
Quand tu teste sur ton ordinateur client, est ce que celui-ci a bien une adresse sur 10.42.0.0/24 ? Et le serveur a bien l'adresse 10.42.0.1 sur l'interface wifi? Tu peux pinguer les deux ordinateurs?
Vérifie aussi que tu n'as pas de pare-feu activé sur ton serveur, sinon il faudra ouvrir le port 8000.
Un LUG en Lorraine : https://enunclic-cappel.fr
# règles NAT ?
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 30 janvier 2022 à 09:27.
peut-être un manque au niveau des règles NAT ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: règles NAT ?
Posté par Craig77 . Évalué à 2. Dernière modification le 30 janvier 2022 à 15:30.
Problème de Hairpinning ?
Les routeurs ne savent pas tous gérer malheureusement
[^] # Re: règles NAT ?
Posté par Yuul B. Alwright . Évalué à 1.
Merci pour cette proposition.
Je ne cherchais pas à rendre le serveur web publique.
Juste à le rendre accessible via l'interface Wifi du serveur où il tournait.
# Listen ?
Posté par cg . Évalué à 6. Dernière modification le 30 janvier 2022 à 10:53.
Connection refused
est le message qu'on a quand il n'y a pas de serveur qui écoute sur un couple adresse:port, ou qu'un firewall bloque en répondant (ce qui est rare, on a en général un timeout avec les firewalls).Est-ce que le serveur web écoute sur l'interface wifi ?
Tu peux le vérifier avec
netstat
ouss
, avec l'option-l
(listen) en particulier (perso je trouve netstat plus lisible).Sur mon ordi, on peut voir que seul CUPS écoute en TCP sur l'interface locale (127.0.0.1) :
Dans
ss
, c'est la colonneLocal Address:Port
qui t'intéresse. Dansnetstat
, c'estLocal Address
.Si tu n'as une ligne pour ton serveur web qui écoute sur
0.0.0.0
ou sur10.42.0.1
, le problème vient de sans doute de là.# Solution
Posté par Yuul B. Alwright . Évalué à 2.
Alors, j'ai finalement trouvé où était le problème: L'interface Wifi et Ethernet ne sont pas dans la même zone du par-feu.
Quand j'ai ouvert le port utilisé par le serveur web, je l'ai fait pour la zone par défaut du par-feu.
Comme l'interface Ethernet se trouve dans cette zone, je pouvais joindre le serveur web via cette interface.
Mais l'interface Wifi, qui servait de point d'accès, se trouvait dans la zone nommée "nm-shared".
Donc, pour rendre mon serveur web accessible sur l'interface Wifi, j'ai dut ouvrir le port 8000 pour la zone "nm-shared".
Pour cela, j'ai exécuté ces 2 commandes:
Merci pour les proposition.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.