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.

J'ai testé, cela marche. Altitude un peu haute par rapport à ce que je connais (+50m), mais je suppose qu'elle s'affinerait en bougeant le téléphone.

J'ai intégré la grille de géoïde EGM96 dans le projet. Sans elle, l'application utilisait l'altitude brute du système WGS84, ce qui provoquait un écart d'environ 50 mètres.

EGM96 corrige cette différence pour donner la vraie altitude par rapport au niveau de la mer.

Désormais, l'altitude MSL s'affiche, et tu devrais avoir la bonne valeur.

Salut,
je ne pense pas que le terme GSM soit adapté au sujet, il vaut mieux parler de routeur LTE (4G), le GSM (2G) est en cours de démontage.
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.