Forum général.général Routage unique pour un accès indifféremment en interne et externe ?

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
3
12
fév.
2025

Bonjour,

Je me pose la question du routage réseau pour accéder à un service hébergé chez moi et auquel je souhaite pouvoir accéder indifféremment à la maison et à distance.

Aujourd'hui :

  • si je suis chez moi, j'accède au service https://service.local
  • si je suis à distance, j'accède au service via https://service.monnomdedomaine.com (routage via un enregistrement DNS sur mon nom de domaine qui pointe sur l'IP de ma box internet + ouverture d'un port spécifique)

Je pourrais faire en sorte de toujours accéder à https://service.mondomaine.com, mais cela signifie :

  • soit que tout le trafic passe par internet (ie quand je suis en local, mes requêtes sortent puis "re-rentrent" - et ça ne marche plus si la connexion internet est inactive)
  • soit que je fais une configuration dans mon /etc/hosts pour lui dire "service.mondomaine.com est sur 192.168.1.234" (et dans ce cas, quand je suis à distance, ça ne fonctionne plus)

J'ai peu de doute sur le fait que l'on puisse faire en sorte que le routage soit fait localement quand je suis dans le réseau local et par internet lorsque je suis à distance, mais je ne suis pas certain de savoir comment faire / quelle serait la bonne solution.

Faut-il un serveur DNS local ? Y-a-t-il une solution "plus simple" ? Avez-vous des idées ?

Merci pour vos retours

  • # Une piste

    Posté par  . Évalué à 4 (+2/-0).

    Dans ce lien sur le routeur/firewall OPNsense, cela parle d'activer le NAT reflection.
    Je suppose que ta box n'a pas ce genre d'option. Il faudrait alors rajouter une machine servant de routeur avec OPNsense entre ta box et ton réseau local. Cela complexifie le réseau. Pour ma part, j'ai cette architecture, car je me sers d'OPNsense pour du vpn site à site sous wireguard.

    • [^] # Re: Une piste

      Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

      Merci pour la piste ; je voudrais éviter d'intercaler une machine (je n'ai pas d'utilité d'un OPNSens …)

      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • # NAT hairpinning

    Posté par  (site web personnel) . Évalué à 6 (+5/-0).

    Le mot-clé c’est le NAT Hairpinning : https://en.wikipedia.org/wiki/Network_address_translation#NAT_hairpinning

    Pas trop d’autres pistes là comme ça…

  • # DNS

    Posté par  (site web personnel) . Évalué à 3 (+2/-0).

    Oui un serveur DNS local c'est une bonne idée. C'est pas très compliqué à mettre en place surtout pour quelques enregistrements et tu trouveras plein de docs sur le sujet.

    Il faudrait configurer les machines de ton réseau pour qu'elles s'adresse à ton serveur DNS local - via la conf du serveur DHCP de ton réseau. De cette manière, celui-ci fera les résolutions sur ton domaine en répondant des adresses privées de ton réseau pour que tu puisses joindre tes services sur leur IP privée et fera suivre aux DNS forwarders (ceux de ton FAI, Quad9, Google, ce que tu veux) définis dans ton serveur pour tous les domaines autre que celui (ou ceux) gérés par ton serveur.

    C'est assez transparent, si ça te saoule ou si ça dysfonctionne tu peux facilement revenir en arrière en changeant la conf du DHCP pour revenir sur tes DNS actuels et passer outre ton DNS local.

    There is no spoon...

    • [^] # Re: DNS

      Posté par  . Évalué à 8 (+5/-0).

      Split DNS ou DNS View

      le meme domaine est géré par un DNS chez toi, repliqué sur un DNS internet.

      Quand tu es chez toi est que tu demande service.domaine.tld => renvoi sur l'IP interne
      quand tu es dehors, service.domaine.tld => renvoie l'IP publique

      ca peut aussi etre le DNS externe (celui de ton registrar, mais il faut alors qu'il gere les "view" pour te fournir les IPs internes quand celle-ci existe

      • [^] # Re: DNS

        Posté par  (site web personnel) . Évalué à 3 (+2/-0).

        Oui alors là, c'est sûr ça fonctionne, mais c'est plus la même limonade ! C'est plus complexe. Ça fait intervenir des concepts plus abstraits et plus difficiles à debugger pour quelqu'un qui semble néophyte sur le sujet.

        C'est à mon avis plus simple de s'en tenir - au moins au début le temps de bien piger comment ça fonctionne - à des enregistrements externes sur le DNS public du registar et des enregistrements internes sur un DNS privé local.

        Mais c'est sûr que pour en avoir mis en place au boulot, les vues avec Bind c'est top, mais mon besoin n'était pas le même non plus. ;)

        There is no spoon...

      • [^] # Re: DNS

        Posté par  . Évalué à 3 (+1/-0). Dernière modification le 13 février 2025 à 23:26.

        Un unbound ou dnsmasq est suffisant s'il s'agit "juste" de fournir une IP locale pour quelques services. Et pour le coup ça s'installe et ça se configure très facilement, dans les deux cas il faut juste dire quel est le DNS upstream et quels records DNS doivent être remplacés. Au vu de la question, l'OP a déjà des serveurs en local, et il suffit alors de changer le serveur DNS annoncé par la box si c'est possible, ou fournir son serveur DHCP dans le cas contraire (via pihole, opnsense/pfsense, openwrt, ou soi-même avec isc-dhcp-server ou son successeur kea-dhcp) et couper celui de la box.

        Par contre, il faut éviter d'utiliser .local pour un nom de domaine interne. C'est un coup à s'attirer des maux de têtes car ça risque d'entrer en conflit avec mDNS (avahi, bonjour, zeroconf, uPnP, etc, voir RFC 6762). Il vaut mieux utiliser soit le nouvellement introduit .internal, soit un sous-domaine d'un nom de domaine enregistré par tes soins.

        • [^] # Re: DNS

          Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 14 février 2025 à 00:07.

          J'ai mis .local car j'ai des trucs en auto découverte locale justement oui. Mais l'objectif c'est de remplacer cet usage interne par qqchose de générique.

          #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

          • [^] # Re: DNS

            Posté par  . Évalué à 3 (+1/-0). Dernière modification le 14 février 2025 à 11:49.

            Ben tu auras toujours .local dans ce cas, c'est dans la RFC. Mais même sans mDNS ta box va attribuer un nom DNS à la plupart de tes équipements locaux grâce à la magie de DHCP: si un client définit l'option 12 (client host name) la box va ajouter un record DNS avec ce nom.

            Donc si ta box a comme zone DNS bouquetin.internal et que ton imprimante (configurée en DHCP) a comme hostname "printer", tu auras typiquement accès à printer.bouquetin.internal. De même l'imprimante va sans doute être disponible via printer.local via mDNS (càd, sous Linux, via Avahi). Tu vas donc avoir deux enregistrements concurrents.

            Maintenant, si tu as des records en plus dans ta zone DNS locale ça peut poser souci, ou si pour une raison ou pour une autre les deux hosts ne sont pas les même… Bref, il vaut mieux éviter. Après, chacun est maître en sa demeure.

      • [^] # Re: DNS

        Posté par  (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 14 février 2025 à 13:42.

        le même domaine est géré par un DNS chez toi, répliqué sur un DNS internet

        c'est tout de même ballot qu'il n'y ait pas de DNS local/forward dans la freebox pour les cas simples :/ ça simplifierait tout de même la gestion des quelques exceptions de services accessibles dans le LAN et potentiellement accessibles d'Internet (déclaré dans DNS externe public).

        Au sein de notre fablab, entre la freebox et le LAN on a ajouté un pfSense (qui fait du DNS forward pour ce qui n'est pas hébergé en LAN) ; ça complique un peu l'infrastructure, et ça ajoute quelques possibilités (gestion des certificats let's encrypt, haproxy qui gère le SNI pour fournir le bon certificat HTTPS et routage vers le bon serveur du LAN, filtrage…

    • [^] # Adguard

      Posté par  . Évalué à 1 (+0/-0).

      adguard peut être l'occasion de faire d'une pierre deux coups, c'est facile à installer avec docker. Il y a une belle interface, ça peut aussi faire du contrôle parental.

      Pour les redirections locales il y a deux façons de le faire, moi j'ai utilisé des rewrite si je me rappelle bien, c'était plus propre dans les logs.

  • # IPv6

    Posté par  (site web personnel) . Évalué à 6 (+3/-0).

    Il existe au moins trois solutions pour accéder avec un nom public à un service situé dans le même réseau local que toi. Deux compliquées :

    • mettre en place un double NAT ;
    • mettre en place des vues DNS.

    Et une simple : faire de l'IPv6. Pas d'adresse IP privées, pas de NAT, pas de problème.

  • # Précisions

    Posté par  . Évalué à 4 (+3/-0).

    quand je suis en local, mes requêtes sortent puis "re-rentrent"

    Ce n’est pas tout à fait vrai, sans le sens où les paquets ne quitteront par le routeur.

    et ça ne marche plus si la connexion internet est inactive

    Ça, c’est exact, par contre.

Envoyer un commentaire

Suivre le flux des commentaires

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