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 Axone . É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 LeBouquetin (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 Sacha Trémoureux (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…
[^] # Re: NAT hairpinning
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Ça a l'air d'être exactement ce que je veux faire …
Je creuse car même problématique ici : https://forum.yunohost.org/t/freebox-v6-et-hairpinning/9034/9
ça n'a pas l'air "plug'n'play" …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# DNS
Posté par madhatter (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 NeoX . É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 madhatter (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 nud . É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 LeBouquetin (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 nud . É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 viaprinter.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 BAud (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 14 février 2025 à 13:42.
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 Craig77 . É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 🚲 Tanguy Ortolo (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 :
Et une simple : faire de l'IPv6. Pas d'adresse IP privées, pas de NAT, pas de problème.
# Précisions
Posté par ocroquette . Évalué à 4 (+3/-0).
Ce n’est pas tout à fait vrai, sans le sens où les paquets ne quitteront par le routeur.
Ç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.