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/2381En 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.
VPN