Ça ne fonctionnerait pas, toujours pour les mêmes raisons; les arbres et la forêt.

Du nouveau tout frais de quelques minutes.
Mon frère, dans un premier temps, a été agréablement surpris de voir des techniciens intervenir sur des câbles cuivre en bordure de route pas très loin de chez lui. Il a demandé aux gars si ils intervenaient pour lui, et leur réponse a été négative et très instructive.
Ils sont les seuls intervenants du secteur  et si une demande de réparation pour sa ligne avait été faite par orange, ils seraient au courant. Ils ont quand même appelé leur donneur d'ordre pour savoir si un rendez-vous était programmé, et encore une fois, réponse négative. Les gars sympas ont quand même essayé de savoir pourquoi la ligne était en panne et ils se sont aperçu qu'une grande partie du câble avait été arrachée et n’existait plus, avait été volée par des "gens du voyage" farceurs (pour être politiquement correcte), habitués qu'ils sont à ce genre de dégradations dans la région. Conclusion: vus les dégâts, la ligne ne sera jamais rétablie car comme nous le craignions, il n'y a pas de fourreau et jamais des travaux ne seront mis en œuvre pour tirer un nouveau câble ni même une fibre optique. Orange s'est encore moqué de mon frangin, en lui promettant encore une fois, que sa ligne serait rétablie le 2 septembre, personne n'étant venu constater les dégâts. Aucun rendez-vous n'étant même programmé, ni même une demande formulées par orange pour l'intervention d'une équipe.
Pour M Léon, ceci n'est pas une affabulation de ma part, mais une triste réalité.
Pour moi, l'aventure s'arrête la, car mon frère est obligé d'en passer par starlink, car comme dit plus haut, pour lui, la communication est vitale.
Merci pour votre aide.

 

Bonjour, récemment j’ai connecté une canonne MB 21 50 sur le réseau wi-fi avec Livebox S tout fonctionnait à merveille. Et puis récemment j’ai installé un MacBook Air M2 je lui ai mis l’imprimante avec le protocole bonjour très rapidement, j’ai imprimé tout était parfait. Donc ça c’est la dernière manip qu’il y a eu sur le réseau, ensuite des amis sont venus visiter trois ou quatre personnes ont dû se connecter sur le réseau. Ensuite la la l’imprimante a indiqué qu’elle n’avait plus le wi-fi dans les équipements connectés de la Livebox S. Pareil, aucune imprimante listé elle est devenue inconnu non listé pas disponible retirer de la liste. Pouvez-vous indiquer ce qu’il s’est passé exactement pour qu’elle imprimante n’apparaissent plus dans le réseau alors qu’elle fonctionnait parfaitement ? Je n’ai jamais eu ce type de problème.

IPv6 devrait être activé. Sinon, cela posera des problèmes un jour ou l'autre.

Merci de l'intérêt que tu prêtes à cette problématique.

Je ne l'ai pas précisé, mais oui et non... Par défaut, les clients GUI ou TUI (l'officiel et alternatifs) ne retourne qu'un seul port, car c'est l'usage le plus courant (et bien plus simple à implémenter j'imagine). Ma théorie est que lorsque le client graphique est sollicité, soit typiquement sur un environnement de travail final et non sur un serveur, il n'y a généralement pas toute une batterie de services ouverts sur l'extérieur qui y tournent. Ca se limite bien souvent à un client BitTorrent, et c'est d'ailleurs l'objet de presque toutes les documentations et discussions sur le port forwarding que l'on peut trouver. Dans mon cas, c'est bien plus que ça. Et côté serveur, ça a intéressé pas mal d'utilisateurs (moi aussi parallèlement) de Gluetun : https://github.com/passteque/gluetun/issues/2381

En réalité, même si je n'ai pas trouvé d'info officielle, plusieurs sources affirment que pVPN permet l'attribution jusqu'à 5 ports (peut-être même 6 ou plus à ce jour, je n'ai pas encore essayé) sur un seul tunnel. C'est donc à multiplier par le nombre de tunnels possibles (soit 6 pour WG je crois - pas encore testé non plus). Les divers clients alternatifs que j'ai essayés - dont le notable pVPN en TUI que j'apprécie pas mal - ne permettent pas (peut être encore) de gérer plusieurs ports, et ne semblent même pas bien ou du tout gérer l'UDP en pratique.
A l'heure actuelle, ça ne semble possible qu'à l'aide d'une boucle natpmpc. Sinon, pourquoi libnatpmp m'aurait retourné des réponses positives à mes requêtes d'obtention de ports en m'affichant les ports publics attribués (et comme je l'avais précisé, sans erreur) ? En plus, par ce biais et d'après mes tests, il semble possible de demander des ports publics particuliers ; le serveur accepte bien sûr s'ils ne sont pas déjà réservés ou retourne un port aléatoire le cas échéant. L'intérêt de custom les ports publics est quasi nul, on est d'accord, mais c'est pour préciser les choses.
Perso, je m'en moque, c'est pour ça que j'ai alloué 1 partout, pour que le serveur me retourne de l'aléatoire ; l'essentiel est surtout de choisir ses ports locaux sur lesquels bind, et de penser à les ouvrir dans son pare-feu. Cela dit, après vérification, même si ce n'est pas bloquant, c'est la valeur 0 qu'il faudrait mettre dans ce cas selon le protocole NAT-PMP (RFC 6886), soit natpmpc -a 0 <local_port> <tcp/udp> 60 -g 10.2.0.1.

Donc en bref : l'ouverture de ports multiples TCP/UDP avec pVPN dépend de la commande natpmpc*, et cela semble bien fonctionner à ce niveau.
(*) gérée par natpmp ou libnatpmp selon l'OS ; dans mon cas, c'est libnatpmp, paquet géré/optimisé par la team de CashyOS.
C'est ailleurs que ça doit bloquer à mon avis ; ou je suis complètement à côté de la plaque (pas exclu) !

Et concernant,

Je me suis trompé. Le trafic transitant par le tunnel doit être filtré par défaut.

Ce n'est pas déjà le cas avec le ufw status que j'ai montré ? D'ailleurs l'interface sur laquelle j'avais ciblé pour allow était "pvpn" et non Tout/Anywhere. C'est ce qui faisait dire dans mon post initial qu'UFW était peut être merdique/bogué, ou peut être juste son interface graphique intégré à CashyOS/KDE, qui balance les mauvaises commandes... Exemple concret : j'ai beau sélectionner IPv4 à la création d'une règle, il me duplique toujours la règle pour IPv6 ! Non seulement d'être contre intuitif, c'est complètement absurde (même si j'ai explicitement bloqué IPv6 au niveau OS, comme je l'ai dis). Cela dit, je n'ai pas le courage de remplacer UFW qui est nativement configuré dans Cashy ; changer de pare-feu c'est courir le risque de casser plein de choses (comme NetworkManager) et de transformer son OS en passoire si quelque chose est mal installé ou configuré. Je le rappelle : je ne suis pas expert.

Après pour le mat et l'antenne, il faut voir suivant la vue directe vers les pylônes du coin, au fond d'une vallée, c'est probablement mort.

J'ai trouvé pas mal de renseignements sur le sujet. Le problème c'est le budget. Entre, le routeur, l'antenne (yagi, panneau ou omnidirectionnelle), le mât ou pylône pour être au dessus des arbres, le coax et le accessoires, avec du matériel sérieux et homologué, on n'est plus dans la même catégorie.
Le plus économique et sûr, dans un premier temps et pour parer au plus pressé, c'est starlink si l'ADSL n'est pas rétabli. C'est une question de vie ou de mort.
L'OP est responsable si il y a un problème et qu'on ne peut pas appeler les secours. Il y avait un moyen de communication qui fonctionnait très bien et cet OP n'est pas capable de mettre un système de remplacement.
Comme dit Léon, il ne faut pas être pessimiste. L'ADSL sera rétabli mercredi.
Et comme le dit ben_becker

Bon d'ici 2029 tu as le temps de voir venir, en espérant que l'ADSL ne tombe plus en panne.