Auteur Sujet: pVPN + Port forwarding TCP & UDP + (lib)natpmp + UFW (Lu 384 fois)

bugmenot · « **le:** **Hier** à 01:07:46 »

Bonjour,

[EDIT] Ne vous emmerdez pas à lire : passez directement à la fin du topic pour comprendre que la résolution du problème est vaine.

Je suis sous CachyOS, KDE Plasma.

Mon problème : impossible de faire aboutir positivement le moindre test en ligne de port ouvert, que ce soit pour TCP ou UDP, mais surtout de faire fonctionner concrètement à plein potentiel mes daemons et applis dépendants d'un port UDP entrant. Toujours le même message : firewalled / derrière un NAT.

Et je ne comprends pas pourquoi. Je ne suis pas expert réseau, mais j'ai quand même passé des heures (pas exagéré) à essayer de trouver une solution pour rendre réellement accessibles depuis l'extérieur ces foutus ports, qui sont sensés l'être, mais le résultat est toujours le même en sortie. C'est UFW et/ou Network Manager qui sont si merdiques et foutent le boxon ?

Profil WG (avec paramètres recommandés pour le port forwarding) chargé depuis NetworkManager :

Code: [Sélectionner]

[Interface]
# Bouncing = 5
# NetShield = 2
# Moderate NAT = off
# NAT-PMP (Port Forwarding) = on
# VPN Accelerator = on
PrivateKey = ***
Address = 10.2.0.2/32
DNS = 10.2.0.1

[Peer]
# NL#***
PublicKey = ***
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = (ip):(port)

PersistentKeepalive = 25

J'ai essayé avec plusieurs serveurs, c'est pareil.

Ensuite, comme documenté ici : https://protonvpn.com/support/port-forwarding-manual-setup
Un petit script pour obtenir 5 ports tcp/udp via (lib)natpmp (tout est affiché OK/Successfully de ce côté là) :

Code: [Sélectionner]

#!/bin/bash
while true; do
    date
    natpmpc -a 1 61300 tcp 60 -g 10.2.0.1 && \
    natpmpc -a 1 61300 udp 60 -g 10.2.0.1 && \
    natpmpc -a 1 55300 tcp 60 -g 10.2.0.1 && \
    natpmpc -a 1 44300 tcp 60 -g 10.2.0.1 && \
    natpmpc -a 1 44301 udp 60 -g 10.2.0.1 || {
        echo "ERREUR natpmpc"
        break
    }
    sleep 45
done

Mes règles pare-feu :

Code: [Sélectionner]

❯ sudo ufw status verbose
Status: active
Logging: on (full)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To Action From
-- ------ ----
61300 ALLOW IN Anywhere
55300/tcp ALLOW IN Anywhere
44300/tcp ALLOW IN Anywhere
44301/udp ALLOW IN Anywhere

61300 (v6) ALLOW IN Anywhere (v6)
55300/tcp (v6) ALLOW IN Anywhere (v6)
44300/tcp (v6) ALLOW IN Anywhere (v6)
44301/udp (v6) ALLOW IN Anywhere (v6)

Je précise que j'ai désactivé l'IPv6 au niveau système et que je bind toujours depuis les paramètres natifs de mes applis sur l'interface du VPN. J'ai générisé le nom de l'interface réseau en 'pvpn' (toujours depuis NetworkManager) pour pouvoir switcher entre différents serveurs en conservant mes paramètres. Mes applis affichent bien toutes l'IPv4 publique du VPN, donc probablement pas un problème de route, mais je ne peux pas le garantir...
Je suppose que le problème doit venir de mon côté, et pas de pVPN, ou peut être pas...

J'espère vraiment que quelqu'un de plus calé que moi va pouvoir m'aider, au moins me mettre sur une piste, parce que là je sèche complètement.
Merci d'avance !

basilix · « **Réponse #1 le:** **Hier** à 09:16:42 »

Je ne connais pas tellement le sujet mais cela m'intéresse.

Le principe du tunnel VPN est d'encapsuler un paquet IP chiffré dans un paquet ordinaire.

Citer

Processus
↓
Socket TCP/UDP
↓
Pile réseau (paquet IP « interne » ordinaire)
↓
Interface virtuelle
↓
Chiffrement + encapsulation VPN (paquet IP interne chiffré et encapsulé dans un paquet IP ordinaire)
↓
Interface physique
↓
Internet (flux réseau ordinaire)
↓
Serveur Proton VPN (déchiffrement et désencapsulation)
↓
Internet (flux réseau ordinaire)

L'application VPN reçoit le paquet IP ordinaire, le déchiffre, désencapsule le paquet IP interne, puis le remet à l'interface virtuelle.
Le noyau traite ensuite ce paquet comme s’il était arrivé par une interface réseau ordinaire.

Citer

Internet
↓
IP publique Proton VPN:51413
↓
NAT (ou DNAT ?) Proton VPN + pare-feu Proton VPN
↓
IP cible : 10.2.0.17:51413 (réseau virtuel : adresse IP du client VPN. Le port est associé à l'adresse IP).
↓
...
↓
Tunnel chiffré
↓
...
↓
Interface virtuelle de votre machine
↓
Application locale

~~Tu n'as pas besoin d'ouvrir des ports dans le pare-feu de ta machine.~~

On ne peut faire correspondre un port qu'à un seul autre.

Code: [Sélectionner]

    natpmpc -a 1 61300 udp 60 -g 10.2.0.1 && \
    natpmpc -a 1 55300 tcp 60 -g 10.2.0.1 && \
    natpmpc -a 1 44300 tcp 60 -g 10.2.0.1 && \

Dans tes commandes, le port 1 est redirigé successivement vers les ports 61300, 55300, 44300.

basilix · « **Réponse #2 le:** **Hier** à 10:24:11 »

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

Par exemple :

Code: [Sélectionner]

sudo ufw allow in on wg0 to any port 51413 proto tcp

Code: [Sélectionner]

while true; do
    natpmpc -a 1 0 udp 60 -g 10.2.0.1 &&
    natpmpc -a 1 0 tcp 60 -g 10.2.0.1 ||
    break
    sleep 45
done

Apparemment, selon ChatGPT, on ne peut gérer qu'un seul port Proton VPN. On ne pourrait pas définir soi-même le port public.

bugmenot · « **Réponse #3 le:** **Hier** à 15:52:07 »

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,

Citer

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.

basilix · « **Réponse #4 le:** **Hier** à 16:27:02 »

@bugmenot :

Je ne savais pas que les ports 0 et 1 étaient particuliers. Je n'ai jamais étudié les VPN.

Est-ce que la redirection d'un seul port fonctionne ? Cela permettra de réduire le problème.

Peut-être que le service ne permet pas d'activer plusieurs ports ?

basilix · « **Réponse #5 le:** **Hier** à 16:29:57 »

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

bugmenot · « **Réponse #6 le:** **Aujourd'hui** à 16:55:42 »

Tu as surement raison concernant l'IPv6, je l'ai réactivé. J'avais désactivé via systemd, car je pensais que ça m'éviterait plus globalement/efficacement les fuite IPv6 hors tunnel, mais puisqu'il est déjà désactivé au niveau de mes interfaces physiques et virtuelles via NetworkManager, ça devrait suffire à sécuriser sans mettre des batons dans les roues aux applis qui en dépendent et de les laisser faire leur fallback IPv4 voyant que l'IPv6 échoue.

MAIS, après encore de nombre tests, je fais un constat amère sur plusieurs points :

- Même avec un seul port, l'allocation via natpmpc bien que retournant toujours des messages positifs ne fonctionne réellement qu'une fois sur dix (en étant généreux) et uniquement sur quelques serveurs (aucun moyen de savoir lesquels, même si dits optimisés P2P + P [port forwarding]).
- L'opening d'un port unique ne fonctionne même pas via l'appli semi-officielle (proton-vpn-gtk-app, pourtant à jour - car oui, il n'y a même pas d'app officielle pour les utilisateurs sous Arch, comme s'il n'y avait que des utilisateurs de Debian ou Fedora en desktop en 2026...).
- L'attribution d'un port unique fonctionne à peu près via des clients GUI / TUI alternatifs (oui, mieux qu'avec l'appli recommandée par pVPN, un comble).
- Mais la plus grosse surprise, c'est que quand l'opening semble fonctionner, c'est seulement les premières minutes ! Oui, oui, tous mes tests l'ont confirmé ! Obligé de se reco sur le/un tunnel pour obtenir un nouveau port ! Donc ça ne sert... à rien !
Ca explique tout ; j'ai fini par comprendre et j'ai facilement pu trouver confirmation ensuite : https://www.reddit.com/r/ProtonVPN/comments/1nc3nhb/how_to_stop_port_from_changing/

Bref, en 2025/2026, si vous envisagez ProtonVPN pour son port forwarding : oubliez direct, même si vous n'avez besoin que d'un seul port. Il reste encore d'autres fournisseurs sérieux qui proposent cette fonction bien plus aboutie et stable.

Je pensais que pVPN ne pouvait que s'améliorer sur ce point, même si on sait qu'il n'en font pas une priorité (ça peut se comprendre), mais la réalité indique tout le contraire. Non seulement il n'est plus possible de gérer plusieurs ports sur un même tunnel comme c'était encore le cas en 2024 d'après tous les retours jusqu'à cette date), mais depuis 2025 (où ça commence à se gâter), cette fonction est carrément devenue un mirage complet.
A la première occasion, je me casse de chez eux. J'étais déjà déçu de leur négligence de l'environnement Linux, en particulier Arch. Même si j'avais payé peu cher et qu'à côté de ça les performances restent bonnes, leur manque de transparence en général (sans parler du fiasco de son PDG...) me tape sur le système ; ils ne peuvent pas ignorer les problèmes de port forwarding depuis plus d'un 1 an que ça dure, et pourtant, je n'ai trouvé aucun note de leur part sur le problème. Il est inadmissible qu'ils passent ça sous silence et qu'ils laissent galérer leurs clients comme de gros abrutis.
J'espère au moins que tout ceci permettra d'alerter sur le problème et d'éviter des déceptions à d'autres.

Donc le sujet est clos : le problème vient bien moins (par ne pas dire pas du tout) de mon environnement que du fournisseur lui-même. Je ne voulais pas croire qu'un fournisseur aussi populaire et même audité puisse offrir une telle expérience, mais c'est pourtant bien le cas.