Forum Linux.général Configuration DNS et domaine

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
6
sept.
2018

Bonjour,

Je travaille sur un projet à base de Raspberry Pi sur lequel j'héberge un site WEB accessible pour des smartphones qui se connectent au point d'accès WIFI de la raspberry.
Je précise que la Raspberry n'a pas d'accès internet.

Le point d'accès est défini sur la raspberry avec hostapd, et un serveur DHCP/DNS avec dnsmasq.

J'ai besoin que mon site soit accessible par un nom de domaine, comme example.local.

Le nom est bien résolu en DNS par dnsmasq, donc ça fonctionne.

La problématique est que si j'active sur le smartphone simultanément internet en 3G et le WIFI pour la raspberry le comportement est aléatoire.

Par exemple peux avoir des problèmes de navigation internet car les noms comme wikipedia.fr n'arrivent pas à être résolus par le DNS de la raspberry, ou inversement mon site example.local n'est pas accessible car le DNS internet n'arrive pas à le résoudre.

Existe-t-il des solutions pour résoudre ce problème ?

  • # soluce

    Posté par  . Évalué à 3. Dernière modification le 06 septembre 2018 à 14:24.

    La problématique est que si j'active sur le smartphone simultanément internet en 3G et le WIFI pour la raspberry le comportement est aléatoire.

    Quand tu es connecté au wifi, ton smartphone reste connecté à la 3G? (normalement quand tu switch sur wifi, android coupe auto la "data" 3G/4G/5G)

    mon site example.local n'est pas accessible car le DNS internet n'arrive pas à le résoudre.

    Tu peux suivre ce tuto : [Tuto/HowTo] Mettre en place un serveur DNS aux noms de domaines parametrable (Rogue DNS) (la section concernant dnschef uniquement, tu n'as pas besoin de bind9)

    • [^] # Re: soluce

      Posté par  . Évalué à 1.

      Le WIFI sur lequel je me connecte qui est sur la raspberry ne donne pas d'accès Internet. Donc en théorie Android devrait pouvoir garder sa connectivité Internet par la data.

      Ce n'est pas un problème spécifique aux smartphones. Avec un PC je peux reproduire la même problématique :
      Le PC est connecté au réseau LAN sur lequel il y'a Internet.
      Lorsque je connecte le PC au WIFI de la raspberry, j'ai le même comportement aléatoire lorsque je ping un site Internet ou le site de la raspberry.

      Je vais jeter un coup d'oeil à la solution dnschef.

      • [^] # Re: soluce

        Posté par  . Évalué à 1.

        J'ai regardé je ne comprend pas bien à quelle problématique répond le tuto que tu as mis en lien, si tu peux détailler le cas d'utilisation.

        Une précision par rapport à mon besoin, la solution apportée doit uniquement être coté serveur. Je veux éviter de devoir paramétrer des choses coté smartphone (si la solution existe).

        • [^] # Re: soluce

          Posté par  . Évalué à 1. Dernière modification le 06 septembre 2018 à 14:48.

          J'ai regardé je ne comprend pas bien à quelle problématique répond le tuto que tu as mis en lien, si tu peux détailler le cas d'utilisation.

          Tu as dis avoir besoin que ton serveur soit joignable via un nom de domaine (très probablement pour respecter les vhost d'apache2).
          DNSChef est un rogue DNS (aussi appelé "serveur DNS menteur"). C'est a dire qu'il te permet de dire (lorsqu'un client DNS l’interroge) que www.tonSite.com se trouve à l'adresse 192.168.42.42 et ce peu importe se que les "vrai" serveur DNS répondraient.
          Donc si tu le configure "au dessus" de dnsmasq, quand tes users vont se connecter et taper www.tonSite.com dans leur navigateur, leur machine va joindre ton serveur ou toute autre IP que tu auras indiqué.
          Dans ton cas il faut configurer ton wifi pour que tes clients interrogent DNSChef et non dnsmasq.

          Ce n'est pas un problème spécifique aux smartphones. Avec un PC je peux reproduire la même problématique :

          Le pc te permet d'utiliser autant de carte réseau que tu veux, même d'en créer. A toi ensuite de gérer, via les "route" par où doivent transiter les paquets.
          Dans un shell tapes route -n pour les afficher.

          Le WIFI sur lequel je me connecte qui est sur la raspberry ne donne pas d'accès Internet. Donc en théorie Android devrait pouvoir garder sa connectivité Internet par la data.

          Ce n'est pas se que j'ai observé sur les machines connectées à mon réseau. (on en discute en ce moment ici).

          • [^] # Re: soluce

            Posté par  . Évalué à 1.

            Tu as dis avoir besoin que ton serveur soit joignable via un nom de domaine (très probablement pour respecter les vhost d'apache2).

            Oui en partie et également pour faire du HTTPS.

            DNSChef est un rogue DNS (aussi appelé "serveur DNS menteur"). C'est a dire qu'il te permet de dire (lorsqu'un client DNS l’interroge) que www.tonSite.com se trouve à l'adresse 192.168.42.42 et ce peu importe se que les "vrai" serveur DNS répondraient.
            Donc si tu le configure "au dessus" de dnsmasq, quand tes users vont se connecter et taper www.tonSite.com dans leur navigateur, leur machine va joindre ton serveur ou toute autre IP que tu auras indiqué.
            Dans ton cas il faut configurer ton wifi pour que tes clients interrogent DNSChef et non dnsmasq.

            Je pense que ce n'est pas représentatif de mon problème.
            Lorsque j'ai deux connexions :
            - Connexion Internet (data ou LAN)
            - Connexion Raspberry (avec le WIFI, qui ne donne pas Internet)
            Le soucis est que lorsque j’interroge un domaine, le smartphone / PC tente de résoudre le domaine en interrogeant soit le DNS Internet (ce qui fonctionne pour les domaines internet, mais échoue pour le domaine example.local), soit le DNS de la raspberry (qui échoue pour les domaines internet).
            Et le comportement aléatoire est due au fait qu'il interroge soit l'un, soit l'autre (mais pas les deux, ou l'un pour mes adresse locales et l'autre pour les adresses internet).

            Ce n'est pas se que j'ai observé sur les machines connectées à mon réseau. (on en discute en ce moment ici).

            Je viens de tester, si je connecte la data, puis le WIFI (wifi qui ne donne pas de passerelle), j'ai bien accès à Internet.
            Par contre je ne peut pas accéder au site example.local (à cause du problème de DNS).

            Je ne sais pas si c'est clair ?

            • [^] # Re: soluce

              Posté par  . Évalué à 1. Dernière modification le 06 septembre 2018 à 16:10.

              Sur certains routeurs (BBOX de Proximus entre autre), tu peux pusher les serveurs DNS primaire et secondaire aux clients.
              Tu dois donc pouvoir, en théorie, depuis le wifi de ton RPI faire pareil. Et donc pusher le primaire vers dnschef sur ton RPI et le secondaire vers un publique.
              Ainsi :

              • quand un client interroge www.tonSite.com, il est renvoyé par DNSChef sur ton serveur

              • quand un client interroge www.google.com, il reçoit un timeout de DNSChef et interroge le serveur DNS secondaire.

              Par contre ce n'est pas noël : des bugs peuvent apparaitre (du genre parfois le client DNS tentera de résoudre www.tonSite.com depuis ton DNS secondaire)

  • # Cas du VPN

    Posté par  . Évalué à 1.

    De manière plus générique, on peut retrouver ce problème dans le cas du VPN :
    - Un PC connecté au LAN avec internet
    - On se connecte en VPN à un serveur qui à un fourni un DNS pour résoudre les IP des machines mais n'a pas de connectivité Internet
    Dans ce cas comment le PC sais avec quel DNS il doit résoudre les domaines (internet VS hostname des machines) ?

    • [^] # Re: Cas du VPN

      Posté par  . Évalué à 1.

      Avec OpenVPN c'est ultra simple :
      ça se résume a ajouter deux push nameserver dans le fichier de conf du serveur, un push vers le rogue DNS isolé du net et un push vers le DNS de google.

      • [^] # Re: Cas du VPN

        Posté par  . Évalué à 1. Dernière modification le 07 septembre 2018 à 16:23.

        Le fait est que si je ping une machine du réseau VPN "machine_1.local" et que mon OS cherche à résoudre ce nom avec les DNS de ma connexion Internet (ce qui est le cas), cela échoue.

        • [^] # Re: Cas du VPN

          Posté par  . Évalué à 1.

          Si tu as vraiment testé et que la situation est avérée, alors on peut en déduire qu'OpenVPN ne push que des DNS primaire et qu'il réparti ensuite les requêtes dessus.
          La question étant "Peut-il injecter un DNS secondaire ou uniquement des primaires". (google à plus tôt l'air d'indiquer que c'est le second cas de figure, rajoutant un énième défaut a ce logiciel)

  • # pas de multi-dns sans configuration poste client

    Posté par  (site web personnel) . Évalué à 2.

    Tout est résumé dans le titre mais si effectivement un android (ou tout autre machine) peut avoir deux connections réseau actives à un instant T il ne sait pas interroger deux serveurs DNS distincts.

    La seule solution a ma connaissance est d'installer un serveur DNS à la main sur le client et de le configurer pour rooter la zone .local sur le dns du raspberry et le reste sur la connection 3G, ce qui est pas simple sur un PC et encore moins sur un android qui "passerait dans le coin".

    Je pense qu'il faut regarder pour un fonctionnement type "Wifi Direct", avec configuration ZeroConf (pas de DHCP/DNS) et diffuser l'adresse du "service web" via un DNS-SD/mDNS (type bonjour)

  • # configuration zeroconf ?

    Posté par  . Évalué à 2.

    Ce que tu essai de faire ressemble de loin à ce que fait recalbox (toujours sur raspberry pi).

    A ma connaissance recalbox n'utilise pas le protocole DNS mais le protocole zeroconf pour signaler la présence d'un serveur example.local (attention ici le .local a un sens).

    Pour ma part, en tant qu'utilisateur, ça marche très bien quand j'accède au raspberry depuis mon PC mais pas depuis mon téléphone Android (je n'ai pas cherché à résoudre le problème.

    Je disais de loin car dans le cas dont je parle, le raspberry n'est pas le point d'accès mais un simple client connecté à celui-ci.

    Les vrais naviguent en -42

  • # Pas facile

    Posté par  . Évalué à 2.

    Avoir une résolution DNS relative à un réseau et non globale a toujours été un problème car le DNS n'a pas été fait pour ça à la base. Toutes les solutions de DNS « privés » ou en split-view sont des gros hacks qui fonctionnent vaguement mais butent toujours à la conception même d'Internet : le DNS a une seule arborescence globale, et tout le monde devrait avoir un adressage global dans l'Internet pour ne pas avoir à faire des résolutions DNS relatives. Ce sont des fondements essentiels d'Internet qui sont cassés par le NAT et dont tout le monde espère trouver des workaround qui marchent toujours à moitié mal depuis 20 ans. Peut-être qu'un jour certaines personnes décideront de faire la bonne chose.

    Une description un peu plus formelle du genre de problème auquel tu fais face : https://tools.ietf.org/html/rfc6418

    Si tu veux vraiment du DNS sur un réseau isolé, le mieux est mDNS comme cité plus haut. Ça marche à peu près partout (c'est standard https://tools.ietf.org/html/rfc6762 et implémenté de base dans pleins d'endroits) sauf sur les OS qui refusent le réseau décentralisé, et il se trouve que ce sont les majoritaires, Windows et Android. C'est malheureux mais je ne connais pas d'autre solution qui soit standard et pas trop crade.

    Étrangement, il y a quelques jours j'ai vu un autre bug volontairement non-résolu dans Chromium, autre produit anti-décentralisation, qui casse volontairement les déploiements IPv6 isolés : https://bugs.chromium.org/p/chromium/issues/detail?id=530482
    On comprend mieux cet état de fait quand on voit l'état d'esprit des devs Google : « can you explain more about why your configuration does not have a IPv6 global route? ». Ça fait peur de voir ce genre de commentaire par quelqu'un qui est censé implémenter et connaître IPv6 (il site plus haut les adresses site-locales, dépréciées depuis 15 ans…). Voir également le test de connectivité avec les adresses de Google hardcodées dans Chromium…

    Bref, Google et consorts pèsent de tout leur poids politique pour casser les déploiements non-centralisés (ça me rappelle https://bugzilla.mozilla.org/show_bug.cgi?id=14328 où les devs qui déconseillent la résolution chez Mozilla viennent de… Google), et il est difficile de trouver des solutions dans ce cas-là.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.