Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS BSD [FreeBSD] NFS via VPN

[FreeBSD] NFS via VPN

6 réponses
Avatar
MaXX
'soir,
Je viens de refaire ma config OpenVPN avec de jolis certificats au lieu
d'une clé prépartagée et VPN obligatoire pour le wifi... Tout fonctionne
bien, malgré la prise de tête avec les script "easy-rsa" fournis avec
OpenVPN.

J'ai tout configuré en 'tcp-server' vu que NFS en UPD ne semblait pas
vouloir passer (rpc timeout). Les performances sont *désatreuses* en TCP
quand je passe le 300KB/s je suis content, avant en UDP sans VPN (pas bien
le wifi avec rien que le wep) j'arrivais allégrement à 1MB/s... Le serveur
me sature une liaison 100Mbps, le pb n'est pas là... Pas de réelle
augmentation des charges système non plus... La compression aide mais pour
des videos ça ne fait que bouffer du CPU...

Y'a quelque chose à faire pour améliorer un peu les perf (600KB/s ce serait
déjà bien) ou il faut juste accepter que ça traine en TCP?

--
MaXX
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
F. Senault

Y'a quelque chose à faire pour améliorer un peu les perf (600KB/s ce serait
déjà bien) ou il faut juste accepter que ça traine en TCP?


Ben, mesure déjà en TCP sans VPN, tu aurais peut-être une idée d'où
vient l'overhead ?

Fred
--
Tu vois la belle bleue Des feux de l'artifice Et tu la sens même un
peu mieux A la faveur d'une éclipse On voit du jour au lendemain Que
ça ne s'invente pas Instantanément comme ça Reprendre de volée d'aussi
loin Comme elle vient Encore et encore (Noir Désir, Comme elle vient)

Avatar
MaXX
F. Senault wrote:


Y'a quelque chose à faire pour améliorer un peu les perf (600KB/s ce
serait déjà bien) ou il faut juste accepter que ça traine en TCP?


Ben, mesure déjà en TCP sans VPN, tu aurais peut-être une idée d'où
vient l'overhead ?
TCP est un protocol avec connection, plus de données dans les headers donc,

c'est clair, ça charge. Mais je ne m'attendait pas à 4x plus lent...


--
MaXX


Avatar
Erwan David
MaXX écrivait :

F. Senault wrote:


Y'a quelque chose à faire pour améliorer un peu les perf (600KB/s ce
serait déjà bien) ou il faut juste accepter que ça traine en TCP?


Ben, mesure déjà en TCP sans VPN, tu aurais peut-être une idée d'où
vient l'overhead ?
TCP est un protocol avec connection, plus de données dans les headers donc,

c'est clair, ça charge. Mais je ne m'attendait pas à 4x plus lent...


Sur un lien peruturbé ça va provoquer des problèmes puisque tu fais
passer du TCP danbs du TCP, si un paquet de la couche basse se perd tu
risque des réémissions à 2 niveaux et donc un overhead nettement plus élevé.

--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf



Avatar
Jacques Caron
Salut,

On Tue, 22 Nov 2005 00:53:05 +0100, MaXX wrote:

J'ai tout configuré en 'tcp-server' vu que NFS en UPD ne semblait pas
vouloir passer (rpc timeout).


J'avoue ne pas comprendre le rapport avec la choucroute... tous les
protocoles qui transitent via le VPN se moquent de comment le VPN est
réalisé, donc il n'y a aucune raison que le VPN soit implémenté en UDP ou
TCP influence NFS. Le problème doit être ailleurs, tu as du changer
plusieurs paramètres en même temps.

Les performances sont *désatreuses* en TCP
quand je passe le 300KB/s je suis content, avant en UDP sans VPN (pas
bien le wifi avec rien que le wep) j'arrivais allégrement à 1MB/s...


En NFS? NFS est très sensible à la latence (il n'y a pas de windowing),
donc il serait utile de mesurer la latence dans les différents cas de
figure, i.e. ping sur l'IP publique du serveur et ping sur l'IP privée,
pour comparer. Tu peux aussi essayer avec openVPN en UDP pour voir si ça
fait une différence.

Je pense que le passage par le VPN augmente sensiblement le volume de
données augmentées, déjà suite à l'overhead du VPN, mais aussi suite à la
"fragmentation" (pas au niveau IP, un peu plus haut) induite. Tu peux
toujours essayer de réduire la MTU utilisée de bout en bout pour voir si
ça change.

Sinon tous les protocoles basés sur TCP (FTP, SFTP, HTTP...) sont eux
nettement moins sensibles à la latence (à condition d'avoir une fenêtre
TCP assez grande).

Jacques.
--
Oxado http://www.oxado.com/

Avatar
MaXX
Erwan David wrote:
MaXX écrivait :
F. Senault wrote:
Y'a quelque chose à faire pour améliorer un peu les perf (600KB/s ce
serait déjà bien) ou il faut juste accepter que ça traine en TCP?
Ben, mesure déjà en TCP sans VPN, tu aurais peut-être une idée d'où

vient l'overhead ?
TCP est un protocol avec connection, plus de données dans les headers

donc, c'est clair, ça charge. Mais je ne m'attendait pas à 4x plus
lent...
Sur un lien peruturbé ça va provoquer des problèmes puisque tu fais

passer du TCP danbs du TCP, si un paquet de la couche basse se perd tu
risque des réémissions à 2 niveaux et donc un overhead nettement plus
élevé.
Bon à savoir, mais je ne vois quasi pas de retransmission (1 paquet par

minutes en gros, plus si le gsm est trop près (bluetooth + wifi = gros
bazard, logique)...

--
MaXX




Avatar
MaXX
Jacques Caron wrote:
Salut,
Salut,


On Tue, 22 Nov 2005 00:53:05 +0100, MaXX wrote:
J'ai tout configuré en 'tcp-server' vu que NFS en UPD ne semblait pas
vouloir passer (rpc timeout).
J'avoue ne pas comprendre le rapport avec la choucroute... tous les

protocoles qui transitent via le VPN se moquent de comment le VPN est
réalisé, donc il n'y a aucune raison que le VPN soit implémenté en UDP ou
TCP influence NFS. Le problème doit être ailleurs, tu as du changer
plusieurs paramètres en même temps.
Moi non plus je comprend pas, les machines refusent de se connecter entre

elle si j'utilise 'udp-server' (le firewall est en allow all from any to
any via tun0).
En 'tcp-server' c'est NFS qui refuse de travailler en UDP le seul moyen pour
monter un share c'est 'mount_nfs -T VPNhost:/share /mnt_pt', tout le reste
fonctionne impec, mail, news, web, video en streaming (RTSP,HTTP,etc),...
Je ne vois pas de grosses bourdes dans ma config, mais je l'ai tellement
relue que je risque de louper un éléphant dans un couloir... Je me demande
si ça n'a rien à voir avec l'utilisation de 'dev-tun', je devrais essayer
en ethernet bridge ('dev-tap'), va faloir que je relise la doc.

-----config serveur------
# Server Deamon
port 6052
proto tcp
persist-key
persist-tun
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
max-clients 5

# Link Config
dev tun
tun-mtu 1500
mssfix 1400
keepalive 10 60
comp-lzo

# Security
ca keys/ca.crt
cert keys/akar.crt
dh keys/dh1024.pem

# Routes
client-to-client
push "route 192.168.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
push "route 192.168.3.0 255.255.255.0"
route 10.8.0.0 255.255.255.252

#Client Config
client-config-dir ccd

#Logging
status openvpn-status.log
log /var/log/openvpn.log
verb 3
----------------------

---Config client coté serveur----
iroute 192.168.3.0 255.255.255.0
ifconfig-push 10.8.0.2 10.8.0.1
---------------------------------

------Config Client-------
#Client Config
client
dev tun
proto tcp
persist-key
persist-tun

#Link
remote myvpnserv.no-ip.org 6052 #Assigné par fichier host à la maison
#commenté ailleur pour resol. DNS
resolv-retry infinite
keepalive 10 60
tun-mtu 1500
mssfix 1400
nobind
comp-lzo

#Security
ca keys/ca.crt
cert keys/laptop.crt
key keys/laptop.key

#Logging
mute-replay-warnings
verb 3
--------------------------

Les performances sont *désatreuses* en TCP
quand je passe le 300KB/s je suis content, avant en UDP sans VPN (pas
bien le wifi avec rien que le wep) j'arrivais allégrement à 1MB/s...
En NFS? NFS est très sensible à la latence (il n'y a pas de windowing),

donc il serait utile de mesurer la latence dans les différents cas de
figure, i.e. ping sur l'IP publique du serveur et ping sur l'IP privée,
pour comparer.
C'est plus du double en gros...

----Ping hors VPN----
PING iakar (192.168.3.1): 56 data bytes
64 bytes from 192.168.3.1: icmp_seq=0 ttld time=2.062 ms
64 bytes from 192.168.3.1: icmp_seq=1 ttld time=2.136 ms
64 bytes from 192.168.3.1: icmp_seq=2 ttld time.395 ms
---------------------

----Ping dans VPN----
64 bytes from 192.168.0.1: icmp_seq=0 ttld time=4.097 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttld time=7.949 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttld timeb.393 ms
---------------------

Tu peux aussi essayer avec openVPN en UDP pour voir si ça
fait une différence.
J'aurais aimé mais pour une raison qui m'échappe ils refusent de parler

entre eux en UDP...

Je pense que le passage par le VPN augmente sensiblement le volume de
données augmentées, déjà suite à l'overhead du VPN, mais aussi suite à la
"fragmentation" (pas au niveau IP, un peu plus haut) induite. Tu peux
toujours essayer de réduire la MTU utilisée de bout en bout pour voir si
ça change.
Ajuster le MTU du tunel reduit sensiblement le nb de paquets de petite

taille (100-300bytes)... 1400b pour le tunel, semble être le mieux que je
puisse faire..

Sinon tous les protocoles basés sur TCP (FTP, SFTP, HTTP...) sont eux
nettement moins sensibles à la latence (à condition d'avoir une fenêtre
TCP assez grande).
Window size : 32768 en générale hors VPN, 32252 dans le tunel (observé avec

pour seul trafic un flux wma à 16Kbps)

Merci,
--
MaXX