Wget sur wifi ad-hoc (via NetworkManager)

Support Debian
#1

Bonjour, lorsque j’utilise wget entre deux debian11 connectées en wifi adhoc via NetworkManager, wget donne « Connexion refusée », alors que ping est ok .

Or je n’ai pas ce problème lorsque le réseau ad-hoc est créé via la méthode manuelle proposée par https://wiki.debian.org/fr/WiFi/AdHoc#M.2BAOk-thode_manuelle, plutôt que via NetworkManager…

Pourquoi la connexion à la machine distante est-elle refusée si la connexion préalable au réseau p2p est faite via NetworkManager ?

C’est probablement quelque chose dans https://manpages.debian.org/testing/network-manager/NetworkManager.conf.5.en.html, mais si c’est le cas, je n’arrive pas à identifier quoi.

PS :

  • adresses IP : 10.42.0.1 et 10.42.0.2
  • firewalld configuré en zone=trusted (All network connections are accepted).
#2

quel est ton DNS? son IP.

#3

Ce réseau ad-hoc constitué des deux machines n’est pas connecté à Internet. Il s’agit d’un mini réseau p2p, donc sans serveur dédié. Par conséquent, la fonction DNS doit être distribuée/copiée sur les deux noeuds. En l’occurrence c’est le fichier /etc/hosts qui assume la résolution des noms.

#4

« Connexion refusée », ça peut vouloir dire que le port n’est pas ouvert en écoute sur l’adresse cible, ou qu’une règle de filtrage rejette la connexion.

Il faudrait comparer dans les deux cas

  • l’adresse IP résolue par ping et wget à partir du nom d’hôte
  • les ports TCP en écoute avec « netstat -ntlp » ou « ss -ntlp » sur le serveur
  • la configuration IP des deux machines avec « ip addr » et « ip route »
  • les règles de filtrage sur le serveur avec « iptables-save » si firewalld (que je ne connais pas) utilise iptables ou « nft list ruleset » s’il utilise nftables.
#5

Tout cela est ok, comme on peut le déduire de la description du problème.

#6

salut
peut-être peux-tu nous fournir le résultat (sur client et serveur ) et les informations proposées par PascalHambourg
car si tous est ok, alors ça marche :slight_smile:

#8

Merci à vous, PascalHambourg et dindoun. Grâce à vos conseils, j’ai trouvé la cause du problème.

En lisant le résultat de « nft list ruleset » j’ai vu que NetworkManager considérait que la connexion en wifi ad-hoc n’était pas dans la zone par défaut de firewalld (« trusted ») mais dans la zone « nm-shared », dont le descriptif est :

« This zone is used internally by NetworkManager when activating a profile that uses connection sharing and doesn’t have an explicit firewall zone set. Block all traffic to the local machine except ICMP, ICMPv6, DHCP and DNS. Allow all forwarded traffic ».

C’est donc le passage suivant qui est la cause du blocage : « and doesn’t have an EXPLICIT firewall zone set ».

Il suffit donc, dans NetworkManager de la machine hébergeant le site web, de configurer la connexion wifi ad-hoc en zone « trusted » de façon explicite plutôt que par défaut (la zone par défaut de firewalld pouvant alors être laissée sur « drop », zone de protection « maximale »).

#9

et syurtout assure toi que la regle est sur une IP particvulière, car sinon toute machine qui arriuverait à négocier une connection AdHoc se connecterait librement à ta machine, utilisant de fait une faille de la configuration de sécurité

#10

Merci Zargos. Le but est que le site web de chaque machine de ce réseau p2p en wifi ad-hoc soit librement accessible (en lecture seulement) par n’importe quel noeud de ce réseau … tout en bloquant l’accès à tout le reste de la machine. Il faudrait donc une DMZ au sein de chaque machine.

J’expérimente. Conseils bienvenus.

#11

@youpitagada , tu es en wifi, donc toute personne à portée d’émission est susceptible de se connecter
Et un site web ça se pirate (suivant le niveau de qualité de développement sécurité du site) :slight_smile:

#12

Oui, l’objectif est de voir comment on peut gérer cela au mieux dans un tel réseau distribué (c-à-d sans serveur dédié), et d’évaluer les risques encourus.

#13

Je ne vois pas le rapport entre le type de réseau et l’absence ou la présence de serveur dédié.

#14

En l’occurrence, ton exemple est justement le contraire d’un réseau distribué.
Quand à la notion de serveur dédié, elle est indépendante de la notion de type de réseau.
le tout sans corrélation de celle de sécurité, avec un trou béant, car le wifi adhoc, coté sécurité c’est plutôt le fond du panier.

#15

Je cherche à tester la faisabilité (notamment en terme de sécurité) d’un réseau wifi décentralisé (composé de deux ou trois machines), dont les fonctions serveur ne sont pas concentrées dans des serveurs dédiés, mais distribuées entre les noeuds de ce réseau p2p. Ainsi les applications de type client-serveur sont installées et configurées symétriquement sur les noeuds. Donc en résumé, mon objectif premier est double : wifi et décentralisé.

#16

Euh… désolé mais ça ne veut rien dire.
un réseau wifi decentralisé, c’est creux, ça ne signifie rien, car par essence, le réseau wifi est centralisé: un routeur, des clients;
des applications qui ne sont pas dans un seul serveurs, ce sont des applications n-tiers (c’est vieux de plus de 20 ans comme terminologie); le plus souvent, un frontal, un serveur d’application, un serveur de base de données; avec souvent un frontal qui sert pour plusieurs applications, une base de données mutualisée. le cas échéant pour le nombre de connections, plusieurs serveurs pour faire de la répartition de charge, aujourd’hui avec l’aide de reverse-proxy.
un réseau wifi ad hoc n’a que peu de chance d’etre correctement sécurisé, la fonctionnalité n’ayant pas vraiment fait l’objet d’une véritable recherche sur le sujet. D’autant plus que son utilisation est faible, et souvent purement ponctuelle.
Et le plus souvent une carte wifi d’un pc, ou d’un smartphone, ne peut recevoir qu’une seule connexion. Donc la notion de noeud ici ne veut là non plus rien dire, ou alors juste pour dire qu’il n’y en a qu’un.
enfin, le p2p est très loin d’être un protocole particulièrement bien sécurisé.

#17

Sans doute que @youpitagada voulait parler de réseau mesh.

Pour un projet comme ça je monterai un réseau mesh et partagerai sur celui-ci des applications dans un cluster Kubernetes avec une scalabilité horizontale assurée par le software et verticale par le hardware.

Utiliser un fichier host pour gérer la partie DNS oO Je ferais pas ça nsd/unbound peuvent fonctionner en master/slave autoritaire/cache-recursif.

#18

Oui, c’est tout cela que je voudrais tester, dans un réseau élémentaire composé de deux ou trois machines (toutes Linux Debian). J’essaie, par expérimentations, de répondre à la question : si un nombre indéterminé de personnes, ne disposant que de leur ordinateur personnel (avec une carte wifi), voulaient composer un réseau wifi décentralisé et indépendant d’Internet, pourraient-elles le faire, et quelles seraient les limitations en terme de sécurité, accessibilité, coordination, etc.

Pour cette expérimentation j’applique également le principe de simplicité :

  • réseau élémentaire : le plus petit réseau p2p (en nombre de noeuds) au moyen duquel on peut représenter un réseau p2p de taille quelconque;
  • commencer par expérimenter avec les méthodes les plus élémentaires (donc je commence avec ad-hoc, /etc/hosts, …);
  • approche progressive, documentée dans un manuel à destination de Mr et Mme Toulemonde (il s’agit, par la même occasion, de donner aux citoyens un moyen de se sortir de l’analphabétisme numérique par la pratique).

https://fr.wikipedia.org/wiki/Topologie_mesh

#19

Tu ne fais pas du mesh avec du ad hoc sur les pc commerciaux. Il faut des cartes wifi particulières, qui ne sont quasiment jamais implémentées sur des pc lambda. Qui plus est le maillage deviendrait vite ingérable avec le nombre croissant de machines :
Nb machines Nb interco
2 2
3 3
4 6
5 9
Etc…

la réponse est non au delà de deux personnes et le niveau de coordination, sécurité, etc… serait celui du plus faible, donc par définition à risque.

pour M et Mme tout le monde, c’est une usine à gaz qu’ils n’arriveraient pas à maintenir, voire même pas à mettre en place. Par ailleurs du fait de la distance geographique limité, autant utiliser des clefs USB sécurisées pour échanger les données.

#20

Le but de l’expérimentation est précisément de voir comment on pourrait distribuer le routage sur l’ensemble des noeuds wifi, de sorte que leur rayon d’accès limité serait compensé par une propagation de proche en proche.

#21

donc autant transformer les PC en routeurs, puis utiliser les protocoles de type OSPF ou celui de la norme mesh mais qui n’est toujours pas vraiment opérationnelle.