Squid et HTTPS et Accès WAN
-
Quand tu parles de segments (un pour les serveurs, un pour les utilisateurs, un pour les guests), tu parles de VLAN ? de tranches IP ?
Si c'est de VLAN que tu parles, dans mes souvenirs imagés, c'est un switch qu'on découpe virtuellement pour faire comme si on en avait plusieurs. Dans mon esprit, je ne vois pas comment les postes pourraient avec communiquer avec les serveurs s'ils sont sur 2 VLAN différents ?
Si c'est par tranche IP, dans ce cas, il faut un routeur pour faire le travail de routage entre les différents segments… ?Ce peut effectivement être du VLAN ou des segments physiquement séparés. La réponse dépend de ton infrastructure réseau physique. Si tes serveurs sont, par exemple, dans un data centre ou une salle machine spécifique, il est facile de les mettre sur un réseau "isolé". Si les serveurs sont répartis dans différents bureaux, selon la manière dont est gérée la baie de brassage, ça peut être beaucoup plus difficile et le VLAN est probablement mieux adapté.
Le VLAN revient à construire, de manière virtuelle (d'où son nom) un LAN virtuel isolé.
Bien sûr qu'il faut dans ce cas, gérer le routage entre ces différents segments réseau et c'est justement tout l'intérêt puisque, en isolant les réseaux, tu contrôles qui accède à quoi et avec quels protocoles.Mais je dirais que ce n'est que la cerise sur le gâteau (bien que dans le cas de serveurs, ce soit plutôt des "best practices")
L'idée principale qui répond à ta question initiale, c'est de dire:
- faisons en sorte que tous les serverus accèdent à internet via un proxy (ce qui signifie, du point de vue de ton fournisseur de service d'une IP interne unique)
- demandons au fournisseur d'autoriser cette IP ou bien configurons le proxy pour utiliser l'IP déjà autorisée.
-
Bonjour,
Bon bon bon… Pas d'évolution de mon côté.
L'opérateur nous facture toujours la possibilité de rajouter des IP dans le watchguard. On a donc décidé de garder notre pfSense en l'utilisant comme passerelle pour que nos serveurs Linux puissent sortir sur Internet.
Mais en voulant configurer le pfSense, je suis embêté car les machines du réseau local (donc connectées via l'interface WAN), configurées avec la passerelle qui correspond à l'interface Wan, peuvent pinguer n'importe quelle domaine mais au moment où je veux aller sur Internet, "la page est inaccessible".
Dans les logs du firewall, j'ai activer les logs pour la règle que j'ai placée dans WAN (voir copie d'écran), tout semble passer... mais ça ne revient pas !En revanche pour le LAN (accès donné aux clients via un AP Wifi), aucun problème de surf.
Que dois-je faire ? Merci
-
L'opérateur nous facture toujours la possibilité de rajouter des IP dans le watchguard. On a donc décidé de garder notre pfSense en l'utilisant comme passerelle pour que nos serveurs Linux puissent sortir sur Internet.
Tu pourrais, stp, poster un schéma à jour montrant cette modification ?
Mais en voulant configurer le pfSense, je suis embêté car les machines du réseau local (donc connectées via l'interface WAN), configurées avec la passerelle qui correspond à l'interface Wan, peuvent pinguer n'importe quelle domaine mais au moment où je veux aller sur Internet, "la page est inaccessible".
J'avoue ne pas comprendre ce que ça signifie. Le schéma devrait répondre à mon interrogation.
Dans ce que tu décris, il semble que les PC utilisateurs ne sont pas derrière pfSense (celui-ci étant intercalé entre le LAN et l'équipement en 10.0.1.254) mais sur un segment auquel serait connectée l'interface WAN de pfSense (en 10.0.1.202)
Si c'est le cas, c'est normal que ça ne fonctionne pas car si 10.0.1.202 est la gateway des PC, ceux-ci vont accéder à cette IP pour joindre internet (au lieu de 10.0.1.254). Tu as peut-^tre ajouté une route pour renvoyer vers 10.0.1.254 (ce qui est une mauvais eidée sauf à prendre quelques précautions de configuration dans pfSense) mais lorsque les paquets reviennent à 10.0.1.254, celui renvoie ces paquet directement vers le PC alors que celui-ci attend une réponse de 10.0.1.202.Bref, un nouveau schéma s'impose ;)
-
Oui, ça doit être ce que tu décris.
Le pfsense est passerelle pour les serveurs Linux. Je n'ai pas créé de route ni rien.
J'ai mis à jour mon schéma.
Si tu peux m'indiquer quoi faire… je suis preneur.
-
Ce schéma ne fonctionne pas, sauf si, et c'est un design que je ne vais pas supporter, pfSense exécute un proxy Squid qui écoute sur son interface WAN.
Je ne comprends même pas pourquoi ça marcherait pour les serveurs et pas pour les PC :o1 - il faut que tes serveurs soient derrière pfSense et non pas coté WAN
2 - si tu n'as pas besoin de pfSense pour tes serveurs (pas de fonction d'isolation via un FW des serveurs et des PC, alors installe un proxy en 10.0.1.244, configure pfSense pour avoir 10.0.1.243 (par exemple) en adresse WAN et dirige les clients qui sont derrière pfSense (wifi) vers 10.0.1.244 (proxy HTTP)
3 - ne change rien aux PC: ceux-ci sont déjà autorisés au niveau du watchguard si ils utilisent 10.0.1.254 comme dft GW. -
Je ne vois pas non plus comment ce schéma pourrait fonctionner. Bien évidement il faut mettre les serveurs derrière Pfsense (éventuellement un second pour ne pas toucher à ce qui est tombé en marche) sur la pâte Lan. Ils en ressortiront translatés avec l'ip wan de Pfsense qui n'a qu'à être une ip autorisée sur le firewall opérateur. Mais il faudra router le trafic à destination de ces serveurs si ils doivent être accédés depuis les machine du lan. Tout cela est tellement alambiqué que je pense avoir perdu de vue l'expression de besoin initiale (si il y en avait une). Sinon le proxy tel que proposé par Chris convient.
Ps1: Je reste étonné par le nombre de réseaux aux architectures approximatives et bancales.
Ps2: Et dire qu'avec une architecture saine ce serait si simple (ou presque) … -
Ce que je constate, c'est
- l'initiateur n'est pas compétent, et fait des réglages 'au petit bonheur' en espérant que cela puisse fonctionner
- l'initiateur a écrit un passage virulent sur le forum et ne semble pas près de s'en excuser (pour moi c'est un blocage !)
- un utilisateur émet des idées, certes logiques mais hélas parfaitement inaccessibles à l'initiateur, en sus de quelques digressions et erreurs. De plus cet utilisateur encourage l'initiateur dans ses opinions vis à vis du forum …
- la société veut tout et son contraire : pas d'expertise = confiance au FAI et ne veut pas payer d'où bricolage par amateur pas éclairé
Or, dans ce cas, avec les réglages initiaux (bien meilleurs et bien plus logiques), il y a une astuce (non trouvée par chris4916) qui donnerait l'accès souhaité.
En fait on en revient exactement à ce que j'ai écrit le 17 à 9h39 et qui reste d'actualité :
- Il y a nécessité de disposer d'un conseil en réseaux qui saura mettre en oeuvre les bonnes techniques (cela a forcément un coût : patauger depuis tout ce temps a déjà couté !)
J'ajoute que, malgré l'astuce que je vois, il y a nécessité de remettre à plat ce schéma !
En ce qui me concerne, à partir du moment où il n'y a pas d'excuses, je ne vois pas pourquoi je donnerais la piste, pourtant simple, qui donnerait l'accès souhaité.
Je répète qu'il y a une astuce simple et il n'est pas question de segments, ....@ccnet :
Beaucoup de PME font confiance à leur opérateur et utilisent un réseau MPLS avec accès Internet 'central'.
Dans le cas, l'opérateur a 'vendu', en sus, un contrôle utilisateur pour la navigation, ce qui 'attire' la PME.
Mais la PME ignore les imperfections et difficultés qui ne manqueront pas, accompagnées de leurs solutions payantes.
Le schéma est bancal parce que la PME tente d'ajouter un pfsense sans expérience et sans passer à une solution solide (i.e. sans accès Internet central)
C'est fréquent en effet ... -
Ps1: Je reste étonné par le nombre de réseaux aux architectures approximatives et bancales.
Ps2: Et dire qu'avec une architecture saine ce serait si simple (ou presque) …Oui surtout que quand c'est simple, généralement ça marche ;-) mais dans la vraie vie, pour certaines sociétés, l'infrastructure n'est pas le résultat d'une réflexion murement réfléchie pour chacune des évolutions et il y a parfois des verrues qui poussent suite à des décisions rapides, d'urgence mal gérée ou de contrainte dont on ne tient plus compte quand on regarde la big picture à postériori.
Si les intervenants dans la société change, il n'y a pas toujours continuité, d'où des designs parfois étranges.
Et heureusement car si tout était parfait, on s'ennuierait ;D ;D ;D
-
@jdh:
Or, dans ce cas, avec les réglages initiaux (bien meilleurs et bien plus logiques), il y a une astuce (non trouvée par chris4916) qui donnerait l'accès souhaité.
Je n'ai pas la prétention d'avoir exposé ni trouvé, ni même cherché, je l'avoue, l'ensemble des solutions possibles à cette problématique :P
Tout le monde n'a pas ta compétence pour trouver LA solution idéale et formuler LA réponse concise et unique.
Mais j'apprends régulièrement en te lisant ;)En ce qui me concerne, à partir du moment où il n'y a pas d'excuses, je ne vois pas pourquoi je donnerais la piste, pourtant simple, qui donnerait l'accès souhaité.
Je répète qu'il y a une astuce simple et il n'est pas question de segments, ….Au moins tu as la satisfaction de connaitre LA bonne solution ;D ;D ;D
Blague à part, la vraie difficulté consiste ici à bien comprendre quels sont les objectifs immédiats.
Le design réseau est assez surprenant et certes sujet à discussion et amélioration mais cette considération, sauf si c'est un point bloquant, ne me semble pas être l'objectif immédiat de l'initiateur du message. La décision ne lui appartient d'ailleurs peut-être même pas.D'où l'intérêt, à mon avis, mais bien sûr ce n'est pas le tien, de proposer modestement différentes pistes avec des explications de ce que ça fait ou pas.
-
@jdh:
Dans pfSense, les règles sont réparties par onglets : LAN, WAN, …
Ces onglets indiquent l'arrivée des paquets (enfin du paquet initial).
Par voie de conséquence, l'onglet WAN contient des règles concernant des flux allant de WAN vers LAN.
Et de même, l'onglet LAN contient les règles concernant les flux allant de LAN vers WAN.Attention à cette vision simplificatrice.
Pour que cette description fonctionne à tous les coups, il faut (faudrait) activer dans le menu "System / Advanced / Firewall/NAT" la fonction "Static route filtering" (*) sans quoi les règles de l'onglet LAN vont bien concerner tous les paquets entrant par l'interface LAN, quelle que soit leur destination ;)(*)
Bypass firewall rules for traffic on the same interface
This option only applies if you have defined one or more static routes. If it is enabled, traffic that enters and leaves through the same interface will not be checked by the firewall. This may be desirable in some situations where multiple subnets are connected to the same interface. -
Quote from: jdh on 17-11-2015, 08:39:22
Dans pfSense, les règles sont réparties par onglets : LAN, WAN, …
Ces onglets indiquent l'arrivée des paquets (enfin du paquet initial).
Par voie de conséquence, l'onglet WAN contient des règles concernant des flux allant de WAN vers LAN.
Et de même, l'onglet LAN contient les règles concernant les flux allant de LAN vers WAN.Attention à cette vision simplificatrice.
Pour que cette description fonctionne à tous les coups, il faut (faudrait) activer dans le menu "System / Advanced / Firewall/NAT" la fonction "Static route filtering" (*) sans quoi les règles de l'onglet LAN vont bien concerner tous les paquets entrant par l'interface LAN, quelle que soit leur destination ;)Il est important de bien suivre ce que j'écris : je décris le fonctionnement de pfSense, rien que le fonctionnement, tout le fonctionnement.
Il est absolument clair que les règles situées dans l'onglet LAN traitent les paquets arrivant à pfSense par cette interface.
Concernant l'onglet WAN, il est rare d'écrire une règle directement dans cet onglet. Généralement on écrit des règles dans NAT > Port forward, règles qui génèrent une règles dans l'onglet WAN.Attention de bien éviter les choses trop complexes ajoutés par d'autres …
-
@jdh:
Il est important de bien suivre ce que j'écris : je décris le fonctionnement de pfSense, rien que le fonctionnement, tout le fonctionnement.
Je sais bien que toi seul détiens la vérité et toute la vérité ::) mais si je me permets de reprendre et préciser ton propos, c'est justement parce que:
-
tu décris quelque chose qui est le fonctionnement "la plupart du temps" mais qui n'est pas, comme tu l'écris "tout le fonctionnement".
-
dans le cas particulier de ce fil, nous sommes justement dans la situation que je relève (et contrairement à ce que tu sembles croire, je ne fais pas cette remarque pour te taquiner mais pour que les autres lecteurs aient une meilleure compréhension) => l'utilisateur à installé pfSense avec des machines sur le LAN mais également des machines coté WAN pour lesquelles il est suggéré qu'une solution pourrait être de changer la route par défaut pour passer par pfSense. D'où ma mise en garde.
La raison pour laquelle ce paramètre "Static routes filtering" existe, BTW, c'est parce qu'il y a des cas de figure où le flux passe par pfSense sans pour autant changer d'interface.
-
-
C'est désespérant ! Il faut TOUJOURS que tu ajoutes un petit truc ALORS que ce qui est essentiel a été dit !
JAMAIS tu ne te poses la question : ce que j'ajoute va-t-il embrouiller le lecteur ?
Je le dis c'est toujours le cas !Ce n'est pas parce que tu ne vois pas l'astuce que je vois ici qu'il faut essayer de bricoler : mon astuce est très simple et ne nécessite que très peu de choses.
Mais comme l'initiateur a insulté l'accueil et ne fait aucune excuse, je ne décrirais pas ici l'astuce.
-
@jdh:
C'est désespérant ! Il faut TOUJOURS que tu ajoutes un petit truc ALORS que ce qui est essentiel a été dit !
JAMAIS tu ne te poses la question : ce que j'ajoute va-t-il embrouiller le lecteur ?
Je le dis c'est toujours le cas !Veux-tu dire que ma remarque sur le fait que dans le cas précis exposé par l'initiateur du fil, il n'y a pas de risque de routage via l'interface WAN sans passer par le LAN ?
Alors j'ai mal compris ::)Ou alors je ne partage pas avec toi la compréhension de ce qu'est l'essentiel :P
Pourquoi faut-il que ce soit toujours avec toi alors que sur les autres fils dans la section anglaise, je ne rencontre jamais ce genre de difficulté de compréhension ?
Ce n'est pas parce que tu ne vois pas l'astuce que je vois ici qu'il faut essayer de bricoler : mon astuce est très simple et ne nécessite que très peu de choses.
Mais comme l'initiateur a insulté l'accueil et ne fait aucune excuse, je ne décrirais pas ici l'astuce.Je ne me suis même pas posé cette question et je ne cherche pas d'autre solution.
Si tu as une solution élégante c'est bien.
Si tu ne veux pas la partager parce que l'initiateur et le autres lecteurs ne te méritent pas, ce n'est pas grave ;)PS 1: à mon avis, qui n'est bien sûr pas le tien, l'initiateur du fil n'a insulté personne. Il a juste fait remarquer, suite à ton intervention :
Je ne sais pas quoi vous répondre… enfin si, c'est très compliqué d'intégrer votre forum compte tenu de l'accueil que vous réservez.
Certes, je comprends que les nuls comme moi vous énervent mais dans ce cas là, ne vous investissez pas dans ce forum...Si tu te sens insulté, c'est ton problème.
PS 2: je pense que l’initiateur a résolu son problème sans avoir recours à ton astuce magique. Ou alors il l'a trouvée sans toi ;)
-
risque de routage via l'interface WAN sans passer par le LAN
On va où là ? Pourquoi faire quelque chose d'aussi nul et d'aussi inutile ?
L'initiateur, qui a oublié son problème car il ne répond plus, n'est pas très compétent, certes. Et il tente, forcément sans logique.
Notamment au point de faire des choses complètement anormales, comme celle de changer la passerelle par défaut !
En aucun cas, je ne saurais lui reprocher son inexpérience.Mais en aucun cas, on doit 'router' avec ce pfSense : encore une aberration !
A quoi servirait d'expliquer une technique très très peu utilisée (et qui, ici, n'a aucun intérêt !) ?
Les 2 phrases citées insultent TOUS ceux qui répondent et donne de leur temps gracieusement.
D'ailleurs certains arrivent très bien à lire le post en haut et savent utiliser le formulaire :
ce fil est d'ailleurs encore ouvert alors que ceux qui ont utilisé le formulaire ont obtenu des réponses, c'est encore une démonstration !
J'ajoute que la dernière phrase est carrément horrible : 'ne vous investissez pas'; et puis quoi, venant d'un tout nouveau !Le problème essentiel est qu'avec 775 posts, on attendrait juste un peu de solidarité sur la question du formulaire.
Il suffit d'observer les fils qui partent en c. : forcément il y a chris4916 qui laisse aller sur le formulaire !