Bonjour à tous,
Je suis face à un problème dont je n'arrive pas à trouver de solution.
J'ai des serveurs dans nos locaux, avec des postes utilisateurs dans nos locaux, d'autres en télétravail et d'autres qui sont parfois dans les locaux et parfois en télétravail.
Pour les télétravailleurs j'ai un VPN openvpn qui marche bien. Mon problème vient de la résolution DNS pour les personnes qui peuvent être chez eux ou alors en local.
pc1 a comme IP, lorsqu'il est en local, 192.168.0.10 avec comme nom DNS pc1, ce même pc lorsqu'il est à l'extérieur a comme IP 192.168.10.50 avec toujours le même nom DNS. Une fois connecté au VPN il peut résoudre les adresses IP de mon réseau local sans problème, les ping passent.
Maintenant je me place côté serveur, lorsque pc1 fait une requête à un serveur lorsqu'il est connecté en local, le serveur interroge le DNS et il obtient la correspondance (192.168.0.10). Maintenant pc1 lui fait une requête depuis chez lui donc en passant par le VPN. Il interroge toujours le DNS et il obtient l'IP local et non celle passant par le VPN. Du coup toutes les requêtes (crystal report par exemple) échoues puisqu'il cherche à envoyer le résultat à 192.168.0.10 et non 192.168.10.50.
Comment est-ce que je pourrais résoudre mon problème ?
Merci d'avance.
# tu peux pas, enfin si peut-être.
Posté par NeoX . Évalué à 2.
tu peux pas vu que c'est le serveur qui semble faire la requête DNS, il obtiendra toujours une seule entrée DNS
peut-être que tu peux jouer du DHCP et de la mise à jour dynamique des DNS
le PC1 est absent => il n'existe pas dans le DNS
il est en reseau local, le DHCP lui donne toujours 192.168.0.10 et met le DNS à jour
il est en VPN, le DHCP du VPN lui donne toujours 192.168.10.50 et met le DNS à jour.
ainsi tu as une seule entrée dans le DNS, et ca pointe vers la bonne IP
[^] # Re: tu peux pas, enfin si peut-être.
Posté par Philippe M (site web personnel) . Évalué à 1.
tu peux pas vu que c'est le serveur qui semble faire la requête DNS, il obtiendra toujours une seule entrée DNS
C'est bien ce qui me semblais :(
Mon autre hic est que l'attribution des ip côté VPN est géré par le serveur VPN et non pas le dhcp local et quand bien même ce serait le dhcp local qui réalise l'adressage, je ferais une réservation par adresse MAC mais quid de l'adresse, celle de l'interface tun, l'interface réseau de pc1, celle de la box fai de l'utilisateur ?
Born to Kill EndUser !
# Ouille
Posté par _kaos_ . Évalué à 2.
Salut,
Ah, je crois qu'en tant qu'utilisateur, j'ai déjà eu cette galère…
Comme je n'ai plus l'ordinateur qui me servait à ce moment, ça ne revient pas directement.
Avec mon admin, on a commencé par une solution quick-fix. Hop, un petit edit de
/etc/hosts
et roule. (bon, ça c'était juste pour prendre le temps de réfléchir)Ah, ça m'énerve (euh, juste contre moi, hein ;) ). C'est pas
ipsec [up|down]
mais ça doit être pas loin…Matricule 23415
[^] # Re: Ouille
Posté par Philippe M (site web personnel) . Évalué à 1.
J'ai pensé à cette solution mais openvpn change les ip des clients vpn à chaque reconnexion du coups je vais passer mon temps à mettre à jour le fichier hosts du serveur :(
openvpn != ipsec
Born to Kill EndUser !
[^] # Re: Ouille
Posté par _kaos_ . Évalué à 1.
Salut,
Oui, bien sûr ! Mais c'était facile, du genre
maCommande up|down
et roule. Donc non, c'est clairement pasipsec
.C'est
maCommande
que j'aimerai bien retrouver. Mais là, pour le moment, ça veut pas…Matricule 23415
[^] # Re: Ouille
Posté par NeoX . Évalué à 3. Dernière modification le 26 mai 2020 à 12:08.
regarde pour réserver l'IP du client VPN (une piste : ipp.txt voire les CCD)
tu amélioreras par la meme occasion ta sécurité,
puis Mme Michu de la compta qui se connecte en VPN ne devrait pas avoir accès aux memes que M Dupont de l'IT, ou Mme Durand la dev full-stack
me semble aussi que le serveur openvpn peut prendre des commandes cmd-up dans les options
tu peux alors scripter une modification du DNS et l'activer quand le client se connecte.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.