Vous n'êtes pas identifié(e).
Pages : 1
Bind / named.conf.options
Bind / named.conf.local
Bind / named.conf.default.zone
Bind / db.mondomaine.tld
Openvpn / server.conf
Ici, j'ai tenté de remplacer 127.0.0.1 par l'ip tun0, ainsi que par venet0, sans succès.
Serveur / resolv.conf
J'ai testé la configuration et la validité de la zone avec :
Réponse Ok.
J'ai vérifié qu'il y ait bien une entrée pour la racine "." dans bind.keys.
J'ai déclaré mon domaine comme dns à mon prestataire de nom de domaine.
Config d'iptables ok pour l'ouverture du port bind. ( d'ailleurs, dans ce cas, est-ce utile d'ouvrir tcp et udp ? )
____
Voilà, je pense avoir donné toutes les infos qui me viennent à l'esprit. Je suis un peu confus, je ne distingue pas bien les rôles de resolv.conf et de la partie de la configuration du serveur vpn qui consiste à mettre "push dhcp-options DNS ...". Et surtout, je suis totalement débutant en terme de DNS/Domaine..
Je fais peut-être une simple ( et bête ) erreur d'ip dans ma configuration.
En tout cas, dès que je mets en fonction Bind9, je ne peux plus resoudre aucun domaine depuis mon client ( le seul tunnelé au vpn ).
Si vous avez des pistes, je prends !
Merci d'avance.
Dernière modification par alkas (09-04-2015 06:05:45)
Hors ligne
Hors ligne
Dernière modification par alkas (31-03-2015 15:02:28)
Hors ligne
Hors ligne
Ca semble ok, non ? Il n'apparait pas l'ip virtuelle attribué au client, qui est dans le range 10.8.0.0/24.
Qu'est ce que tcp6 ?
Je remarque par contre l'utilisation du port 953 par lo, j'ai peut-être quelque chose à faire du côté d'iptables. ( qui est assez restrictif sur les INPUT et FORWARD, moins sur les OUTPUT ) )
_______
J'ai relancé bind9 et openvpn, après avoir fait les modif suivantes :
Ajout de l'ip publique du serveur dans le push de server.conf. edit : puis remplacement par l'ip en 10.8.X.X du serveur.
Ajout du range ip virtuel attribuable au client dans named.conf.options.
Et ça semble fonctionner : voici la dernière ligne de /var/log/bind/query.log :
Dernière modification par alkas (31-03-2015 23:30:11)
Hors ligne
Dernière modification par kawer (31-03-2015 22:24:05)
ThinkPad T530 - Debian - CoreBoot
Hors ligne
Dernière modification par alkas (01-04-2015 00:17:34)
Hors ligne
Dernière modification par nikau (01-04-2015 13:11:42)
Hors ligne
ThinkPad T530 - Debian - CoreBoot
Hors ligne
server.conf
kawer, quand tu dis "il faut bien faire attention que le serveur dns écoute sur 127.0.0.1 port 53" ou doit se trouver cette configuration ?
C'est celle du named.conf.options ?
Dernière modification par alkas (06-04-2015 04:13:56)
Hors ligne
Hors ligne
Hors ligne
Dans le serv.conf openvpn ( côté serveur of course ), j'ai mis une unique ligne :
edit : je n'ai rien touché au resolv.conf côté client.
Je passe le sujet en résolu. Si je peux faire un tuto / aider à sa rédaction, à ce sujet, n'hésitez pas à me faire signe.
Merci pour vote aide !
Dernière modification par alkas (09-04-2015 06:04:36)
Hors ligne
Hors ligne
Hors ligne
Dernière modification par kawer (18-04-2015 16:24:09)
ThinkPad T530 - Debian - CoreBoot
Hors ligne
Donc j'avais raison, push <<"redirect-gateway def1 bypass-dhcp" indique qu'il faut router les requêtes dns ainsi : client -> vpn -> dns -> vpn -> client>> veut dire que le vpn interroge un dns externe tournant sur je ne sais pas quoi au lieu d'un serveurDNSlocal. Désolé de ne pas avoir été explicite au point que tu comprenne d'un seul coup.
pas seulement les requêtes dns mais tout le traffic du client vers le vpn.. on le savais, par contre c'est l'option
." qui n'était pas clair.
Dernière modification par nikau (18-04-2015 18:09:53)
Hors ligne
Dernière modification par kawer (18-04-2015 18:12:07)
ThinkPad T530 - Debian - CoreBoot
Hors ligne
, tout le traffic sur le client ne sera pas routé et passera par la connexion internet standard, il suffit de vérifer route -n sur le client, alors forcément les dns sont concernées aussi par le routage.
mais pour l'option push
, je ne sais pas exactement, il faudrait que j'installe bind9 sur côté serveur pour bien comprendre son rôle.
je viens de changer l'option push "dhcp-option DNS..." et cela ne modifie aucunement resolv.conf (côté serveur) alors je ne sais pas pour l'instant ou cela modifie.
Dernière modification par nikau (18-04-2015 18:22:31)
Hors ligne
ThinkPad T530 - Debian - CoreBoot
Hors ligne
Hors ligne
logiquement il dit à openvpn d'aller piocher dans le resolv.conf pour les requêtes vpn, c'est une manière de bypass sur les informations auquel openvpn n'écoute pas puisqu'il indique juste à la table de routage de d'aller router toutes les connections entre client > openvpnserver > tun0 > <interface_internet> dns extérieur > <interface_internet> > tun0 ... Donc en clair cette option vas avec "redirect-gateway def1 bypass-dhcp" et qui permet de choisir entre le dns local et le dns extérieur.
Si je ne me trompe pas car j'ai juste survolé openvpn, alors j'ai raison et en ce cas laisser "push "dhcp-option DNS x.x.x.x" feras que le serveuropenvpn ira fouiner dans le resolv.conf au lieux de bypass dhcp et donc l'interface internet et sa expliquerais pourquoi 127.0.0.1 peu ne pas fonctionner. ::)
La réponse est là. Encore faut-il comprendre ma logique informatique. Je ne peu pas faire mieux
ThinkPad T530 - Debian - CoreBoot
Hors ligne
kawer a écrit :logiquement il dit à openvpn d'aller piocher dans le resolv.conf pour les requêtes vpn, c'est une manière de bypass sur les informations auquel openvpn n'écoute pas puisqu'il indique juste à la table de routage de d'aller router toutes les connections entre client > openvpnserver > tun0 > <interface_internet> dns extérieur > <interface_internet> > tun0 ... Donc en clair cette option vas avec "redirect-gateway def1 bypass-dhcp" et qui permet de choisir entre le dns local et le dns extérieur.
Si je ne me trompe pas car j'ai juste survolé openvpn, alors j'ai raison et en ce cas laisser "push "dhcp-option DNS x.x.x.x" feras que le serveuropenvpn ira fouiner dans le resolv.conf au lieux de bypass dhcp et donc l'interface internet et sa expliquerais pourquoi 127.0.0.1 peu ne pas fonctionner. ::)
La réponse est là. Encore faut-il comprendre ma logique informatique. Je ne peu pas faire mieux
Pour faire mieux, il ne faut pas survoler openvpn mais l'étudier plus précisément. Les lecteurs attendent des réponses formelles et non des suppositions qui deviennent des affirmations, l'option redirect-gateway def1 s'applique au routage vis à vis du client, dès que j'aurais la réponse exact pour dhcp-option DNS je reviendrais compléter. bonne journée à tous.
Hors ligne
Pages : 1