[Résolu] Lenteur d'acces au serveur de fichiers (VPN PPTP) Le sujet est résolu

[Axaide]

Bonjour à tous,

Je sais que le titre est très vague, c'est pourquoi je vais essayer d'être le plus précis possible.
(il contient les mots clé que j'ai utilisé lors de ma recherche, l'histoire que sa facilite les prochaines recherches sur le même sujet).

Présentation du problème

Nos utilisateurs nomades sont sensés accéder au serveur de fichier (serveur membre du domaine) via le VPN PPTP lorsqu'il ne sont pas au siège (donc non connecté au LAN de la société).
Hors, depuis que nous les avons passés sur le nouveau domaine l'ouverture de la fenêtre listant tout les partages du serveur de fichier prend jusqu'à 5 minute pour s'ouvrir, ce qui n'est pas acceptable pour les utilisateurs (ce que je comprend tout a fait).

Existant et historique

Il y a encore quelque mois, nous étions sur un domaine contrôlé par un unique 2k server. Ce domaine a été ensuite migré sur un 2008 server.
Pour plusieurs raison nous avons décidé de recréer de A à Z l'infrastructure réseau ainsi qu'un domaine tout neuf (nom de domaine existant sur le Net, AD "gruyère", sécurité mal élaborée au départ, etc...).
Nous avons donc acquit de nouvelles machine après quoi nous avons entreprit de monté notre nouveau domaine AD (sous 2008 server). le nouveau DC étant en réalité une VM sur un XenServer, mais je doute que cela soit important dans notre problème.
Je précise aussi que nous avons fait cohabiter les deux domaines pendant la migration en appliquant une relation d'approbation entre les deux domaine (les machines du domaine pouvant alors ouvrir une session sous le domaine de leur choix).

Notre société est composé d'un site unique ou nous avons tout nos serveurs (et bien sur une centaine de postes).
Les commerciaux ainsi que les tech. SAV sont itinérant et accèdent au réseau du siège via un VPN PPTP. Le firewall / routeur du LAN du siège est un PF Sense, c'est grace à cette machine que les utilisateurs mobiles se connectent en VPN.
Les portables des utilisateurs mobiles sont joints au domaine, nous ouvrons une session avec leur compte d'utilisateur avant de leur mettre a disposition de telle sorte qu'une fois chez eu (et donc non connecté au LAN) il puissent ouvrir leur session en local (étant donné que leur credential AD est en cache sur la bécane).
Une fois leur session ouverte, ils ont la possibilité de se connecter au VPN et d'accéder alors à différent services disponibles sur le LAN dont le serveur de fichiers.

Jusqu'a maintenant les utilisateurs exécutaient un script VBS qui les authentifiait sur le serveur de fichier après la connexion VPN et connectait un lecteur réseau sur leur machine. Ce qui leur permettait ensuite d'explorer les différents partages disponible sur le serveur de fichier.
Seulement, nos utilisateurs nous rapportent que le script met un temps fou à répondre (bon entre 4 et 5 min... pour eux c'est un temps fou) et la navigation dans les partages est plus longue que d'habitude (environ 1 a 2 min a chaque changement de dossier) et je ne vous parle pas de la copie ou l'édition de fichiers.
A savoir qu'avec l'ancien domaine nous n'avions pas ce souci (connexion < 30 sec et navigation normal).

Config réseau :
Un réseau en 130.169.0.0 / 16
passerelle 130.169.8.254

Les serveurs sont sous 2008
les postes utilisateurs sont sous XP pro SP3.

Diagnostique effectué

Rien de bien utile dans l'observateur d'évènement des portables des utilisateurs.
Les dcdiag et netdiag sur le DC ne font remonter aucun défaut.
On a cherché du coté des GPO, mais rien de significatif n'a changé depuis l'ancien domaine.

Tests effectués avec un portable dans la meme config que ceux des utilisateurs mobiles via VPN :
- L'acces SMB au serveur de fichier est problématique quelque soit le chemin UNC utilisé (nom netbios, FQDN ou meme IP).
- L'acces TSE à ce même serveur est normal, connexion quasi instantané (en utilisant nom netbios, FQDN ou meme IP).
- Ping sur serveur de fichier ou meme DC et encore divers machine : OK.
config local : ip en 192.168.0.../24, comme quasiment tout les réseau domestique, une passerelle en 192.168.0.254 (mais qui peut bien etre mon FAI ?) et les DNS fournis par le FAI.
config connexion VPN : ip en 10.10.10..../28, sa propre ip en passerelle et le DNS interne de la société (le DC).

Test effectué avec une machine externe a la société via VPN (donc pas sur le domaine) :
- L'acces SMB est normal (< 30 sec) quelque soit le chemin UNC.
- L'acces TSE à ce même serveur est normal, connexion quasi instantané
config local : similaire au précédent.
config connexion VPN : similaire au précédent.

Je précise que dans les deux cas, machine joint au domaine ou pas, une authentification est demandé lors de l'accès SMB au serveur de fichier (si on a pas utilisé le script de connexion VBS avant).

J'ai effectué les tests décrit dans ce topic sur mon poste d'utilisateur mobile témoin :
post623277.html#p623277
D'apres ce que je peux voir apres avoir réussis a afficher seulement les paquets qui vont sur le DC, c'est que le pc utilisateur fait des centaines de requête KerberosV5, Netlogon / NTLM, et autres trames assimilées entre le moment ou je valide la boite executer avec \\ipduserveur et le moment ou il affiche la fenetre listant tout les partages du serveur.

On vois effectivement plein de demande de jeton Kerberos en echec dans l'observateur d'évenement du DC.

Voila, a partir de là vous en savez a peu pres autant que moi.
Je ne sais pas si j'ai posté au bon endroit ni si un autre tropic à résolut ce probleme, tout ce que je sais c'est que sa fait une semaine qu'on cherche et qu'on fait du "sur place"...

Si sa évoque quelque chose chez l'un d'entre vous, ou si vous avez une idée de piste, je vous remercie d'avance de m'en faire part.

[steve86]

Salut,

Je vois que personne n'a répondu, alors :

1) Sur le DC : logging Kerberos : http://support.microsoft.com/kb/262177/en-us
2) Trace réseau "trace1.cap" quand le client DOMAINE accède en VPN à \\ip-serveur et attendre que le partage s'affiche, naviguer dans les dossiers, arrêter la trace.
3) Trace réseau "trace2.cap" quand le client DOMAINE accède en VPN à \\nom-serveur et attendre que le partage s'affiche, naviguer dans les dossiers, arrêter la trace.
4) Trace réseau "trace3.cap" quand le client EXTERNE accède en VPN à \\ip-serveur et attendre que le partage s'affiche, naviguer dans les dossiers, arrêter la trace.
5) Trace réseau "trace4.cap" quand le client EXTERNE accède en VPNà \\nom-serveur et attendre que le partage s'affiche, naviguer dans les dossiers, arrêter la trace.

Indique moi adresse IP client + IP et noms des serveurs (DC et File serveur...) + IP firewall + nom du share + date/heure à laquelle tu as effectué la trace.

Avant chaque trace bien vider les caches pour voir les demandes :

# Fermer toutes les applications en cours afin d'avoir une trace réseau la plus "clean" possible
# Vider le cache DNS : ipconfig /flushdns
# Vider le cache NETBIOS : NBTStat -R
# Vider le cache KERBEROS : Klist purge

6) MPS Reports du DC + Client DOMAINE + Client Externe:
http://download.microsoft.com/download/ ... dirsvc.exe

7) Compresse le tout (3 MPS Reports + 4 traces) et upload sur un espace perso ou autre, http://xthost.info/ par exemple et donne moi les identifiants en MP, je vais essayer d'analyser ça (je pars demain en congé).

====

Seulement, nos utilisateurs nous rapportent que le script met un temps fou à répondre (bon entre 4 et 5 min... pour eux c'est un temps fou)

As-tu la possibilité de mettre un echo et redirection vers un fichier à chaque étape du script (dans le cas où tu as plusieurs étapes)?
Ainsi, nous pourrons voir quelle est l'étape qui prend le plus de temps et ensuite analyser dans la trace réseau.

[Axaide]

Merci de vous pencher sur le probleme.

As-tu la possibilité de mettre un echo et redirection vers un fichier à chaque étape du script (dans le cas où tu as plusieurs étapes)?
Ainsi, nous pourrons voir quelle est l'étape qui prend le plus de temps et ensuite analyser dans la trace réseau.

En faite, le script VBS c'est ni plus ni moins qu'une interface utilisateur pour effectuer un "net use" sur le file server.
Il ouvre deux boite de dialogue qui demandent respectivement l'user puis le password et qui crée la chaine de la commande net use avant de l'exécuter.
il fait un net use sur le dossier personnel de l'utilisateur pour le connecter en lecteur réseau et jusqu'a maintenant sa suffisait a authentifier l'user sur le file server et a lui permettre de naviger dans ses partages.
Donc pour répondre a votre question, c'est le net use qui prend 3 plombes (je viend de faire des test en mettant des msgbox à chaque etapes)

Sinon je vais faire les traces et les MPS reports et je les mettrais sur un serveur.

[Axaide]

J'ai fait les traces que tu demandais, sa a pris plus de temps que prévu parce que ma machine test a la quel j'accédais a distance pour faire mes tests s'est éteinte et que j'ai due attendre de rentrer chez moi pour faire ses traces.

IP du client joint au domaine depuis le VPN: 10.10.10.2 (portable40)
IP du client non joint au domaine depuis le VPN: 10.10.10.1 (compta01)
IP du controleur de domaine : 130.169.7.100 (DC1)
IP du serveur de fichier : 130.169.7.34 (FILE1)
IP du firewall (pfsense) du coté LAN : 130.169.8.254
IP du firewall (pfsense) du coté VPN PPTP : 10.10.10.96

En faite c'est pas un partage en particulier, c'est déja le listage des partages qui pose probleme, apres le changement de partage / dossiers est aussi relativement long mais moins (cela dis c'est quand meme invivable pour les utilisateurs).

Sinon, les traces ont été faites aux alentours de 1h du mat, mais quelque soit l'heure le problème est le même.

Je t'envois les acces aux dump par MP.

Merci d'avance.

[steve86]

J'ai bien récupéré le fichier rar sur le serveur, je vais regarder ça ce soir et je tiens au courant.

[steve86]

Je viens de regarder rapidement avant d'aller au travail, je vois déjà l'erreur suivante : KRB5KRB_ERR_RESPONSE_TOO_BIG

This behavior occurs when the UDP Kerberos authentication packet is too large and needed to be fragmented.
This symptom mostly happens in a Remote access (such as VPN) scenario due to the MTU (Maximum Transmission Units) size.

Dans un premier temps, pourrais-tu appliquer ces 2 méthodes sur le poste ONDOMAINE :

1) http://support.microsoft.com/kb/244474/en-us

You can change MaxPacketSize to 1 to force the clients to use Kerberos traffic over TCP. To do this, follow these steps:

1. Start Registry Editor.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters
Note If the Parameters key does not exist, create it now.
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type MaxPacketSize, and then press ENTER.
5. Double-click MaxPacketSize, type 1 in the Value data box, click to select the Decimal option, and then click OK.
6. Quit Registry Editor.
7. Restart your computer.

Reboot puis refais un test, si jamais ça ne passe pas, étape suivante :

2) http://support.microsoft.com/kb/314825/en-us

Follow these steps:

1. Start Registry Editor (Regedit.exe).
2. Locate the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\parameters
3. On the Edit menu, click Add Value, and then add the following registry value:
Value Name: EnablePMTUBHDetect
Data Type: REG_DWORD
Value: 1
4. Quit Registry Editor, and then restart the computer.

Reboot et refais un test.

Si jamais ça ne fonctionne pas, je vais analyser plus en détails.

[Axaide]

Merci beaucoup de ton aide,
Les pistes que j'ai exploitées m'ont amener a ce genre de choses, mais sa n'était pas aussi précis que ça.

Je testes ça en début d'aprèm et je te dis ce que ça donne.

[Axaide]

Franchement, steve86 t'es trop un killeur !
Je savais que si quelqu'un pouvait nous aider, on le trouverait sur ce forum

J'ai utilisé la première solution sur mon poste témoin, à savoir :

1) http://support.microsoft.com/kb/244474/en-us

You can change MaxPacketSize to 1 to force the clients to use Kerberos traffic over TCP. To do this, follow these steps:

1. Start Registry Editor.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters
Note If the Parameters key does not exist, create it now.
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type MaxPacketSize, and then press ENTER.
5. Double-click MaxPacketSize, type 1 in the Value data box, click to select the Decimal option, and then click OK.
6. Quit Registry Editor.
7. Restart your computer.

J'avais trouvé cette clé, mais pas sur les supports crosoft et il ne précisaient pas de créer la clé si elle n'existait pas (en l'occurence elle n'existait pas).
Mais qu'un gas qui peux me sortir deux clés a modifier en lisant mes log 10 minutes me le dise clairement, sa m'a rassuré

Maintenant l'ouverture de la fenêtre listant les partages du serveur de fichiers prend moins d'une minute.
La navigation dans les dossiers est tres acceptable. Je commencerais a déployer cette solution sur toute la flotte de portable lundi et je posterais le résultats ici.
Cela dis je commence a me dire que le SMB n'est pas forcément ce qu'il y a de plus adapté a une connexion VPN (mais bon, je ne vais pas lancer un troll .

Je met mon petit [Résolu] dans le nom de topic,
et je te remercie encore.

[steve86]

Bonne nouvelle.

Voici mon analyse de manière un peu plus détaillée :

capture_ondomain_ip.cap

3599 (Trame 29) et 3107 (Trame 1484).
3599-3107= 492, 492/60=8
Il s'est donc écoulé environ 8 minutes.
Il y a 1484 trames.

capture_externe_ip.cap

3619 (Trame 3) et 3596 (Trame 470).
3619-3596=23
Il s'est donc écoulé 23 secondes.
Il y a 470 trames.

Conclusion rapide : Pour la même opération, le poste qui est dans le domaine prend 8 minutes et le poste qui n'est pas dans le domaine prend 23 secondes.

Pour faire simple, on va appeler "DOMAIN" le poste qui est dans le domaine.

Analyse de la trace capture_ondomain_ip.cap :

Requête KRB_AS_REQ
22 2133433787.409184 10.10.10.2 130.169.7.100 KRB5 AS-REQ
=> Le cache Kerberos a été vidé donc DOMAIN envoie KRB_AS_REQ au KDC, pour être précis, au serveur d'authentification pour obtenir un TGT (Ticket Granting Ticket)

Réponse à KRB_AS_REQ
40 2133433787.519776 130.169.7.100 10.10.10.2 KRB5 KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG
=> Le paquet envoyé est trop gros et a besoin d'être fragmenté.
=> On voit clairement que le protocole UDP est utilisé : User Datagram Protocol, Src Port: kerberos (88), Dst Port: availant-mgr (1122)

Fragmentation du paquet
Le paquet est fragmenté et réassemblé dans la trame 51
50 -3599.257812 10.10.10.2 130.169.7.100 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=02b5) [Reassembled in #51]
51 -3599.257812 10.10.10.2 130.169.7.100 KRB5 TGS-REQ

Requête KRB_TGS_REQ
51 -3599.257812 10.10.10.2 130.169.7.100 KRB5 TGS-REQ
=> DOMAIN envoie KRB_TGS_REQ au KDC, pour être précis, au TGS (Ticket Granting Server) pour obtenir un Service Ticket.

Fragmentation des paquets
Le paquet est fragmenté et réassemblé dans la trame 60.
59 -3594.256860 10.10.10.2 130.169.7.100 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=02bb) [Reassembled in #60]
60 -3594.256860 10.10.10.2 130.169.7.100 KRB5 TGS-REQ

Le paquet est fragmenté et réassemblé dans la trame 95.
94 -3590.327325 10.10.10.2 130.169.7.100 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=02ca) [Reassembled in #95]
95 -3590.327325 10.10.10.2 130.169.7.100 KRB5 TGS-REQ

Le paquet est fragmenté et réassemblé dans la trame 109.
108 -3589.036207 10.10.10.2 130.169.7.100 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=02d5) [Reassembled in #109]
109 -3589.036207 10.10.10.2 130.169.7.100 KRB5 TGS-REQ

Le paquet est fragmenté et réassemblé dans la trame 119.
118 -3585.326373 10.10.10.2 130.169.7.100 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=02d8) [Reassembled in #119]
119 -3585.326373 10.10.10.2 130.169.7.100 KRB5 TGS-REQ

Le paquet est fragmenté et réassemblé dans la trame 136.
135 -3580.100704 10.10.10.2 130.169.7.100 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=02e1) [Reassembled in #136]
136 -3580.100704 10.10.10.2 130.169.7.100 KRB5 TGS-REQ

Ensuite, un peu plus loin on voit à nouveau l'erreur KRB5KRB_ERR_RESPONSE_TOO_BIG.
997 -3236.748482 130.169.7.100 10.10.10.2 KRB5 KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG

En comparant le temps entre la trame initiale et la trame finale, on voit clairement que ce qui prend le plus de temps c'est la fragmentation / réassemblement des paquets.
3599-3126=473, 473/60=7,8
Il s'est donc écoulé environ 8 minutes.

50 -3599.257812 10.10.10.2 130.169.7.100 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=02b5) [Reassembled in #51]
1342 -3126.679384 10.10.10.2 130.169.7.100 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=054e) [Reassembled in #1343]
1343 -3126.679384 10.10.10.2 130.169.7.100 KRB5 TGS-REQ

Analyse de la trace capture_externe_ip.cap :
Aucun paquet fragmenté.

Conclusion : C'est bel et bien un problème lié à l'authentification Kerberos UDP (Le paquet envoyé est trop gros et a besoin d'être fragmenté)

Comme décrit dans l'article KB http://support.microsoft.com/kb/244474/en-us, tu peux déployer très facilement cette clé sur les postes du domaine.

The following template is an administrative template that can be imported into Group Policy to let the MaxPacketSize value be set for all enterprise computers that are running Windows Server 2003, Windows XP, or Windows 2000. To view the MaxPacketSize settings in Group Policy Object Editor, click Show Policies Only on the View menu so that Show Policies Only is not selected. This template modifies registry keys outside the Policies section. By default, Group Policy Object Editor does not display these registry settings.

===
ps : la description de ton problème m'a fait pensé à "une étude de cas" , j'apprécie qu'on détaille un maximum, ça permet de résoudre le problème plus facilement.

Je te souhaite d'avance un joyeux noël et une bonne année 2010.
C'est le dernier message que je poste sur ce forum pour l'année 2009, je vais faire une coupure avec l'IT pendant mes vacances ...

[Axaide]

Intéressante ton analyse.

ps : la description de ton problème m'a fait pensé à "une étude de cas" , j'apprécie qu'on détaille un maximum, ça permet de résoudre le problème plus facilement.

Je sais, je ne supporte pas les gas qui posent leur problème en 3 lignes et vas y démerdes toi avec...
Je trouve même que c'est normal de détailler au max le problème pour orienter autant que possible ceux qui sont susceptible de t'aider.

Merci encore,
bonne fêtes à toi et a tout les labo Microsoft.

[Axaide]

Bonjour,
Je reviens vers vous car le problème n'est pas totalement réglé.

J'ai commencé à déployer le correctif sur un panel de postes mobiles.
J'ai bien crée la GPO comme indiqué par le support Microsoft et mes postes locaux prenne bien la clé de registre. Par contre impossible de faire remonté la GPO sur mes postes mobiles en faisant un gpupdate, a mon avis a cause du problème que je vais énoncer après. Qu'à cela ne tienne, j'ai fais un petit exe qui crée la clé et sa fonctionne plutôt bien.

Maintenant, ce qui me gènes c'est qu'une fenêtre d'authentification apparait lorsqu'on veux accéder au serveur de fichier, elle apparait quasiment instantanément, aucun souci de ce coté la, mais elle apparait quand même.
En gros, si je comprend bien le concept, lorsqu'on est sur le LAN et qu'on ouvre une session sur le domaine, un jeton d'identification valable sur le domaine nous est délivré et il est valable sur toutes les ressources gérées par ce même domaine.
Par contre lorsqu'on ouvre une session hors LAN (et sans etre encore connecté au VPN) on utilise l'identité de l'utilisateur mis en cache lorsqu'il s'est connecté depuis le LAN. Le souci c'est que Cette identité, ou le jeton qui en résulte n'est donc pas valable sur le domaine si l'utilisateur se connecte au VPN apres avoir ouvert sa session et il ne peux donc pas accéder aux ressource de ce domaine sans s'identifier de nouveau et qu'un nouveau jeton lui soit délivré. C'est donc pour ça qu'une authentification est demandé lorsque l'utilisateur tente d'accéder au serveur de fichier après s'être connecté au VPN.

Par contre, j'ai remarqué qu'en faisant un bette net use sur le serveur de fichiers avec un compte du domaine (et sa ne me redemande pas le mot de passe) j'accédais aux partages sur lesquel l'utilisateur a les droits sans aucun souci.

Mes questions seront donc les suivantes :
1. Est ce que cela est un problème, ou est-ce voulue par mesure de sécurité ?
2. Existe-t-il une solution pour faire en sorte d'augmenter la durée de vie du jeton mis en cache, de valider les identifications effectuées avant la connexion au réseau afin de réduire au maximum les manipulation des utilisateurs ? Et si oui est ce que cela est une grosse faille se sécu ?
3. Est ce que je ne cherches pas trop loin, et n'aurais je pas meilleur compte a laisser mes utilisateurs exécuter leurs script VBS qui fait un net use sur le serveur de fichiers avant d'accéder à ce dernier comme s'était le cas jusqu'à maintenant (le problème dans ce cas c'est qu'ils doivent s'authentifier sur chaque ressources du domaine qu'ils veulent utiliser).

Merci d'avance pour votre aide.

[BriWil]

Bonjour à tous !
Je viens poser un problème similaire, car j'ai appliqué les orientations données ici mais je n'ai pas eut de résultat.
En fait j'ai déployé un VPN L2TP/IPSEC site à site avec des équipements mikrotik.
Et cette configuration fonctionne dépuis près de 5 ans dejà mais depuis quelques jours j'ai un site et un utilisateur nomade (mon Laptop à moi même) qui ne parviennent plus à attaquer une application web tournant sous XAMP et hébergé sur un windows server 2008 R2. Les Fichiers partagés sur ce Windows Server 2008 R2 également ne sont pas accessibles .
Il faut noter que une fois le VPN connecté, depuis les postes clients les ping et tracert vers le serveur sont ok, mais aucun service n'est accéssible.
La majorité des postes clients sont sur Window 8.1 et sur Windows 10 .
Il faut également noter que pendant ce temps les autres sites se connectent et travaillent normalement sans soucis.
Aidez moi à solutionner ce Problème SVP.
A vous lire .
Merci .

[magnancc51]

Bonjour,
Merci de créer ton propre sujet et de ne pas déterrer un topic qui a 11ans