Bonjour,
Le 09/04/2020 à 10:35, Pierrick CHOVELON a écrit :
- Ajouter un sous-domaine en interne pour accéder à ces applications ->
mais gestion de deux certificats côté appli
- Récupérer les infos sur le DNS client avec une délégation -> mais se
pose le problème du NAT
ça parait être le plus simple.
Dans le cas où vous avez un NAT entre vous, il faudrait que le serveur
faisant autorité côté client vous renvoie des enregistrements adaptés
(depuis une zone différenciée du même domaine interne donc soit un
serveur dédié, soit une gestion de vue).
sinon j'ai jamais testé (et ça fait pas rêver) mais certains pare-feux
proposent un truc appelé "DNS doctoring" basé sur l'inspection DNS. En
gros, si une IP est concernée par du NAT, le pare-feu modifie la réponse
DNS :
- Cisco ASA :
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115753-dns-doctoring-asa-config.html
- Juniper SRX :
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-dns-algs.html#id-understanding-dns-and-ddns-doctoring
- Déporter la résolution DNS chez le client en utilisant un proxy web
configuré au même endroit que l'appli -> très contraignant à l'utilisation
- Rester sur la modif de notre fichier /etc/hosts à la main ... ... ...
Quitte à maintenir des entrées manuellement alors autant déclarer une
zone pour le domaine client sur un serveur faisant autorité de votre
côté (avec copie sur vos resolvers ou forward) et maintenir le mapping
pour les cas où il y a du NAT, non ?
Bonne journée
--
Jérôme BERTHIER
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
