Si on doit passer par un dispositif NAT ou un pare-feu “à état” (stateful), UDP doit passer mais il y a des précautions à prendre : générer du trafic régulièrement (par exemple toutes les 30 secondes minimum) pour maintenir l’état de connexion dans le NAT ou le pare-feu, car les délais d’expiration pour absence de trafic sont plus courts en UDP qu’en TCP. Ce n’est pas spécifique à UDP mais à tous les protocoles “non connectés”. Cela peut être prévu dans l’implémentation du VPN via une fonction “keepalive”.[/quote]
Sinon je présume que la connexion saute?
Quelle est la différence entre Tun et Tap?
Sinon, j’ai fait un essai en installant dans ma VM (W7) l’interface du VPN et en changeant le mode de connexion internet entre l’invité et l’hôte de NAT à accès par pont. Donc ça marche, je peux avoir une connexion normale côté hôte et une connexion VPN sur la VM, reste à voir si le problème ne revient pas côté VM lorsque je vais réactiver l’IPv6 sur la Freebox et la désactiver uniquement sur la VM…
Ce n’est pas aussi net. Si la “connexion” UDP est effacée de la table d’état du pare-feu ou NAT, il y a deux effets possibles selon quel côté envoie le prochain paquet :
Sans règle explicite, le dispositif ne saura pas quoi faire des paquets émis par le serveur VPN situé à l’extérieur et les jettera au lieu de les transmettre au client VPN situé à l’intérieur.
Il recréera une entrée pour un paquet émis par le client VPN, mais peut-être avec un port source différent de la connexion initiale dans le cas d’un NAT, qui ne sera pas forcément reconnu par le serveur comme faisant partie de la connexion initiale. Mais cela dépend de la spécification ou de l’implémentation du serveur VPN.
Dans le cas d’un pare-feu sans NAT, on peut éviter ce problème en autorisant explicitement les paquets provenant de l’adresse IP et du port du serveur VPN avec une règle.
Tun crée une liaison de type tunnel IP (v4 ou v6). Il n’y a pas de couche de liaison, pas d’adresse MAC, pas de protocole de résolution d’adresse de type ARP… Elle ne peut être que routée.
Tap crée une liaison de type ethernet. Elle permet de transporter n’importe quel protocole réseau compatible avec ethernet, pas seulement IP (ex : PPPoE, IPX, NetBEUI, Appletalk…) et peut être pontée ou routée.
Ce n’est pas aussi net. Si la “connexion” UDP est effacée de la table d’état du pare-feu ou NAT, il y a deux effets possibles selon quel côté envoie le prochain paquet :
Sans règle explicite, le dispositif ne saura pas quoi faire des paquets émis par le serveur VPN situé à l’extérieur et les jettera au lieu de les transmettre au client VPN situé à l’intérieur.
Il recréera une entrée pour un paquet émis par le client VPN, mais peut-être avec un port source différent de la connexion initiale dans le cas d’un NAT, qui ne sera pas forcément reconnu par le serveur comme faisant partie de la connexion initiale. Mais cela dépend de la spécification ou de l’implémentation du serveur VPN.
Dans le cas d’un pare-feu sans NAT, on peut éviter ce problème en autorisant explicitement les paquets provenant de l’adresse IP et du port du serveur VPN avec une règle.
Tun crée une liaison de type tunnel IP (v4 ou v6). Il n’y a pas de couche de liaison, pas d’adresse MAC, pas de protocole de résolution d’adresse de type ARP… Elle ne peut être que routée.
Tap crée une liaison de type ethernet. Elle permet de transporter n’importe quel protocole réseau compatible avec ethernet, pas seulement IP (ex : PPPoE, IPX, NetBEUI, Appletalk…) et peut être pontée ou routée.[/quote]
Bon ben il me reste plus qu’à réétudier tout ça
Merci en tous cas pour toute cette aide et tous ces éclaircissements.
J’ai une autre question, qui n’est pas complètement en rapport avec le sujet mais elle se rattache aux serveurs publiques DNS.
Quel interêt peut-on avoir à changer ses DNS publiques fournis par le FAI contre ceux de Google par exemple ou OpenDNS, hormis le fait que le FAI n’aura plus accès à notre historique de requêtes DNS et ne pourra plus espionner notre activité internet?
Y a t-il un gain en rapidité? (par rapport à la vitesse de résolution des requêtes je parle, j’ai compris que le changement de DNS n’améliore pas l’up-down ni le ping de la connexion).
Mais alors c’est Google ou OpenDNS qui connaîtra ton historique (et en fera bon usage, n’en doute pas). Pour éviter cela, tu peux utiliser ton propre cache récursif qui va directement interroger les serveurs DNS faisant autorité pour les domaines cibles. Mais alors ce sont ces serveurs qui sauront quelles requêtes DNS tu fais. C’est probablement un moindre mal dans la mesure où ces requêtes DNS sont probablement un préalable à des communications avec des machines de ces mêmes domaines.
Quant au FAI, à moins de passer par un VPN, il pourra toujours voir ton trafic DNS passer à travers ses routeurs même s’il ne se fait pas avec ses propres serveurs. Et si tu passes par un VPN, l’opérateur du VPN verra ton trafic DNS, quelle que soit sa destination.
Choisis ton espion, camarade. De qui te méfies-tu le plus ?
Ah, si, un éventuel léger intérêt de ne pas utiliser les DNS de son FAI serait de contourner la censure de certains domaines ordonnée par les z-autorités judiciaire ou administrative aux FAI grand public.
Réponse de Normand : ça dépend. De la latence avec le serveur, du contenu de son cache, de sa rapidité à traiter une requête…
Les serveurs DNS de Google sont plus “loin” de toi que ceux de ton FAI et ont donc une latence IP supérieure, mais cela peut être compensé par un contenu du cache plus important ou une plus grande rapidité à trouver la réponse, et au final le délai de réponse peut être plus court. Ou pas. Selon ton type d’utilisation, la différence visible sera peut-être négligeable.
Oui ça c’est sûr, mais apparemment OpenDNS ne conserve les historiques que 2 jours pour les clients qui n’ont pas de compte payant chez eux, quant à ma suggestion de Google elle et purement rhétorique… Ils ont juste réputation d’avoir les serveurs DNS les plus rapides au niveau résolution des requêtes (sans doute dû au cache…), mais ils ne s’inviteront pas sur ma machine
Par contre pour OpenDNS j’avais trouvé quelque chose sur le net (article ou forum, je retrouve plus) qui remettait en cause leur côté “Open” justement…
Sinon utiliser son propre cache récursif comme tu le suggères implique de conserver ce cache sur sa machine c’est bien ça? Et si t’as un tuto sous la main je suis preneur pour un peu de lecture.
[quote=“PascalHambourg”]Quant au FAI, à moins de passer par un VPN, il pourra toujours voir ton trafic DNS passer à travers ses routeurs même s’il ne se fait pas avec ses propres serveurs. Et si tu passes par un VPN, l’opérateur du VPN verra ton trafic DNS, quelle que soit sa destination.
Choisis ton espion, camarade. De qui te méfies-tu le plus ?
Ah, si, un éventuel léger intérêt de ne pas utiliser les DNS de son FAI serait de contourner la censure de certains domaines ordonnée par les z-autorités judiciaire ou administrative aux FAI grand public.[/quote]
Moi, je me méfie de tout le monde…
Blague à part, si ta question est orientée vers les protagonistes ci-dessus (OpenVPN, Google, FAI, VPN), je dirais que je m’en fous car c’est plus un côté éducatif pour moi plutôt que des choses à cacher, mais j’aime quand même conserver le côté privé de ce que je fais, donc je dirais Google en premier.
Après si tu me poses la question directement, concrètement je n’ai aucune raison de me méfier ou de cacher au vu de ce que je fais avec un PC, si ce n’est pour ce que je fais avec le VPN mais bon là non plus rien de spécial ni de très illégal (pas de p2p, torrent, streaming ou autre…), juste accès à des sites bloqués en France .
[quote=“PascalHambourg”]Réponse de Normand : ça dépend. De la latence avec le serveur, du contenu de son cache, de sa rapidité à traiter une requête…
Les serveurs DNS de Google sont plus “loin” de toi que ceux de ton FAI et ont donc une latence IP supérieure, mais cela peut être compensé par un contenu du cache plus important ou une plus grande rapidité à trouver la réponse, et au final le délai de réponse peut être plus court. Ou pas. Selon ton type d’utilisation, la différence visible sera peut-être négligeable.
Le seul moyen de savoir, c’est de comparer.[/quote]
Les résultats de Namebench sont-ils fiables à ce sujet?
Et d’ailleurs je fais un test avec les serveurs DNS d’OpenDNS… J’ai donc rentré manuellement les IP des DNS pour passer par OpenDNS et non plus Free, mais par contre qu"est ce que viennent foutre encore les serveurs de chez Free dans ce fichier…?
[code]# Generated by NetworkManager
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 2a01:e00::2
NOTE : il se peut que le solveur libc ne prenne pas en charge plus de 3 serveurs de noms.
Les serveurs de noms listés ci-dessous peuvent ne pas être reconnus.
[quote=“SwordArMor”][quote=“GOGI”]
Sinon utiliser son propre cache récursif comme tu le suggères implique de conserver ce cache sur sa machine c’est bien ça? Et si t’as un tuto sous la main je suis preneur pour un peu de lecture.
[/quote]
J’avais écrit un truc en vitesse à ce sujet : swordarmor.fr/installer-son … ement.html
Si ce n’est pas clair et que tu as des questions, n’hésite pas [/quote]
Merci pour le tuto je suis passé par bind9 en fait…
D’ailleurs @ Pascal j’ai vu sur un autre fil qui date que tu utilisais bind9 pour tes serveurs DNS, pourrais-tu me récapituler les choses à faire impérativement pour bien configurer bind?
Pour l’instant j’en suis à avoir configuré le fichier [mono]/etc/bind/named.conf.options[/mono] en ayant ajouté ceci :
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
Puis j’ai modifié à la main le fichier [mono]/etc/resolv.conf[/mono] :
NOTE : il se peut que le solveur libc ne prenne pas en charge plus de 3 serveurs de noms.
Les serveurs de noms listés ci-dessous peuvent ne pas être reconnus.
#nameserver 2a01:e00::1 #nameserver 2620:0:ccc::2 #nameserver 2620:0:ccd::2[/code]
Et j’ai enfin fait un [mono]chattr +i /etc/resolv.conf[/mono] afin que Network-Manager ne me le modifie pas à chaque redémarrage/reconnexion.
Et enfin dans le gestionnaire de connexions j’ai passé tous les DNS des IPv4 en manuel et rentré 127.0.0.1
A l’époque ce qui m’avait fortement déplu chez OpenDNS, c’est le côté “DNS menteur”, notamment le renvoi de l’adresse IP d’un site de pub pour les noms de domaine inexistants, au lieu d’une réponse NXDOMAIN.
Ou bien sur un serveur hébergé, si tu as les moyens.
Je l’ignore, ne l’ayant jamais utilisé. Mais il semble fait pour cela.
Ils proviennent des annonces de routeur IPv6 émises par la Freebox.
BIND 9 fait le boulot mais il est un peu “riche” pour faire juste un cache récursif. Je l’utilise parce que j’ai aussi besoin de servir des zones. Il y a longtemps que je n’ai pas touché à sa configuration.
C’est mal (et sale). Il serait préférable de trouver comment configurer correctement NetworkManager, ou d’installer resolvconf pour gérer le contenu de /etc/resolv.conf.
Exact c’est bien ce que j’avais trouvé, ils avaient été vivement critiqués par la communauté pour ces “détournements”, et d’autant plus depuis qu’ils ont été rachetés par Cisco qui n’est pas du tout plebiscité par les sceptiques pour avoir justement travaillé avec la NSA entre autre… Apparemment une alternative à laquelle on retrouve pas mal de références sur le net comme substitution : OpenNIC.
Mais bon je sais pas ce que ça vaut et comme tu le disais de toute façon que ce soit chez alfa, beta ou lambda, l’historique finit par atterrir chez quelqu’un
Quid de la discussion, lorsqu’on passe par son propre serveur DNS, c’est notre machine qui résout les DNS et stocke le cache (d’ailleurs quel est le chemin du cache sous bind9?), donc théoriquement le FAI ne l’a plus on est d’accord?
Mais comme le trafic internet va quand même sortir en passant par le FAI, est-ce que celui-ci peut tout de même logguer d’une façon ou d’une autre nos requêtes même si on ne passe plus par ses DNS (par exemple l’équivalent d’un keylogger sur le transit entre la xxxbox et le destinataire de la requête qui récupèrerait les infos sous forme d’un monitoring, un log…)?
Ou bien sur un serveur hébergé, si tu as les moyens.[/quote]
Non pas forcément, ni l’utilité. Je me sers de mon PC vraiment à titre personnel, utilisation desktop… Par contre j’ai déjà posé la question plus haut pour le chemin où sont enregistrées les requêtes pour un DNS local, et quelle taille moyenne celà prend-il approximativement (bien entendu je présume que ça dépend du trafic internet que l’on effectue)? Est-il aussi possible de dédier une partition à son serveur DNS afin de l’isoler de la partition racine et du /home où bien ça n’a aucune utilité? (c’est un pc portable en même temps… J’ai également vu que l’on pouvait isoler le démon de bind9 en faisant un chroot sur /var/lib/bind pour l’emprisonner : quelle est l’utilité de cette opération?
Ils proviennent des annonces de routeur IPv6 émises par la Freebox.[/quote]
Ok, ils proviennent donc directement du fait qu’il existe une option d’activation de l’IPv6 dans l’interface de la Freebox?
Je conçois que tu ne peux pas faire un cours sur bind9 ici, ce n’est pas la vocation de la section support, je reviendrai vers toi si j’ai des questions.
C’est mal (et sale). Il serait préférable de trouver comment configurer correctement NetworkManager, ou d’installer resolvconf pour gérer le contenu de /etc/resolv.conf.[/quote]
C’est une solution temporaire, le temps de trouver la façon propre…
Il peut s’il fait du DPI, mais à mon avis il autre chose à faire. Si tu as vraiment « peur » de ton FAI, tu peux te monter un tunnel chiffré depuis une machine de ton LAN et l’utiliser comme routeur, résolveur DNS, etc. Par contre, elle devra tourner tout le temps (ou tout du moins quand tu veux accéder à Internet).
L’emplacement du cache DNS, je n’en ai strictement aucune idée. Mais ça doit prendre 20 Ko grand max.
Le chroot sert à éviter que bind9 ne puisse sortir de ce dossier (et donc lire les fichiers qui sont en dehors). As toi de voir si tu le veux ou pas.
Ils proviennent des annonces de routeur IPv6 émises par la Freebox.[/quote]
Ok, ils proviennent donc directement du fait qu’il existe une option d’activation de l’IPv6 dans l’interface de la Freebox?
[/quote]
Sans IPv6, tu aurais les serveurs en v4. Ça ne changerait pas grand chose au problème
Je conçois que tu ne peux pas faire un cours sur bind9 ici, ce n’est pas la vocation de la section support, je reviendrai vers toi si j’ai des questions.
[/quote]
Tu peux tout de même regarder datalove.swordarmor.fr/netcamp- … 151011.ogv, ça t’aidera à comprendre pas mal de chose à propos du DNS.
(c’est normal si ça prend quinze ans à arriver, ça sort de chez moi et je n’ai pas la fibre (et je n’ai pas envie de louer un serveur à l’extérieur alors que j’ai déjà de l’IP chez moi))
Comme je disais à PascalHambourg je n’ai pas peur, j’ai rien à cacher, c’est vraiment par curiosité pour comprendre comment tout ça fonctionne en fait, qu’est ce qui est public, qu’est ce qui est caché, qu’est ce que l’on voit et surtout ce que certains (l’état, les FAI, …) font dans notre dos et de notre “intimité”.
Pour le tunnel je vois pas trop comment faire, je suis juste sur mon PC portable, pas d’autre machine, et c’est ma Freebox qui me sert de routeur. Pour tourner tout le temps c’est pas un problème puisque de toute façon je ne vais sur internet que quand mon pc est allumé (en même temps je peux pas faire autrement hein ) et je ne l’ai pas éteint depuis que je l’ai acheté en 2010…
Mais je ne vois pas comment créer ce tunnel? Où bien ça sous-entendait de posséder justement une deuxième machine qui ne servirait que de routeur et aurait donc “un rôle de VPN local” si je peux dire ainsi (un peu comme la fameuse brique)?
Alors j’ai mal posé la question, en effet à la page où c’était expliqué ils parlaient de ça justement, mais je ne comprends pas pourquoi bind9 sortirait de ce dossier et irait lire quelque chose ailleurs?
[quote=“SwordArMor”]Tu peux tout de même regarder datalove.swordarmor.fr/netcamp- … 151011.ogv, ça t’aidera à comprendre pas mal de chose à propos du DNS.
(c’est normal si ça prend quinze ans à arriver, ça sort de chez moi et je n’ai pas la fibre (et je n’ai pas envie de louer un serveur à l’extérieur alors que j’ai déjà de l’IP chez moi))[/quote]
Pas grave pour la lenteur, je n’ai pas de fibre non plus mais ça marche bien, en revanche penses à mettre un certificat de sécurité sur ta page, j’ai l’invite de sécurité qui bondit à chaque fois que je visite le site
Si je ne m’abuse, le cache de BIND est en mémoire, pas sur disque (sauf éventuellement lorsqu’on l’arrête et le relance). Je doute qu’il n’occupe que 20 ko, certaines réponses font autour d’1 ko voire plus.
Le chroot est une mesure de sécurité. On découvre régulièrement des failles exploitables à distance dans BIND, comme dans tout logiciel usine à gaz.
Les DNS IPv6 de Free proviennent de l’activation de l’IPv6 dans la Freebox, oui. Mais pas seulement. Il faut aussi que la machine qui reçoit une annonce avec des adresses de DNS en tienne compte. Comme en DHCP : le client n’est pas obligé de tenir compte des DNS quie lui transmet le serveur.
Un “tunnel chiffré”, c’est juste une autre façon de dire un VPN. Ça, tu l’as déjà.
Nous avons tous “quelque chose à cacher”, qu’on l’appelle “vie privée”, “intimité”…
Ça veut dire qu’à chaque redémarrage le cache est vide et qu’il repart de 0 à chaque fois?
[quote=“PascalHambourg”]Le chroot est une mesure de sécurité. On découvre régulièrement des failles exploitables à distance dans BIND, comme dans tout logiciel usine à gaz.
Les DNS IPv6 de Free proviennent de l’activation de l’IPv6 dans la Freebox, oui. Mais pas seulement. Il faut aussi que la machine qui reçoit une annonce avec des adresses de DNS en tienne compte. Comme en DHCP : le client n’est pas obligé de tenir compte des DNS quie lui transmet le serveur.
Un “tunnel chiffré”, c’est juste une autre façon de dire un VPN. Ça, tu l’as déjà.
Nous avons tous “quelque chose à cacher”, qu’on l’appelle “vie privée”, “intimité”…[/quote]
Vu et compris l’utilité de chroot-er le démon de bind sur le wiki debian.
Sinon pour les IPv6 de Free, comment faire pour que ma machine n’en tienne pas compte par exemple? Il faut que je me penche comme tu le disais sur la config de Network-Manager? (l’histoire de chattr “sale” ci-dessus?).
Apparemment. La page de manuel de named mentionne l’option -x pour charger le cache à partir d’un fichier au lancement, mais ajoute qu’il ne faut pas l’utiliser. D’autres logiciels de cache DNS récursif ont sûrement cette fonctionnalité.
Dans l’onglet “Paramètres IPv6” de la modification de la connexion, en sélectionnant “Automatique, adresses uniquement” au lieu de “Automatique” et en spécifiant d’autres adresses de DNS, cela devrait le faire.
En effet, j’ai rien trouvé non plus qui fait mention d’un fichier log. Mais bon je ne constate pas non plus de ralentissement au chargement, au contraire je trouve que les pages se chargent en tous cas plus vite depuis que je suis passé au serveur local…
C’est ce que j’avais vu ailleurs sur un tuto, mais le souci c’est que justement chez moi je n’ai pas cette option, enfin dans le menu au lieu de [mono]Automatique, adresses uniquement[/mono] j’ai [mono]Automatique, DHCP seulement[/mono]…
Les deux options sont présentes sur ma machine, mais elle a Wheezy. Ça a peut-être changé dans Jessie, mais je n’ai pas d’installation pour vérifier. Tu peux essayer “Ignorer”, chez moi cela revient à peu près au même car l’interface reste configurée automatiquement en IPv6 par le noyau sans toucher resolv.conf.
