Deux serveurs Web distinct derrière une DMZ
-
Bonjour à tous,
Après plusieurs semaine de galère à m'arracher les cheveux, je viens solliciter votre aide.
J'ai un serveur branché sur une livebox avec pfsense.
J'ai créé un LAN et une DMZ
Sur la DMZ on retrouve un premier serveur WEB qui est fonctionnel avec un reverse proxy (squid) et accessible depuis le local et net.
Jusque là tout fonctionne, cependant l'histoire se complique quand j'essaye de monter un deuxième serveur web.
J'accède toujours au 1er site mais jamais au deuxième, j'ai essayé les règles de port forward / NAT dans tout les sens à en perdre mon latin.
Quand j'arrive a faire fonctionner le second serveur (accéder à la page web), l'autre devient inaccessible.
J'aurais pu jouer avec un virtual host. Cependant l'idée est de comprendre le NAT dans pfsense afin de pouvoir construire une infrastructure correcte par la suite sans venir vous embêter.
Donc si une personne peu m'aiguiller je lui en serais grandement reconnaissant.
Cordialement
-
Manque de connaissance et de recherche.
Le rôle du NAT est de transférer un flux réseau donné, de l'ip publique vers un serveur.
Dans le cas de serveur web, les flux réseaux sont soit HTTP = 80/tcp soit HTTPS = 443/tcp. Au passage, je n'indique aucunement un domaine (dns), et c'est normal et doit être bien compris !
Si on veut héberger non pas UN serveur web (sous un seul nom de domaine), mais DEUX ou PLUS serveurs web, il faut insérer un reverse proxy. Ce proxy saura analyser les requêtes HTTP pour transmettre le trafic à son serveur, c'est à dire selon le nom de domaine. Typiquement, le proxy définira des 'virtual host' qui assureront l'association 'nom de domaine' <-> 'serveur web'.
Je vous ai donc indiqué les étapes nécessaires :
- le NAT effectué depuis pfSense,
- le reverse proxy qui effectué l'aiguillage,
- les serveurs web qui répondent à des noms de domaines.
Si vous mélangez les étapes cela ne risque pas de fonctionner ...
NB : des reverse proxy, il y en a plein, à commencer par les serveurs web tels Apache ou Nginx. Squid est un proxy pur et costaud, il est peut-être plus facile de commencer par les serveurs web ...
NB2 : Pour le trafic depuis le LAN, la règle de NAt ne peut s'appliquer, il faut donc une définition dns locale pour chaque serveur web ou plutôt nom de domaine !
-
Merci d'avoir pris le temps de me répondre JDH.
Le manque de connaissance est certain.
Le rôle du NAT pour moi est de traduire une IP interne qui sera accessible via l'adresse publique.
Pour ce qui est des Flux HTTP et HTTPS je connais le principe HTTP non sécurisé et HTTPS sécurisé avec un certificat SSL.
J'ai bien un reverse proxy, j'ai défini les Web server, le mapping.
J'ai bien un nom de domaine et des sous domaines
La ou je n'arrive pas a comprendre c'est la partie NAT, je dois définir l'adresse IP WAN donc j'imagine celle du serveur Hyper-v ou bien la patte WAN du pfsense (j'ai testé avec les deux solutions).
Donc je suppose que mon soucis vient de la règle de NAT. Mais si vous avez un tutoriel ou documentation à me communiquer je suis preneur car je ne trouve que des infos erronées ou de version bien antérieures.
Cordialement.
-
Quand on répète qu'il faut encore plus d'expérience quand on veut virtualiser ...
Je connais mal Hyper-V (et je ne cherche pas à améliorer cela).
Le principe est clairement d'avoir 3 'switchs' internes dans l'hyperviseur. Et cela est très clair puisque vous voyez bien 3 réseaux distincts. J'appelerai ces 3 réseaux 'WAN', 'DMZ' et 'LAN'. Dois-je préciser que, seule le pfSense a 3 interfaces réseaux, chacune sur un 'switch' ?
Je suppose que tout cela est juste pour apprendre, donc on peut imaginer une seule carte réseau pour la machine, qui sera nécessairement associée au réseau WAN. L'adresse affectée à l'hyperviseur lui-même sera dans 'WAN'. C'est juste super délicat d'avoir des PC physiques en 'WAN' ...
Le mieux eut été de disposer de 2 cartes réseaux 'WAN' et 'LAN' avec un switch connecté à 'LAN' pour les PC physiques (et bien sûr ne pas utiliser le Wifi de la Livebox).
Avec une seule carte, la Livebox envoie tout le trafic à l'ip WAN de pfSense, lequel fait le NAT de l'ip WAN (adresse privée recevant la totalité du flux vers l'ip publique de la Livebox) vers l'ip du reverse proxy (en DMZ).
-
Bonjour JDH ;
Je pense que nous ne nous sommes pas bien compris.
Je peux dire sans crainte que je connais bien Hyper-V, les switchs etc…
Mon infrastructure fonctionne parfaitement résolution DNS et flux.
J’ai modifié le port d’accès au Pfsense afin de réserver les port 80 et 443 au web et pour la sécurité.Mon squid proxy et reverse proxy fonctionne également.
Je pense que mon problème vient de ma configuration du reverse proxy ou bien des règles de NAT que je ne gère pas du tout sur pfsense (autant je sais les faire sur la livebox).
Ou de l'Outbound (pour lequel je n'ai vraiment pas compris).
Cordialement
-
Pour ceux qui rencontreraient la même difficulté que moi, j'ai fini par trouver ma solution.
J'avais donc bien travaillé, mais il me fallait une règle outbound dans un premier temps et je m'étais trompé sur un bind d'adresse.
-
Ce lien ne vaut rien (et est faux) !
Il est impossible de faire fonctionner 2 règles identiques : la première sera toujours exécutée, la seconde jamais. D'ailleurs le comptage d'utilisation doit bien l'indiquer.
Il est parfaitement évident qu'un paquet HTTP est un paquet IP, donc il est envoyé à une adresse IP correspondante au nom dns du serveur web cible. Mais le paquet HTTP (la partie DATA) contient la requête HTTP qui précise le nom dns. C'est donc le serveur web ou le proxy qui va analyser la requête et en déduire vers quel serveur web cible il faut envoyer la requête.
Le Dns Resolver n'a d'intérêt que localement : définit les valeurs dns utile localement. Si vous avez un serveru dns local, vous fe rez la même chose. ( Dans le lien, le dns est fourni à WAN et ce n'est pas les règles NAT qui fonctionnent, il doit y avoir une route vers l'adressage interne, bref du grand n'importe quoi).
-
J'abandonne de vous aider :
- il n'y a que très peu d'infos pratiques sur la config,
- votre schéma n'est pas bon : le LAN ne devrait pas être wonfondu avec le WAN,
- vous croyez un lien qui ne correspond à rien
Néanmoins je vous ai indiqué les bonnes pratiques.
-
JDH merci pour vos retour,
cependant je ne comprends vraiment pas ce que vous raconté a chaque fois pour être honnête, j'ai l'impression de lire wikipédia.
Je ne mets pas en doute vos compétence, mais j'aimerais connaitre votre niveau.
Mon formateur a valider cette infrastructure, et il est de niveau ingénieur systèmes et réseaux.
Concernant les règles elles sont peu être fausse, cependant j'ai retrouvé les mêmes information sur d'autre TP ou Labo.
J'ai bien un AD qui me fait les resolutions DNS avec un forward sur la box.
J'espère ne pas vous offenser.
Cordialement
-
Le bon schéma est
Internet <-> box <-> (WAN) pfSense
puis selon
pfSsense (LAN) <-> switch <-> PC internes
pfSense (DMZ) <-> switch <-> serveursSi vous virtualisez, il est indispensable d'avoir au moins 2 interfaces ethernet.
Internet <-> box <-> eth0 / hôte / eth1 <-> lan interne
La VM pfSense aura 2 interfaces réseau : l'une reliée à eth0, l'autre à eth1; et vous administrerez depuis le 'lan intern" (=eth1).
Au besoin, vous ajouterez un switch interne à l'hôte pour créer une DMZ.
Si celui qui vous conseille, vous dit qu'une seule interface suffit et que c'est c'est celle de WAN, et bien changez d'ami !
Pour mon niveau, je fais du firewalling depuis avant 2000, ça ira ?
-
Merci pour votre éclaircissement.
Alors je vais faire comme vous concernant les schémas.
L'infrastructure actuelle est:
Internet (FAI) => Livebox => serveur (Hyper-V) => avec adressage fixe et mac associé
serveur => External Switch => PfSense
PfSense => WAN (external Switch) => LAN => DMZ
sur le Lan on trouve un AD et 3 VMs qui jointent au domaine.
sur la DMZ on trouve deux serveurs indépendant avec dns.l'Administration du PfSense ce fait uniquement via le serveur Hyper-V et non via Internet, je n'ai donc pas besoin d'avoir un second Lan d'administration, le SSH du Pfsense est désactivé et le shell vérouillé.
L'AD à une double authentification.
Je pense que nous disons plus ou moins la même chose, cependant vous restez buté sur vos connaissances et n'écoutez pas les personnes sur ce forum (j'ai vu plusieurs prises de bec avec des usagés du forum), de ce fait on tourne en rond, cela est un peu dommage de plus vous parlez avec vos connaissances Proxmox que je connais pour l'avoir utilisé et non Hyper-v qui fonctionne différemment et permet plus de souplesse.
Cordialement
-
J'ai du Proxmox à mon domicile (2 hosts). Mais en entreprise j'ai fait du Xen (peu) et du VMware (pas mal). Dernièrement j'avais 10 hosts VMware et environ 70 VM.
Pour le firewall, j'ai fait du Raptor (devenu Symantec), Debian (ou Linux) avec script écrit à la main (iptables) ou générateur (Shorewall), du CheckPoint, des appliances WatchGuard, Fortigate, Stormshield.
Je ne suis pas buté, j'ai des 'habitudes', une recherche et lecture permanente, et une pratique que n'ont pas forcément ceux ... qui jouent la provocation ... (D'allleurs ceux qui s'opposent sont loin d'aider sur le forum ni même d'être présents !)
Dans vos explications, on ne sait toujours pas si votre hôte dispose de 2 cartes réseau !! Parce que vous ne semblez pas comprendre que c'est totalement indispensable : il serait stupide d'avoir des machines dans la zone WAN (box <-> WAN de pfSense) !!
L'administration de toutes les VM doit être réalisée depuis les PC internes (qui ne peuvent être dans la zone WAN et pour cause ...) et non depuis l'hôte Hyper-V : seulement la création et l'initialisation des VM.
(Plus de souplesse pour Hyper-V ? Pas le bon qualificatif, à mon avis ! Vous ne connaissez sans doute pas les autres produits : ils ont en commun une install en 100-300 Mo contre au moins 4 Go pour Windows Core.
-
Voici l'infra plus détaillé, avec la définition des vSwitchs créaient sur Hyper-V.
"Dans vos explications, on ne sait toujours pas si votre hôte dispose de 2 cartes réseau !! Parce que vous ne semblez pas comprendre que c'est totalement indispensable : il serait stupide d'avoir des machines dans la zone WAN (box <-> WAN de pfSense) !!"
-
Ce n'est nullement indispensable du moment ou l'administration se fait en local et non via internet.
-
Si vous regardez correctement le schéma, il n'y a aucune machine dans le WAN de PfSense !!.
"L'administration de toutes les VM doit être réalisée depuis les PC internes (qui ne peuvent être dans la zone WAN et pour cause ...) et non depuis l'hôte Hyper-V : seulement la création et l'initialisation des VM."
- Stupide non, manque de sécurité surement. Il n'y a qu'une seule carte réseau, et je redis l'administration du PfSense ce fait depuis l’Hôte exclusivement (entendez donc, depuis une VM en l’occurrence l'AD en liste blanche).
"(Plus de souplesse pour Hyper-V ? Pas le bon qualificatif, à mon avis ! Vous ne connaissez sans doute pas les autres produits : ils ont en commun une install en 100-300 Mo contre au moins 4 Go pour Windows Core."
-
Je ne parle de souplesse au niveau du système (services et poids du système), mais sur la création et la mise en application des vSwitch.
-
Ce que je peux envier a un système tel que Proxmox pour l'utilisation que j'en ai faite est seulement le fait de pouvoir faire un Template de façon rapide et pouvoir modifier sa configuration après déploiement sans que cela ne parte en cacahuète dans tout les sens par la suite.
Concernant ESXI, je ne le connais réellement mais il doit cependant être très proche de Proxmox de ce que j'ai pu voir.
PS: Cet échange est ouvert à tous n'hésitez pas à donner votre avis, vos connaissances, on apprend toujours, même de personne ayant un profil dit Junior. Merci d'avance.
Cordialement.
-
-
J'oubliais de mentionner la règle:
RFC1918 addresses are blocks of network IP addresses reserved for private.
Ce qui n'empêche que j'ai tout de même changé le port d'administration.
-
Ok tout est virtuel, et il n'y a qu'une seule carte, donc forcément pour WAN. C'est très loin d'être idéal ...
Quand vous aurez plusieurs PC physiques, il faudra suivre ce que j'écris : 2 cartes réseau dans l'hôte, l'une connecté à la box, l'autre aux PC (dans le LAN) via un switch physique.
Il vous est possible d'installer un ESXi (en free = gratuit) et apprendre à vous en servir : c'est pro et très solide. (D'ailleurs Hyper-V étant inclus dans la licence Windows, et donc gratuit une fois la licence Windows acquise, pourquoi la plupart des entreprises achètent, en sus, des licences VMware payantes ... si ce n'est que VMware a des 'plus' ?)
Quelque soit le système de virtualisation, il faudra en comprendre les concepts réseau inclus.
-
Yep, bon juste voilà, je suis Technicien supérieur systèmes et réseau et je prépare une licence en bachelor donc je pense savoir de quoi on parle, mais merci de rappeler les notions.