[OPENVPN] problème de résolution DNS
Résolu/Fermé
A voir également:
- Openvpn dns
- Changer dns - Guide
- Dns gratuit - Guide
- Dns bouygues - Accueil - Guide box et connexion Internet
- Clear dns cache - Guide
- Dns jumper - Télécharger - Serveurs
6 réponses
chers amis je viens de repousser les limites de l'informatique, j'ai accompli l'impossible.
les clients du VPN peuvent sortir sur internet a travers le tunnel.
le miracle est ici :
/proc/sys/net/ipv4/conf/tap0/rp_filter
la valeur du filtre de retour de paquet était à 1, les paquets étaient donc interprétés comme spoofés.
j'ai passé la valeur à 0 et tout fonctionne, les paquets incompréhensibles, l'autre partie de mon LAN du VPN qui n'est pas dans le même réseau (<-- ?), TOUT !
Merci à Manu pour la clôture autour de mon jardin, et à Google pour les Docs OpenVPN.
iskander
les clients du VPN peuvent sortir sur internet a travers le tunnel.
le miracle est ici :
/proc/sys/net/ipv4/conf/tap0/rp_filter
la valeur du filtre de retour de paquet était à 1, les paquets étaient donc interprétés comme spoofés.
j'ai passé la valeur à 0 et tout fonctionne, les paquets incompréhensibles, l'autre partie de mon LAN du VPN qui n'est pas dans le même réseau (<-- ?), TOUT !
Merci à Manu pour la clôture autour de mon jardin, et à Google pour les Docs OpenVPN.
iskander
Bonjour,
Quel est le dns de votre réseau privé ? j'ai l'impression que vous confondez avec le dns public.
la route par defaut est bien le routeur qui a une patte sur Internet
Oui, mais si vous êtes sur un réseau privé, la patte sur Internet ne doit pas vous faire sortir de votre réseau privé, elle ne peut servir qu'à accéder à une partie de votre réseau privé qui est sur un autre site.
j'ai essayé avec 192.168.0.1 qui est le routeur qui fait DNS et aussi le DNS de mon fournisseur ça ne marche pas
C'est normal. le dns public n'est pas dans votre réseau privé. De toutes façon il ne servirait à rien, il ne donne que des adresses qui ne sont pas dans votre réseau. Il vous faut le dns privé qui donne les adresses des machines sur votre réseau privé.
Comparaison : vous construisez une clôture autour de votre jardin pour empêcher les gens de rentrer et vous vous étonnez que la clôture vous empêche de sortir de votre jardin.
Manu
Quel est le dns de votre réseau privé ? j'ai l'impression que vous confondez avec le dns public.
la route par defaut est bien le routeur qui a une patte sur Internet
Oui, mais si vous êtes sur un réseau privé, la patte sur Internet ne doit pas vous faire sortir de votre réseau privé, elle ne peut servir qu'à accéder à une partie de votre réseau privé qui est sur un autre site.
j'ai essayé avec 192.168.0.1 qui est le routeur qui fait DNS et aussi le DNS de mon fournisseur ça ne marche pas
C'est normal. le dns public n'est pas dans votre réseau privé. De toutes façon il ne servirait à rien, il ne donne que des adresses qui ne sont pas dans votre réseau. Il vous faut le dns privé qui donne les adresses des machines sur votre réseau privé.
Comparaison : vous construisez une clôture autour de votre jardin pour empêcher les gens de rentrer et vous vous étonnez que la clôture vous empêche de sortir de votre jardin.
Manu
Merci pour ces précieuses remarques mais ce n'est pas l'objet de ma demande, je reformule :
j'ai un LAN en 192.168.0.0/24 sur une des stations du LAN en l'occurence le 192.168.0.2
mon serveur OpenVPN route en en mode TAP dans un subnet 10.8.0.0/24
le serveur passe en parametre au clioent une route statique de 10.8.0.0 vers 192.168.0.0
un client connecté en 10.8.0.x peux donc joindre les stations en 10.8.0.0/24 et en 192.168.0.0/24.
l'objet de ma demande, je souhaite que les clients openvpn du subnet 10.8.0.0/24 puissent sortir sur internet au travers du tunnel VPN.
cependant je bloque sur la résolution DNS, je n'ai pas de DNS privé pour 5 stations je n'en ai pas l'utilité je passe par le fichier Hosts et ça marche très bien, cependant les requetes DNS vers internet ne fonctionnent pas.
donc il n'y a pas de confusion entre dns public/privé, je ne vois pas pourquoi le dns devrait etre dans le même lan, le routage doit tres bien faire l'affaire, d'ailleurs ça FAIT très bien l'affaire puisque les requêtes ICMP aboutissent.
je peux d'ailleurs acceder au partages samba de 10.8.0.2 et 192.168.0.2 qui sont en réalité le tap0 et eth0 d'un même machine.
reste la question de la résolution, où ai-je fais l'erreur...
j'ai un LAN en 192.168.0.0/24 sur une des stations du LAN en l'occurence le 192.168.0.2
mon serveur OpenVPN route en en mode TAP dans un subnet 10.8.0.0/24
le serveur passe en parametre au clioent une route statique de 10.8.0.0 vers 192.168.0.0
un client connecté en 10.8.0.x peux donc joindre les stations en 10.8.0.0/24 et en 192.168.0.0/24.
l'objet de ma demande, je souhaite que les clients openvpn du subnet 10.8.0.0/24 puissent sortir sur internet au travers du tunnel VPN.
cependant je bloque sur la résolution DNS, je n'ai pas de DNS privé pour 5 stations je n'en ai pas l'utilité je passe par le fichier Hosts et ça marche très bien, cependant les requetes DNS vers internet ne fonctionnent pas.
donc il n'y a pas de confusion entre dns public/privé, je ne vois pas pourquoi le dns devrait etre dans le même lan, le routage doit tres bien faire l'affaire, d'ailleurs ça FAIT très bien l'affaire puisque les requêtes ICMP aboutissent.
je peux d'ailleurs acceder au partages samba de 10.8.0.2 et 192.168.0.2 qui sont en réalité le tap0 et eth0 d'un même machine.
reste la question de la résolution, où ai-je fais l'erreur...
Rebonjour,
bien, cependant les requetes DNS vers internet ne fonctionnent pas.
Vous faites des requêtes sur un dns qui est dans un autre réseau... Les exemples que vous donnez sont tous sur le réseau privé (adresses en 10. ou 192.168), mais le dns que vous cherchez à joindre il est où ?
donc il n'y a pas de confusion entre dns public/privé, je ne vois pas pourquoi le dns devrait etre dans le même lan, le routage doit tres bien faire l'affaire,
Je n'ai pas dit dans le même lan, j'ai dit dans le même réseau (. Le but du VPN est d'empêcher de sortir du réseau. Le routage peut très bien faire transiter les paquets par le réseau public, mais les données ne peuvent être interprétées puisque les trames privées sont chiffrées et encapsulées.
Si ça marchait, votre réseau privé serait percé.
Manu
bien, cependant les requetes DNS vers internet ne fonctionnent pas.
Vous faites des requêtes sur un dns qui est dans un autre réseau... Les exemples que vous donnez sont tous sur le réseau privé (adresses en 10. ou 192.168), mais le dns que vous cherchez à joindre il est où ?
donc il n'y a pas de confusion entre dns public/privé, je ne vois pas pourquoi le dns devrait etre dans le même lan, le routage doit tres bien faire l'affaire,
Je n'ai pas dit dans le même lan, j'ai dit dans le même réseau (. Le but du VPN est d'empêcher de sortir du réseau. Le routage peut très bien faire transiter les paquets par le réseau public, mais les données ne peuvent être interprétées puisque les trames privées sont chiffrées et encapsulées.
Si ça marchait, votre réseau privé serait percé.
Manu
le DNS est le 192.168.0.1 qui est donc sur le LAN.
les stations en 10.8.0.x peuvent bien joindre cette adresse.
Comme c'est la passerelle par défaut, le comportement normal serait que les paquets passent par cette interface si le nom n'est pas résolu via le hosts.
Mais pour une raison que j'ignore ça n'est pas le cas.
les stations en 10.8.0.x peuvent bien joindre cette adresse.
Comme c'est la passerelle par défaut, le comportement normal serait que les paquets passent par cette interface si le nom n'est pas résolu via le hosts.
Mais pour une raison que j'ignore ça n'est pas le cas.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Rebonjour,
Le DNS est le 192.168.0.1 qui est donc sur le LAN.
Il est sur le LAN, mais pas dans le VPN. Il ne peut pas comprendre ce qu'il voit passer.
Comme c'est la passerelle par défaut, le comportement normal serait que les paquets passent par cette interface si le nom n'est pas résolu via le hosts.
C'est probablement ce qui se passe, mais tout ce qui est issu du VPN est incompréhensible, il ne peut qu'être routé vers une autre partie du VPN.
Mais pour une raison que j'ignore ça n'est pas le cas.
Un VPN c'est fait pour être fermé.
Manu
Le DNS est le 192.168.0.1 qui est donc sur le LAN.
Il est sur le LAN, mais pas dans le VPN. Il ne peut pas comprendre ce qu'il voit passer.
Comme c'est la passerelle par défaut, le comportement normal serait que les paquets passent par cette interface si le nom n'est pas résolu via le hosts.
C'est probablement ce qui se passe, mais tout ce qui est issu du VPN est incompréhensible, il ne peut qu'être routé vers une autre partie du VPN.
Mais pour une raison que j'ignore ça n'est pas le cas.
Un VPN c'est fait pour être fermé.
Manu
ah ok merci pour ces analyses.
donc en fait j'envoie des requetes ICMP incompréhensibles qui arrivent a destination et qui reviennent, mais les requetes DNS incompréhensibles n'arrivent pas.
j'envoie des demandes d'ouverture de fichiers samba incompréhensibles et le fichier s'ouvre, mais par contre il est impossible malgré tout de faire de la resolution de nom.
et bien un grand merci pour ton aide, je pensais naivement qu'OpenVPN n'etait qu'une encapsulation SSL
des données via internet, et qu'une fois arrivée a destination le paquet était utilisable voir routable ou que sais-je, je n'avais pas réalisé que mon LAN était 'une autre partie' de mon VPN.
je vais donc arreter de perdre mon temps sur une question techniquement impossible.
donc en fait j'envoie des requetes ICMP incompréhensibles qui arrivent a destination et qui reviennent, mais les requetes DNS incompréhensibles n'arrivent pas.
j'envoie des demandes d'ouverture de fichiers samba incompréhensibles et le fichier s'ouvre, mais par contre il est impossible malgré tout de faire de la resolution de nom.
et bien un grand merci pour ton aide, je pensais naivement qu'OpenVPN n'etait qu'une encapsulation SSL
des données via internet, et qu'une fois arrivée a destination le paquet était utilisable voir routable ou que sais-je, je n'avais pas réalisé que mon LAN était 'une autre partie' de mon VPN.
je vais donc arreter de perdre mon temps sur une question techniquement impossible.
