Implementació d'un sistema d'autenticació RADIUS d'alta disponibilitat

PROJECTE FINAL DE CARRERA IMPLEMENTACIÓ D’UN SISTEMA D’AUTENTICACIÓ RADIUS D’ ALTA DISPONIBILITAT IMPLEMENTATION OF A HIGH AVAILABILITY RADIUS AUTHENTICATION SYSTEM Estudis: Enginyeria de Telecomunicació Autor: Xavier Bové Sánchez Director: Jordi Pérez Romero Any: 2013 1 Índex general Índex general ...................................................................................................... 1 Índex de taules ................................................................................................... 4 Índex de figures .................................................................................................. 5 Acrònims ............................................................................................................ 7 Col·laboracions .................................................................................................. 9 Resum del Projecte .......................................................................................... 11 Resumen del Proyecto ..................................................................................... 13 Abstract ............................................................................................................ 15 1 Introducció ................................................................................................. 17 1.1 Objectius ............................................................................................ 17 1.2 Estructura de la memòria ................................................................... 18 2 Fonaments teòrics ..................................................................................... 19 2.1 Conceptes bàsics de seguretat .......................................................... 19 2.1.1 Autenticació d’usuaris ................................................................... 19 2.2 Arquitectura AAA................................................................................ 20 2.3 RADIUS ............................................................................................. 23 2.3.1 Seqüència d’autenticació AAA de RADIUS .................................. 26 2.4 Estàndard 802.1x ............................................................................... 28 2.4.1 EAP .............................................................................................. 29 2.4.1.1 LEAP ...................................................................................... 30 2.4.1.2 EAP-TLS ................................................................................ 30 2.4.1.3 EAP-TTLS .............................................................................. 31 3 Descripció general de la solució ................................................................ 33 4 Implementació de la solució ...................................................................... 37 4.1 Requeriments ..................................................................................... 37 4.1.1 Virtualització ................................................................................. 37 4.1.2 Sistema operatiu ........................................................................... 37 4.1.3 Alta disponibilitat ........................................................................... 37 4.1.4 Conexió remota ............................................................................ 38 4.1.5 Hardware ...................................................................................... 38 2 4.2 Entorn de desenvolupament .............................................................. 38 4.2.1 Creació de les màquines virtuals .................................................. 38 4.2.2 Descripció de l’entorn de proves d’autenticació ............................ 38 4.3 Instal·lació i configuració del sistema operatiu ................................... 40 4.3.1 Particionament dels discs ............................................................. 44 4.3.2 Configuració de la xarxa ............................................................... 51 4.4 Instal·lació i configuració del sistema d’alta disponibilitat ................... 54 4.4.1 Instal·lació i configuració del DRBD .............................................. 54 4.4.2 Instal·lació i configuració del Heartbeat ........................................ 70 4.5 Instal·lació i configuració dels serveis a disposar en alta disponibilitat 74 4.5.1 Instal·lació i configuració Apache2 ............................................... 74 4.5.2 Instal·lació i configuració Mysql .................................................... 75 4.5.3 Instal·lació i configuració de FreeRadius i DaloRadius ................. 79 5 Creació de serveis i usuaris en DaloRadius .............................................. 94 5.1 Creació d’un usuari ............................................................................ 94 5.2 Creació de serveis ............................................................................. 96 6 Migració de RadiusManager a DaloRadius ............................................. 103 7 Testeig del sistema ................................................................................. 110 7.1 Testeig de la conectivitat de xarxa ................................................... 110 7.2 Testeig del sistema de replicació de dades DRBD .......................... 111 7.3 Testeig del sistema de replicació de serveis Heartbeat ................... 113 7.4 Testeig del sistema RADIUS ............................................................ 118 7.4.1 Proves en local ........................................................................... 118 7.4.2 Proves en remot ......................................................................... 120 8 Implementació de solucions als problemes sorgits ................................ 122 8.1 Control de l’execució del Heartbeat ................................................. 122 8.2 Control de l’execució del servei FreeRadius .................................... 123 8.3 Replicació dels fitxers de configuració ............................................. 125 8.4 Correcció de bug en l’interfície DaloRadius ..................................... 127 8.5 Correcció del comportament del fitxer d’arrencada d’Ubuntu .......... 127 9 Monitorització i manteniment del sistema................................................ 129 9.1 Monitorització i manteniment del DRBD ........................................... 129 3 9.2 Monitorització i manteniment del Heartbeat ..................................... 130 9.3 Monitorització i manteniment dels serveis a replicar ........................ 131 9.3.1 Monitorització i manteniment d’ Apache2 ................................... 131 9.3.2 Monitorització i manteniment de Mysql ....................................... 132 9.3.3 Monitorització i manteniment del sistema RADIUS ..................... 132 10 Conclusions ......................................................................................... 136 11 Possibles millores del sistema ............................................................. 137 12 Apèndix ................................................................................................ 138 12.1 Característiques dels servidors ........................................................ 138 12.2 Comparativa ext3 vs ext4 ................................................................. 139 12.3 Creació de la màquina virtual ........................................................... 139 13 Referències ......................................................................................... 144 4 Índex de taules Tabla 5.1: Taula d’atributs d’un servei amb assignació IP POOL................... 101 Tabla 5.2: Taula d’atributs d’un servei amb assignació NAS IP o DHCP ....... 102 Tabla 5.3: Taula d’atributs d’un servei amb assignació IP fixa ....................... 102 Tabla 6.1: ETL entre RadiusManager i DaloRadius I ..................................... 103 Tabla 6.2: Creació taula intermedia ................................................................ 104 5 Índex de figures Figura 2.1: Infraestructura de clau pública PKI ...................................... 25 Figura 2.2: Seqüència AAA de RADIUS .................................................... 28 Figura 2.3: Comunicació EAP i pila de protocols utilitzats .................... 29 Figura 2.4: Certificat TLS enviat al NAS per part del servidor RADIUS ......................................................................................................................... 31 Figura 2.5: S’estableix el tunel TLS .......................................................... 31 Figura 2.6: Autenticació interna ................................................................ 31 Figura 3.1: Esquema de la solució ............................................................ 34 Figura 3.2: Cluster Actiu/Passiu DRBD ..................................................... 35 Figura 4.1: Esquema PPPoE Servidor/Client ........................................... 39 Figura 4.2: RouterBoard 433 ..................................................................... 40 Figura 4.3: Diagrama d’una configuració RAID 5 ................................... 42 Figura 4.4: Assignació nom del servidor .................................................. 43 Figura 4.5: Configuració nom usuari ........................................................ 43 Figura 4.6: Configuració contrasenya d’usuari ....................................... 43 Figura 4.7: Creant particions I ................................................................... 44 Figura 4.8: Creant particions II ................................................................. 45 Figura 4.9: Creant particions II ................................................................. 46 Figura 4.10: Creant particions III ............................................................. 46 Figura 4.11: Creant particions IV .............................................................. 47 Figura 4.12: Creant particions V ............................................................... 47 Figura 4.13: Creant particions VI .............................................................. 48 Figura 4.14: Creant particions VII ............................................................ 48 Figura 4.15: Creant particions VIII ........................................................... 49 Figura 4.16: Creant particions IX .............................................................. 49 Figura 4.17: Administració d’actualitzacions ........................................... 50 Figura 4.18: Selecció de programes per instal·lar ................................. 50 Figura 4.19: Pantalla de login del servidor daloRadius01 .................... 51 Figura 4.20: Escriptura en el Bitmap ........................................................ 63 Figura 4.21: Importació del certificat de Motorola Canopy .................. 91 Figura 4.22: Pàgina d’inici de DaloRadius ............................................... 93 Figura 5.1: Pàgina d’inici de DaloRadius .................................................. 94 Figura 5.2: Creació d’un usuari en DaloRadius ....................................... 95 Figura 5.3: Assignació d’un atribut d’usuari en DaloRadius ................. 96 Figura 5.4: Creació d’un servei en DaloRadiusI ..................................... 97 Figura 5.5: Creació d’un servei en DaloRadius II ................................... 97 Figura 5.6: Creació d’un servei en DaloRadius III ................................. 98 6 Figura 5.7: Creació d’un servei en DaloRadius IV .................................. 99 Figura 5.8: Creació d’un Pool d’IPs I ...................................................... 100 Figura 5.9: Creació d’un Pool d’IPs II ..................................................... 101 Figura 6.1: Creació d’una connexió a una BBDD amb Workbench ... 104 Figura 6.2: Creació d’una connexió a una BBDD amb Workbench II105 Figura 6.3: SQL Editor del Workbench ................................................... 106 Figura 6.4: Gestionar importació amb Workbench .............................. 106 Figura 6.5: Gestionar importació amb Workbench II .......................... 107 Figura 7.1: WinBox..................................................................................... 121 Figura 7.2: WinBox creació de pool d’IPs .............................................. 121 Figura 9.1: Pàgina d’inici d’Apache2 ....................................................... 131 Figura 9.2: Activació del GIS de DaloRadius ......................................... 134 Figura 12.1: Característiques dels servidors ......................................... 138 Figura 12.2: Comparació ext3 vs ext4 ................................................... 139 Figura 12.3: Creació màquina virtual ..................................................... 140 Figura 12.4: Creació màquina virtual II ................................................. 140 Figura 12.5: Creació màquina virtual III ............................................... 141 Figura 12.6: Creació màquina virtual IV ................................................ 141 Figura 12.7: Creació màquina virtual V ................................................. 142 Figura 12.8: Creació màquina virtual VI ................................................ 142 Figura 12.9: Creació màquina virtual VII .............................................. 143 Figura 12.10: Creació màquina virtual VIII ........................................... 143 7 Acrònims ADSL BBDD CA CPD CPU DHCP DNS DRBD DVD EAP EAPOL EAP-TLS ETL GB Gbps GRUB IEEE IP LAMP LAN LVM MB Mbps MD5 Asymetric Digital Subscriber Line Base de dades Certificate Authority Centre de processament de dades Central Processing Unit Dynamic Host Configuration Protocol Domaine Name System Distributed Replicated Block Device Digital Versatile Disc Extensible Authentication Protocol EAP over LAN EAP Transport Layer Security Extracty Transform and Load Giga Byte Giga bits per second Grand Unifier Bootloader Institute of Electrical and Electronics Engineers Internet Protocol Linux Apache Mysql Php Local Area Network Logical Volume Manager Mega Byte Mega bits per second Message Digest algorithm 5 14 15 Abstract In this final degree project I have designed, proposed and implemented an “Open Source” solution for a RADIUS authentication system with high availability. Both hardware and software implementations have been carried out with the aim of replacing a server which had the proprietary solution RadiusManager. First, I have worked in a development or layout environment using the virtual machine for the emulation of two servers. Later, I have implemented the solution in a preproduction environment with real servers that have been used to test the correct behavior of the system. In this same environment I have done a migration of the users from RadiusManager and I have created some profiles and services in DaloRadius that covers the three kinds of IP assignments that the solution can offer when the user logs in or identifies him or herself. When I have checked that the high availability works and the users can identify themselves and receive the service that has been designed, I have proceeded to move the servers in a CDP, the final production environment. In the CPD I have checked again the correct behavior of the whole system and I have given 15 period days of production working simultaneously with the server that contains RadiusManager. Finally, with the servers settled in the CPD and having completed the first validation of 15 days, I have done a trespassing from the database to the proper RadiusManager system in order to make the migration to new servers in the most possible atomical way, trying to avoid losing users unregistered during this process. To sum up, during the migration the process must not add new users to the database. During this process I have had to modify the code of the operative system as well as the creation of some scripts or patches to get the best expected behavior from the system. 16 17 1 Introducció En l’actualitat l’ús de xarxes inalàmbriques està molt estès gràcies als seus avantatges en quant a mobilitat, flexibilitat, productivitat i moltes altres, i per aquest motiu no és estrany trobar-les en aeroports, campus universitaris, cafeteries etc. En contraposició als avantatges que les xarxes inalàmbriques presenten, aquest tipus d’implementacions porten diversos riscos de seguretat, la majoria associats a la inexistència de delimitació física de forma clara, i altres més importants associats a la carència de mecanismes de seguretat suficientment robustos que protegeixin l’accés als recursos tecnològics i a la informació. A mesura que la tecnologia ha anat evolucionant s’han proposat vàries recomanacions per dotar d’un nivell de seguretat adequat a les xarxes inalàmbriques que segueixen l’estàndard 802.1X com poden ser les Wi-Fi o Wimax. Entre les solucions més eficients pel que fa al control d’accés als recursos és la implementació del protocol d’autentificació, autorització i accounting també conegut com protocol AAA, per mitjà d’una infraestructura o sistema RADIUS. L’avantatge d’aquest sistema és la capacitat de poder autenticar els usuaris que pretenen accedir a un recurs de forma remota i centralitzada. Aquesta gestió de l’autenticació centralitzada d’usuaris és especialment útil a mesura que el volum d’usuaris registrats augmenta, ja que l’habilitació o inhabilitació de l’accés al recurs per part d’un usuari es pot realitzar de forma molt més ràpida i simple, que si es disposés d’un sistema descentralitzat. Actualment hi ha plataformes o sistemes que realitzen aquesta tasca. Alguns són propietaris com és el cas de RadiusManager, que a mesura que el nombre d’usuaris a autenticar augmenta el cost de la llicència augmenta en proporció.[1]¡Error! No se encuentra el origen de la referencia. Afortunadament també hi ha sistemes de lliure distribució totalment open source que implementen la solució RADIUS com és el cas del sistema format per DaloRadius i FreeRadius, que seran utilitzats en la realització d’aquest projecte.[2]-[14] 1.1 Objectius L’objectiu d’aquest projecte és donar resposta a la necessitat d’un client de disposar d’una forma centralitzada la gestió de les credencials d’autenticació i accounting dels seus usuaris en substitució d’una solució propietària. 18 Es disposa del hardware que formarà la nova infraestructura i la tasca que s’encomana és la d’implementar la solució a nivell de software. Per tal de garantir més robustesa davant possibles eventuals errors en el sistema es proposa un cluster de servidors en alta disponibilitat amb redundància. Per gestionar les credencials d’autenticació d’usuari de forma centralitzada s’utilitzarà el sistema open source format per FreeRadius com a servidor d’autenticació que implementa el protocol RADIUS, i DaloRadius com a frontend del sistema. 1.2 Estructura de la memòria La memòria s’ha estructurat en els següents capítols. El primer del qual en forma part aquest apartat on s’ha realitzat una introducció a la temàtica i el context en que s’emmarca aquest projecte, així com els objectius que s’han perseguit en la realització d’aquest projecte. En el segon capítol s’expliquen els fonaments teòrics en els que aquest projecte s’emmarca. En el tercer apartat del projecte es realitza una descripció general del sistema que s’ha implementat a mode resum. En els blocs quatre, cinc i sis s’ha detallat tot el procés per realitzar la implementació de la solució, descrivint de forma didàctica els diferents processos o fases que aquest ha comptat. En el capítol set s’han detallat les proves realitzades per tal de verificar el correcte funcionament del sistema. Pel que fa al capítol vuit es mostren els problemes sorgits durant tot procés d’implementació i les solucions que s’han implementat per resoldre’ls. Al capítol nou es mostren les comandes o instruccions que s’han utilitzat al llarg de tot el projecte, indicant els procediments a seguir per tal de poder mantenir el sistema en cas de que es produeixi algun error. Finalment en els capítols deu i onze s’exposen les conclusions extretes després de realitzar aquest projecte per part de l’autor d’aquesta memòria així com les limitacions i possibles punts de millora d’aquest respectivament. 19 2 Fonaments teòrics Per entendre l’arquitectura de la solució primerament s’ha de conèixer que és el protocol d’autenticació RADIUS. Abans fins i tot convindria aclarir alguns conceptes de seguretat. 2.1 Conceptes bàsics de seguretat Hi ha moltes formes de definir el concepte de seguretat, la que actualment es segueix pel que fa a seguretat de dades és la que conforma sis elements atòmics de la informació com són confidencialitat, possessió o control, integritat, autenticitat, disponibilitat i utilitat. El concepte de confidencialitat fa referència a mantenir en secret la informació excepte a aquells que tenen autorització per accedir-hi. Integritat significa que s’ha d’assegurar que la informació no ha estat alterada per mitjans o agents no autoritzats o desconeguts. El concepte de possessió o control fa referència a la capacitat de controlar la informació així com s’utilitza. S’enten per disponibilitat que tots els agents utilitzats pel processament de la informació així com els que serveixen per facilitar la seguretat estiguin actius i per tant es pugui accedir a la informació quan es requereixi. El valor de la informació resideix en la seva utilitat, és a dir no té sentit disposar d’unes dades que no poden ser interpretades com pot ser una informació xifrada sense cap sistema que la pugui desxifrar, en aquest cas la informació no és útil. Finalment el concepte d’autenticitat defineix la possibilitat d’un usuari d’establir l’origen de la informació de forma que cap altre agent pugui fer-se passar per un altre usuari. 2.1.1 Autenticació d’usuaris Autenticació és l’acció d’establir o comprovar si una entitat disposa d’unes credencials vàlides, és a dir, que un ens les reconeix com a vàlides. En el cas d’aquest projecte es parla d’autenticar usuaris o clients per tal d’accedir a serveis. L’autenticació és la base dels controls d’accés ja que els sistemes han de ser capaços d’identificar i diferenciar entre els diversos usuaris. 20 Convindria fer una distinció entre els termes identificació i autenticació, ja que no són el mateix. Identificació és el medi que un usuari o client proporciona a un sistema per afirmar una identitat, en canvi autenticació es el medi que estableix la validesa d’aquesta afirmació. Pensant en un esquema de control d’accés a través d’identificador (ID) i contrasenya, l’usuari s’identifica amb el seu ID el qual és conegut per l’administrador del sistema i fins i tot per altres usuaris, però la forma en que s’autentica es mitjançant la seva contrasenya secreta. Tot mecanisme d’autenticació ha de seguir a grans trets un procés com el que tot seguit es mostra: 1. L’usuari demana accés a un recurs. 2. El sistema li sol·licita el seu medi d’autenticació. 3. L’usuari entrega les seves credencials d’autenticació. 4. El sistema verifica les credencials d’usuari. 5. El sistema proporciona o nega l’accés al recurs a l’usuari en funció de si les credencials són correctes o no.. 2.2 Arquitectura AAA En seguretat informàtica l’acrònim AAA correspon a uns tipus de protocols que realitzen tres funcions: Autenticació, Autorització i Accounting. En l’arquitectura AAA existeixen diferents components com són:  Sol·licitant: és l’equip o usuari que sol·licita autenticació.  NAS Network Access Server : és l’equip de xarxa que fa de porta d’entrada física i tramita l’autenticació. Aquest equip és qui inicia la seqüència d’autenticació al detectar una connexió activa, per això se’l coneix també com a autenticador.  Servidor d’autenticació: és el que dirigeix tot el procés AAA dels equips i usuaris que sol·liciten accés, pot fer el paper de proxy derivant les consultes a altres servidors.  Servidor de directori o servidor de base de dades d’usuaris i credencials: és al que el servidor d’autenticació va a consultar les dades d’autenticació dels sol·licitants d’accés. Aquest servidor pot ésser físicament la mateixa màquina que el servidor d’autenticació.  Proveïdors de serveis o SP: és el propietari de la infraestructura d’accés a la que es connecta l’usuari i per tant és el propietari del servidor AAA i del NAS. 21 Amb la infraestructura que formen els components anteriorment descrits es pretén implementar les tres As. La primera A correspon a autenticació, que com anteriorment s’ha esmentat, autenticació és el procés pel que una entitat prova la seva identitat a una altra. Normalment la primera entitat és el client i la segona un servidor. L’autenticació s’aconsegueix presentant una proposta d’identitat (nom d’usuari) i la demostració d’estar en possessió de les credencials que permeten comprovar-la. Els primers sistemes d’autenticació utilitzaven una estructura simple de nom d’usuari i contrasenya en text pla, basant tot aquest sistema en aquestes dues dades, que podrien ser fàcilment interceptats. Amb el temps es va millorar aquests sistemes mitjançant el “desafiament” o challenge. En aquests sistemes no hi ha intercanvi de contrasenyes durant el transport de l’autenticació, sinó mitjançant l’encriptació de missatges usant una mateixa clau i algoritme. El procés d’autenticació dins l’arquitectura AAA es pot realitzar seguint diferents esquemes:  Seqüència d’agent. En aquesta seqüència, el servidor AAA actua com a delegat entre l’equipament que dona el servei i l’usuari final. L’usuari contacta inicialment amb el servidor AAA el qual autoritza la seva petició i notifica a l’equipament de la seva decisió de que se li presti el servei a l’usuari. L’equipament del servei notifica al servidor AAA quan s’ha complert la petició, i el mateix servidor AAA notifica en última instancia a l’usuari. [15]  Seqüència de pull. És la més freqüent en serveis dial (de marcació telefònica) tradicionals. L’usuari realitza la petició directament al NAS, i aquest comprova amb el servidor AAA si se li ha de proporcionar accés o no en funció de les credencials. [15]  Seqüència de push. Aquesta seqüència fa que l’usuari demani algun tipus de certificació al servidor AAA, la qual haurà de presentar més endavant a l’equipament que li presta el servei per tal de garantir la seva identitat i accés a aquest. [15] En aquest projecte s’utilitzarà la seqüència pull. Seguint amb aquesta seqüència, en el procés d’autenticació l’usuari no interacciona directament amb el servidor d’autenticació, sinó que ho fa amb el NAS o autenticador i és aquest qui tradueix o encamina els paquets cap el servidor d’autenticació. En la fase d’autenticació es produeix un missatge inicial de sol·licitud d’accés des del NAS cap al servidor d’autenticació, prèviament el sol·licitant envia al NAS una sol·licitud d’accés Access-Request , enviant el nom d’usuari i la contrasenya xifrada. El NAS envia al servidor d’autenticació un missatge Access-Request sol·licitant també el port d’accés pel sol·licitant. 22 Pel que fa a la segona funció que el protocol AAA realitza, és a dir autorització fa referència a la concessió de privilegis específics a una entitat o usuari basant-se en la seva identitat (autenticada), els privilegis que sol·licita, i l’estat actual del sistema. Entre aquets privilegis que es poden aconseguir està l’assignació d’adreça IP i ample de banda (privilegis que s’utilitzen en aquest projecte). En la fase d’autorització el servidor d’autenticació respon la sol·licitud d’autenticació mitjançant un missatge enviat al NAS per permetre, denegar o tornar a demanar més informació per a autenticar-se. Els missatges emprats són bàsicament:  Acceptació d’accés o Access-Accept  Denegació d’accés o Access-Reject  Sol·licitud d’informació addicional per l’accés (Access-Challenge). S’entén per accounting al seguiment del consum de recursos de xarxa per part dels usuaris. Aquesta informació pot utilitzar-se posteriorment per l’administració, planificació facturació o altres propòsits. L’accounting en temps real és aquell en que les dades generades s’entreguen al mateix temps que es produeix el consum dels recursos. En contraposició la comptabilització per lots consisteix en la gravació de les dades de consum per la seva entrega en un moment posterior. La informació típica que un procés d’accounting o comptabilitat registra és la identitat de l’usuari, el tipus de servei que te associat, l’instant en que es va començar a utilitzar el servei i l’instant en que finalitza l’ús. [16] Durant aquesta fase es produeixen el següents missatges:  Sol·licitud d’inici d’accounting o Accounting-Request [Start]. Sol·licitud d’inici enviada pel NAS al servidor, que indica que ha començat la fase d’accounting i es començaran a registrar les dades de sessió d’usuari.  Resposta d’assentiment o prohibició al inici d’accounting o AccountingResponse [Start] o Accounting-Response [Stop] enviat del servidor d’autenticació al NAS.  Sol·licitud de final d’accounting o Accounting-Request [Stop]. El NAS comprova que hi ha desconnexió amb l’usuari i li envia el missatge al servidor d’autenticació. AAA es versàtil, ja que no suporta un únic mètode d’autenticació sinó que és considerat com un protocol extensible ja que admet qualsevol tipus d’autenticació que s’integri o adapti al seu format de missatges i arquitectura, de fet hi ha diferents protocols que implementen AAA com són RADIUS, DIAMETER, TACACS o TACACS+. En aquest projecte s’utilitzarà RADIUS. 23 2.3 RADIUS RADIUS també és conegut com servidor d’autenticació, autorització remota per a sistemes de marcatge telefònic a xarxes. Aquest nom prové dels seus inicis, on el seu únic ús era l’accés a xarxes a través de módem, però actualment té una funcionalitat molt més àmplia. El motiu pel qual RADIUS és el protocol AAA més estès en l’actualitat entre d’altres motius és per que ha anat creixent, evolucionant i millorant des del seu inici. Malgrat algunes de les seves limitacions, ha adoptat una sèrie de millores que li han permès gestionar des de petites xarxes segures fins a xarxes d’alt nivell. RADIUS és un servei, també anomenat en l’entorn Linux “dimoni”, el qual s’executa en una de les múltiples plataformes que permet, entre elles UNIX, GNU/Linux, Windows... i que està de forma passiva escoltant sol·licituds d’autenticació fins que aquestes es produeixen. Per fer-ho utilitza el protocol UDP i roman a l’escolta en els ports 1812 o 1645 per autenticació i 1813 o 1646 per accounting. El protocol RADIUS està basat en un model client-servidor, ja que RADIUS escolta i espera de forma passiva les sol·licituds dels seus clients o del NAS, que respon de forma immediata. En aquest model, el client és el responsable de l’enviament i la correcta recepció de les sol·licituds d’accés, i és el servidor RADIUS el responsable de verificar les credencials de l’usuari, que en cas de ser correctes enviarà al NAS els paràmetres de connexió necessaris per a presentar el servei. El motiu pel qual RADIUS justifica l’ús del protocol UDP enlloc del TCP és per aprofitar la capacitat del protocol UDP que manté una còpia del paquet de sol·licitud sobre la capa de transport amb l’objectiu de poder-lo recuperar per reenviar-lo en cas que sigui necessari a un altre servidor RADIUS si el primer no estigués disponible. D’aquesta manera es simplifica el disseny del protocol, evitant així haver-se de fer càrrec del control d’arribada dels paquets al seu destí. Donat que UDP no és un protocol orientat a connexió, les retransmissions es realitzaran més ràpidament cap als servidors ja que el port no quedarà col·lapsat pel control de la connexió evitant-se així les esperes que es produirien en el protocol TCP. RADIUS disposa d’una extensa varietat de mòduls d’autenticació que es pot anar ampliant a mesura que n’apareixen de nous ja que és un protocol extensible. Aquest mòduls d’autenticació contenen una sèrie de funcions matemàtiques encarregades de realitzar el xifrat, desxifrat i empaquetat dels processos d’autenticació. Quan el servidor RADIUS rep una sol·licitud d’accés, 30 d’autenticació el PAP i el CHAP. PAP és un mecanisme de d’autenticació de baixa seguretat, ja que permet transmetre contrasenyes sense xifrar. EAP està definit en el RFC 3748 i al ser “extensible” o tenir l’estatus de framework es permet que pugui ser modificat per incloure nous mètodes d’autenticació. En el cas de transmissions inalàmbriques, EAP és utilitzat com s’ha vist abans per l’estàndard 802.1x per realitzar la comunicació entre els dispositius que intervenen en l’autenticació del client. Tot seguit es descriuen alguns dels mètodes d’autenticació que disposa el framework EAP. ¡Error! No se encuentra el origen de la referencia.[16] 2.4.1.1 LEAP LEAP (Lightweight Extensible Authentication Protocol) va ser dissenyat per la companyia CISCO Systems per tal de proveir al seus sistemes d’una autenticació robusta i a la vegada senzilla d’implementar. Aquest sistema, donat el seu caràcter propietari, només se`n pot fer ús en dispositius CISCO i alguns compatibles amb aquests. Aquest sistema utilitza un servidor RADIUS el qual també ha de ser de CISCO. Amb això es limita l’agilitat del sistema donada l’obligació d’utilitzar dispositius del fabricant. Donat que LEAP utilitza el sistema d’autenticació CHAP el qual és insegur, actualment s’ha desaconsellat el seu ús per part del propi fabricant. [16] 2.4.1.2 EAP-TLS Aquest mètode és el més robust de tots els mètodes d’autenticació que implementa EAP. EAP-TLS considera la xarxa inalàmbrica totalment insegura, és a dir com si es tractés de la xarxa d’Internet la qual cosa implica que l’autenticació ha de ser mútua, per tant el client i el servidor han de ser autenticats. L’autenticació es realitza per mitja de certificats digitals, amb la qual cosa es requereix disposar d’una estructura PKI (Public Key Infrastructure). Aquesta estructura de clau pública assegura que l’autenticació és completa i segura. Els certificats proporcionen autenticació entre usuaris i servidor evitantse així possibles atacs de suplantació de l’access point. A més donat que els certificats digitals inclouen claus criptogràfiques, aquests proporcionen un mètode per a distribuir claus de xifrat de forma segura. 31 2.4.1.3 EAP-TTLS Aquest sistema és similar al EAP-TLS però únicament s’utilitza el certificat del servidor, és a dir no es requereix que cada usuari emeti un certificat. L’autenticació d’usuaris es realitza mitjançant contrasenya, però les credencials de la contrasenya es transporten en un túnel encriptat TLS mitjançant el certificat digital del servidor d’autenticació (en el qual es confia ja que està firmat per una autoritat certificadora CA). Un cop establert el túnel segur, s’envia l’autenticació d’usuari original que ja no depèn del mètode EAP. Tot seguit es mostren els passos realitzats en un procés d’autenticació via EAP-TTLS. Figura 2.4: Certificat TLS enviat al NAS per part del servidor RADIUS En el primer pas el servidor d’autenticació determina que un usuari ha fet una petició d’autenticació i conseqüentment envia el seu certificat al usuari. Figura 2.5: S’estableix el tunel TLS Un cop s’ha establert el tunnel TLS, les credencials es poden intercanviar de forma segura entre el servidor i l’usuari ja que el túnel encripta totes les dades que es transmeten per ell. Aquesta etapa es coneix com inner Authentication o autenticació interna, tal com es pot veure en la següent figura. Figura 2.6: Autenticació interna 32 Com es pot veure amb aquest mètode s’elimina part de la infraestructura PKI, ja que no són necessaris els certificats d’usuari, només es requereix la contrasenya per part de l’usuari i la identitat.[16] 33 3 Descripció general de la solució En aquest apartat es mostrarà quina solució s’ha utilitzat per proveir d’un sistema centralitzat d’autenticació d’usuaris via RADIUS en alta disponibilitat. Es parteix d’un usuari que vol accedir a la xarxa, a través del seu router. Per poder-ho fer aquest router ha de tenir accés als recursos que un proveïdor de serveis d’internet ISP li ofereixi. El proveïdor de servei te un contracte amb l’usuari on s’estipula quins serveis té contractats així com les dades de l’usuari. Des del punt de vista tècnic per l’ISP el client és el router. Per tal que el client pugui accedir a internet primer ha d’autenticar-se. L’autenticació la realitza l’autenticador o NAS que és l’encarregat de consultar en la base de dades de l’empresa proveïdora de serveis d’internet, si hi apareixen les credencials d’aquest client. Aquesta base de dades està emmagatzemada en un servidor d’autenticació RADIUS. Un cop el servidor comunica al NAS que les credencials són correctes aquest proporciona accés als serveis al client, com pot ser l’assignació de la IP pública al router o client. A partir d’aquí el router dona accés als usuaris assignant-los-hi IPs internes o privades. Tot aquest procés per realitzar l’autenticació d’un client, requereix d’una gestió i d’una infraestructura que ho permeti. Aquesta infraestructura és propietat de l’empresa que ofereix els serveis. L’objectiu de la solució d’aquest projecte és precisament proporcionar i configurar aquesta infraestructura per tal que la gestió de l’autenticació es realitzi de forma centralitzada. A més es vol que les dades estiguin protegides davant de possibles fallades del servidor d’autenticació o dels serveis que hi conté. A efectes pràctics es pretén que els responsables d’introduir els usuaris en la base de dades del servidor d’autenticació puguin accedir-hi sempre i de forma ininterrompuda, és a dir es vol que el sistema estigui en alta disponibilitat. Per tal d’assolir l’alta disponibilitat del sistema s’empraran dos servidors RADIUS idèntics amb les seves bases de dades que guardaran les dades dels usuaris i clients. La inserció dels usuaris a la base de dades i l’assignació dels serveis o recursos que tenen contractats es realitzarà a través de la interfície web DaloRadius, que accedirà al servidor d’autenticació a través d’una IP virtual. Aquesta IP, apuntarà a un dels dos servidors RADIUS, aquell que en aquell moment estigui en funcionament. 34 En la següent figura es mostra un esquema o diagrama de tot el sistema i més endavant es detallaran cadascun dels components que el formen i quina funció tenen. Figura 3.1: Esquema de la solució Com es pot apreciar en la imatge anterior el sistema està format per dos servidors RADIUS amb dues interfícies de xarxa cadascun, la eth1 és la que s’utilitza per la replicació de dades del DRBD i per la eth0 és té visibilitat cap al router que dona accés a internet. El DRBD (Distributed Replicated Block Device) és un sistema de replicació de dades que forma un cluster de servidors en els que les dades que s’emmagatzemen, es generen o es modifiquen són replicades en tots els nodes o servidors que formen aquest cluster, de manera que en cas que algun dels servidors fallés no es perdria la informació. El sistema DRBD pot treballar en diversos modes en funció del rol que assumeixen cada servidor, és a dir, pot ser que en un cluster de dos servidors un servidor tingui el rol d’actiu i l’altre de passiu, el que equival a dir que un és primari i l’altre secundari, respectivament. El node que té el rol de primari té accés a la base de dades i pot per tant realitzar operacions d’escriptura, lectura o modificació de les dades, mentre que el secundari no hi té accés, tot i que internament hi ha una comunicació peer-to-peer amb l’altre servidor i va 35 replicant les dades en un dispositiu del DRBD que fins que no estigui muntat en una partició no es pot accedir. Només quan el servidor assoleix el rol de primari és quan munta el dispositiu DRBD (que conté la base de dades) en la partició que està reservada per aquest dispositiu. L’altre mode de funcionament del DRBD és que ambdós servidors siguin actius i per tant puguin accedir a la base de dades que romandran sincronitzades en ambdós servidors. En aquest projecte s’ha utilitzat el cluster en mode Actiu/Passiu tal com il·lustra la següent figura: Figura 3.2: Cluster Actiu/Passiu DRBD Com es pot apreciar en la figura anterior hi ha dos nodes (cadascun d’ells associats a un dels dos servidors RADIUS), el primari i el secundari que en el cas del primari té muntat el dispositiu /dev/drbdN que conté la base de dades, en la partició /dev/sda. Ambdós nodes coneixen l’estat de l’altre a través d’una comunicació peer-to-peer que com ja s’ha comentat abans a part de transmetre les dades per replicar els canvis del servidor actiu al passiu, s’envien paquets de control de l’estat o rol, de forma que ambdós nodes saben quin rol han de tenir i si l’altre node ha fallat o no. En cas que el node actiu falli, el secundari ho detectarà a través de la comunicació peer-to-peer i canviarà el seu rol passant a ser el node actiu o primari. Fins aquí es contempla el que seria l’alta disponibilitat de dades, ja que, sigui en un node o en l’altre, la base de dades sempre estarà accessible. Tot i que no és del tot cert, ja que pot donar-se el cas que el node actiu funcioni correctament a nivell de hardware, la comunicació entre ambdós nodes és correcta, però no obstant el servei de base de dades falli, en aquest cas el servei Mysql. Arribat a aquest punt ja no es pot garantir l’alta disponibilitat de la base de dades. Per tal de poder corregir això és necessari l’ús d’un sistema que monitoritzi els serveis que hi ha i que en cas que l’error es produeixi a nivell software pugui detectar-ho i en conseqüència actui avisant al node secundari per tal que sigui ell qui assumeixi el rol de primari arrencant els serveis i posant en definitiva el sistema disponible. 36 Per realitzar aquesta tasca de monitorització i replicació de serveis garantint doncs l’alta disponibilitat de serveis s’utilitza el mòdul software Heartbeat. Seguint amb la figura 3.1 entre el switch i el router s’hi troba la IP virtual que generà el Heartbeat i per on s’accedirà al servidor RADIUS que en aquest moment estigui com a primari. Per defecte el servidor RADIUS 1 estarà com actiu o primari, així doncs la IP virtual de cara al client és transparent. A través d’aquesta s’accedirà a la interfície DaloRadius des d’un navegador tan sols dirigint-se a http://<ip virtual>/daloradius. Tal com es veu en la il·lustració el concepte de client pel que fa a l’arquitectura RADIUS és el servidor d’accés a la xarxa NAS que és el primer dispositiu en la xarxa IP a proveir serveis a un usuari. Si s’agafa com a perspectiva el sistema d’autenticació 802.1x el client en aquest cas són els usuaris que es connecten a la xarxa mitjançant el seu router, són els sol·licitants, la figura del NAS correspondria a la de l’autenticador, i finalment entre el NAS i el servidor RADIUS s’hi estableix una comunicació via el protocol RADIUS. Cal esmentar que els protocols de comunicació que es pot utilitzar per transmetre els paquets d’autenticació EAP són el protocol EAPoL i el PPPoE. En la il·lustració es mostra l’arquitectura client/servidor del protocol PPPoE però ambdós protocols són vàlids. El protocol PPPoE és molt utilitzat ja que és anterior al EAPoL i s’utilitza molt amb la tecnologia ADSL sent per tant un protocol molt estès. Actualment encara s’utilitza tot i ser menys eficient que el protocol EAPoL ja que encapsula els paquets utilitzats per l’autenticació en més trames que les que utilitza EAPoL generant així un overhead superior. Concretament en el protocol PPPoE els paquets necessaris per l’autenticació van encapsulats dins de trames PPP les quals van encapsulades dins de trames PPPoE les quals van encapsulades en trames Ethernet. Pel que fa al protocol EAPoL els paquets EAP van encapsulats directament a la trama Ethernet. 37 4 Implementació de la solució 4.1 Requeriments Per la realització d’aquest projecte s’han emprat tres entorns de treball que són: desenvolupament, preproducció i producció. 4.1.1 Virtualització Per l’entorn de desenvolupament s’ha utilitzat la versió gratuïta de VMPlayer v8.3 per crear dues màquines virtuals que emularan els dos servidors RADIUS de la figura 3.1. 4.1.2 Sistema operatiu S’hi ha instal·lat en ambdues màquines virtuals la versió 12.04.1 LTS 64 bits d’Ubuntu Server. Com el seu nom indica Ubuntu Server és una edició creada específicament per a servidors. Com a tal a priori s’instal·la sense una interfície gràfica ja que el que es pretén és que ofereixi el màxim rendiment. No obstant és possible instal·lar-hi una, tot i que en aquest cas no es farà. S’ha triat aquesta versió a part de per ser una distribució de Linux gratuïta, per la seva estabilitat i el suport, com l’acrònim LTS (Long Term Support) indica. A més s’ha utilitzat la versió de 64 bits per poder aprofitar les 16GB de memòria RAM que els servidors porten incorporats de sèrie, ja que amb la versió de 32 bits únicament es poden adreçar fins a 3GB. 4.1.3 Alta disponibilitat Tal com s’ha comentat a la secció 3 s’ha optat pel parell DRBD + Heartbeat com a solució d’alta disponibilitat, DRBD com a mòdul de replicació de dades en mode actiu/passiu, la versió 2 de Heartbeat per a la monitorització de l’estat dels serveis. S’ha instal·lat Apache2 com a servidor web i com a base de dades s’ha optat per MYSQL. Els motius pels que s’ha utilitzat l’esmentada base de dades en comptes d’altres també opensource és per qüestions de compatibilitat amb el sistema RADIUS que s’ha emprat. Finalment, com a sistema d’autenticació RADIUS s’ha utilitzat FreeRadius + DaloRadius, sent aquest últim el frontend que es comunica amb la implementació del protocol RADIUS, FreeRadius. 38 4.1.4 Conexió remota Per poder conèixer la plataforma RadiusManager s’ha tingut accés a mode de “read only” al servidor de producció del client, accedint a la seva xarxa de forma remota mitjançant la seva VPN. Per connectar remotament amb el servidor s’ha realitzat via el protocol SSH, mitjançant el client Putty [20] ja que permet tenir múltiples finestres obertes sobre un mateix servidor, la qual cosa resulta d’especial utilitat per a poder tenir visualitzats en pantalla diversos processos com pot ser la monitorització dels logs de les aplicacions que es vol monitoritzar. 4.1.5 Hardware En l’entorn de preproducció i producció s’han utilitzat dos servidors allotjats en una cabina per la fase de preproducció i en un CPD en la fase de producció veure les especificacions a l’anex 12.1 Característiques dels servidors. Per la interconnexió dels servidors s’han utilitzat 4 cables Ethernet Full Duplex. Per l’encaminament s’ha utilitzat un switch connectat a ambdós servidors i a la xarxa interna del client, d’on es dona sortida cap a la backbone. 4.2 Entorn de desenvolupament Com s’ha comentat anteriorment per provar les configuracions del sistema, i posteriorment aplicar-les als servidors de producció, s’han emulat ambdós servidors mitjançant dues màquines virtuals, que òbviament no poden emular al cent per cent les especificacions dels servidors ja que els recursos des d’on s’han creat són limitats, és a dir la màquina que conté les màquines virtuals té menys capacitat que els servidors emulats. 4.2.1 Creació de les màquines virtuals Per la creació de les màquines virtuals s’ha d’arrencar el software VMWarePlayer que és de distribució gratuïta i pot obtenir-se des de la pàgina web oficial del producte. [23] Veure apèndix Creació de màquina virtual per més informació sobre el procés. 4.2.2 Descripció de l’entorn de proves d’autenticació Per tal de realitzar proves d’autenticació es pretén reproduir la part de la figura 3.1 formada per el NAS que en aquest cas també se’l pot anomenar PPPoE Server i el router de l’usuari que en l’arquitectura del protocol PPPoE és el PPPoE client. Un servidor PPPoE o NAS pot autenticar múltiples clients així com assignar-los-hi els recursos que cada usuari tingui contractats. La següent figura intenta il·lustrar l’escenari que s’està esmentant. 39 Figura 4.1: Esquema PPPoE Servidor/Client A l’hora de realitzar proves d’autenticació s’ha utilitzat un dispositiu que s’anomena RouterBoard 433 de Mikrotik que fa de PPPoE Server o NAS i o PPPoE Client. El RouterBoard 433 és una placa amb circuits integrats que disposa de 3 ports ethernet. Veure figura 4.2. En el primer port es connecta el gateway/firewall que correspon al cable gris de la figura 4.2 el qual es connectarà a la xarxa del subministrador del servei. Pel que fa al port eth2 és el que correspon al servidor PPPoE o NAS i el port eth3 es correspon al client PPPoE que pot ser des d’un usuari que es connecta directament al servidor fins a un router que donarà connexió als usuaris. En aquest cas aquest pas intermedi no hi és i per tant el client es connecta directament al servidor connectant amb un cable ethernet els ports eth2 i eth3 tal com mostra el cable blau en la figura 4.2. 46 En la figura següent es mostra les opcions de configuració de la partició així com la nova partició buida que s’ha generat. Figura 4.9: Creant particions II Seleccionant la partició buida dirigirà cap un menú on permetrà crear una segona partició així com definir la capacitat de cadascuna de les particions ja creades. Figura 4.10: Creant particions III 47 Figura 4.11: Creant particions IV L’estructura de particions que s’utilitzarà en aquest projecte serà la de dues particions, i opcionalment si es perceben problemes de rendiment linux té l’avantatge de poder crear diverses àrees d’intercanvi swap. A cada àrea se li assigna una prioritat de 1 fins a 32, i el sistema treballarà o utilitzarà cada àrea segons ho requereixi en funció de la prioritat establerta. Si s’assignen per exemple dues zones swap amb prioritat 1 pot produir un empitjorament del rendiment. Així doncs a priori es crearan dues úniques particions, la corresponent a root i la que utilitzarà el DRBD per a muntar la unitat que anirà replicant entre un servidor i l’altre. Cal establir o fixar les mateixes particions en ambdós servidors, amb les mateixes capacitats, especialment en la partició destinada a replicació utilitzada pel DRBD. L’assignació de les capacitats es realitzarà tenint en compte l’ús que se’n farà del servidor. Presumiblement el que mes volum de dades generà serà la base de dades que allotjarà les dades dels clients i que és el que es vol replicar, per tant es destinarà el 70% de la capacitat total dels disc durs per a la partició del DRBD i el 30% restant per a la partició root. Es defineixen ambdues particions com a primàries: Figura 4.12: Creant particions V La partició root s’ubicarà al principi de l’espai de memòria lliure del disc dur, que en aquest cas degut a ser la primera partició definida també ocuparà el principi de la memòria del disc dur. Pel cas de la partició del DRBD ocuparà també el principi de la memòria lliure del disc dur, seguint doncs l’espai que ha ocupat la primera partició. 48 Figura 4.13: Creant particions VI En la següent captura es mostra com queda configurada la partició root, com es pot veure es defineix com a punt de muntatge “ / ” que indica el directori arrel. Pel que fa al sistema de fitxers s’utilitza el ext4 que és l’evolució del antics ext2 i ext3. Com a millora respecte els seus antecessors ext4 suporta volums de fins a 1024 PiB, fa un menor ús de la CPU i augmenta la velocitat de lectura/escriptura.(veure apèndix 12.2 Comparació entre ext3 vs ext4) Figura 4.14: Creant particions VII Pel que fa a la segona partició a l’opció de Utilitzar como es triarà la de no usar la partición. 49 Figura 4.15: Creant particions VIII Evidentment no tindrà cap punt de muntatge ni cap format, d’això serà el DRBD el que se n’encarregarà. Finalment les particions queden definides com es mostra en la imatge següent, amb dues particions primàries. Figura 4.16: Creant particions IX Un cop definides les particions es continua amb l’assistent d’instal·lació fins que s’atura en la finestra d’administració d’actualitzacions del sistema: 50 Figura 4.17: Administració d’actualitzacions Donat que el que es busca en aquests servidors és la màxima estabilitat possible, s’optarà per l’opció de Sin actualizaciones automáticas ja que es pot donar el cas que s’actualitzi algun component i pugui produir conflictes o incompatibilitats i per tan generar-se errors. Qualsevol canvi de configuració o actualització prèviament s’ha de testejar en l’entorn de desenvolupament abans de traslladar-lo a l’entorn de producció. Per tal de poder accedir al servidor via SSH s’ha d’instal·lar el OpenSSH server, així doncs es marca com a opció com es mostra en la següent captura. Figura 4.18: Selecció de programes per instal·lar Notar que entre la llista de programes que permet instal·lar hi ha el conjunt LAMP server corresponent a Apache Mysql i PHP per a Linux. Malgrat que 51 s’utilitzaran els tres, s’ha optat per instal·lar-los de forma separada, per poder testejar part a part cada bloc. A més a més molt possiblement aquest paquet no contingui les últimes versions de cada programa o pel contrari potser conté versions massa noves i incompatibles amb altres programes o mòduls que s’instal·laran més endavant. Així doncs poder triar la versió de cada mòdul amb la que treballar és l’opció que s’ha triat. Continuant amb el procés d’instal·lació seleccionem l’opció de que instal·li GRUB. Es un gestor d’arrancada, és el primer que es carrega quan s’inicia el servidor. Permet tenir diferents sistemes operatius i versions d’aquests. Amb la instal·lació del GRUB es finalitza la instal·lació del sistema operatiu Ubuntu Server, la següent pantalla que es mostrarà serà la de login del servidor. Figura 4.19: Pantalla de login del servidor daloRadius01 Per logar-se s’ha d’introduir usuari i com a contrasenya password. 4.3.2 Configuració de la xarxa Per tal de poder utilitzar els servidors amb una certa estabilitat és important configurar les IPs estàtiques, ja que en cas d’apagada o tancament de sessió del servidor, en una configuració DHCP s’assignarà una nova adreça IP, la qual cosa no és convenient ja que aplicacions com el DRBD o Heartbeat requereixen tenir una IP fixa. Així doncs per configurar la IP fixa s’ha d’editar el fitxer d’interfaces. Com a editor s’ha utilitzat VIM. Tot i que evidentment hi ha múltiples opcions per triar. Cada modificació de fitxers es realitzarà en mode super usuari, així com qualsevol ordre, per això es posarà devant de la sentència, la paraula reservada sudo que solicitarà la contrasenya per poder accedir a super usuari. S’edita el següent fitxer: $ sudo vim /etc/network/interfaces El contingut del fitxer per al servidor primari daloRadius01 queda de la següent forma: # The loopback network interface auto lo iface lo inet loopback # The primary network interface 52 auto eth0 iface eth0 inet static address 172.18.2.130 netmask 255.255.255.248 gateway 172.18.2.129 broadcast 172.18.2.135 dns-nameservers 8.8.8.8 8.8.4.4 auto eth3 iface eth3 inet static address 172.18.2.132 netmask 255.255.255.248 network 172.18.2.129 broadcast 172.18.2.135 Pel que fa al servidor secundari daloRadius02 el fitxer d’interfícies queda: # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 172.18.2.131 netmask 255.255.255.248 gateway 172.18.2.129 broadcast 172.18.2.135 dns-nameservers 8.8.8.8 8.8.4.4 auto eth3 iface eth3 inet static address 172.18.2.133 netmask 255.255.255.248 network 172.18.2.129 broadcast 172.18.2.135 Com es pot apreciar hi ha definides dues interfícies, la eth0 i la eth3 en ambdós servidors. Per ambdues interfícies es defineix IP estàtica mitjançant la sentencia: iface eth0 inet static iface eth3 inet static La eth0 tindrà conexió directa al Gateway que li dona visibilitat cap a internet, per aquest motiu s’hi defineixen dues adreces IP de servidors DNS gratuïts, en aquest cas s’han utilitzat els de GOOGLE. També s’ha de definir l’adreça del Gateway, que per la interfície eth3correspondrà a l’adreça de xarxa. 53 L’adreça de broadcast s’ha calculat a partir del rang d’IPs que el client ha subministrat és a dir a partir de l’adreça del Gateway o xarxa i de la màscara de xarxa. La eth3 s’utilitzarà per comunicar a través del DRBD ambdós servidors, per aquest motiu es defineix una subxarxa sense visibilitat cap a l’exterior. Per tal de poder accedir a un servidor a través del seu Hostname en comptes de la seva adreça IP, és necessari que es mapegin els Hostname d’ambdos servidors amb les seves respectives IPs. Per fer-ho s’ha d’editar el següent fitxer en ambdós servidors: $ sudo vim /etc/hosts El contigut del fitxer és idèntic pels dos servidors: 127.0.0.1 localhost 172.18.2.132 daloRadius01 172.18.2.133 daloRadius02 # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters Per a que s’apliquin els canvis realitzats en la configuració de xarxa s’ha de reiniciar el servei com s’indica a continuació. $ sudo /etc/init.d/networking restart En aquests moments si es realitza un ping a qualsevol de les 4 interficies configurades, respondrà correctament, de la mateixa forma si el ping es realitza a través del Hostname, respondrà amb les IPs que s’han mapejat al fitxer hosts. (Veure proves de conectivitat al apartat de Testeig). 54 4.4 Instal·lació i configuració del sistema d’alta disponibilitat Com anteriorment s’ha comentat el sistema d’alta disponibilitat està format pel mòdul de replicació DRBD i pel monitoritzador Heartbeat. També com es veurà més endevant s’ha creat un script per replicar alguns fitxers de configuració necessaris per garantir l’alta disponibilitat dels sistema. 4.4.1 Instal·lació i configuració del DRBD Un cop s’ha instal·lat el sistema operatiu, ja es pot procedir a la instal·lació del DRBD. Primerament per tenir la certesa de que ambdós servidors estan correctament actualitzats, es realitza una actualització mitjançant la següent instrucció: $ sudo apt-get update Per poder començar la instal·lació i configuración del DRBD s’ha de conèixer la disposició de les particions, ja que s’hi haura de fer referència en els fitxers de configuració. Executant la següent instrucció: $ sudo fdisk -l Mostra la taula de particions creades, marcant amb un asterisc la partició que conté el sistema operatiu, és a dir la partició arrel o root. En aquest cas es pot apreciar com la partició root és la corresponent a l’etiqueta /dev/sda1 que està allotjada tal com s’ha defeinit en el procés d’instal·lació a la part del principi del sistema de memòria. Així doncs la partició /dev/sda2 és la que està sense punt de muntatje i sense cap format, i per tan és la que s’emprarà pel DRBD. Disposit. Inicio Comienzo Fin Bloques Id Sistema /dev/sda1 * 1 1946 15624192 83 Linux /dev/sda2 1946 2611 5345280 83 Linux Un cop coneguda la disposició de les particions del disc dur, el primer que s’ha de realitzar és una sincronització dels rellotges d’ambdós servidors, ja que un cop s’activi el DRBD la sincronització i monitorització entre ells serà constant. Per tal de sincronitzar-los s’executa en ambdós servidors la comanda que es mostra a continuació: $ sudo apt-get install ntp ntpdate Ja amb els servidors sincronitzats es pot descarregar i instal·lar la distribució més actualitzada del DRBD mitjançant la següent instrucció, una vegada més en els dos servidors. $ sudo apt-get install drbd8-utils 55 Ja que DRBD està referenciat dins el repositori d’Ubuntu, la comanda anterior funcionarà. En cas que s’utilitzés una distribució diferent no està assegurat que estiguí inclòs en el repositori, no obstant es podria descarregar els arxius binaris via el protocol wget i posteriorment compilar-los i finalment executar-los. Quan s’ha instal·lat el DRBD es procedeix a la seva configuració. Per configurar el mòdul DRBD s’ha d’editar de forma idèntica en els dos servidors el següent fitxer: $ sudo vim /etc/drbd.conf El contingut del fitxer final queda com es mostra a continuació: global { usage-count yes; } common { syncer { rate 100M; } } resource r0 { protocol C; handlers { pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f"; pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f"; #local-io-error "echo o > /proc/sysrq-trigger ; halt -f"; split-brain "/usr/bin/drbd/notify-split-brain.sh root"; } startup { degr-wfc-timeout 60; } disk { on-io-error detach; } syncer { rate 30M; al-extents 257; } net { after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect; } on daloRadius01 { device /dev/drbd0; disk /dev/sda2; address 172.18.2.132:7788; meta-disk internal; } 62  call-pri-lost-after-sb: Invoca a través del parametre pri-lost-after-sb l’script que prèviament s’ha hagut de crear i referenciar en bloc handler.  discard-secondary:Sobreescriu el bloc de dades del node secundari. Finalment el tercer escenari ve representat per after-sb-1pri, el qual contempla la situació en el que un cop produït l’split-brain els dos servidors asumeixen el rol de primari. En aquest context només es pot procedir de dues formes, o en mode disconnect o en mode call-pri-lost-after-sb. Un cop s’han vist les diferents estratègies a seguir en cas de produir-se un split-brain, les opcions que s’han utilitzat en aquest projecte són, pel primer escenari s’aplica el discard-zero-changes ja que és el que garanteix una menor pèrdua de dades. Pel que fa al segon escenari i amb el mateix objectiu que l’anterior s’ha optat per el discard-secondary ja que en el moment que el primari està funcionant les dades són correctes i actualitzades i simplement fent una copia o sobreescribint les dades al secundari s’assegura que no s’ha produït pèrdua de dades. I pel que fa a l’últim escenari s’ha optat per disconnect ja que donat aquesta situació en que tots dos poden intentar escriure asumint el rol de primaris, pot provocar problemes greus d’inconsistència de dades, en aquest cas es prefereix que momentàneament el sistema s’aturi, es desconectin els recursos i no es produeixin escriptures no desitjades. On Finalment per acabar de configurar el recurs, s’ha d’especificar els nodes que compartiran aquest. Per fer-ho es comença amb la instrucció on seguit del hostname del node. Mitjançant el paràmetre device s’assigna el dispositiu que allotjarà aquest recurs. És a dir en aquest cas el recurs que s’ha anomenat r0 s’allotjarà al dispositu /dev/drbd0. Per convenció tot i que no és obligatori si el nom del recurs acaba amb un valor numèric el valor del dispositiu ha d’acabar amb el mateix. Això és especialment útil quan hi ha més d’un recurs creat, alhora de realitzar tasques de manteniment, és més intuitiu relacionar cada recurs amb el seu corresponent dispositiu. Amb el paràmete disk s’indica quina partició utilitzarà el DRBD per muntar el dispositiu. En aquest cas tal i com s’ha definit la taula de particions, la partició emprada és la /dev/sda2. 63 Pel que fa a l’atribut address, s’especifica l’adreça IP de la interfície per la qual el DRBD es comunicarà amb l’altre node o servidor seguit del port. S’utilitzarà un port TCP dins del rang 7788 -7799, en aquest cas s’ha optat pel 7788. Ha d’assegurar-se que el port assignat està lliure i no està sent utilitzat per cap altre servei. Finalment el paràmetre meta-disk és l’encarregat de emmagatzemar meta-data del DRBD. La meta-data són peces d’informació que conté entre d’altres coses el valor del tamany del dispositiu DRBD,el Generation Identifier (GI), els Activity Log (AL) i els quick-sync bitmap. El GI són uns identificadors utilitzats pel DRBD per identificar blocs de dades replicats. Utilitza un mecanisme intern per determinar si els dos nodes pertanyen al mateix cluster, també determina la direcció de la resincronització, és a dir si el nodeA és el que estava primari i per tant havia modificat o escrit noves dades, requereix replicar-les al node B, o si pel contrari és a l’inversa. Amb aquest mecanisme també es determina si es necessita que hi hagi una resincronització total del disc o únicament d’una part de les dades. Els AL són els extents que anteriorment s’ha esmentat en el paràmetre alextents del bloc syncer. Pel que fa al quick-sync bitmap, és una estructura interna de dades que el DRBD utilitza per fer un seguiment dels blocs que estan sincronitzats (sync) o desincronitzats (out-of sync). En aquest paràmetre, un bit representa un tros 4KiB de dades del disc. Si un bit és esborrat significa que el bloc corresponent a aquest està encara sincronitzat amb l’altre node i que per tant no s’ha modificat desde la última desconexió. Si pel contrari el bit no està esborrat representa que el bloc associat ha estat modificat i per tant requereix ser resincronitzat tan aviat com la conexió amb l’altre node estigui disponible. Quan el DRBD detecta una escriptura en un dispositiu desconectat, aleshores comença a establir bits en el quick-sync bitmap Figura 4.20: Escriptura en el Bitmap Quan el node recobra la conexió DRBD combina la informació del bitmap d’ambdós servidors per determinar el total de dades que ha de ser 64 resincronitzada. Simultàniament DRBD examina els GI per determinar la direcció de la sincronització. El node que actua com a font en la sincronització transmet els blocs acordats amb l’altre node i a la vegada va “netejant” els bits de sincronització del bitmap que ja s’han sincronitzat. En el cas que el proces de sincronització fos interrumput per algun error de xarxa o el que sigui, un cop es tornés a aixecar la conexió es continuaria la sincronització des del punt on s’havia deixat i que queda guardat en el bitmap. Un cop conegut què son les meta dades, s’ha de conèixer on s’han d’emmagatzemar. Meta-disk permet definir dos modes de emmagatzematge de les meta dades, els modes internal i external. En el mode internal DRBD enmagatzema la meta data en la mateixa partició on s’ha muntat el dispositu del DRBD és a dir en aquest cas el /dev/sda2, en la part final de la partició. Pel contrari en el mode external la meta data s’emmagatzema en una unitat o partició dedicada per tal efecte. El principal avantatge de tenir un mode internal és que la meta data està intrínsicament vinculada a les dades i per tant al estar al mateix dispositiu no es requereix cap acció d’administració en cas que el disc falli ja que es reestableix automàticament amb les dades, a diferència del mode external. Pel que fa al mode external l’avantatge que té és que per operacions d’escriptura es pot millorar la latència. En el cas de que s’utlitzés un únic disc dur i no un sistema RAID, el mode internal podria provocar una pèrdua del rendiment en l’escriptura, però no és el cas d’aquest projecte. Per tant, valorant la simplicitat en quant administració i no apreciant gran millora en quant a latència es refereix, s’ha optat pel mode d’emmagatzematge de meta data internal. Un cop ja s’ha configurat el fitxer de configuració del drbd.conf, s’ha de procedir a carregar el módul del DRBD al nucli o kernel del sistema operatiu en ambdós servidors per fer això s’aplica la següent instrucció: $ sudomodprobe drbd Si l’operació s’ha realitzat amb èxit el mòdul s’haura carregat dins del directori /etc/modules. També es pot verificar a través de la comanda: 65 $ sudo lsmod | grep drbd Que en cas de càrrega del mòdul de forma correcte mostrarà per pantalla: drbd 268994 0 lru_cache 14896 1 drbd El següent pas és el de crear el meta-disk del recurs que contindrà la meta dataque en aquest cas s’ha anoment r0, en ambdós servidors, així doncs apliquem la comanda que es mostra a continuació: $ sudo drbdadm create r0 En cas que el procés hagi tingut èxit es mostrarà per pantalla: v08 Magic number not found Writing meta data... initialising activity log NOT initialized bitmap New drbd meta data block sucessfully created. success Tot seguit s’ha d’aixecar o activar els recursos en els dos servidors. Això es realitza amb la instrucció: $ sudo drbdadm up r0 Per poder monitoritzar o saber que està passant realment i si en definitiva el procés està produint-se de forma correcta es pot utilitzar la comanda de monitorització: $ sudo watch cat /proc/drbd En aquest punt la sortida que s’espera que mostri la comanda anterior és la següent: version: 8.3.0 (api:88/proto:86-89) GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by buildsystem@linbit, 2008-12-18 16:02:26 0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r--- ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:200768 El que mostra la pantalla anterior és l’estat general del sistema que DRBD gestiona. En primer lloc la primera línia mostra la versió del DRBD que s’està utilitzant. La segona línia conté informació sobre el compilat. El bloc format per les últimes 4 línies restants conté la informació del dispositu DRBD configurat. El prefix 0 indica que aquesta configuració pertany al dispositiu /dev/drbd0. El prefix cs (connection state) indica l’estat de conexió de la xarxa, la qual pot tenir un dels següents estats: 66  StandAlone: No hi ha configuració de xarxa disponible. El recurs no ha estat encara conectat o ha perdut la conexió degut a un error d’autenticació o per un split-brain.  Disconnecting: És l’estat temporal que es dona durant la desconexió just avans de pasar a l’estat StandAlone.  Unconnected: És un estat temporal produït avans d’un intent de conexió. El possibles estats que en derivarà son els WFConnection i WFReportParams.  Timeout: Estat temporal seguint un timeouten la comunicació amb l’altre node, l’estat que el segueix és el Unconnected.  BrokenPipe: Estat temporal que es produeix un cop s’ha estat conectat amb l’altre servidor i de s’obte la conexió per on DRBD es comunica amb l’altre node s’ha tallat, tot i que no necessàriament la conexió de xarxa hagi hagut de deixar de funcionar. El següent estat serà el Unconnected.  NetworkFailure: Es dona després que la conexió de xarxa falli i per tant es perdi la comunicació amb l’altre node. Altre cop el pròxim estat serà el Unconnected.  ProtocolError: Similar a l’anterior estat.  TearDown: Es produeix quan reb una petició de desconexió, en derivarà al Unconnected.  WFConnection: En aquest estat el node està esperant fins que l’altre node es fa visible, és a dir te visiblitat a la xarxa respon a ping.  WFReportParams: S’ha establert una conexió TCP i es manté a l’espera de rebre un packet de l’altre node.  Connected: És l’estat normal i esperat, que es produeix quan la conexió del DRBD s’ha establert i la replicació està activa.  StartingSyncS:És l’estat de sincronització completa iniciada per l’administrador, els possibles estats derivats són SyncSource o PausedSyncS.  StartingSyncT:És l’estat de sincronització completa iniciada per l’administrador, el pròxim estat és el WFSyncUUID.  WFBitMapS: Tot just comença la sincronització parcial que en pot derivar en l’estat PausedSyncS. 67  WFBitMapT: Comença la sincronització parcial i el següent estat pot ser el WFSyncUUID.  WFSyncUUID: En aquest estat la sincronització està per començar. Els possibles estats que el seguiran són SyncTarget o PausedSyncT.  SyncSource: S’esta duent a terme la sincronització essent el node actual l’origen de la sincronització.  SyncTarget:S’esta duent a terme la sincronització essent el node actual el destí de la sincronització.  PausedSyncS: És dona la situació que el disc local d’aquest node havia iniciat una sincronització però actualment està aturada.  PausedSyncT: En aquest cas el disc local es el desti d’una sincronització que s’havia iniciat però que en aquests instants està aturada.  VerifyS: S’està executant una verificació on-line essent el disc local l’origen del procés de verificació.  VerifyT: Com en el cas anterior hi ha una verificació oberta i aquest disc local és el destí. Com s’aprecia en aquest cas ja s’ha produït la conexió per part dels dos servidors i per això indica que està en Connected. Pel que fa al prefix ro, indica el rol que té cada servidor sent el de l’esquerra el node local i el de l’esquerra l’altre node. Bàsicament els rols que un node pot tenir són un dels següents:  Primary: En aquest cas el recurs està en el rol primari o actiu i per tant es pot tan llegir com escriure, aquest rol només succeeix en un dels dos nodes a no ser que s’especifiqui un cluster en mode dual, és a dir més d’un node actiu.  Secondary: En aquest rol es pot rebre les actualitzacions dels blocs escrits o modificats en el node primari, és a dir la replicació, però el recurs no està muntat i per tant no es pot ni llegir ni escriure.  UnKnown: Aquest rol mai es pot donar en el node local, sempre s’ha de donar en el remot, bàsicament es produeix quan es desconeix el rol del node remot ja que no hi ha conexió o esta en mode disconnected. En aquest cas com és el primer cop que s’ha aixecat i carregat els recursos i encara no s’ha realitzat cap sincronització completa és normal que en la captura aparegui que ambdós nodes estan com a Secondary. 68 Pel que fa al prefix ds (disc state) indica l’estat en que es troben els discs. Aquest estat pot ésser un dels que es mostren a continuació:  Diskless: No s’ha assignat un dispositu pel disc del DRBD. Es pot produir després d’una comanda drbdadm detach.  Attaching: Aquest estat es dona de forma transitoria mentre s’està llegint el meta data.  Failed: Estat transitori que es dona després d’un error d’I/O. El següent estat serà el Diskless.  Negotiating: És un estat on s’esta duent a terme un attach amb un dispositu DRBD ja conectat.  Inconsistent:Aquest estat es dona inmadiatament després de la creació d’un nou recurs en ambdós servidors avans de realitzar una sincronització total.  Outdated: El disc conté dades consistents com a secondari però no poden ser utilitzades perquè no han estat sincronitzades.  DUnknown: Aquest estat és utilitzat pel disk remot si no hi ha conexió de xarxa disponible.  Consistent: El disc conté dades consistents però el node no té conexió, tan bon punt es reestableix la conexió es decidirà si les dades passen a ser UpToDate o Outdated.  UpToDate: És l’estat normal i el que s’espera amb les dades consistents. En aquest cas com que encara no s’ha realitzat la sincronització total l’estat del disc en ambdós servidors és el de Inconsistent. En aquesta mateixa línia es mostra el flag d’estat de les operació I/O. En aquest cas està en mode r que indica que està funcionant correctament. Finalment a la última línia es mostren els indicadors de rendiment que són:  ns (network send): Volum en Kibyte de dades enviades al node remot a través de la xarxa.  nr (network receive): Volum en Kibyte de dades rebudes, enviades pel node remot a través de la xarxa.  dw (disk write): Volum en Kibyte de dades escrites en el disc local.  dr (disc read):Volum en Kibyte de dades llegides del disc local. 69  al (activity log): Nombre d’actualitzacions dels activity log del meta data.  bm (bit map): Nombre d’actualitzacions de l’àrea del bitmap del meta data.  lo (local count): Nombre de peticions de processos I/O oberts gestionats pel DRBD.  pe (pending): Nombre de peticions enviades al node remot però que encara no han estat respostes.  ua (unacknowledged): Nombre de peticions rebudes pel node remot però que encara no han estat respostes.  oos (out of sync): Volum en kibibytes de dades emmagatzemades però no sincronitzades. Evidentment en aquest cas la majoria d’aquests paràmetres que es mostren en la captura anterior estaran a 0. Tot seguit es procedirà a realitzar la sincronització entre els nodes, que per ser la primera que es realitza serà una sincronització total, que depenent del tamany del disc dur i de la tasa de sincronització disponible trigarà més o menys. Així doncs amb la següent instrucció executad únicament desde el node primari s’iniciarà la sincronització total: $ sudo drbdadm -- --overwrite-data-of-peer primary r0 En el node primari s’ha de donar format al dispositiu del DRBD és a dir s’estableix el sistema de fitxers ext4. Executan la següent instrucció: $ sudo mkfs.ext4 /dev/drbd0 Finalment ja per acavar la instal·lació del DRBD s’ha de muntar el dispositiu del DRBDcom es mostra a continuació: $ sudomount /dev/drbd0 /mnt Per comprovar que s’ha muntat correctament el dispositiu es pot executar la comanda: $ sudo mount Per pantalla ha d’aparèixer : /dev/drbd0 on /mnt type ext4 (rw) Que indica que el dispositiu del DRBD s’ha muntat en el directori mnt amb un sistema de fitxers ext4 amb permisos de lectura/escriptura. Per tal d’assegurar que el sistema de replicació de dades funciona correctament s’haurà de procedir a testeja el sistema avans de prosseguir amb 70 la instalació del Heartbeat. (Veure l’apartat 7.2 Testeig del sistema de replicació de dades DRBD). 4.4.2 Instal·lació i configuració del Heartbeat Amb la instal·lació del sistema de replicació de dades DRBD, resta instal·lar el sistema de replicació de serveis que en aquest cas és el Hearbeat. Per realitzar la instal·lació de Heartbeat s’ha de descarregar del repositori d’Ubuntu mitjançant la instrucció: $ sudo apt-get install heartbeat Un cop descarregats i instal·lats els paquets del Heartbeat es procedeix a la seva configuració. El primer fitxer que s’ha d’editar és el ha.cf el contingut del qual serà diferent en cada servidor. Mitjançant la següent instrucció s’edita el fitxer: $ sudo vim /etc/ha.d/ha.cf El contingut del fitxer pel node primari és el següent: debugfile /var/log/ha-debug logfacility local0 logfile /var/log/ha-log keepalive 1 deadtime 60 warntime 10 initdead 120 udpport 694 ucast eth0 172.18.2.131 ucast eth3 172.18.2.133 auto_failback on node daloRadius01 node daloRadius02 #bcast eth0 #ping 172.18.2.129 Pel que fa al contingut d’aquest mateix fitxer però pel node secundari és: debugfile /var/log/ha-debug logfacility local0 logfile /var/log/ha-log keepalive 1 deadtime 60 warntime 10 initdead 120 udpport 694 ucast eth0 172.18.2.130 71 ucast eth3 172.18.2.132 auto_failback on node daloRadius01 node daloRadius02 #bcast eth0 #ping 172.18.2.129 El primer atribut que es mostra en el fitxer de configuració és el debugfile, que com el seu nom indica assigna el camí i el fitxer on s’emmagatzemaran els logs que el Heartbeat vagi generant. Tant els atributs logfile com logfacility serveixen per emmagatzemar els missatges que el Heartbeat va generant. La diferència ente el logfile i el logfacility és que el segon retransmet els logs cap al syslog que és el sistema de logs general on a part de capturar el logs del Heartbeat també captura els de tots els serveis que s’estiguin executant i tinguin habilitat el mode debug. El paràmetre keepalive defineix l’espai de temps entre “batecs”. S’entén per batec cada consulta que el Hearbeat realitza per monitoritzar tant l’estat del serveis que vol replicar com la comunicació amb el node remot. El valor de la unitat de temps que pren aquest atribut és en segons. Depenent de la celeritat amb que es pretén que Hearbeat detecti qualsevol canvi en el sistema, aquest valor de temps serà inferior o superior. En aquest cas s’ha optat per un valor de temps entre batecs d’un segon, ja que es vol que el sistema reaccioni de la forma més ràpida possible davant alguna eventual incidència. El següent atribut que s’hi troba és el deadtime. Aquest indica quant de temps ha de passar des de que un node no detecta a l’altre per tal de considerar-lo com mort (dead). Malgrat que el que es busca és que el sistema reaccioni el més ràpid possible davant un eventual error o incidència, establir o fixar un valor de deadtime molt baix pot produir amb més probabilitat que es generi un split-brain amb la qual cosa, el temps que pot passar fins que a través dels mecanismes d’autorrecuperació del sistema es recuperi el funcionament, sigui bastant més alt que el valor establert en el deadtime. Per aquest motiu un valor raonable per aquest atribut pot ser entre 60 i 120 segons. En aquest cas s’ha optat per 60. En l’opció warntime s’especifica el temps en segons que transcorre abans d’iniciar l’avís de l’últim intent d’enviar un ping en la monitorització. Quan es supera aquest període de temps en principi el node no s’hauria de considerar com a mort, per tant el valor del warntime ha de ser inferior al del deadtime. El paràmetre initdead indica el període de temps que ha de transcorrer abans de la posada en marxa del Heartbeat. Si per algun motiu un node no és capaç d’iniciar-se abans no hagi passat el període de temps indicat per initdead, es considera que el node està mort. Aquest valor s’entén que ha de ser superior al de deadtime ja que el temps que una màquina pot arribar a trigar després de 78 I finalment s’assigna el propietari al directori allotjat en el dispositiu del DRBD que conté els fitxers de configuració del servei Mysql de forma idèntica com s’ha realitzat al node primari pel directori data. $ sudo chown mysql:mysql /mnt/mysql/conf –R Tot seguit es comprova que es pot iniciar correctament el servei, que donat que s’ha eliminat el dimoni apparmor no donarà cap problema. Abans d’iniciar el servei, el node secundari ha de tenir rol de primari de forma temporal per tal que la unitat del DRBD estigui muntada en aquest servidor, ja que sinó el servei no es podria iniciar. Per tal que Heartbeat d’igual forma que amb Apache2 es faci càrrec d’iniciar i aturar el servei de forma automàtica en funció del context, s’ha de realitzar dos passos. El primer és crear un script dins del directori /etc/ha.d/resource.d que és on Heartbeat guarda els RA ja que per defecte no es disposa per aquest servei. El nom que tindrà el fitxer d’aquest script ha de seguir una nomenclatura específica per tal que Heartbeat el pugui reconèixer com a RA. El nom doncs ha d’estar format per una primera part seguida d’un punt i acabat amb el sufix resource. El nom que s’utilitzi abans del punt serà el que posteriorment s’afegirà en el haresources. Així doncs donat que el servei es Mysql es crearà el següent fitxer amb el nom mysql.resource en ambdós servidors novament: $ sudo vim /etc/ha.d/resource.d/mysql.resource El contingut del fitxer és l’script que es mostra a continuació: #!/bin/bash # #This script is inteded to be used as resource script by heartbeat # #Mar 2006 by Monty Taylor # ### . /etc/ha.d/shellfuncs case "$1" in start) res=`/etc/init.d/mysql start` ret=$? ha_log $res exit $ret ;; stop) res=`/etc/init.d/mysql stop` ret=$? ha_log $res 79 exit $ret ;; status) if [[ `ps -ef | grep '[m]ysqld'` > 1 ]] ; then echo "running" else echo "stopped" fi ;; *) echo "Usage: mysql {start|stop|status}" exit 1 ;; esac exit 0 Si s’observa amb detall el l’script anterior, el que fa és recollir de la línia de comandes una de les possibles “ordres” d’execució que poden ser aplicades al servei, com són start per arrencar el servei, stop per aturar-lo i status per consultar-ne l’estat, és a dir si està encès o aturat. En funció del paràmetre que se li passa efectua alguna de les tres accions esmentades. Finalment queda el segon pas que com ja s’ha comentat consisteix en afegir el servei a monitoritzar pel Heartbeat dins del fitxer haresources, en els dos servidors. $ sudo vim /etc/ha.d/haresources Així doncs de moment el contingut d’aquest fitxer és: daloRadius01 drbddisk::r0 Filesystem::/dev/drbd0::/mnt::ext4 IPaddr::172.18.2.134/29/eth0 apache2 mysql Com es pot veure s’afegeix mysql en minúscula coincidint amb el nom de l’script. Amb aquest segon pas ja es dona per conclosa la instal·lació i configuració del servei Mysql. 4.5.3 Instal·lació i configuració de FreeRadius i DaloRadius Un cop instal·lats els serveis dels que el sistema RADIUS depèn, ja es pot procedir a la instal·lació dels mòduls que el formen. Primerament s’instal·larà FreeRadius. Per fer-ho s’executarà la següent comanda: $ sudo apt-get install freeradius freeradius-mysql freeradius-utils Com es pot veure des del repositori d’Ubuntu es descarrega els paquets de FreeRadius i els seus connectors amb Mysql. 80 Finalitzada la instal·lació de FreeRadius i abans de procedir a la seva configuració s’instal·larà DaloRadius, que com ja s’ha comentat és el frontend del sistema RADIUS. Per realitzar la instal·lació s’ha de descarregar dins del directori /usr/local/src el codi font, que es pot trobar en els repositoris de sourceforge. Situant-se en el directori esmentat: $ cd /usr/local/src Es descarrega el codi font: $ wget http://sourceforge.net/projects/daloradius/files/latest/download/daloradius0.9-9.tar.gz El pròxim pas a executar és el d’instal·lar les dependències de DaloRadius per tal que pugui funcionar correctament. Aquestes dependències són bàsicament el llenguatge amb el que està creat, és a dir PHP i els connectors amb Apache2 i Mysql. $ sudo apt-get install php5 php5-gd php-pear php-db libapache2-mod-php5 phpmail php5-mysql Un cop instal·lades les dependències es procedeix a descomprimir els fitxers de DaloRadius que prèviament s’han descarregat: $ sudo tar xzf /usr/local/src/daloradius-0.9-9.tar.gz Si el procés de descompressió s’ha realitzat correctament s’haurà generat el directori: /usr/local/src/daloradius-0.9-9 daloradius/ Tot seguit es copia aquest directori al del servei web Apache2 /var/wwwi es renombrarà amb un nom més curt, concretament daloradius: sudo mv -f /usr/local/src/daloradius-0.9-9 /var/www/daloradius El següent pas és assignar al directori daloradius el propietari www-data:wwwdata. Com s’ha realitzat anteriorment s’executa la instrucció: $ sudo chown -R www-data:www-data daloradius A continuació s’assignarà permisos de lectura a tots els usuaris i únicament permisos de lectura i escriptura al usuari root al fitxer de configuració de DaloRadius. Amb la comanda següent es realitza aquest tasca: $ sudo chmod 644 daloradius/library/daloradius.conf.php Per tal que DaloRadius pugui funcionar correctament s’ha de configurar alguns paràmetres del fitxer anterior, així doncs si s’edita: $ sudo vim/var/www/daloradius/library/daloradius.conf.php Els paràmetres que s’han de modificar són els que es mostren a continuació: 81 $configValues['CONFIG_DB_ENGINE'] = 'mysql'; $configValues['CONFIG_DB_HOST'] = 'localhost'; $configValues['CONFIG_DB_PORT'] = '3306'; $configValues['CONFIG_DB_USER'] = 'radius'; $configValues['CONFIG_DB_PASS'] = 'radpass'; $configValues['CONFIG_DB_NAME'] = 'radius'; En primer lloc s’especifica quin motor de base de dades s’utilitzarà, en aquest cas és Mysql. El host que conté la base de dades serà el mateix que està donant el servei FreeRadius per tant serà localhost. En el paràmetre que defineix el port que Mysql utilitzarà s’especifica sempre i quan estigui lliure el que utilitza per defecte, és a dir el 3306. El següent paràmetre a definir és l’usuari, el password i el nom de la base de dades que DaloRadius utilitzarà, s’han deixat els valors per defecte. Amb els paràmetres de la base de dades definits es procedeix a crear-la amb el seu esquema complet, per fer-ho s’utilitzarà un esquema que incorpora el paquet DaloRadius que s’ha descarregat, el qual conté l’estructura de taules per Mysql que tant DaloRadius com FreeRadius utilitzen. Així doncs amb la instrucció següent es crea la base de dades que tindrà per nom radius. $ mysqladmin -u root -p create radius Tot seguit dirigint-se cap al directori on DaloRadius guarda els esquemes: $ cd /var/www/daloradius/contrib/db Es realitza l’importació de l’esquema anteriorment esmentat per generar l’estructura de taules en la base de dades radius que s’acaba de crear. $ mysql -u root -p radius < fr2-mysql-daloradius-and-freeradius.sql Tot seguit s’accedeix a la consola del client de Mysql: $ mysql -u root –p Un cop dins el prompt del client de Mysql mitjançant la següent comanda s’atorgarà tots els permisos al usuari radius sobre la base de dades radius que s’identificarà amb la contrasenya radpass anteriorment definida en el fitxer de configuració de DaloRadius daloradius.conf.php. mysql>GRANT ALL ON radius.* TO radius@localhost IDENTIFIED BY 'radpass'; S’executa la instrucció quit per sortir del client de Mysql: mysql> quit Amb el frontend DaloRadius configurat és el torn de configurar el servei FreeRadius. 82 A l’hora d’autenticar un client FreeRadius permet treballar de dues formes diferents, la primera és la d’anar afegint en el fitxer /etc/freeradius/clients.conf el nom o shortname i contrasenya o secret del client que autenticarà contra el servidor RADIUS. L’altra opció és que aquestes dades es guardin en base de dades i que el servidor FreeRadius vagi a consultar-les allí. Aquesta segona opció és la que s’ha triat amb aquest projecte, per raons òbvies, i és que a mesura que el nombre de clients va augmentant és més pràctic gestionar grans quantitats de dades a través d’una base de dades que no pas des d’un fitxer. Per poder utilitzar la segona opció s’ha d’activar el suport SQL. Per realitzar aquesta tasca s’ha d’editar el fitxer: $ sudo vim /etc/freeradius/radiusd.conf I des-comentar la línia $INCLUDE sql.conf per tal d’habilitar el mòdul sql.conf que és el que s’encarregarà d’accedir a les taules que contenen els paràmetres necessaris per poder realitzar l’autenticació del client. El contingut d’aquest fitxer amb el canvi aplicat destacat és el que es mostra a continuació, : prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = ${exec_prefix}/sbin logdir = /var/log/freeradius raddbdir = /etc/freeradius radacctdir = ${logdir}/radacct # name of the running server. See also the "-n" command-line option. name = freeradius # Location of config and logfiles. confdir = ${raddbdir} run_dir = ${localstatedir}/run/${name} # Should likely be ${localstatedir}/lib/radiusd db_dir = ${raddbdir} libdir = /usr/lib/freeradius pidfile = ${run_dir}/${name}.pid user = freerad group = freerad 83 max_request_time = 30 cleanup_delay = 5 max_requests = 1024 listen { type = auth ipaddr = * port = 0 } listen { ipaddr = * port = 0 type = acct } hostname_lookups = no allow_core_dumps = no regular_expressions = yes extended_expressions = yes log { destination = files file = ${logdir}/radius.log syslog_facility = daemon stripped_names = no auth = no auth_badpass = no auth_goodpass = no } checkrad = ${sbindir}/checkrad security { max_attributes = 200 reject_delay = 1 status_server = yes } proxy_requests = yes $INCLUDE proxy.conf 84 thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } modules { $INCLUDE ${confdir}/modules/ $INCLUDE eap.conf $INCLUDE sql.conf $INCLUDE sqlippool.conf } instantiate { exec expr expiration logintime } $INCLUDE policy.conf $INCLUDE sites-enabled/ Com es pot apreciar en aquest fitxer de configuració central de Freeadius es defineix el sistema de directoris de l’aplicació així com el propietari del directoris, és a dir el usuari i grup que com es pot veure en aquest cas és freerad, freerad. També es defineixen el nombre màxim de peticions, i el rang d’IPs i ports per on s’escoltarà i acceptaran peticions d’autenticació i accounting. Més avall en el fitxer es referencia on s’emmagatzemarà els logs així com alguns paràmetre de seguretat. Finalment al bloc modules hi apareixen els mòduls que hi ha habilitats, entre ells el que s’acaba d’habilitar el sql.conf. Amb les la base de dades creada amb l’esquema de les taules importat, i l’activació del mòdul SQL es preparà FreeRadius per connectar-lo posteriorment amb la base de dades Mysql. Per fer-ho s’ha d’editar el mòdul SQL: $ sudo vim /etc/freeradius/sql.conf En aquest fitxer es defineixen els paràmetres de connexió de la base de dades que en aquest cas es mantindran valors per defecte. També s’hi defineixen les taules de la base de dades i on es guardaran les dades, per exemple es pot apreciar com els valors que contenen la informació dels clients que autenticaran contra RADIUS s’emmagatzemaran a la taula nas. I que per que 85 RADIUS llegeixi els clients d’aquesta taula la variable readclients ha de tenir assignat el valor yes. El contingut final del fitxer un cop configurat (subratllat en groc els canvis importants) és el següent: sql { # # Set the database to one of: # # mysql, mssql, oracle, postgresql # database = "mysql" # # Which FreeRADIUS driver to use. # driver = "rlm_sql_${database}" # Connection info: server = "localhost" port = 1812 login = "radius" password = "radpass" # Database table configuration for everything except Oracle radius_db = "radius" # If you are using Oracle then use this instead # radius_db = "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA =(SID=your_sid)))" # If you want both stop and start records logged to the # same SQL table, leave this as is. If you want them in # different tables, put the start table in acct_table1 # and stop table in acct_table2 acct_table1 = "radacct" acct_table2 = "radacct" # Allow for storing data after authentication postauth_table = "radpostauth" authcheck_table = "radcheck" authreply_table = "radreply" groupcheck_table = "radgroupcheck" groupreply_table = "radgroupreply" # Table to keep group info 86 usergroup_table = "radusergroup" # If set to 'yes' (default) we read the group tables # If set to 'no' the user MUST have Fall-Through = Yes in the radreply table # read_groups = yes # Remove stale session if checkrad does not see a double login deletestalesessions = yes # Print all SQL statements when in debug mode (-x) sqltrace = no sqltracefile = ${logdir}/sqltrace.sql # number of sql connections to make to server num_sql_socks = 5 # number of seconds to dely retrying on a failed database # connection (per_socket) connect_failure_retry_delay = 60 # lifetime of an SQL socket. If you are having network issues # such as TCP sessions expiring, you may need to set the socket # lifetime. If set to non-zero, any open connections will be # closed "lifetime" seconds after they were first opened. lifetime = 0 # Maximum number of queries used by an SQL socket. If you are # having issues with SQL sockets lasting "too long", you can # limit the number of queries performed over one socket. After # "max_qeuries", the socket will be closed. Use 0 for "no limit". max_queries = 0 # Set to 'yes' to read radius clients from the database ('nas' table) # Clients will ONLY be read on server startup. For performance # and security reasons, finding clients via SQL queries CANNOT # be done "live" while the server is running. # readclients = yes # Table to keep radius client info nas_table = "nas" # Read driver-specific configuration $INCLUDE sql/${database}/dialup.conf } 87 Un altre mòdul que s’havia habilitat en el /etc/freeradius/radiusd.conf i que també s’ha de configurar és: $ sudo vim /etc/freeradius/sqlippool.conf El contingut del qual un cop configurat és: sqlippool { ######################################### ## SQL instance to use (from sql.conf) ## ## ## If you have multiple sql instances, such as "sql sql1 {...}", ## use the *instance* name here: sql1. ######################################### sql-instance-name = "sql" ## SQL table to use for ippool range and lease info ippool_table = "radippool" ## IP lease duration. (Leases expire even if Acct Stop packet is lost) lease-duration = 3600 ## Attribute which should be considered unique per NAS ## Using NAS-Port gives behaviour similar to rlm_ippool. (And ACS) ## Using Calling-Station-Id works for NAS that send fixed NAS-Port ## ONLY change this if you know what you are doing! #pool-key = "%{NAS-Port}" pool-key = "%{Calling-Station-Id}"quit ################################################################ # # WARNING: MySQL has certain limitations that means it can # hand out the same IP address to 2 different users. # # We suggest using an SQL DB with proper transaction # support, such as PostgreSQL, or using MySQL # with InnoDB. # ################################################################ # # Use the same database as configured in the "sql" module, "database" # configuration item. Change the "postgresql" name below to be the # same as the "database" field of the SQL module referred to in the # "sql-instance-name", above. # 94 5 Creació de serveis i usuaris en DaloRadius En el present apartat es detallaran les passes a seguir per a la creació dels tres tipus d’usuaris utilitzats a través de la interfície de DaloRadius, així com la creació de serveis o profiles que s’assignaran als usuaris. Els tres tipus d’usuaris que abans s’ha esmentat corresponen a les tres formes diferents com s’assignen les IPs als usuaris. 5.1 Creació d’un usuari Primerament per poder accedir dins del menú de DaloRadius es requereix introduir les credencials, que en aquest cas són com a username = “administrator” i com a password = “radius”. Figura 5.1: Pàgina d’inici de DaloRadius Per crear un usuari s’ha de dirigir-se a l’etiqueta Management, dins d’aquesta al subtag Users. Un allí dirigir-se a l’opció New User, la qual ens mostrarà un formulari on introduir les dades de l’usuari com el username i password. Per crear un usuari és tan simple com introduir el nom i password i clicar el botó Apply. El problema és que no tindria assignat cap servei per tant a efectes pràctics tot i que autentiqués no es beneficiaria de cap servei. Per assignar un servei a l’usuari s’ha de seleccionar el que en aquesta pantalla mostra com a Groups. (pas 6). S’entén que prèviament hauran estat creats els serveis. En la següent il·lustració es pot veure de forma numerada els passos esmentats: 95 Figura 5.2: Creació d’un usuari en DaloRadius Les dades d’usuari que s’insereixen en aquesta vista es guarden en la taula de radchecki part de la taula userinfo de la base de dades radius que anteriorment s’ha creat. Hi ha casos en que als usuaris se’ls hi ha d’assignar algun atribut que complementi els serveis que tinguin assignats, com pot ser el cas de l’assignació d’una IP fixa que requereix un atribut d’usuari. Això és el que en la captura anterior mostra el pas 7. En la imatge que es mostra a continuació es veu el procés d’assignació d’un atribut d’usuari, concretament el Framed-IP-Address que s’utilitza per establir una IP fixa, com es veurà en el pròxim apartat. 96 Figura 5.3: Assignació d’un atribut d’usuari en DaloRadius 5.2 Creació de serveis En aquest apartat es mostrarà com crear un mateix servei però per les tres formes diferents d’assignació d’IP al client. Per la creació d’un servei s’ha d’accedir al subtag Profile si en el menú Profiles Management seleccionar New Profile (pas 2): 97 Figura 5.4: Creació d’un servei en DaloRadiusI Després d’executar el pas 2 es dirigirà cap a la pantalla de creació del perfil o servei: Figura 5.5: Creació d’un servei en DaloRadius II 98 En el pas 1 s’introdueix el nom que tindrà el servei, aquest nom serà el que apareixerà en la llista de grups el qual podrà ser associat a un usuari. Per tal que l’access point pugui donar el servei que se li especifica, s’han de definir alguns atributs que s’afegiran en els paquets que s’enviaran entre el servidor RADIUS i el client. Cada fabricant té els seus atributs tot i que n’hi ha alguns que són estàndards i comuns a tots. En el pas 2 es selecciona el diccionari del fabricant, i en el 3 els atributs que conté el diccionari seleccionat. Per afegir els atributs es clica al botó Add Attribute i es mostrarà a la part inferior de la pantalla on se li haurà de configurar els seus paràmetres: Figura 5.6: Creació d’un servei en DaloRadius III Com es pot veure en la captura anterior a la part inferior de la pantalla hi apareix l’atribut Mikrotik-Rate-Limit del fabricant Mikrotik. Com es pot veure en l’opció Target té per valor reply, això indica que aquest atribut s’enviarà en paquets de tipus “resposta”. Cal esmentar que hi ha dos tipus d’atributs, els reply i els check que es munten en paquets de consulta o de resposta, la majoria dels atributs que s’utilitzaran en el projecte són del tipus reply i només l’atribut que s’encarrega de consultar les IPs d’un pool d’IPs serà del tipus check. Cal fixar-se que en l’opció OP l’operador utilitzat és el “=” , això és així pels atributs de tipus reply, pel que fa als atributs de tipus check l’operador a usar-se és el “:=” . 99 Ja només queda destacar que en el camp Value s’hi assigna el valor que tindrà aquest atribut, en aquest cas com que es tracta de l’atribut que regula el throughput que el client tindrà el valor és el parell de velocitat de pujada/ velocitat de baixada en Mbps. Finalment per confirmar la creació del perfil es clica al botó superior Apply i si s’ha creat correctament i s’ha guardat en la base de dades, en l’opció List Profiles del menú Profiles Management es mostraran els perfils que hi ha i evidentment el que s’acaba de crear, tal com mostra la següent captura: Figura 5.7: Creació d’un servei en DaloRadius IV Un cop s’ha vist el procediment per a crear un servei o profile, tot seguit es detallaran els atributs necessaris per a la creació de tres tipus de serveis que oferiran el mateix throughput, però la manera com es realitzarà l’assignació de la IP al client serà diferent. Les assignacions d’IP que es contemplen en aquest projecte són tres: Assignació d’IP fixa En l’assignació d’IP fixa com es pot preveure, l’assignació es realitza de forma manual assignant una IP a un paràmetre o atribut del tipus reply, concretament al paràmetre Framed-IP-Address del diccionari dictionary.rfc2865. Assignació NAS IP o DHCP En aquest cas l’encarregat d’assignar l’IP al usuari és el NAS via DHCP Assignació IP POOL 100 En l’assignació per IP POOL l’encarregat de subministrar la IP l’usuari és el servidor RADIUS, que utilitzant algún pool d’IPs que s’hagi prèviament inserit en la taula radippool assignarà la IP. En la següent captura es mostra com assignar a través del la interfície de DaloRadius un pool d’IPs: Figura 5.8: Creació d’un Pool d’IPs I El primer pas és seleccionar el subtag IP-Pool. Tot seguit es selecciona l’opció New IP-Pool del menú IP Pools. En el pas 3 s’indica el nom del Pool que contindrà la IP que s’especifica en el pas 4. Finalment fent clic al botó Apply es guarda en la taula radippol. Si s’ha guardat correctament a l’opció List IP-Pool apareixeran totes les IPs amb els seus Pools associats. En la il·lustració que es mostra a continuació es pot veure llistats dos pools que s’han creat (Pool_Prova i Pool_Prova2) amb les IPs associades: 101 Figura 5.9: Creació d’un Pool d’IPs II Un cop vistos els diferents mètodes d’assignació d’IPs es detallaran la llista d’atributs de cada tipus de servei, seguint amb l’exemple anterior amb un rate connexió de 2Mbps /3Mbps. Tot seguit es mostra la taula d’atributs pertanyent al servei Prova 2M/3M IP POOL que com es pot intuir oferirà la connexió 2Mbps de pujada 3Mbps de baixada i l’assignació de la IP la realitzarà el servidor RADIUS agafant-la del llistat d’IPs que conte el pool Pool_Prova assignat a l’atribut tipus check PoolName. L’atribut Service-Type especifica el tipus de servei proveït al usuari entre els possibles tipus de serveis que hi ha són:  Login-User: L’usuari connecta via Telnet, Rlogin, pmd o TCP-Clear  Framed-User: L’usuari utilitza PPP o SLIP per la connexió.  Outbound-User: L’usuari utilitza Telnet per connexions sortints.  Callback-Login-User: Es verifica la identitat de l’usuari desconnectant el port i re-connectant l’usuari a una línia telefònica. En aquest projecte s’ha emprat el servei Framed-User ja que el dispositiu NAS de Mikrotik que s’utilitzarà en aquest projecte treballa amb el protocol PPP. En l’atribut Framed-protocol s’especifica que el protocol de transmissió serà el que s’hagi definit en el Service-Type. I en aquest cas s’opta pel PPP i no SLIP ja que el PPP mica en mica ha anat substituint a SLIP com a protocol de transmissió de datagrames IP. El Framed-MTU defineix el MTU (unitat màxima de transmissió) per la connexió de l’usuari, en aquest cas son 1500 bytes. Atributs Reply Diccionari del Fabricant Atribut Operador Valor dictionary.Mikrotik Mikrotik-RateLimit = 2M/3M dictionary.rfc2865 Framed-protocol = PPP dictionary.rfc2865 Service-Type = Framed-User dictionary.rfc2865 Framed-MTU = 1500 Atributs Check Diccionari del Fabricant Atribut Operador Valor dictionary.freeradius.internal Pool-Name : = Pool_Prova Tabla 5.1: Taula d’atributs d’un servei amb assignació IP POOL 102 El segon servei que es mostrarà és el d’assignació per NAS IP o DHCP i els atributs són els que es mostren en la taula que tot seguit es mostra: Atributs Reply Diccionari del Fabricant Atribut Operador Valor dictionary.Mikrotik Mikrotik-RateLimit = 2M/3M dictionary.rfc2865 Framed-protocol = PPP dictionary.rfc2865 Service-Type = Framed-User dictionary.rfc2865 Framed-MTU = 1500 dictionary.rfc2869 Framed-Pool = Pool_Prova2 Tabla 5.2: Taula d’atributs d’un servei amb assignació NAS IP o DHCP Com es pot veure en la taula anterior, aquest servei només conté atributs de tipus reply i pràcticament són els mateixos que pel cas anterior, excepte el paràmetre Framed-Pool. Aquest atribut té un comportament molt similar al Pool-Name del servei anterior, de fet la única diferència es qui assigna la IP, és a dir en aquest cas el NAS és el que consulta un pool d’IPs prèviament creat i d’aquestes via DHCP assigna una IP al usuari. Com es pot veure en aquest cas a mode didàctic s’ha assignat el valor per aquest atribut Pool_Prova2. Finalment només queda configurar el servei amb assignació d’IP fixa. Atributs Reply Diccionari del Fabricant Atribut Operador Valor dictionary.Mikrotik Mikrotik-RateLimit = 2M/3M Atribut d’usuariReply Diccionari del Fabricant Atribut Operador Valor dictionary.rfc2865 Framed-IPAddress = <IP assignada> Tabla 5.3: Taula d’atributs d’un servei amb assignació IP fixa En aquest cas com en l’anterior només conté atributs de tipus reply, però la diferència és que els atributs que s’han utilitzat fins ara són atributs de perfil o com DaloRadius també anomena de grup, els quals s’emmagatzemen en les taules radgroupreply i radgroupcheck pels atributs reply i check respectivament. En aquest cas un dels atributs reply que s’utilitza és un atribut d’usuari i no de grup i per tant es guardarà en la taula radreply. Concretament l’atribut del que es fa referència és el Framed-IP-Addressel qual indica l’adreça IP que s’assignarà al client. Aquesta assignació es realitza de forma manual. 103 6 Migració de RadiusManager a DaloRadius Com s’ha comentat a l’inici d’aquesta memòria un dels objectius és el de migrar una base de dades del sistema propietari RadiusManager al sistema DaloRadius. Ambdós sistemes reposen sobre la solució FreeRadius, per tant comparteixen les taules d’aquest en les seves base de dades. La forma com cada sistema emmagatzema els usuaris, serveis i altres paràmetres és diferent. Per tant per poder realitzar la migració d’un sistema a l’altre s’ha de realitzar el que es coneix com a ETL que és Extreure Transformar i Carregar , que bàsicament consisteix en fer un estudi complert de les taules de les bases de dades d’ambdós sistemes i conèixer de quina forma emmagatzemen les dades, per tal de realitzar una exportació de les dades del sistema RadiusManager i disposar-les en la forma i en l’estructura amb que DaloRadius treballa. Pot donar-se el cas que en el que en RadiusManager es guarda en una única taula, en DaloRadius se n’utilitzi més d’una és per tan doncs la tasca de extreure i dividir les dades si s’hi escau per finalment inserir-les a la base de dades de DaloRadius. Hi ha un seguit de taules en ambdós sistemes que en aquest projecte no s’han utilitzat, com són les taules encarregades d’emmagatzemar dades de facturació, únicament s’han utilitzat les taules que contenen informació necessària per realitzar l’autenticació i les que contenen els atributs i les definicions dels serveis o perfils. A continuació es mostren les taules emprades en ambdós sistemes així com les relacions que hi ha entre elles: Tabla 6.1: ETL entre RadiusManager i DaloRadius Com es pot veure en la taula de relacions anterior, la taula radusergroup pertanyent a la base de dades del sistema DaloRadius està format per algunes de les columnes o camps que contenen les taules de RadiusManager rm_users i rm_services a més d’altres columnes o camps addicionals que s’hauran d’omplir amb les dades de les columnes d’una taula addicional 110 7 Testeig del sistema L’estratègia que s’ha seguit per testejar el funcionament del sistema, és testejar per separat o de forma aïllada cada servei, i finalment un test global del sistema posant a prova tots els mòduls que composen la solució implementada en aquest projecte. 7.1 Testeig de la conectivitat de xarxa Per començar es comprovarà que ambdós servidors tenen visibilitat entre ells per les dues interfícies de xarxa de que disposen. Per comprovar la visibilitat o connexió entre ells s’utilitzarà la instrucció de xarxa ping. Primer es realitzarà prova de connectivitat del node primari a la primera interfície del secundari, i es repetirà el procés per la segona interfície. Les adreces IP són les següents: Node Primari: Eth0 : 192.168.1.71 Eth1 : 172.168.1.71 Node Secundari: Eth0: 192.168.1.73 Eth1: 172.168.1.73 Es realitza ping a la interfície 0 del servidor secundari: $ ping 192.168.1.73 Si la resposta al executar la instrucció anterior és la que es mostra a continuació, la prova de connexió de primari a eth0 del secundari és exitosa: PING 192.168.1.73 (192.168.1.73) 56(84) bytes of data. 64 bytes from 192.168.1.73: icmp_req=1 ttl=64 time=0.727 ms 64 bytes from 192.168.1.73: icmp_req=2 ttl=64 time=0.466 ms 64 bytes from 192.168.1.73: icmp_req=3 ttl=64 time=0.591 ms Prova de connectivitat servidor primari a interfície eth1 del secundari: $ ping 192.168.1.73 El resultat : PING 172.168.1.73 (172.168.1.73) 56(84) bytes of data. 64 bytes from 172.168.1.73: icmp_req=1 ttl=64 time=0.807 ms 64 bytes from 172.168.1.73: icmp_req=2 ttl=64 time=0.437 ms 64 bytes from 172.168.1.73: icmp_req=3 ttl=64 time=0.430 ms Test superat. 111 Es realitza el procés a la inversa, del secundari al primari de forma anàloga. Un cop verificat que tenen connectivitat total per IP s’ha de verificar que el fitxer hosts que mapeja el hostname amb la IP del servidor està correctament configurat, per fer les proves es realitzarà un ping al hostname. $ ping daloRadius02 El resultat mostrarà a través de quina adreça s’ha mapejat el hostname: PING daloRadius02 (172.168.1.73) 56(84) bytes of data. 64 bytes from daloRadius02 (172.168.1.73): icmp_req=1 ttl=64 time=0.604 ms 64 bytes from daloRadius02 (172.168.1.73): icmp_req=2 ttl=64 time=0.498 ms 64 bytes from daloRadius02 (172.168.1.73): icmp_req=3 ttl=64 time=0.483 ms Com es pot veure en aquest cas el hostname del secundari està associat a l’adreça IP de la interfície eth1. Es repeteix la prova a la inversa de forma anàloga des del servidor secundari al primari. Finalment queda comprovar que ambdós servidors tenen visibilitat a internet, per verificar-ho es realitzarà un ping a una adreça externa, en aquest cas s’ha optat per www.google.com. $ ping www.google.com Si el resultat és correcte la sortida serà com aquesta: PING www.google.com (173.194.45.18) 56(84) bytes of data. 64 bytes from lis01s06-in-f18.1e100.net (173.194.45.18): icmp_req=1 ttl=56 time=39.6 ms 64 bytes from lis01s06-in-f18.1e100.net (173.194.45.18): icmp_req=2 ttl=56 time=28.6 ms 64 bytes from lis01s06-in-f18.1e100.net (173.194.45.18): icmp_req=3 ttl=56 time=28.0 ms Es realitza la mateixa prova per l’altre node, si el resultat és exitós, ja es dona per acabada la connectivitat de xarxa. 7.2 Testeig del sistema de replicació de dades DRBD Per comprovar que el sistema de replicació de dades funciona de forma correcte primer s’ha de verificar que els nodes detecten o coneixen el rol que té assignat cadascú. Per conèixer el rol del node actual s’executa la següent instrucció: $ sudo service drbd status Si la instrucció s’executa en el node que en aquest moment estigui actiu, és a dir amb rol primari es mostrarà el resultat següent: drbd driver loaded OK; device status: version: 8.3.11 (api:88/proto:86-96) 112 srcversion: 71955441799F513ACA6DA60 m:res cs ro ds p mounted fstype 0:r0 Connected Primary/Secondary UpToDate/UpToDate C /mnt ext4 Si des d’on s’executa la instrucció és des del node secundari el resultat serà: drbd driver loaded OK; device status: version: 8.3.11 (api:88/proto:86-96) srcversion: 71955441799F513ACA6DA60 m:res cs ro ds p mounted fstype 0:r0 Connected Secondary/Primary UpToDate/UpToDate C Com es pot apreciar la primera línia indica que el dispositiu del DRBD s’ha carregat correctament. En la última línia indica pel primer cas que el node és el primari que l’estat del disc és el que s’espera, és a dir UpToDate/UpToDate. Finalment es pot apreciar com en el node primari en la columna mounted hi apareix el directori en es munta el dispositiu del DRBD tot indicant que està muntat correctament. Tan mateix en la columna fstype es pot apreciar el sistema de fitxers que té el dispositiu del DRBD que tal com es va configurar és ext4. Lògicament pel que fa al node secundari aquestes dues columnes han d’aparèixer buides ja que només en es pot tenir muntat el dispositiu en el node actiu. Per comprovar que el sistema de replicació de fitxers funciona correctament, es pot crear un fitxer de prova en el node actiu dins del directori mnt on el dispositiu DRBD està muntat. Tot seguit tancar el servidor actiu i des del servidor que fins aleshores és el secundari comprovar que en el directori mnt efectivament hi apareix el fitxer que s’ha creat en l’altre node. Es procedeix a realitzar la prova esmentada. Primer es genera un fitxer de prova: $ sudo vim /mnt/fitxer_prova Tot seguit es procedeix a tancar el servidor primari: $ sudo halt Si ara des del secundari comprovem el rol amb la comanda anteriorment utilitzada es donarà la següent sortida: drbd driver loaded OK; device status: version: 8.3.11 (api:88/proto:86-96) srcversion: 71955441799F513ACA6DA60 m:res cs ro ds p mounted fstype 0:r0 WFConnection Primary/Unknown UpToDate/DUnknown C /mnt ext4 113 Com es pot comprovar el node secundari assumeix el rol de primari i per tant s’ha muntat el dispositiu DRBD en la carpeta mnt. Donat que el node que anteriorment estava actiu està desconnectat, l’estat que indica el DRBD d’aquest node és Unknown i conseqüentment l’estat del seu disc DUnknown com és d’esperar. Un cop verificat que DRBD detecta correctament l’apagada de l’altre servidor que verificar si realment el fitxer_prova s’ha replicat correctament. Així doncs si s’accedeix al directori mnt i es realitza un ls: $ cd /mnt $ sudo ls Dins dels fitxers d’aquest directori haurà d’aparèixer el fitxer_prova. Verificant que el fitxer s’ha replicat correctament. Finalment cal verificar que el procés es realitza també a la inversa i que per tan si es crea un fitxer en el node secundari es replica de la mateixa manera al primari. 7.3 Testeig del sistema de replicació de serveis Heartbeat Per comprovar que el sistema de replicació de serveis Heartbeat funciona correctament es realitzarà una bateria de proves, que a continuació es comenten. Amb ambdós servidors online es reinicia el servidor primari: $ sudo reboot El comportament que s’espera és que la màquina primària envia a la secundària un senyal de que s’està reiniciant i que per tant alliberarà els recursos per tal que el node secundari agafi el testimoni convertint-se en primari, conseqüentment a això si es monitoritza els logs del syslog en el servidor secundari es veurà: Jan 31 18:41:54 daloRadius02 kernel: [ 8571.141933] block drbd0: peer( Primary -> Secondary )1 Jan 31 18:41:54 daloRadius02 heartbeat: [4070]: info: Received shutdown notice from 'daloradius01'.2 Jan 31 18:41:54 daloRadius02 heartbeat: [4070]: info: Resources being acquired from daloradius01.3 Jan 31 18:41:54 daloRadius02 heartbeat: [4070]: debug: StartNextRemoteRscReq(): child count 1 Jan 31 18:41:54 daloRadius02 heartbeat: [4855]: info: acquire local HA resources (standby). Jan 31 18:41:55 daloRadius02 heartbeat: [4855]: info: local HA resource acquisition completed (standby). 114 Jan 31 18:41:55 daloRadius02 heartbeat: [4070]: info: Standby resource acquisition done [foreign]. Jan 31 18:41:55 daloRadius02 harc[4881]: info: Running /etc/ha.d//rc.d/status status4 Jan 31 18:41:55 daloRadius02 mach_down[4896]: info: Taking over resource group drbddisk::r05 Jan 31 18:41:55 daloRadius02 ResourceManager[4921]: info: Acquiring resource group: daloradius01 drbddisk::r0 Filesystem::/dev/drbd0::/mnt::ext4 IPaddr2::192.168.1.72 apache2 mysql6 Jan 31 18:41:55 daloRadius02 ResourceManager[4921]: info: Running /etc/ha.d/resource.d/drbddisk r0 start7 Jan 31 18:41:55 daloRadius02 kernel: [ 8571.245638] block drbd0: role( Secondary -> Primary )8 Jan 31 18:41:55 daloRadius02 Filesystem[4987]: INFO: Resource is stopped Jan 31 18:41:55 daloRadius02 ResourceManager[4921]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /mnt ext4 start9 Jan 31 18:41:55 daloRadius02 Filesystem[5059]: INFO: Running start for /dev/drbd0 on /mnt Jan 31 18:41:55 daloRadius02 kernel: [ 8571.407817] EXT4-fs (drbd0): mounted filesystem with ordered data mode. Opts: (null) Jan 31 18:41:55 daloRadius02 Filesystem[5050]: INFO: Success Jan 31 18:41:55 daloRadius02 IPaddr[5129]: INFO: Resource is stopped Jan 31 18:41:55 daloRadius02 ResourceManager[4921]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.72 start10 Jan 31 18:41:55 daloRadius02 IPaddr[5206]: INFO: ip -f inet addr add 192.168.1.72/24 brd 192.168.1.255 dev eth0 Jan 31 18:41:55 daloRadius02 IPaddr[5206]: INFO: ip link set eth0 up Jan 31 18:41:55 daloRadius02 IPaddr[5206]: INFO: /usr/lib/heartbeat/send_arp - i 200 -r 5 -p /var/run/resource-agents/send_arp-192.168.1.72 eth0 192.168.1.72 auto not_used not_used Jan 31 18:41:55 daloRadius02 IPaddr[5194]: INFO: Success Jan 31 18:41:55 daloRadius02 ResourceManager[4921]: info: Running /etc/init.d/apache2 start11 Jan 31 18:41:55 daloRadius02 ResourceManager[4921]: info: Running /etc/init.d/mysql start12 Jan 31 18:41:57 daloRadius02 mach_down[4896]: info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired13 Jan 31 18:41:57 daloRadius02 /etc/mysql/debian-start[5429]: Checking for insecure root accounts. En la captura dels logs s’ha subratllat en groc els processos que mostren el funcionament de la replicació dels serveis, en vermell s’ha enumerat cadascun per tal de fer-ne referència. En primer lloc (procés 1) donat que la forma com el servidor primari s’ha tancat és de forma controlada, és a dir mitjançant un reset o inclús si s’hagués apagat amb la instrucció halt es dona temps al DRBD per que envií un peer al node 115 secundari comunicant-li que canviarà de rol i que per tant passarà de Primary - > Secondary. En el procés 2 Heartbeat pren consciència d’aquesta notificació de tancament del node primari. I comença el procés 3 que és el d’adquisició dels recursos. En el 4 es comprova l’estat dels serveis que Heartbeat ha de gestionar per conèixer quins d’ells ha d’aixecar o arrencar, ja que si per algun motiu algun servei ja estigués arrencat, no s’enviaria la instrucció d’execució del servei. En el procés 5 s’adquireix el recurs r0 associat al DRBD. En el pas 6 Heartbeat consulta el fitxer /etc/ha.d/haresources per conèixer quins recursos ha d’adquirir o executar. En el pas 7 arrenca el recurs r0, fent que conseqüentment el node canviï de rol passant de secundari a primari, tal com es pot veure al pas 8. Pel que fa al procés 9 s’executa el resource agent Filesystem que com es pot veure té com a arguments el dispositiu del DRBD /dev/drbd0, el directori on es munta /mnt i finalment l’extensió dels fitxers ext4. En el 10 s’inicia el procés per muntar la IP virtual, i un cop està muntada, que es sap quan a pareix el missatge [Success], ja es comencen a arrencar els serveis que s’hi ha configurat en el /etc/ha.d/haresources, tal com mostren els passos 11 i 12 pels serveis Apache2 i Mysql respectivament. Finalment en el 13 s’indica que el procés s’ha realitzat correctament i que els recursos que el node primari gestionava ja estan correctament adquirits. Un cop s’ha vist que el node secundari assumeix correctament el rol de primari quan es desconnecta el primari, s’ha de comprovar que un cop es torna a aixecar el servidor, torna a recuperar el rol de primari i per tant el que fins ara de forma temporal havia exercit de primari torna a cedir el control i assumeix el rol de secundari. Així doncs arrencant el servidor altre cop i analitzant els logs del node secundari es veu la següent sortida: Jan 31 19:23:49 daloRadius02 kernel: [11084.172508] block drbd0: state = { cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate r--- }1 Jan 31 19:23:49 daloRadius02 kernel: [11084.172834] block drbd0: wanted = { cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate r--- }2 Jan 31 19:26:51 daloRadius02 heartbeat: [4070]: info: Heartbeat restart on node daloradius01 Jan 31 19:26:51 daloRadius02 heartbeat: [4070]: info: Link daloradius01:eth1 up. Jan 31 19:26:51 daloRadius02 heartbeat: [4070]: info: Status update for node daloradius01: status init 116 Jan 31 19:26:51 daloRadius02 heartbeat: [4070]: info: Status update for node daloradius01: status up Jan 31 19:26:51 daloRadius02 heartbeat: [4070]: debug: StartNextRemoteRscReq(): child count 1 Jan 31 19:26:51 daloRadius02 heartbeat: [5998]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL Jan 31 19:26:51 daloRadius02 harc[5998]: info: Running /etc/ha.d//rc.d/status status3 Jan 31 19:26:52 daloRadius02 heartbeat: [4070]: debug: get_delnodelist: delnodelist= Jan 31 19:26:52 daloRadius02 heartbeat: [4070]: info: all clients are now paused Jan 31 19:26:53 daloRadius02 heartbeat: [4070]: info: Status update for node daloradius01: status active Jan 31 19:26:53 daloRadius02 heartbeat: [6028]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL Jan 31 19:26:53 daloRadius02 harc[6028]: info: Running /etc/ha.d//rc.d/status status Jan 31 19:26:53 daloRadius02 heartbeat: [4070]: info: remote resource transition completed. Jan 31 19:26:53 daloRadius02 heartbeat: [4070]: info: daloradius02 wants to go standby [foreign] Jan 31 19:26:54 daloRadius02 heartbeat: [4070]: info: all clients are now resumed Jan 31 19:26:54 daloRadius02 heartbeat: [4070]: info: standby: daloradius01 can take our foreign resources Jan 31 19:26:54 daloRadius02 heartbeat: [6043]: info: give up foreign HA resources (standby).4 Jan 31 19:26:54 daloRadius02 ResourceManager[6057]: info: Releasing resource group: daloradius01 drbddisk::r0 Filesystem::/dev/drbd0::/mnt::ext4 IPaddr::192.168.1.72 apache2 mysql5 Jan 31 19:26:54 daloRadius02 ResourceManager[6057]: info: Running /etc/init.d/mysql stop6 Jan 31 19:26:55 daloRadius02 ResourceManager[6057]: info: Running /etc/init.d/apache2 stop7 Jan 31 19:26:56 daloRadius02 ResourceManager[6057]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.72 stop8 Jan 31 19:26:56 daloRadius02 IPaddr[6149]: INFO: Success Jan 31 19:26:56 daloRadius02 ResourceManager[6057]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /mnt ext4 stop9 Jan 31 19:26:56 daloRadius02 Filesystem[6199]: INFO: Running stop for /dev/drbd0 on /mnt10 Jan 31 19:26:56 daloRadius02 Filesystem[6199]: INFO: Trying to unmount /mnt Jan 31 19:26:56 daloRadius02 Filesystem[6199]: INFO: unmounted /mnt successfully Jan 31 19:26:57 daloRadius02 Filesystem[6193]: INFO: Success Jan 31 19:26:57 daloRadius02 ResourceManager[6057]: info: Running /etc/ha.d/resource.d/drbddisk r0 stop11 117 Jan 31 19:26:57 daloRadius02 kernel: [11271.099515] block drbd0: role( Primary -> Secondary )12 Jan 31 19:26:57 daloRadius02 kernel: [11271.099537] block drbd0: bitmap WRITE of 0 pages took 0 jiffies Jan 31 19:26:57 daloRadius02 kernel: [11271.099546] block drbd0: 0 KB (0 bits) marked out-of-sync by on disk bit-map. Jan 31 19:26:57 daloRadius02 heartbeat: [6043]: info: foreign HA resource release completed (standby).13 Jan 31 19:26:57 daloRadius02 heartbeat: [4070]: info: Local standby process completed [foreign].14 Jan 31 19:26:57 daloRadius02 kernel: [11271.285975] block drbd0: peer( Secondary -> Primary )15 Jan 31 19:26:59 daloRadius02 heartbeat: [4070]: WARN: 1 lost packet(s) for [daloradius01] [18:20] Jan 31 19:26:59 daloRadius02 heartbeat: [4070]: info: remote resource transition completed. Jan 31 19:26:59 daloRadius02 heartbeat: [4070]: info: No pkts missing from daloradius01! Jan 31 19:26:59 daloRadius02 heartbeat: [4070]: info: Other node completed standby takeover of foreign resources. En la instrucció 1 es mostra l’estat actual del node, és a dir és primari. En el 2 mostra l’estat intermedi que es vol un cop ha detectat que l’altre node s’ha aixecat. Aquest estat de Secondary/Secondary es dona quan el que fins ara conté els recursos i per tant està actuant de primari, els va alliberant per tal que l’altre node pugui adquirir-los i per tant assumir l’estat o rol de primari. En el procés 3 es realitza un reconeixement de l’estat dels recursos de la mateixa manera que s’havia fet anteriorment. En el pas 4 indica que comença el procés d’alliberació dels recursos que li havien estat atorgats anteriorment, i preparant-se doncs per passar a un estat d’standby és a dir d’espera. En el procés 5 Heartbeat novament consulta el fitxer /etc/ha.d/haresoures per tenir coneixement de quins resource agents ha de consultar per tal d’executar l’ordre d’aturada o stop dels serveis. Els passos 6 i 7 atura els serveis de dreta a esquerra tal com estan disposats al fitxer /etc/ha.dharesources els serveis Mysql i Apache2 respectivament. En el pas 8 desmunta la IP virtual, i en el 9, 10 el dispositiu del DRBD. En l’11 atura el recurs r0 la qual cosa provoca que el node canviï de rol passant de secundari a primari tal com es mostra en 12. Els processos 13 i 14 indiquen que s’han alliberat els recursos correctament i que el procés d’standby del node s’ha realitzat, és a dir que ja té assumit el rol secundari, donant-se temporalment l’estat que anteriorment s’ha esmentat de Secondary/Secondary. 118 En aquests moments el DRBD envia un peer (Secondary -> Primary) pas 15, a l’altre node per comunicar-li que ja pot iniciar el procés d’adquisició de recursos i de canvi de rol. A partir d’aquí en l’altre node es seguiran els mateixos passos que anteriorment ha seguit el node secundari en la fase d’adquisició dels recursos i assumpció de rol primari, per que finalment en aquest node es doni l’estat Seconday/Primary corroborant així el correcte funcionament del Heartbeat. 7.4 Testeig del sistema RADIUS 7.4.1 Proves en local Per comprovar que el sistema d’autenticació RADIUS funciona correctament, hi ha diverses opcions, la primera és crear un usuari de prova amb les credencials (username, password) des de la interfície de DaloRadius i mitjançant la instrucció radtest que permet fer servir el servidor RADIUS com a client, es procedirà a verificar que el client s’autentica correctament. Prèviament es crearan tres usuaris, que correspondran a les tres formes com s’assignaran les IP, el primer usuari s’anomena usuariIPfixa amb contrasenya test que com el nom indica serà un usuari amb assignació d’IP fixa i tindrà associat el Servei Prova 2M/3M. El segon usuari a crear-se serà un usuari que l’assignació de la seva IP la proporcionarà el NAS via DHCP d’un pool d’IPs que s’anomenarà Pool_Prova. Les credencials d’aquest usuaris seran usuariIPNAS i contrasenya test. Tindrà associat el Servei Prova 2M/3M IP NAS. Finalment el tercer tipus d’usuari rebrà l’assignació de la IP per part del servidor RADIUS que a través del Pool_Prova3 agafarà una IP i li assignarà. Les credencials d’aquest usuari són usuariIPPOOL i contrasenya test. Tindrà associat el Servei Prova 2M/3M IP POOL. Així doncs si s’executa la següent instrucció: $ sudo radtest usuariIPFixa test 127.0.0.1 1581 testing123 En la instrucció anterior es té com a usuari usuariIPFixa, la seva contrasenya és test. Pel que fa a l’adreça IP del client, donat que s’està utilitzant el servidor RADIUS com a client s’utilitza l’adreça local o localhost (127.0.0.1) el port per realitzar aquesta prova és un port reservat, concretament el 1581 i el paràmetre testing123 és una contrasenya que simula al shared secret del NAS. Si la resposta és la que es mostra a continuació vol dir que l’usuari s’ha autenticat correctament: Sending Access-Request of id 89 to 127.0.0.1 port 1812 119 User-Name = "usuariIPfixa" User-Password = "test" NAS-IP-Address = 172.168.1.71 NAS-Port = 1581 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=89, length=39 Framed-IP-Address = 192.168.1.106 Mikrotik-Rate-Limit = "2M/3M" Com es pot apreciar l’usuari realitza una petició d’autenticació enviant les seves credencials a través del NAS que en aquest cas NAS client i servidor RADIUS estan allotjats en la mateixa màquina. El servidor RADIUS envia per mitjà d’un paquet rad_recv un Access-Accept al NAS que el reenvia al client. Aquest paquet indica que ha acceptat l’autenticació i li assigna els “privilegis” que s’han especificat en els atributs del servei, en aquest cas els privilegis son un rate de 2M/3M i l’assignació de la IP estàtica 192.168.1.106. Si l’autenticació no es realitzés correctament, ja sigui perquè les credencials dels usuaris no són correctes o perquè la clau compartida amb el NAS tampoc el missatge que es mostrarà serà el següent: Sending Access-Request of id 21 to 127.0.0.1 port 1812 User-Name = "usuariIPfixa" User-Password = "test1" NAS-IP-Address = 172.168.1.71 NAS-Port = 1581 rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=21, length=20 Com es pot apreciar en la resposta anterior, s’ha introduït intencionadament una contrasenya d’usuari errònia. En resposta el servidor envia una denegació d’autenticació Access-Reject. Per comprovar que el segon tipus d’usuari s’autentica correctament es repeteix el procediment anterior, amb la instrucció que tot seguit es mostra: $ sudo radtest usuariIPNAS test 127.0.0.1 1581 testing123 En cas que l’autenticació sigui correcte es mostrarà: Sending Access-Request of id 162 to 127.0.0.1 port 1812 User-Name = "usuariIPNAS" User-Password = "test" NAS-IP-Address = 172.168.1.71 NAS-Port = 1581 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=162, length=50 Framed-Protocol = PPP Service-Type = Framed-User Framed-MTU = 1500 Framed-Pool = "Pool_Prova" 126 Tot seguit demanarà que s’introdueixi la contrasenya i la confirmació d’aquesta, en aquest cas s’utilitzarà la mateixa que la de l’usuari del sistema és a dir password. L’assignació de contrasenya al super usuari root es realitza en ambdós servidors. El següent pas a realitzar és copiar la clau pública del servidor daloRadius01 al daloRadius02: $ scp /root/.ssh/id_rsa.pub [email protected]:/root/.ssh/ Un cop s’executa la instrucció anterior es sol·licitarà la contrasenya del super usuari root, que serà la que s’ha definit al pas anterior, és a dir password. Aquest serà l’últim cop que es demanarà la contrasenya, ja que s’emmagatzemarà al fitxer /root/.ssh/known_hosts el parell usuari contrasenya. Al servidor daloRadius02 s’ha d’executar les següents instruccions: $ cat id_rsa.pub >> /root/.ssh/authorized_keys $ chmod 700 /root/.ssh/authorized_keys S’ha concatenat al fitxer authorized_keys la clau pública i s’ha donat permisos totals al usuari root. Un cop realitzat aquests passos ja es pot enviar via scp fitxers des de daloRadius01 a daloRadius02 sense la necessitat d’introduir la contrasenya. Per automatitzar la tasca de copiar fitxer i directoris via scp es crea el següent script: $ sudo vim /home/usuari/config_files_replication.sh El contingut del fitxer és: #!/bin/sh scp /etc/drbd.conf [email protected]:/etc scp /etc/ha.d/authkeys [email protected]:/etc/ha.d scp -r /etc/ha.d/resource.d [email protected]:/etc/ha.d scp -r /etc/apache2 [email protected]:/etc scp -r /etc/freeradius [email protected]:/etc scp -r /usr/share/freeradius [email protected]:/usr/share scp -r /var/www/daloradius [email protected]:/var/www Finalment es procedeix a afegir la tasca al crontab: $ sudo crontab –e I s’afegeix la següent línia: */10 * * * * /home/eurona/config_files_replication.sh >> /dev/null 2>&1 127 Com es pot veure s’ha fixat un temps de 10 minuts per que cron llenci l’execució de l’script de replicació. Donat que idealment els fitxers de configuració no es canviaran gaire sovint, s’ha considerat raonable establir el temps de periodicitat de la tasca amb uns10 minuts ja que en cas de modificació dels fitxers no suposa un gran temps d’espera i a la vegada tampoc es genera tant de moviment de processos. 8.4 Correcció de bug en l’interfície DaloRadius Quan s’estava realitzant la creació dels perfils o serveis es va notar que quan s’afegien atributs que tenien per valor “0” no DaloRadius no els menyspreava i per tant no els afegia en el servei que s’estava creant. Gràcies a que DaloRadius és un frontend de codi obert es pot tenir accés al codi font de la seva implementació i en aquest cas, es va poder modificar codi per tal d’assegurar que DaloRadius tenia el comportament desitjat. Concretament l’error que es va detectar era degut a un condicional que no acceptava el “0” com a un possible valor d’atribut i per tant el descartava. Per solucionar aquest bug es van haver de modificar els següent fitxers:  /var/www/daloradius/mng-rad-groupcheck-new.php  /var/www/daloradius/mng-rad-groupreply-new.php  /var/www/daloradius/mng-rad-profiles-edit.php  /var/www/daloradius/mng-rad-profiles-new.php El canvi que es va realitzar en tots ells va ser el mateix, és a dir substituir la següent línia de codi: if (!($value)) Per la següent: if (!($value)&& $value !=0) Amb aquest canvi en la condició ja permet assignar el valor zero a un atribut. 8.5 Correcció del comportament del fitxer d’arrencada d’Ubuntu En el sistema operatiu Ubuntu, l’arrencada del sistema operatiu es gestiona mitjançant el fitxer /boot/grub/grub.cfg. En la distribució d’12.04.1 d’Ubuntu aquest fitxer conté una opció en el codi que en cas que el servidor s’hagi apagat de forma brusca ja sigui per una fallada en el subministrament elèctric o altres causes al psar-se en marxa altra cop, es manté en una pantalla de 128 selecció del sistema operatiu a arrencar, i per tal d’accedir-hi s’ha de clicar una tecla. El fet que no arrenqui el sistema operatiu de forma automàtica és un problema, ja que la idea és que els servidors estaran allotjats en un CPD i no hi haurà un tècnic permanentment per prémer la tecla que permeti accedir al sistema operatiu. Per tal de modificar aquest comportament, s’ha d’editat el fitxer anteriorment esmentat: $ sudo vim /boot/grub/grub.cfg I modificar el següent tros de codi: terminal_output gfxterm if [ "${recordfail}" = 1 ]; then set timeout=-1 else set timeout=2 fi Pel següent: terminal_output gfxterm if [ "${recordfail}" = 1 ]; then set timeout=2 else set timeout=2 fi S’ha de modificar el valor de time out que és el temps que la pantalla de selecció del sistema operatiu és manté abans no arrenca Ubuntu. Com es pot veure en el primer cas estava fixat a -1, el qual implica que el valor de time out és indefinit i per tant romandrà en la pantalla de selecció fins que es cliqui l’opció de selecció del sistema operatiu, per tant si es modifica aquest paràmetre com és el cas que es mostra a 2, esperarà 2 segons abans d’arrencar Ubuntu, solucionant així el problema anteriorment esmentat. 129 9 Monitorització i manteniment del sistema En aquest apartat es detallarà un seguit d’instruccions per a monitoritzar l’estat dels serveis i del sistema en general que s’han emprat al llarg de tot el projecte. 9.1 Monitorització i manteniment del DRBD Per tal de conèixer l’estat del DRBD: $ sudo service drbd status Aquesta instrucció indica l’estat actual del cluster indicant els rol de cada servidor així com l’estat dels seus discs. drbd driver loaded OK; device status: version: 8.3.11 (api:88/proto:86-96) srcversion: 71955441799F513ACA6DA60 m:res cs ro ds p mounted fstype 0:r0 Connected Secondary/Primary UpToDate/UpToDate C Per tenir una monitorització en temps real de l’estat del DRBD i no únicament una captura en un instant determinat, tal com fa la instrucció anterior pot executar-se la comanda: $ sudo watch cat /proc/drbd Per posar en marxa el sistema DRBD: $ sudo service drbd start I per aturar-lo: $ sudo service drbd stop Per sincronitzar els dos nodes un cop es produeix un split brain s’ha d’executar les següents instruccions: En el node secundari: $ sudo drbdadm secondary r0 $ sudo drbdadm disconnect r0 $ sudo drbdadm -- --discard-my-data connect r0 En el node primari: $ sudo drbdadm primary r0 $ sudo drbdadm disconnect r0 $ sudo drbdadm connect r0 Per verificar que la unitat del DRBD s’ha muntat correctament en el directori /mnt del node primari hi ha diverses opcions: $ sudo df –h 130 Aquesta comanda mostrarà la següent sortida: S.ficheros Tamaño Usado Disp Uso% Montado en /dev/sda1 9,3G 3,1G 5,8G 35% / udev 488M 4,0K 488M 1% /dev tmpfs 199M 300K 199M 1% /run none 5,0M 4,0K 5,0M 1% /run/lock none 497M 0 497M 0% /run/shm /dev/drbd0 11G 806M 9,4G 8% /mnt La línia subratllada en groc mostra que el dispositiu està muntat correctament. L’altra comanda que realitza mostra una informació similar es: $ sudo mount Que mostra la sortida que a continuació es veu: /dev/sda1 on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) /dev/drbd0 on /mnt type ext4 (rw) Subratllat en groc es mostra a més del directori on està muntat el dispositiu DRBD el sistema de fitxers que té i els permisos de lectura/escriptura. En cas que no s’hagi muntat correctament, es pot muntar mitjançant la instrucció: $ sudo mount /dev/drbd0 /mnt 9.2 Monitorització i manteniment del Heartbeat Per conèixer l’estat del Heartbeat: $ sudo /etc/init.d/heartbeat status La sortida de la instrucció anterior mostrarà si el Heartbeat està funcionant: heartbeat OK [pid 4070 et al] is running on daloradius02 [daloradius02]... o si pel contrari està apagat: heartbeat is stopped. No process Per arrencar el Heartbeat: 131 $ sudo /etc/init.d/heartbeat start Per aturar-lo: $ sudo /etc/init.d/heartbeat stop Per reiniciar-lo: $ sudo /etc/init.d/heartbeat restart 9.3 Monitorització i manteniment dels serveis a replicar 9.3.1 Monitorització i manteniment d’ Apache2 Per comprovar l’estat del servei Apache2: $ sudo service apache2 status Mostrarà en cas que estigui arrencat: Apache2 is running (pid 3674). I si està aturat: Apache2 is NOT running. Per arrencar el sistemaApache2: $ sudo service apache2 start Per aturar-lo : $ sudo service apache2 stop Finalment per reiniciar-lo: $ sudo service apache2 restart Per comprovar que es pot accedir correctament al servei, des d’un navegador s’inserirà l’adreça IP del servidor que es vol comprovar, si es pot accedir correctament es mostrarà la següent pantalla: Figura 9.1: Pàgina d’inici d’Apache2 132 9.3.2 Monitorització i manteniment de Mysql Per comprovar l’estat del servei Mysql: $ sudo service mysql status Si el servei està arrencat es mostrarà: mysql start/running, process 3732 Si està aturat: mysql stop/waiting Per arrencar el servei s’ha d’executar la següent comanda: $ sudo service mysql start Per aturar-lo s’ha d’executar: $ sudo service mysql stop I per reiniciar-lo: $ sudo service mysql restart Per accedir a la consola del client de Mysql s’executa la següent comanda: $ mysql –u <usuari> -p<password> Si per algun motiu es precisés des-instal·lar el servei s’ha d’executar les següents comandes: $ sudo apt-get purge mysql-server mysql-common mysql-client $ sudo apt-get autoremove I per forçar la reinstal·lació: $ sudo apt-get –f install mysql-server mysql-common mysql-client 9.3.3 Monitorització i manteniment del sistema RADIUS FreeRadius El servei FreeRadius a diferència dels altres serveis esmentats anteriorment no disposa d’una instrucció explícita per conèixer el seu estat. Per fer-ho es realitzarà un llistat dels procés amb un filtre que contingui la paraula freeradius, de forma que llistarà tots els processos oberts que continguin aquest nom, podent determinar així si el servei està arrencat o aturat. Així doncs la comanda esmentada és: $ sudo ps aux | grep freeradius En cas que el servei estigui arrencat en la llista de serveis i figurarà el procés que tot seguit es mostra: 133 freerad 966 0.0 0.4 207728 4476 ? Ssl 09:53 0:00 /usr/sbin/freeradius usuari 12501 0.0 0.0 11912 928 pts/2 S+ 14:57 0:00 grep -- color=auto freeradius La línia subratllada indica que l’usuari freerad esta executant el procés /usr/bin/freeradius corresponent al servei FreeRadius. L’altre procés que es mostra és el que correspon a la instrucció que s’acaba d’executar, per tant no té res a veure amb l’estat del servei. Si pel contrari, el procés llistat fos únicament aquest segon, implicaria que el servei FreeRadius està aturat. Per tal d’arrencar el servei la instrucció que realitza tal tasca és la que es mostra a continuació: $ sudo /etc/init.d/freeradius start Per aturar el servei: $ sudo /etc/init.d/freeradius stop Per reiniciar-lo: $ sudo /etc/init.d/freeradius restart I per detectar algun canvi en la base de dades sense la necessitat de reiniciar el servei es pot executar la comanda: $ sudo /etc/init.d/freeradius reload Finalment per tancar el bloc de manteniment del servei FreeRadius, tal com s’ha indicat en l’apartat de testeig del sistema, per poder executar FreeRadius en mode debug s’ha d’executar la següent instrucció: $ sudo freeradius -X Per finalitzar el procés de freeradius en mode debug s’ha de matar el procés amb la instrucció kill. Així doncs primer s’haurà d’identificar el PID (Process Identifier) o identificador de procés mitjançant la comanda utilitzada anteriorment: $ sudo ps aux | grep freeradius I posteriorment matar-lo aplicant: $ sudo kill -9 <PID del procés freeradius debug> DaloRadius Durant el procés d’instal·lació de DaloRadius no s’han configurat alguns dels mòduls opcionals que tot i no ser utilitzats en aquest projecte, poden ser d’interès activar-los o configurar-los. 134 El primer mòdul a activar és el GIS (Grafic Information System) que serveix per a situar en un mapa la ubicació dels clients, entre d’altres factors. Aquesta api de Google obté els paràmetres que es poden emmagatzemar en la taula userbillinfo. Per activar-lo s’ha de sol·licitar una clau a Google i inserir-la en el textinput RegisterGoogleMaps API i finalment clicar sobre el botó Register Code i ja s’ha activat la api. Figura 9.2: Activació del GIS de DaloRadius Un altre mòdul important per temes de manteniment del sistema és la d’habilitar els logs en el frontend de forma que es pugui tenir en el mateix DaloRadius un seguiment del comportament del servei. Des de l’aplicació DaloRadius es poden visualitzar quatre logs, que són el Boot Log, el System Log, el Radius Log i el Daloradius Log. Per a poder tenir accés als tres primers s’ha de donar permisos als fitxers que contenen aquests logs. Per a l’habilitació del Boot Log: $ sudo chmod 777 /var/log/dmesg Per a l’habilitació del System Log: $ sudo chmod 777 /var/log/syslog Per a l’habilitació del Radius Log: $ sudo chmod 777 /var/log/freeradius Pel que fa al DaloRadius Log s’ha d’editar el fitxer de configuració següent: $ sudo vim /var/www/daloradius/library/daloradius.conf.php I especificar els valors a afegir al log a yes tal com es mostra a continuació: 135 $configValues['CONFIG_LOG_PAGES'] = 'yes'; $configValues['CONFIG_LOG_ACTIONS'] = 'yes'; $configValues['CONFIG_LOG_QUERIES'] = 'yes'; $configValues['CONFIG_DEBUG_SQL'] = 'no'; $configValues['CONFIG_DEBUG_SQL_ONPAGE'] = 'no'; $configValues['CONFIG_LOG_FILE'] = '/tmp/daloradius.log'; Finalment per acabar amb l’apartat de monitorització i manteniment del sistema, cal esmentar la comanda que permet visualitzar en temps real els logs de tots els serveis que hagin habilitat que els seus logs siguin reenviats al syslog. Per realitzar aquesta operació s’ha d’executar la següent instrucció: $ sudo tail –f /var/log/syslog 142 Figura 12.7: Creació màquina virtual V En la imatge que es mostra a continuació s’ha de configurar el hardware que la màquina emularà. En el pas 1 es selecciona la targeta de xarxa i es configura en mode Bridged tal com es mostra en 2, per tal que cada màquina tingui connexió directa al router i a efectes pràctics sigui com una màquina física més, a diferència de l’opció NAT que s’utilitza la IP de la màquina física que conté les màquines virtuals per accedir al router. Per afegir l’altra targeta de xarxa es clica l’opció Add mostrada en el pas 3, i un cop afegida al hardware s’haurà de repetir els passos 1 i 2. Figura 12.8: Creació màquina virtual VI 143 Abans d’executar el pas 4 de la imatge anterior s’ha de seleccionar la ubicació del sistema operatiu, que en aquest cas s’ha gravat en un DVD, per tan es selecciona la unitat de disc. Figura 12.9: Creació màquina virtual VII Amb aquest últim pas ja s’ha creat el emulador de la màquina virtual i ja es mostrarà en la pantalla d’inici de l’aplicació VMWare Player on es podrà procedir a la instal·lació del sistema operatiu. Figura 12.10: Creació màquina virtual VIII 144 13 Referències [1] Manual d’usuari RADIUS MANAGER 4 [DMA Softlab LLC] http://www.dmasoftlab.com/cont/documents/user_manual_4.0.pdf [2] Servidor RADIUS con gestión Web: FreeRADIUS + daloRADIUS http://blog.e2h.net/2011/07/01/servidor-radius-con-gestion-web-freeradiusdaloradius/ [3] DaloRADIUS http://www.soportejm.com.sv/kb/index.php/article/daloradius [4] DaloRADIUS http://www.soportejm.com.sv/kb/index.php/article/radius-fortigate [5] DaloRADIUS http://www.soportejm.com.sv/kb/index.php/article/wmxxxmac [6] Adolfo Alonso Márquez, “Remote Access Dial In User Service“ http://es.scribd.com/doc/43768082/Radius [7] Carlos Osmin Pocasangre , “Implementación de un servidor de Radius con gestión web: FreeRadius + daloRadius “ http://es.scribd.com/doc/97685523/servidor-freeRadius [8] RADIUS MANAGER http://acacha.org/mediawiki/index.php/Radius_Manager#Connection_trackin g [9] RADIUS http://www.stat.ufl.edu/system/man/portmaster/RADIUS/guide/4user.html [10] Juniper Networks, ”Concepts & Examples Screen OS Reference Guide” http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ce_U serAuth.pdf [11] Protocol AAA http://adictosalsoma.blogspot.com.es/2007/06/software-libre-aaa-yfreeradius.html [12] FreeRADIUS http://www.openlogic.com/wazi/bid/188089/Authenticating-Wi-Fi-Userswith-FreeRADIUS 145 [13] Mitton & Beadles, “Network Access Server Requirements Next Generation NAS Model “ http://tools.ietf.org/html/rfc2881 [14] Estàndar 802.1X http://es.kioskea.net/contents/wifi/wifi-802.1x.php3 [15] RADIUS http://blackspiral.org/docs/pfc/itis/node12.html [16] Alicia Cruz Guzmán, ”Modelo e infraestructura de Seguridad basado en identificación y autenticación para redes” http://www.bibliosepi.esimez.ipn.mx/telecomunicaciones/2011/Modelo%20e%20infraestructur a%20de%20seguridad%20basado%20en%20identificacion%20y%20autentifi cacion.pdf [17] Infraestructura de clau pública PKI http://en.wikipedia.org/wiki/Public-key_infrastructure [18] Anabel Córdoba Téllez, Gricel Durán Martínez, Verónica Flores Sánchez; “Diseño de un Sistema de seguridad de Control de Acceso con RADIUS configurado en un Sistema Operativo LINUX para una LAN Inalámbrica” http://itzamna.bnct.ipn.mx:8080/dspace/bitstream/123456789/6823/1/ESI ME-RADIUS.pdf [19] Juniper Networks, “EAP TTLS Authentication Protocol” http://www.juniper.net/techpubs/software/aaa_802/sbrc/sbrc70/sw-sbrcadmin/html/EAP-024.html [20] Client SCP PuTTY http://ca.wikipedia.org/wiki/PuTTY [21] Alta disponibilitat & Linux http://www.linuxha.org/doc/usersguide/_the_literal_authkeys_literal_file.html [22] Alta disponibilitat & Linux http://lists.linux-ha.org/pipermail/linux-ha/2002-April/004652.html [23] VMWare http://my.vmware.com/web/vmware/free#desktop_end_user_computing/vm ware_player/5_0 [24] Ubuntu http://sliceoflinux.wordpress.com/2009/05/08/instalar-ubuntu-904-serverpaso-a-paso/ 146 [25] Linux http://upiicsalibre.wordpress.com/2011/02/18/swap-en-linux/ [26] Sistema de fitxers Ext4 http://commons.wikimedia.org/wiki/File:Tabla_ext3_ext4.png//upiicsalibre.w ordpress.com/2011/02/18/swap-en-linux/ [27] Sistema de fitxers Ext4 http://es.wikipedia.org/wiki/Ext4 [28] Sistema de fitxers Ext4 http://www.guiaubuntu.com/index.php?title=GRUBes.wikipedia.org/wiki/Ext4 [29] Configuració DRBD http://www.seas.es/blog/content/drbd-i-de-iv [30] RAID http://ca.wikipedia.org/wiki/RAID [31] DRBD http://www.drbd.org/ [32] Configuració DRBD http://luismido.wikidot.com/drbd [33] Philipp Reisner, “DRBD” http://www.drbd.org/fileadmin/drbd/publications/drbd_lk9.pdf [34] Jordi Prats Català, “Migración en caliente en Xen usando DRBD” http://systemadmin.es/wpcontent/uploads/2008/10/xen_drbd_systemadmin. pdf [35] Configuració DRBD http://www.pluzzi.com/pluzzi/os/drbd/drbd.conf [36] MikroTikls SIA, “RouterBOARD 433 Series User’s Manual” http://routerboard.com/pdf/71/rb433uga.pdf [37] Configuració de Mikrotik RADIUS RouterBOARD 433 http://sourceforge.net/apps/trac/hotcakes/wiki/yfi_setup_nas_Mikrotik#RAD IUSonRouterboard433 [38] Mikrotik & RADIUS http://wiki.mikrotik.com/wiki/Manual:RADIUS_Client#Radius_Client [39] Mikrotik 147 http://wiki.mikrotik.com/wiki/First_time_startup [40] Configurar Mikrotik Wireless http://configurarmikrotikwireless.com/blog/descargar-e-instalar-winbox-elprograma-que-controla-tu-isp.html [41] Ubuntu Server & Apache http://www.linuxhispano.net/2010/11/22/solucionar-problema-delservername-en-apache-2/ [42] Ubuntu Server & MySQL http://cambio.name/personal/content/reinstalaci%C3%B3n-de-mysql-enubuntu-1004 [43] Ubuntu Server http://www.ubuntu.com/download/server [44] Francisco José Méndez Cirera, “PFC Diseño e implementación de un sistema de VoIP de alta disponibilidad y alto rendimiento. Capítulo 4. Alta disponibilidad en GNU/Linux” http://www.adminso.es/wiki/images/3/31/Pfc_Fransico_cap4.pdf [45] Configuració Heartbeat http://linux-ha.org/wiki/Ha.cf#Defaults [46] Configuració Heartbeat http://jmaslibre.wordpress.com/2008/09/01/heartbeat-mi-configuracion/ [47] Configuració Heartbeat http://www.ultramonkey.org/3/topologies/config/ha/single/realserver/ha.cf [48] Configuració DRBD http://mike.mcmurray.co.nz/blog/wp-content/uploads/2010/01/drbd.txt [49] Eugenio Villar Fernández, “Virtualización de servidores de telefonia IP en GNU/Linux Capítulo 6. Alta disponibilidad en clústers virtuales” http://www.adminso.es/images/2/24/Eugenio_cap6.pdf