Choix d'architecture / Portail multi-LAN

grinderfurax

Bonsoir.
Faute de temps, je me permets de vous poser quelques questions avant de tenter une install et de "voir par moi-même".
Tout d'abord voici un schéma simplifié de mon architecture réseau :

Nous sommes dans un environnement Active Directory, avec plusieurs centaines de postes client cablés. La moitié des usagers ont un espace de stockage à disposition situé sur le serveur AD. Pour des raisons de disponibilité et d'optimisation du traffic, une réplication de l'AD est située dans un autre bâtiment (contenant à lui seul la moitié de notre parc info), et sert d'espace de stockage pour l'autre moitié des utilisateurs. Chaque utilisateur doit être malgré tout capable de se connecter sur n'importe quelle machine du réseau et accéder à son espace de stockage.

Pour optimiser le traffic et limiter l'épidémie en cas de problème réseau, les 4 bâtiments sont dans des sous-réseau différents, reliés à un unique serveur qui fait office de routeur, DHCP pour les postes clients, et Proxy Squid pour filtrer et enregistrer le traffic des utilisateurs.

Les AD servent de serveur DNS pour le LAN (et sont déclarés respectivement en DNS primaire et secondaire dans le DHCP), des redirecteurs DNS sont configurés sur les AD pour l'accès à internet.

Cette architecture fonctionne, mais souffre de grosses lacunes quand on y ajoute l'accès Wifi.

Notre routeur (qui sert de DHCP) redirige sur le service de proxy tout le traffic en port 80. Les usagers qui souhaitent surfer avec un appareil mobile peuvent donc accéder au net tout en bénéficiant du filtrage, mais aucun log ne permet de remonter jusqu'à l'utilisateur, à moins d'établir un filtrage MAC sur les bornes.

Pour alléger l'administration (en moyenne 800 nouveaux utilisateurs par an), l'idée était donc de mettre en place un portail captif, afin de ne pas distinguer les machines (mobiles ou non), et de tout tracer directement à partir de l'authentification AD.

Dans ce but j'ai cherché à configurer le portail captif du Netasq, avec une liaison LDAP vers notre AD. Le bon point est qu'il semble distinguer un utilisateur déjà logué sur un poste (passe à travers) d'un appareil externe (qui est lui redirigé vers le portail captif). Le problème, et pas des moindres, c'est que l'ensemble du traffic venant du routeur est masqué par l'IP du proxy, et que le portail captif réclame une authentification seulement pour le premier utilisateur (les autres étant reconnus sur la même ip, celle du proxy).

J'en viens donc à PFSense (ouf !). En tant que portail captif, je vois deux endroits d'implantation possibles :

en série en amont du Netasq, mais dans ce cas je risque d'être confronté aux mêmes problèmes que lors de l'utilisation du portail captif du Netasq ?
en remplacement de notre routeur, ce qui m'amène à une série de problématiques et de questions.

Notre proxy battant de l'aile, c'est sans remord que je le remplacerait par une nouvelle machine, sous PFSense, avec toute une série de services la clef.

Quid des performances de cette distribution si j'associe sur la même machine un service de proxy, DHCP, routeur, et portail captif ? Le Netasq peut servir de filtrage URL, mais les log sont un peu pitoyables, risquent d'être recouvert par l'IP du routeur, et je perds de cache de fichiers de Squid qui est plutôt intéressant.
Sur les tutos que j'ai trouvé ici et là, il m'a semblé qu'on devait désigner une interface unique pour le portail captif de PFSense, hors dans mon cas, il me faut un portail captif sur les 3 interfaces réseau. Des pistes pour éviter d'avoir à mettre en place un portail captif par sous réseau ?
Quid des possibilités de traffic sans devoir s'authentifier sur le portail, par exemple pour l'ouverture de session utilisateur (primordial !), le partage de fichiers, l'accès aux serveurs SQL et serveurs d'impression ? et ce parfois dans les deux sens puisque nous avons 2 AD sur 2 interfaces du routeur.
Des règles sont-elles possibles pour éviter de devoir s'authentifier sur le portail captif pour les win update (que l'on fait sur un serveur WSUS, qui écoute sur le port 80), l'idée étant de ne pas avoir à m'authentifier partout quand je veux faire une vague de mises à jour…

Je précise que notre infra est faite de switchs non manageables, et que je dois donc abandonner l'idée des VLAN, puisque je n'obtiendrai pas les fonds nécessaires.

L'autre possibilité de mettre 3 portails captifs (un par batiment), en série entre nos bornes et notre routeur est peu exploitable. Il faudrait déjà 3 portails captifs (je n'ai pas la place physique pour les stocker, du moins pas dans chaque batiment), et pas mal de bornes wifi sont brassées sur les mêmes switch que nos postes client, donc même en segmentant, à moins de tirer des câbles j'aurai toujours des postes clients qui passeront sur des portails captifs (avec les problématiques précédemment évoquées), et tirer des nouveaux câbles n'est pas envisageable avant au moins du très long terme....

Merci de l'attention que vous me porterez.

jdh

(Bravo pour la présentation et l'effort d'explication : à continuer … et à prendre pour modèle !)

Quelques mots sur les principes généraux :

idéalement, les switchs doivent être administrables pour supporter des vlan, dont l'un pourra correspondre au wifi
le proxy DOIT être sur une machine dédiée : ce n'est pas le même boulot et les besoins mémoire/disque/proc sont différents.
on peut activer WPAD : Web Proxy AutoDiscovery protocol qui permet de trouver automatiquement le proxy
il est impossible de faire du proxy transparent et de l'identification
un portail captif est plutôt destiné à des utilisateurs occasionnels,
un portail captif est plutôt destiné à du wifi, physiquement ou logiquement séparé du LAN interne,
un portail captif permet d'authentifier (y compris sur AD en mode Radius ou LDAP) mais quid d'un proxy "enchainé"
pfSense remplacerait plutôt le firewall qu'un simple routeur
les serveurs AD ne doivent pas être dans une DMZ : ils peuvent être dans des réseaux LAN1/LAN2 distincts en mode "routage" = tout protocole
dans un environnement AD, il est souhaitable que le DC fournisse DHCP et DNS : il y a meilleure mise à jour en reverse dns.

A suivre ...

jdh

Concernant un portail captif et un proxy, je souhaite préciser les choses :

un portail captif autorise ou non l'accès à Internet,
un portail captif est normalement placé sur un firewall,
un portail captif peut authentifier un utilisateur, par exemple, via Radius puis vers un LDAP et donc AD,
un proxy peut identifier un utilisateur,
par exemple, l'identification peut être via un LDAP ou via AD,
dans les logs du proxy, l'utilisateur est indiqué.

Il n'y a pas de lien (automatique) entre un identifiant de portail et un identifiant d'un proxy.
Par contre, l'identification du portail permet d'associer une adresse ip à un identifiant, et dans un proxy, on a au minimum l'ip de l'utilisateur.

grinderfurax

Merci pour vos réponses.
Je ne suis pas passé depuis un moment car deux serveurs critiques ont rendu l'âme… ce qui m'a beaucoup occupé (et pré-occupé), sans compter le travail normal sur lequel le retard s'est accumulé...
J'ai donc profité de cet état de crise pour remonter des suggestions à ma direction, afin que "cela ne se renouvelle plus", ce qui m'a permis de débloquer un peu de budget et faire quelques remises en question de notre infra, ce qui m'a permis notamment de tenir compte de vos remarques, notamment sur la séparation proxy/routeur.

Voici donc un schéma de mon infra actuelle.

J'ai donc isolé le proxy sur un serveur tout neuf (merci le budget), que j'ai au passage virtualisé pour gagner des possibilités de restauration en cas de crash, je pense à terme virtualiser de plus en plus de serveurs mais c'est une autre affaire…

La machine qui faisait office de routeur et de proxy a été formatée, j'ai installé pfsense, et je ne destine cette machine qu'au rôle de routeur/firewall (oui suite à cet échange, ainsi que des discussions sur un autre de mes sujets, vous m'avez convaincu, vous avez gagné :p).

Du points de vue du routeur :

serveur DHCP pour mes postes clients (jamais eu de problème DNS =) ), en se déclarant comme passerelle par défaut, et en mettant mon AD comme serveur DNS et serveur WINS (on verra plus tard pour le WPAD, pour l'instant j'ai scripté avec les GPO mon changement de proxy)
la passerelle par défaut est mon Netasq
le firewall est pour l'instant en pass all (any any ipv4)
un petit ntop pour surveiller un peu ce qu'il s'y passe
l'interface WAN est celle qui tape sur les serveurs, mais j'ai veillé à décocher le blocage des paquets di'p privées (block private networks, block bogon networks) puisque j'ai un autre parefeu en amont pour le WAN.

Du point de vue de mon AD :

il gère le DHCP pour le sous réseau de la baie de serveurs (au cas où je plug un portable pour faire des essais ou autre besoin temporaire)
serveur DNS pour toute l'infra, des redirecteurs sont configurés pour les résolutions DNS liées au WAN
sa passerelle par défaut est mon routeur (vu que lui tape sur le netasq s'il ne connait pas le réseau demandé…)

Ce qui m'amène à vous, outre ce petit bout d'histoire, c'est un problème dans mon LAN depuis que je suis passé à pfsense.

A première vue, tout est fonctionnel, dans la mesure où j'arrive à assurer tous mes services sans blocage ferme et définitif.
Par contre, il y a énormément de ratés, par exemple des bouts de scripts d'ouverture de session qui se perdent, des lecteurs partagés qui n'apparaissent pas...
Lors de l'ouverture d'un lecteur réseau, je vais avoir 9 fois sur 10 le dossier qui s'affiche, mais une fois sur 10 j'aurai un blocage ou une déco avant la fin de la liste, puis avec un simple rafraichissement le reste apparait.
J'ai globalement l'impression que mes postes clients "décrochent".

Alors j'ai trouvé une demi-solution à ce problème, qui consiste à cocher "Disable all packet filtering". Pour info cette option coupe toute règles de parefeu ainsi que le NAT, et depuis plus de problèmes…
Donc la logique viendrait à dire que mon problème initial vient soit du parefeu, soit du NAT.

Hors :

mon parefeu est en pass all, sur chacune des 4 interfaces
j'ai déjà tenté de couper le NAT, en le passant en manuel et en supprimer toutes les règles, et là j'avais plus de réseau du tout !

Puisqu'à terme j'aimerais pouvoir utiliser les fonctions de parefeu, il me faut résoudre cette problématique.

Merci pour le temps que vous voudrez bien me consacrer.