je suis preneur de plus d'info sur la solution moderne.
Les systèmes de fichiers réseau comme SMB ou NFS sont anciens et n'ont pas été conçus pour fonctionner au travers d'un WAN qui plus est via un tunnel. Ca marche mais c'est pas concu pour. Apres si c'est pour juste un ou 2 utilisateurs pour un usage occasionnel ca peut faire l'affaire mais si la connexion a des perfs limitée comme c'est le cas ici, ces protocoles ne savent gérer les transferts avec plusieurs connexions en parallèle (pour un même fichier). Certes NFS v4 et SMB v3 ont un support pour cela mais c'est plutôt pour du "multi channel" (plusieurs carte réseau sur le serveur et le client).
Donc si le but c'est des transferts de gros fichiers (vidéo par exemple) entre un serveur et un PC distant (donc on 'copie' plutôt qu 'ouvre a distance') cet aspect 'plusieurs connexions en parallèle' est encore plus crucial et devient indispensable dans le choix de la solution. Il faut s'orienter vers un système de synchro/copie qui supporte plusieurs sessions en même temps pour un même fichier. Ca peut devenir complexe rapidement.
Donc franchement
le mieux c'est de virer le VPN ...vu que c'est ce qui génère la perte de débit.
Donc une une solution du style Nextcloud ou Owncloud (géré par soi-même) ou Microsoft Windows 365 / Google Workspace (managé), sans utiliser de VPN donc (important pour la performance dans le cas présent). Ou alors du transfert via ssh/scp si c'est une gestion manuelle des copies (ou via un script).
On peut aussi ouvrir directement SMB sur Internet si on maitrise le sujet (ce que fait Microsoft avec
Azure Files) mais y'a des implications sur la version du serveur et des clients et il faut bien verrouiller sa configuration.