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 : aucune
1
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é à 3 (+1/-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é à 3 (+2/-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é à 1 (+0/-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é à 4 (+1/-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

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.