[ Introducció ] [
Cas-Estudi
] [ Instal·lació ] [ Configuració
base ] [ Àlies ] [ NAT
] [ Regles ] [ DNS ] [ DHCP
] [ Cabal ] [ OpenVPN
] [ Portal ]
[ OpenVPN sense DHCP ] [ spamd
]
Objectius
Balanceig de càrrega de les ADSL
Les comunicacions peer-to-peer (P2P)
FTP-Proxy Helper
DMZ (zona desmilitaritzada)
Estats i diagnosi
Aïllar físicament i lògicament les xarxes dedicades a servidors, professorat, alumnes i sensefils (wireless). Seguretat de dins a dins.
Regular les comunicacions entre les diferents xarxes locals i de les xarxes locals a Internet. Seguretat de dins a dins i de dins a fora.
Aprofitar el cabal de les tres ADSL de que es disposa, a poder ser de forma automàtica. Balanceig de càrrega.
Augmentar la seguretat en els serveis que tenim a Internet. Seguretat de fora a dins.
Poder tenir una xarxa sensefils (wireless) oberta.
Utilitzar una solució oberta, de codi lliure.
Utilitzar un hardware de tamany reduït, integrable dins l'armari de comunicacions.
Utilitzar un hardware no basat en disc dur, que no requereixi protecció amb un SAI d'apagada i engegada automàtics.
Poder configurar tots els dispositius de la xarxa (ordinadors, impressores, punts d'accés, ...) per DHCP estàtic, és a dir, assignant-los una adreça IP en funció de la seva adreça MAC.
Control de l'ús d'aplicacions P2P.
Estandarditzar i automatizar la configuració dels navegadors pel que fa a ús de servidors proxy i la configuració de xarxa de totes les màquines.
Esquemàticament, el muntatge ha quedat tal com mostra la figura (observeu que hi ha d'haver sis xarxes diferenciades AAA, BBB, CCC, XXX, YYY i ZZZ):
Pràcticament tots els objectius han estat assolits amb escreix, fora d'algunes limitacions que s'han trobat. pfSense té moltes funcionalitats, però cal tenir en compte que algunes són incompatibles entre elles. I, per tant, s'ha de triar llavors quina és la millor opció. S'expliquen a continuació doncs les decisions adoptades.
pfSense permet balanceig de càrrega amb detecció de fallada (fail-over), la qual cosa és molt interessant si es té més d'una ADSL. Aquesta prestació permet doncs equilibrar les càrregues de les ADSL i en cas de fallada d'una d'elles redireccionar el seu trànsit cap una altra.
pfSense empra per al balanceig el dimoni (daemon) slbd. Com la majoria de balancejadors, la seva intenció és millorar la navegació per Internet i no entén les connexions múltiples. Això descarta el seu ús en accessos FTP. Per tant, o es renuncia a balanceig o es renuncia a FTP. O bé es munta un altre pfSense exprés per a FTP. Es va decidir renunciar al balanceig.
El balanceig es configura definint una pila (pool) on s'indica la IP pública de cada ADSL (IP a monitoritzar) i la IP privada per la qual s'hi accedeix. Llavors pfSense comprova periòdicament si l'ADSL en qüestió està funcionant, fent-li un ping. Cal, per tant, que la IP pública de l'ADSL contesti a aquests ping interns. Del contrari, pfSense no sap veure si l'ADSL està activa.
Les comunicacions peer-to-peer (P2P)
Un altre dels maldecaps dels administradors de xarxa són les descàrregues indiscriminades emprant programes com Emule o Ares: ocupació d'ample de banda, problemes de seguretat, ilegalitat, ...
Una solució dràstica és fer que les connexions a Internet es permetin només pels ports (serveis) més usuals (80, 443, 21, 53, 119, ...) A http://www.iana.org/assignments/port-numbers trobareu la llista oficial de ports.
L'altra solució és fer servir el regulador de cabal (traffic shaper) ALTQ que té pfSense i posar els accessos P2P a la cua de prioritats. És una solució que requereix un cert afinament però és la més recomanable. Actualment té la limitació que només es pot fer servir ALTQ entre una de les LAN i una de les WAN del tallafocs (és a dir, ALTQ a pfSense no és multiWAN, però s'està treballant perquè ho sigui ...)
En tot cas, tant si es fa servir una solució o altra, ha d'entrar en joc una altra prestació de pfSense: FTP-Proxy Helper.
Es tracta d'una funcionalitat de Packet Filter (PF), que permet que la pròpia màquina (127.0.0.1) faci de proxy per a les connexions FTP. D'aquesta manera queda obviat el problema de que un client FTP operi amb el servidor no només pel port 21 sinó també amb un port dinàmic, que està per damunt del 1023 i que es confon a la vegada amb un accés P2P.
Malauradament FTP-Proxy Helper tampoc és multiWAN, la qual cosa vol dir que sempre surt/entra per la porta d'enllaç per defecte que tingui el nostre pfSense. Per això a l'esquema anterior es pot veure que només se l'ha activat per a la xarxa Alumnes, a l'igual que ALTQ.
Si teniu més curiositat de com funciona FTP-Proxy Helper visiteu http://www.openbsd.org/faq/pf/ftp.html#client
A l'esquema de més amunt es pot veure que no hi ha una DMZ (zona desmilitaritzada) pròpiament dita. S'ha renunciat a ella perquè implicava un profund canvi a l'estructura de servidors, es necessitava una setena tarja de xarxa en el tallafocs i un altre concentrador de xarxa (switch) per a la DMZ. Tot i que no tenir una DMZ no és una situació ideal, l'adopció de pfSense amb l'estructura proposada és, sens dubte, un important augment de seguretat.
pfSense té tota una sèrie d'eines que permeten veure amb tot detall què està passant o què ha passat. Estat de les connexions, gràfics de l'ús de cada interfície (històrics i en temps real), eines de diagnosi, ... L'administrador de xarxa té doncs amb pfSense les eines necessàries per prendre decisions sobre el trànsit a la seva xarxa.
Autor: Josep
Pujadas i Jubany
© 2006-2007. Tots els drets reservats