Bonjour,
 
Je suis en train de me prendre la tête sur un truck sans savoir si c'est possible, je m'explique:
 
Il y a deux réseaux A et B séparé par un Firewall
Les utilisateurs du réseau A se connectaient sur une machine B' du réseau B
la machine B' est maintenant dans le réseau A
 
Je voudrais que mes utilisateurs puissent se connecter à la machine B' avec l'adresse quel avait quand elle était dans le réseau B
 
 
J'ai fait une règle de NAT sur le firewall:
 
Origine      Destination       Port_dest        Translaté          port_transl
Any       B' dans réseauB        Any       B' dans réseau A        Any
 
 
Mais ça ne fonctionne pas
 
 

Faudrait préciser quel firewall tu utilises (Juniper, CISCO, machine sous linux ...) pour plus d'aide. Ce que tu cherches à faire s'appelle du NAT statique, c'est souvent simple à mettre oeuvre ... et bien documenté

Le titre de ton sujet est un peu en contradiction avec le contenu de ton message.
 
Ça serait effectivement pas mal de dire avec quel firewall.
 
Je pense qu'un simple NAT 1:1 pourrait faire l'affaire.
 
Petite question pourquoi vouloir un NAT ?

C'est un netasq en version 8.1
 
J'ai trois docs différentes et je n'y arrive pas, alors sois je ne comprend pas leurs logique ou ça ne marche pas ^^  
 
pourquoi du NAT:
C'est temporaire le temps de mettre tous les clients à jour
 
Pour le titre je ne trouvais pas ce qui pouvait convenir car au final la requete des clients du réseau A doit allez jusq'au firewall pour revenir dans le réseau A sur le serveur B' (donc on reste dans le même réseau)

Ptet en doublant la règle en inversant origine et destination?

 
Je ne comprend pas.
 
Tu a un client A qui se trouve dans le réseau A et un client B qui se trouve dans le réseau B ou pas ?
 
En gros
 
Client A = 192.168.1.1/24
Client B = 192.168.2.1/24
 
Chacun connecté à une patte différente de ton FW.
 
J'ai bon ?

Papy u235 avec ses kilomètre en réseau va donner quelques conseils avant de se désintégrer.
 
Utiliser l'adresse IP d'une interface réseau comme identifiant d'une machine n'est pas une bonne idée. Et vouloir faire des acrobaties d'adressage par un NAT pour essayer de résoudre les problèmes occasionnés par l'utilisation d'une adresse IP comme identifiant est une idée encore plus mauvaise. Le NAT est toujours la plus moisie des "solutions" à des besoins de connectivité.
 
Dans ton cas, commence par donner un identifiant (FQDN) à ta machine, et utilise une archi DNS propre pour faire la colle entre l'identifiant (fixe dans le temps) et l'adresse IP (qui peut changer dans le temps). Les utilisateurs ne doivent connaitre que l'identifiant.
 
Mettre en place un DNS c'est un effort à faire au départ, mais tu me remercieras à terme. Et tes utilisateurs aussi.

C'est faire des plans sur la comète: aussi bien il y a des applications qui travaillent directement avec l'IP et on lui a demandé de mettre en place le NAT pour pas avoir à toucher aux applications ni à leurs paramètres

 
Oui mais le client B va bientôt se retrouver dans le réseaux A et aura une adresse expl  192.168.1.2/24
je veut que le client A envoi ça requête sur 192.168.2.1 et que celle-ci aille sur 192.168.1.2
 
 
 

 
le client A utilise déjà le FQDN du client B pour s'y connecter mais je veut faire face aux utilisateurs itinérants qui laissent leurs pcs portables en veille prolongé, leur cache DNS me posera problème.
 
Le NAT est une solution temporaire mise en place afin de rendre ce changement totalement transparent.
 
 

Si j'ai bien compris il y a:
Un réseau A avec un routeur donnant accès au Wan et passerelle par défaut pour le LAN A
Un réseau B avec un routeur donnant accès au Wan et passerelle par défaut pour le LAN B
Un routeur entre les deux réseaux  
 
Si le trafic n'est pas bloqué par le firewall et le NAT effectif, il reste le problème des passerelles par défaut et des routes statiques.
 
Un schéma réseau permet de mettre rapidement en évidence les cheminements possibles.

Dans ce cas fallait anticiper en diminuant le TTL de l'enregistrement DNS
Il a quelle valeur aujourd'hui ?

ouais enfin les machines en veille prolongée, le cache sera surement vidé depuis le temps ...

Perso, j'irai plus loin dans la réflexion.
Pourquoi avoir deux réseaux séparés par un parefeu ?
Pourquoi passer un serveur d'un réseau à l'autre ?

 
C'est pas faux ^^ il dit est à 24h certainement
 
 

 
Ne te prend pas la tête avec ça car la présentation que je vous ai faite est fictive mais représente bien mon problème de NAT
 
 
 
Je vais modifier le TTL DNS

 
C'est bien connu que les applications qui travaillent directement avec l'IP (et/ou avec les numéros de port TCP/UDP dans le flux applicatif) sont ravies avec un NAT/firewall. J'espère que les développeurs de ces fabuleuses applications ont prévu l'ALG correspondante pour le NETASQ sinon l'bebech risque une calvitie précoce.

 
Je vois pas le problème avec du NAT statique. Je maintiens des applications qui travaillent souvent avec des IPs et des configs réseaux avec du NAT statique dans le cadre de VPNs, donc ça m'intéresse si j'ai loupé un épisode.

 
Si le Netasq est pas codé avec les pieds, pour un NAT statique l'ALG n'est pas nécessaire pour faire le mapping de ports TCP/UDP, par contre à moins que je vieillisse trop vite l'ALG reste nécessaire pour ouvrir les règles de sécurité adhoc vu que les deux machines sont sur deux pattes de niveau de sécu différent ? ou alors il faut au minimum ouvrir manuellement une règle pour une plage de ports. A moins que le firewall ouvre un "permit ip source dest" automatiquement avec le NAT statique, ce qui serait violent pour un firewall.
 
Si je devais trouver une raison à la louche pourquoi ca n'a pas fonctionné pour bebech, c'est qu'il a oublié des règles de flux pour la machine qu'il a déplacé. Ca peut devenir compliqué, par expérience j'ai arreté non seulement à cause des contraintes mais aussi parceque ca encourage les mauvaises pratiques. Si ca fonctionne dans ton réseau so far so good, perso je l'ai interdit sur le réseau interne. Suffit d'expliquer pourquoi à tout le monde, développeurs, sysadmins, etc.

Pas besoin d'alg tant qu'il n'y a pas de discussion port/adresse IP au sein même du protocole et c'est tout. Un ALG entre dans le protocole pour inspecter et récupérer les infos nécessaires pour autoriser le flux dans le cadre d'un FW ou faire la translation si nécessaire. On ne parle pas de niveau de sécu. Les contraintes sont justes celle-là. Après si on veut aller plus loin, certains ALG permettent de valider le déroulement protocolaire et de valider que c'est le protocole désiré qui tourne sur tel port

Quand philippe06 parle que les applications travaillent avec des adresse IP directement c'est plus au niveau de la configuration de l'applciation elle même où il n'y aurait pas possibilité de rentrer un fqdn