Bonjour,

j'ai le problème suivant chez un client :

cette société "toto" a un domaine "totodmn.com".
Il y a plusieurs sites reliés en SDSL par un VPN opérateur. L'opérateur met à dispo également un accès VPN PPTP géré par leur routeur Cisco qui effectue le routage entre les sites.

Les nomades peuvent donc se connecter au réseau de l'entreprise par ce VPN.
Ils obtiennent une IP sur une plage définie par l'opérateur puis peuvent joindre les matériels de n'importe quel site, notamment les serveurs DNS du domaine.

Tout cela fonctionnait sans souci jusqu'à ce que quelqu'un achète le domaine "totodmn.com" que le client ne possédait pas

Depuis, les sous-domaines de "totodmn.com" sont résolus par les serveurs DNS publics.
Chez certains nomades, cela ne pose pas de souci. Dès qu'ils montent le VPN, hop, ils tapent sur les serveurs DNS du domaine.
Mais chez d'autres, VPN monté, bien que le serveur DNS primaire soit du domaine (vérifiable via nslookup), un ping ou une résolution d'hôte sous un soft (IE) tape ailleurs et ne renvoie pas les réponses des DNS du domaine.

Exemple :
srvmachin.totodmn.com est résolue par les DNS publics en 67.89.56.12
sur le domaine, srvmachin.totodmn.com a l'IP 192.168.56.23
VPN monté, chez certains nomades, un nslookup va taper sur le serveur DNS du domaine 192.168.56.200 et résout srvmachin.totodmn.com en 192.168.56.23
Mais un ping ou tout autre soft va résoudre srvmachin.totodmn.com en 67.89.56.12

Evidemment, cela pose problème
Plus de lecteurs réseaux, plus d'accès à des sites internes, des serveurs, etc.

Depuis, j'ai appris que nslookup possède son propre moteur de résolution qui n'est pas le même que celui de Windows qui se base aussi sur le fichier host, netbios et je ne sais pas quoi d'autre.

Bien sur j'ai vérifié sur les postes de nomades impactés que tout était conforme aux postes des nomades non impactés.

La seule différence que j'ai trouvé et qui permet de contourner le problème, plus que de le résoudre, est que chez les nomades impactés, le serveur DNS de leur interface primaire est celui de leur box.
Si je définie sur cette interface les DNS publics de Google ou ceux de leur FAI par exemple, alors tout rentre dans l'ordre. Les résolutions de noms d'hôtes sous Windows deviennent conformes à nslookup et renvoient les réponses des serveurs DNS du domaine.
Mais bon je ne peux pas en rester là

Alors je sèche. Pourquoi cette différence de traitement selon que l'interface primaire du poste a comme serveurs DNS ceux de la box du nomade ou des serveurs DNS publics ?

Humm, quand ton lien VPN est monté je suppose qu'il est bien paramétré pour obliger à passer par ton nouveau "LAN" même pour les requêtes externes.  
 
Le souci doit venir du fait que dans tes cas litigieux la box est vue comme faisant partie du LAN (puisque IP locale) => du coup Windows l'interroge en priorité pour la résolution DNS => ton problème.
 
T'aurais pas moyen de forcer les serveurs DNS au lancement de ton client VPN ?

Bonjour,  
 
Une des solutions possible est de mettre ton entré DNS dans le etc/hosts de la workstation cliente.
 
Celui-ce n'aura plus de problèmes.
 
@ +    
 

 
Oui je me suis dit aussi que le caractère "local" (même plage IP que le poste sur son interface locale) devait jouer.
Mais bon je ne suis sûr de rien.
 
Que veux-tu dire par "forcer les serveurs DNS" ?
Lorsque le VPN est monté, a priori, le serveur DNS du domaine est bien celui primaire. En tout cas, c'est ce que j'en déduis puisque un nslookup tape directement dessus.

 
Oui sauf que le fichier host c'est crade et que je n'ai pas qu'une entrée mais des centaines et qu'il faut que le domaine soit joignable par son nom "totodmn.com" (GPO, DFS, etc.)

quelle idée de ne pas acheter un domaine alors que tu l'utilises ...
 
Si ton client a déjà en cache le nom c'est normal. Essaie un ipconfig /flushdns

 
Tu n'as pas d'autres solution, car il faut que tu dises à ta workstation que est dans le cloud qu'elle doit se connecter chez toi.
Ou alors que tu force l'utilisation de ton dns quand il rentre sur le vpn, ça existe sur les vpn juniper ou cisco, mais sous windows, je ne sais pas faire
 
 
@ +  

 
Houla, t'imagine bien que j'ai dépassé le test du "ipconfig /flushdns"

 
Euh ... je ne saisi pas la première phrase
Ensuite, VPN monté, c'est bien le serveur DNS du domaine qui semble considéré comme primaire (test sous nslookup positif)
C'est plutôt la méthode de résolution du client DNS Windows (utilisé par les softs et ping) qui semble s'en moquer et aller taper sur le serveur DNS local (la box des nomades quand ils sont chez eux)
Si le poste des nomades pointe sur son interface locale vers un serveur DNS non local (celui du FAI par exemple) alors il n'y a plus de problème.

Tu as regardé l'ordre des cartes réseaux ?

La vraie solution ça serait de racheter votre domaine...
 
Ou alors de renommer votre forêt  

Je soupconne que tu as un conflit de DNS entre celui fourni par le DHCP du boitier internet et celui fourni par le VPN.
Apres peut-etre selon les boitiers internet (ou selon les FAI), certains sont configures pour un DNS public et d'autre pour un proxy DNS via le boitier
 
Dans les 2 cas, toutes les machines essaient d'abord le DNS du boiter puis le DNS du VPN
Apres je pense que
- ceux qui marchent : le DNS primaire pointe sur un DNS public, donc le paquet "requete DNS" qui sort de ta machine va etre routé dans le tunnel VPN et la sans doute il est bloque ou filtre je sais pas, enfin toujours est-il la requete n'a pas de reponse donc ca bascule sur le 2e DNS et c'est le DNS VPN qui va repondre a la requete et donc ca marche
- ceux qui marchent pas : le DNS pointe sur le boitier internet qui est sur le reseau local, donc le paquet "requete DNS" qui sort de ta machine va etre envoye au boitier internet direct qui lui va repondre a la requete DNS avec l'adresse publique que tu veux pas. En fait le paquet est meme pas rentre dans le tunnel.
 
Apres si c'est effectivement ce probleme, il faudrait forcer le DNS VPN en primaire. J'ai googleisé vite fait et trouvé ca, peut-etre que ca peut t'aider :