Forward dns zone to lan adress

jdh

A force de questions, cela devient plus clair. Mais il vous manque quelques notions essentielles.

Si on écoute le trafic réseau sur une carte ethernet,
si fait 'ping google.fr', on va trouver des paquets 'ICMP echo request' et 'ICMP reply' (de réponse) entre l'ip du PC et une ip correspondante à 'google.fr',
et … aucune trace (textuelle) de 'google.fr' !

En effet, ping, comme la totalité des commandes générant du trafic internet, converti l'adresse 'nom' en adresse 'ip' pour générer les paquets ip :
=> il n'y a que des adresses ip dans les entêtes de paquets !

Or, pour le protocole http (et https), et seulement pour ce (s) protocole(s), à l'intérieur des paquets échangés, il est copié la requête http réelle.

D'où le travail du (reverse) proxy ou du serveur web, capable d'analyser l'intérieur du paquet et d'agir selon le domaine indiqué.

Quand on cherche un hébergement web, on peut souvent lire 'serveur mutualisé' : eh bien c'est exactement ça :

plein de domaines www.XXXX pointe sur la même ip du serveur,
le serveur web (apache ou iis) analyse l'intérieur du paquet, décode le domaine recherché,
le serveur affiche, en conséquence, le 'bon' site web.

cf Christian CALECA ...

De facto, pour d'autres protocoles ... ça ne fonctionne pas ! Exemple, FTP, SMTP, ...

Mais comme vous ne parlez pas du protocole cible ...

En fait, comme bien souvent et pour d'autres, vous pensez solution avant de pensez besoin, et donc vous ignorez les conséquences de tel ou tel besoin.

chris4916

Si tes besoins sont basics et que ton fournisseur d'accès te permet d'avoir plusieurs IP, tu peux faire ça avec le load-balancer de pfSense en définissant un pool par serveur interne (qui à ne mettre qu'un serveur par pool) et un virtual server par IP externe (en configurant des virtual IP sur ton interface externe)

Bien sûr ça ne marche que pour un nombre limité d'IP.

La solution standard étant le reverse proxy, comme expliqué plus haut.

interact

Bonjour,
Je ne parle pas de protocole http(s) je parle bien de connexion tcp d'un client (une application qui construit un paquet TCP et l'envoie sur un server en LAN) sur internet qui se doit se connecter sur un serveur en LAN. Hors nous avons plusieurs client et nous voulons donc pour chaque client qu'ils utilisent une url clientx.domaine.com (ou une ip) soit rediriger sur un serveur (le même) en LAN mais avec un port différent.

On ne parle pas de reverse proxy car il ne s'agit pas de http ni de load balancer car ce n'est pas un problème de charge à proprement parler.

C'est un besoin d'une grande simplicité qui ne concerne que la couche 4.

jdh

Je reprends mon explication, que vous ne semblez pas avoir bien suivi, :

un paquet ne comporte QUE des adresses ip dans les entêtes, et aucunement un nom de domaine,
seul http (et https), inclut dans le protocole le nom de domaine (dans le contenu du paquet).

De facto, avec http, il est aisé de faire du 'mutualisé'.

interact

Jdh, je n'ai pas besoin de 'bien suivre' vos explications car elles ne me concernent pas (ou vous n'avez pas bien compris ma demande).
La solution dont je parle fonctionne parfaitement en réseau local. Mon soucis est un NAT simple entre WAN et LAN. Que ce soit en url ou ip peut importe, notre application doit se connecter sur une ip dans le LAN avec un port différent suivant la source d'entrée.
Hors cela ne passe pas et c'est pour cela que j'ai demandé de l'aide aux .. experts pfSense dont je ne fais pas partie (encore).

jdh

Clairement vous n'indiquez toujours pas votre protocole : de quel protocole s'agit-il ?

interact

TCP de bout en bout. J'ai fait un test d'envoi de paquet TCP entre mon application (donc celle qui ira chez different clients) et mon serveur en LAN. Evidemment il n'y arrive pas (d'ou l'objet de mon post). Mais en faisant un tcpdump sur mon pfSense on voit clairement que ce paquet reste au niveau du pfSense…
Je ne sais pas si je peux poste un .cap ici.

ccnet

Jdh, je n'ai pas besoin de 'bien suivre' vos explications car elles ne me concernent pas (ou vous n'avez pas bien compris ma demande).

Elles vous seraient pourtant profitables.

Que ce soit en url ou ip peut importe,

Un nat en url ? ha ….

Prenons le problème autrement.
Pour votre application TCP de bout en bout (au fait http c'est aussi du tcp de bout en bout ...), quel est le port d'écoute de votre serveur ? C'est peut être 5001 mais vérifions. Lorsque depuis wan votre application cliente souhaite atteindre le serveur, quel port est indiqué dans le champ port destination de l'entête TCP ?
Même question pour l'autre application qui fait de l'http sur un port différent de 80. Avec des réponses claires nous pourrons vous dire quoi faire

jdh

Désolé, il me semble que certaines réalités sur les échanges de paquets IP entre clients et serveurs vous soient inconnues.
Cette connaissance me paraissant totalement nécessaire, je ne vais pas encombrer plus.

A tout hasard, un lien qui explique certaines choses bien mieux que moi : http://irp.nain-t.net/doku.php/

chris4916

c'est maintenant un peu plus clair mais ta manière de poser la question prêtait à confusion.

lorsque ton client va chercher à joindre un service du tu exposes "via pfSense", il va s'appuyer sur un fqdn et un port
le fqdn est résolu via un DNS publique et à un fqdn correspond (pour simplifier) une seule adresse IP (il pourrait y en avoir plusieurs mais c'est un autre débat)

Donc la formulation "rediriger une zone DNS" n'as pas vraiment de sens.

Ensuite, ton client va arriver sur une des IP publiques de pfSense et, maintenant que je comprends mieux, il s'agit uniquement de faire un forward vers un serveur interne qui répond sur un port différent.
Tu peux faire ça avec une simple règle de forward ou faire ça avec le service de load balancing vers un pool qui ne contient qu'un seul serveur. Les deux vont fonctionner, la deuxième solution n'ayant du sens que si tu souhaites un jour ajouter d'autres serveurs internes pour le même service.

interact

Merci chris4916, enfin un qui a compris et qui semble avoir de bonnes notions d'échange entre paquets.
J'ai en parallèle trouvé la solution si cela vous intéresse :

j'ai ajouter plusieurs zone dns (depuis mon FAI) qui sont redirigées sur un ensemble d'alias IP (attention, il faut mettre la même MAC que celle du Pfsense). Chaque zone correspond donc à une ip publique enregistrées comme alias sur le pfsense. Ensuite, il me suffit de NATer ces IP destination sur le server en LAN avec chacun son port.
On arrive donc à une solution simple pour rediriger une zone dns sur un serveur/port en LAN.

Je dois encore vérifier quelques règles de sécurité mais cette solution fonctionne correctement.

Cordialement

chris4916

je ne sais pas ce que tu appelles "zone dns" mais ce que tu décris, dans le dns, c'est un enregistrement de type A ou CNAME, pas une zone.
Par ailleurs, je ne comprends pas ton histoire de MAC ? Tu parles des IP alias que je te décrivais dans mon premier messages ?

Si c'est le cas, au vocabulaire près ;) oui c'est la solution.

Si je la reformule, il s'agit de faire correspondre à une entrée DNS (publique) de type A ou CNAME une IP (éventuellement virtuelle) coté pfSense pour ensuite faire un forward ;)
C'était ma première réponse 8) mais comme souvent, le problème, c'est le glossaire ;)

jdh

Risible …

Au revoir ... ou pas

Je répète : pfsense (et n'importe quel firewall) NE VOIT PAS arriver une requête 'client1.mondomaine.com', il voit juste arriver des paquets dont l'ip destination est l'ip WAN.
Si vous avez 'client1' jusqu'à 'client10', et que vous possédez 10 adresses ip (autant), une règle 'port forward' par adresse ip fait l'affaire (et c'est 'admin très débutant').
Si vous n'avez qu'une seule adresse ip, c'est juste mort (même quand le génial chris4196 a tout compris).