Lenteur pour l'accès au partages Windows via VPN.
-
Bonjour,
Est-ce que le poste distant utilise le DNS du 2008?
Nusa
-
Au moment de la connexion VPN, pfSense transmet comme serveurs DNS pour la connexion, sa propre adresse comme serveur DNS principal et l'adresse du DNS du 2008 comme serveur DNS secondaire.
-
Et le pfsense, il utilise quoi comme DNS?
Forwarder?Nusa
-
S'il y a un serveur dns interne, il est parfaitement clair que c'est celui là qui doit être fourni par OpenVPN.
Normalement le dns d'un firewall est celui du fai, et un serveur typiquement sous Windows est dns interne même s'il forward le reste vers le firewall.
Un client VPN aura donc instantanément la resolution locale puis avec un petit délai la résolution du rest of the world.
-
On peut aussi configurer une règle de forward dans le DNS forwarder pour le domaine LAN en direction du DNS 2008.
-
Alors, tout d'abord merci pour l'intérêt que vous portez à mon problème.
Voici un peu plus de détails concernant ma configuration.DC2008 (ip : 130.169.7.100/16) – (LAN: 130.169.8.254/16) pfsense (PPTP: 10.10.10.96) -- client nomade (ip: 10.10.10.x)
Le pfSense est configuré en DNS Forwarder avec comme serveurs DNS :
1 : DC2008 (130.169.7.100)
2 : DNS Fournisseur d'accès à internetLe DC 2008 est lui-même configuré en DNS Forwarder vers le DNS du fournisseur d'accès pour tous les domaines hors de son autorité.
Les clients nomades reçoivent comme DNS :
1 : IP LAN du pfSense (130.169.8.254)
2 : IP du DC2008 (130.169.7.100)La configuration DNS fonctionne correctement depuis les postes nomades, aussi bien pour le nom d'hites internes au LAN que pour les domaines internet.
Le problème d'accès aux partages se pose que l'on tente d'accéder à ceux-ci depuis un nom d'hôte ou depuis une adresse IP.
Je pense donc que ce n'est pas lié à la configuration DNS.De plus (notre migration de domaine n'étant pas tout à fait terminée) les clients nomades qui se trouvent encore sur l'ancien domaine accèdent sans problème aux partages.
Il n'y a que ceux qui sont sur le nouveau domaine qui rencontre des problèmes (latence de presque 5mn avant d'obtenir la mire d'authentification).
Le pire dans tout ça est que si on se connecte au VPN depuis une machine ne faisant pas partie du domaine et que l'on tente d'accéder aux partages, l'accès est instantané.
Je pense donc que le dysfonctionnement doit être lié à Kerberos et doit certainement avoir un lien avec le fait que les utilisateur se sont connectés à leurs machines avec leur compte du domaine sans pouvoir joindre le DC (logique, ils sont à l'extérieur) et tente, après s'être connectés au VPN, d'accéder aux partages avec ce même compte.
-
-> Faites une capture wireshard coté poste client pour voir ce qu'il se passe.
Deux questions:
Le problème n'apparait-il que lorsqu'on essaye de joindre un serveur 2008 ?Le réseau par lequel arrive ces nomades (10.10.10.X) a-t-il été renseigné dans Active Directory Sites et Services et rattaché au site ou se trouve vos DC et le serveur pfSense ?
-
J'ai fais une capture (avec Microsoft Network Monitor):
http://maxk69.free.fr/DL/capture_chezremy.cap
-Le problème se pose aussi lorsque l'on accède à un serveur 2003.
-Le réseau n'a pas été déclaré dans Active Directory Sites et Services (je vais creuser cette piste)
Au vu de la capture, il semblerai que les requêtes Kerberos KRB_TGS_REQ n'obtiennent pas de réponse.
[EDIT] J'ai regardé Active Directory Sites et Services et je ne sais pas trop où déclarer ce réseau.
Dans subnets, il n'y a rien pour l'instant. [/EDIT] -
Cela veut dire que l'AD est déployé en mode "a l'arrache" ;-) Avec un Default-First-Site-Name…
Concernant l'AD : Pour chaque subnet réseau présent dans le LAN il faut le créer dans sites et services. Ensuite, il faut associer les réseaux IP aux sites physiques créés dans cette meme console. On cré un site lorsque différents sites, dans différents adressages, possèdent un ou plusieurs controleur de domaine. Dans une topologie simple on a un site=un subnet= un ou deux DC, quand on a plusieurs sites/DC il faut un mécanisme pour orienter les clients vers les DC les plus proches, c'est à celà que servent les sites AD et les subnet (sans compter les notions de synchro inter sites). Dans la pratique cette console doit donc contenur au minimum un site au nom de votre site principal (le site par défaut renommé) et le ou les subnet de ce site.
Dans votre cas, les DC voient arriver des demandes d'authentification d'un réseau qu'il ne connaissent pas, ceci n'est pas bloquant mais génère du trafic superflu afin de déterminer quel DC (si vous en avez plusieurs bien entendu) doit répondre à leur demande. Si c'est le cas un evenement de source NETLOGON doit apparaitre une fois par jour stipulant que des stations provenant d'un site inconnu ont tentés un authantification.Ensuite, simple remarque, pourquoi votre LAN n'est-il pas dans un adressage RFC1918 ?
Votre portable est-il à l'heure ? par rapport à vos DC?
-
Ok, merci pour le détail.
On a qu'un seul DC pour le moment et un seul site alors j'ai laissé le site par défaut et ajouté le subnet mais il n'y a aucun changement.
Les IP en 10.10.10, c'ezst pas vraiment un LAN en fait c'est seulement les IP du VPN qui sont distribuées en /32.
C'est vrai qu'on aurai pu mettre 10.0.0.x ça aurai été plus propre. Celà dit ça ne représente pas un problème bloquant.
Je pense que l'heure est correcte car le portable sur lequel nous faisons les test a été installé était sur le LAN il y a quelques jours encore à peine et qu'il était synchroniser en NTP via le DC.
Je continu à chercher, j'ai quelques pistes à approfondir, je posterai ici si je trouve quelque-chose.