-
Notifications
You must be signed in to change notification settings - Fork 0
/
trabajo.tex
365 lines (236 loc) · 36.7 KB
/
trabajo.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
% !TeX spellcheck = <none>
%%%%
% Modificaci�n de una plantilla de Latex para adaptarla al castellano.
%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Thin Sectioned Essay
% LaTeX Template
% Version 1.0 (3/8/13)
%
% This template has been downloaded from:
% http://www.LaTeXTemplates.com
%
% Original Author:
% Nicolas Diaz ([email protected]) with extensive modifications by:
% Vel ([email protected])
%
% License:
% CC BY-NC-SA 3.0 (http://creativecommons.org/licenses/by-nc-sa/3.0/)
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%----------------------------------------------------------------------------------------
% PACKAGES AND OTHER DOCUMENT CONFIGURATIONS
%----------------------------------------------------------------------------------------
\documentclass[a4paper, 10pt]{article} % Font size (can be 10pt, 11pt or 12pt) and paper size (remove a4paper for US letter paper)
\usepackage[protrusion=true,expansion=true]{microtype} % Better typography
\usepackage{graphicx} % Required for including pictures
\usepackage[usenames,dvipsnames]{color} % Coloring code
\usepackage{wrapfig} % Allows in-line images
\usepackage[utf8]{inputenc}
\usepackage{enumerate}
\usepackage{enumitem}
\usepackage{geometry}
\geometry{
a4paper,
total={210mm,297mm},
left=3cm,
right=3cm,
top=25mm,
bottom=25mm,
}
% Imagenes
\usepackage{graphicx}
\usepackage{amsmath}
% para importar svg
%\usepackage[generate=all]{svgfig}
% sudo apt-get install texlive-lang-spanish
\usepackage[spanish]{babel} % English language/hyphenation
\selectlanguage{spanish}
% Hay que pelearse con babel-spanish para el alineamiento del punto decimal
\decimalpoint
\usepackage{dcolumn}
\newcolumntype{d}[1]{D{.}{\esperiod}{#1}}
\makeatletter
\addto\shorthandsspanish{\let\esperiod\es@period@code}
\makeatother
\usepackage{longtable}
\usepackage{tabu}
\usepackage{supertabular}
\usepackage{multicol}
\newsavebox\ltmcbox
% Símbolos matemáticos
\usepackage{amssymb}
\let\oldemptyset\emptyset
\let\emptyset\varnothing
% Fuente Arial
\renewcommand{\rmdefault}{phv} % Arial
\renewcommand{\sfdefault}{phv} % Arial
%URL's
\usepackage{url}
\usepackage[section]{placeins} % Para gr�ficas en su secci�n.
\usepackage{mathpazo} % Use the Palatino font
\usepackage[T1]{fontenc} % Required for accented characters
\newenvironment{allintypewriter}{\ttfamily}{\par}
\setlength{\parindent}{0pt}
\parskip=8pt
\linespread{1.05} % Change line spacing here, Palatino benefits from a slight increase by default
\makeatletter
\renewcommand\@biblabel[1]{\textbf{#1.}} % Change the square brackets for each bibliography item from '[1]' to '1.'
\renewcommand{\@listI}{\itemsep=0pt} % Reduce the space between items in the itemize and enumerate environments and the bibliography
\newcommand{\imagen}[2]{\begin{center} \includegraphics[width=90mm]{#1} \\#2 \end{center}}
\usepackage[hidelinks]{hyperref}
% Para las enumeraciones anidadas y sus referencias, basado en http://stackoverflow.com/questions/691351/how-to-customize-references-to-sublists-in-latex
\renewcommand{\theenumi}{\arabic{enumi}.}
\renewcommand{\theenumii}{\arabic{enumii}}
\renewcommand{\theenumiii}{\arabic{enumiii}}
\renewcommand{\labelenumi}{\theenumi}
\renewcommand{\labelenumii}{\theenumi\theenumii.}
\renewcommand{\labelenumiii}{\theenumi\theenumii.\theenumiii.}
\makeatletter
\renewcommand{\p@enumii}{\theenumi}
\renewcommand{\p@enumiii}{\theenumi\theenumii.}
%------------------------------------------------
% TITLE
%------------------------------------------------
\title{\textbf{Hosting Virtual}} % Title
\date{\today} % Date
%------------------------------------------------
\begin{document}
\maketitle
\tableofcontents
\pagebreak
\section{Resumen}
En este trabajo vamos a tratar sobre el hosting virtual y su implementación en un servidor Apache. Comenzaremos con la historia del almacenamiento web y su evolución a lo largo de los años, una introducción que servirá tanto de presentación como de motivación para el tema. Continuaremos tratando más a fondo el concepto de hosting virtual y sus diferentes opciones y usos, y pasaremos al servidor Apache, del cual veremos los conceptos básicos y enlazaremos con el hosting virtual. Analizaremos y comprobaremos las diferentes opciones que nos proporciona Apache para ofrecer este tipo de servicio, explicando la funcionalidad y las ventajas que nos ofrece cada una de ellas. Trataremos también distintos aspectos a tener en cuenta a la hora de usar hosting virtual en un servidor, tales como la seguridad, y veremos qué opciones nos permite Apache para configurar dichos aspectos y adaptarlos lo más posible a nuestros requerimientos.
\section{Memoria}
\subsection{Introducción}
A lo largo de los años, el alojamiento de contenido en internet ha sido objeto de constante evolución. Inicialmente se tenían estaciones de trabajo locales, que cada persona se encargaba de montar y mantener, normalmente en su propio domicilio si se trataba de un particular. Para tener un sitio web propio había que tener un ordenador o un servidor que alojase y sirviera la página, ya que el negocio del alojamiento web no estaba todavía explotado. Se trataba por tanto de una tecnología un poco primitiva y complicada, pues eran necesarios conocimientos tanto en la gestión del software como del hardware, haciendo que el almacenamiento web no estuviera al alcance de todo el mundo, ya fuera por falta de conocimientos, de tiempo o de recursos económicos para montar la infraestructura necesaria.
El uso de internet fue aumentando gradualmente con el paso de los años, y poco a poco las estaciones de trabajo fueron creciendo en tamaño, gracias a la bajada de precios de la infraestructura necesaria y el aumento del tamaño del contenido ofrecido y de la potencia del hardware. Así fue como llegaron los primeros \textit{racks} de servidores, unión de varios de ellos para aumentar la capacidad general del sistema. Cuando estos alcanzaron un tamaño considerable (necesitando incluso edificios para ser alojados) pasaron a denominarse datacenters (en castellano, centros de procesamiento de datos). Estos introdujeron ciertas ventajas, siendo la mayor de ellas el aumento de la capacidad de procesamiento, aunque también introdujeron mejoras en seguridad física de la infraestructura, pues ahora esta se alojaba en un lugar específico para ello. Este tipo de almacenamiento se sigue usando hoy en día, sobre todo por grandes compañías que requieren tener almacenada una cantidad de información masiva, como por ejemplo Google (ver [1] para más información sobre los datacenters de Google). Al aumentar la capacidad de almacenamiento y procesamiento de los servidores, el uso de estos como una nueva forma de negocio fue instaurándose en el mundo de la informática; empiezan a surgir empresas que alquilan recursos a aquellas personas que quieren tener su propia página web sin necesidad de que tengan que montar la estructura en casa, lo que les ahorra trabajo, mantenimiento y una cantidad de dinero considerable.
Después del boom que supusieron los datacenters, estos pronto empezaron a tener un tamaño descomunal, complicando su mantenimiento e incluso almacenamiento, ya que como hemos comentado los más grandes necesitaban sus propios edificios, lo que provocaba que solo las grandes empresas podían costear el tamaño de los datacenters necesarios. Así, poco a poco, la virtualización fue abriendose paso como tecnología emergente. La virtualización ofrece una capa de abstracción entre software y hardware, proporcionando beneficios tales como el aislamiento entre aplicaciones, un mayor aprovechamiento del hardware disponible y una mejora del mantenimiento. Aquí entra en juego el término 'Virtual Hosting'(en castellano 'almacenamiento virtual'), que tratará sobre las diferentes posibilidades de almacenamiento web en estos servidores virtuales. La virtualización adquiere una mayor potencia cuando los servidores virtuales empiezan a cooperar entre ellos en clusters virtuales\footnote{\url{https://technet.microsoft.com/en-us/magazine/hh965746.aspx}}, lo que consigue una mejora en términos de flexibilidad y coste, si bien requiere una configuración extra que puede añadir algunos problemas. Es necesario evaluar si el trabajo de configuración y mantenimiento extra compensa la ganancia que nos da el cluster virtual, pues puede que no necesitemos tantos recursos.
\subsubsection{Tecnología posterior: Cloud Computing}
Sin embargo esta tecnología también vería aparecer los mismos problemas que sus predecesoras, estando atadas a un almacenamiento en un lugar físico. Es aquí donde aparece el denominado 'Cloud Computing' o almacenamiento en la nube. Su presencia en este sector ha ido aumentando a pasos agigantados, apoyada gracias al uso que le han dado grandes compañías como Amazon, Google y Microsoft, de quienes emergió una arquitectura que se ha mantenido hasta hoy.
El almacenamiento en la nube se fundamenta en la oferta de servicios, de forma que el usuario accede a los recursos de internet mediante ellos sin tener que adquirir ningun tipo de hardware, manejar licencias software ni conocer a fondo la gestión de los mismos \footnote{\url{http://web.archive.org/web/20120915111539/http://www.itnews.ec/news/000396.aspx}}. Para atender todas las peticiones de servicios existen servidores desde internet encargados de ellas, teniendo acceso a ellos únicamente con tener conexión a internet. Se servirá a los usuarios desde varios proveedores repartidos por todo el mundo, lo que permite una mejora del tiempo de actividad.
Sin embargo, no todo lo referente al almacenamiento en la nube es bueno. Han surgido diversas críticas, sobre todo relativas a la privacidad de los datos alojados, pues estos quedan expuestos a terceros que pueden acceder a ellos y copiarlos. Richard Stallman fue uno de los que levantó la voz, diciendo que la nube exponía a los usuarios y que era una trampa para que la gente adquiriera cada vez más servicios y se volviera más dependiente a ellos, lo que conllevaría una dependencia con las empresas que gestionan estos servicios.\footnote{\url{http://www.theguardian.com/technology/2008/sep/29/cloud.computing.richard.stallman}} Otros problemas pueden ser la interdependencia entre proveedores web y la necesidad de conexión a internet para acceder a todo, lo que en caso de necesitar los datos en todo momento puede comprometernos en algunas situaciones. Este almacenamiento de datos que puedan ser sensibles e importantes en un lugar remoto puede dar lugar a problemas adicionales, sobre todo en grandes empresas y organizaciones, a las que puede no beneficiar ese tipo de almacenamiento.\footnote{\url{http://es.wikipedia.org/wiki/Computaci\%C3\%B3n_en_la_nube} \\ \url{http://www.artifactconsulting.com/lapeira/2011/02/28/motivos-para-rechazar-el-cloud-computing/}}
La nube es bastante joven aun, por lo que le queda un desarrollo importante a lo largo de los próximos años. Poco a poco irá cambiando y aumentando la infraestructura de la nube, gracias a la inversión de las empresas que ya se encuentran en ella y a la llegada de nuevas. Las nuevas ideas que estas aporten, unidas a un aumento progresivo del uso de la nube, harán que esta vaya evolucionando y adaptándose a las necesidades del usuario final, las personas de a pie, pues recordemos que el uso de internet está a la orden del día para casi cualquier persona del primer mundo\footnote{\url{http://ticsyformacion.com/2012/02/13/la-evolucion-del-web-hosting-infografia-infographic-internet/}}. ([2])
\subsection{Virtual Hosting}
El concepto de Virtual Hosting se refiere al método para alojar múltiples dominios en un único servidor, lo que permite a dicho servidor compartir su funcionalidad entre los distintos dominios, como por ejemplo la memoria o el procesador. Uno de sus principales usos es el almacenamiento web compartido, un servicio donde cada sitio web ocupa una parte del servidor, que está contectado a internet. Es la forma de almacenamiento más económica, pues permite a todo aquel que quiera tener una página web alojarla a un precio mucho más barato que si tuviera que alquilar un servidor completo, ya que se reparten los gastos de mantenimiento y alquiler del servidor entre todos los usuarios. Gracias a esto también se permite un mayor aprovechamiento de los servidores, los cuales tienen cada vez más capacidad de cómputo y podrían quedar desaprovechados si únicamente alojasen una web.
Sin embargo, no son todo ventajas en el hosting virtual. Debido al alojamiento compartido, es común que aparezcan fallos de seguridad, normalmente debidos a que el servidor tiene múltiples administradores independientes que trabajan con herramientas distintas, creando dificultades en el mantenimiento de los programas que se ejecutan en el servidor. Además, a causa del reparto de recursos, se crea una dependencia con los compañeros de servidor, ya que estos pueden sobrecargarlo, provocando una bajada en el rendimiento de nuestra propia web. En general, podemos decir que estamos fuertemente condicionados por lo que nuestros vecinos hagan en el servidor, tanto en materia de seguridad como de recursos.
Centrándonos ahora en el hosting virtual en sí, tenemos distintos tipos a diferenciar, de los cuales destacan dos: basado en nombre (name-based) y en IP (IP-based), aunque también existe una versión basada en puertos (port-based), si bien es más extraña. Vamos a hablar un poco de ellas con más detalle:
\underline{Name-based:} Esta opción almacena hosts con distintos nombre pero que comparten la misma IP, diferenciándolos a todos ellos por su nombre, que debe ser único. De esta forma, podemos tener dos o más páginas, como por ejemplo www.ejemplo.com y www.ejemplo.org, compartiendo IP pero distintas entre sí (y con su información almacenada en lugares distintos). Es una opción útil si no tenemos suficientes direcciones IP para cubrir todas nuestras páginas, pudiendo utilizar únicamente una. Debido a esto, se nos presenta un problema con las DNS, ya que al tener una única IP todos los nombres de nuestras páginas estarán asociados a ella. Por tanto, si DNS no funciona debidamente resulta imposible acceder a la página web, aun conociendo la IP, ya que no sabría a cual de las páginas acceder. Por norma general, si intentamos acceder directamente mediante la IP el servidor responderá con una página web por defecto, que usualmente no es a la que el usuario quiere acceder.
Existen ciertos problemas de seguridad adicionales si utilizamos este tipo de alojamiento, pero los trataremos más adelante en una sección propia.
\underline{IP-based:} En esta opción cada página web tendrá una IP única para sí misma, lo que facilita la configuración a costa de consumir más direcciones IP\footnote{Debido al rápido agotamiento de direcciones IPv4, esta opción no sería viable si la utilizara todo el mundo. Este es el principal problema de esta opción, la disponibilidad de direcciones IP.}. Es menos problemático en cuanto al acceso, pues cada web es distinta a las demás y se gestiona por separado, aunque aumenta un poco la carga del servidor, que tiene que escuchar distintas IP's, si bien esto no es significativo en gran medida. Se eliminarán los problemas anteriormente mencionados relacionados con las DNS, pues cada IP corresponde únicamente con una página.
\underline{Port-based:} Cada dirección estará asociada a un puerto concreto, aunque tendremos la misma IP. El puerto generalmente será el 80 para HTTP y el 443 para HTTPS, aunque puede estar sujeto a cambios. Es una forma de establecer conexiones seguras por defecto si el usuario las soporta. Por lo demás no está muy extendida, aunque se le puede dar uso.
Estas técnicas pueden ser combinadas dentro de un servidor, pudiendo tener varias direcciones IP y distinción de nombres dentro de estas.
Generalmente, para alojar nuestra página web, necesitaremos un servidor web, como pueden ser Apache, IIS o nginx, un servidor de bases de datos, como MySQL, servicios FTP y SSH para transferencia de archivos y control remoto y de correo a nivel de servidor.
\subsection{Apache}
El servidor web Apache\footnote{Para acortar, nos referiremos a él simplemente como 'Apache'.} es un servidor web HTTP de código abierto, siendo actualmente el más utilizado en todo el mundo [3]. Actualmente se encuentra en su versión 2.4.12.
Apache es un producto de la Apache Software Fundation, que se inició en el año 1995. La propia fundación lo presenta de la siguiente forma: \textit{'El servidor HTTP Apache es un servidor HTTP de código abierto para sistemas operativos modernos, incluyendo UNIX, Microsoft Windows, Mac OS/X y Netware. El objetivo de este proyecto es el de proveer un servidor seguro, eficiente y extensible que proporciona servicio HTTP de acuerdo a los estándares HTTP actuales. Apache ha sido el servidor web más popular en internet desde Abril de 1996.'}\footnote{http://httpd.apache.org/}
En el desarrollo de este trabajo trabajaremos con Apache instalado en Ubuntu 14.04. Para instalarlo, únicamente tenemos que ejecutar la orden 'sudo apt-get install apache2'. En caso de tener otro gestor de paquetes distinto a apt, el proceso a seguir es el mismo, con la orden correspondiente para dicho gestor y el paquete apache2. Para Windows, tenemos distintas aplicaciones que nos permiten usar Apache, tales como Apache Haus o WampServer, el cual incluye también MySQL y PHP, proporcionando lo conocido como WAMP: Windows, Apache, MySQL y PHP. En mi caso, al trabajar en Ubuntu, tengo instalado LAMP, si bien no es necesaria toda su funcionalidad en el desarrollo del trabajo.
\subsection{Configuración general de Apache}
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %
% La parte importante del trabajo. Virtual Hosting en Apache. Comentar que no se pueden hacer experimentos a gran escala pues conllevaría alquilar un servidor, crear una web y monitorizarla.
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %
En este apartado vamos a hablar de la configuración de Apache en Ubuntu de forma general, mientras que en el siguiente apartado nos centraremos en la configuración necesaria para proporcionar un servicio de hosting virtual.
Una vez realizada la instalación de Apache, tendremos todo lo relacionado con el servidor web en el directorio /etc/apache2. Aquí será donde tengamos todos los archivos de configuración de Apache, como por ejemplo apache2.conf o ports.conf. Cada archivo es relativo a una característica del servidor, y deberemos modificarlos para obtener los resultados que buscamos.
El archivo principal de configuración es apache2.conf. Aquí tendremos la configuración general del servidor: dónde tenemos el directorio raíz de Apache (por defecto /etc/apache2), qué archivos de configuración adicionales estamos utilizando (como podría ser el archivo de configuración de puertos), parámetros para la conexión, etc.
Para la configuración de los puertos de escucha, tenemos un archivo inicial que es ports.conf. Su formato es muy sencillo, simplemente hemos de indicarle los puertos que queremos escuchar con la línea 'Listen X', donde X es el número de puerto. Por defecto se escucha al puerto 80, y si tenemos posibilidad de conexión segura mediante SSL se escucha también el puerto 443 (para conexiones HTTPS). Si quisiéramos añadir más puertos podemos hacerlo añadiendo manualmente la línea indicada anteriormente. Para añadir otros archivos de configuración de puertos deberíamos irnos al archivo de configuración general apache2.conf y especificarlos ahí, utilizando la directiva Include (por ejemplo, Include ports.conf).
\subsection{Configuración enfocada al hosting virtual}
La carpeta sites-enabled tendrá mucha importancia para nosotros, pues ahí definiremos los archivos de configuración de los hosts virtuales que tendremos alojados en nuestro servidor. Dentro de esta, se encuentra el archivo de configuración 000-default.conf, que es el archivo de configuración por defecto que viene incluido con Apache. En mi caso, para definir los hosts virtuales, he creado varios archivos de configuración (uno para cada propósito), usando el que viene por defecto como plantilla. Al principio únicamente tenemos una entrada, que escuchará un host virtual. Está especificado de la siguiente forma:
<VirtualHost *:80> \\
\# ServerName www.example.com\\
DocumentRoot /var/www \\
...\\
</VirtualHost>\\
Al declarar el nuevo host, le indicaremos la IP y el puerto o puertos en los que escucha. En este caso estamos diciendo que escuche todas las IP's del sistema, y que escuche al puerto 80. Como solo tenemos asignada la IP local 127.0.1.1, se usará esta. Podemos ver el siguiente mensaje que aparece al iniciar el servicio apache: \\
\textit{'apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message'}
Este mensaje es un simple aviso de que, al no haber determinado un nombre para el servidor (pues tenemos la línea ServerName comentada, que es la que se encarga de hacerlo), solo se tendrán en consideración las peticiones hechas a la IP 127.0.1.1. En añadido, la IP del \textit{loopback} 127.0.0.1 también podrá usarse para el acceso a conexiones locales, por la naturaleza de esta IP.
La línea DocumentRoot nos indica el directorio raíz que almacenará los archivos para nuestra página web, que normalmente variará dependiendo de esta. Tenemos más opciones de configuración que podemos añadir aquí, tales como el correo del administrador del servidor, para el que usaremos la directiva ServerAdmin dirección-de-correo, y para el tratamiento de errores, disponiendo de las directivas ErrorLog y CustomLog entre otras. Se pueden añadir otras directivas, tales como la <Directory>, para el tratamiento de distintas opciones relacionadas con directorios. Como estas opciones no son especialmente relevantes para este trabajo, no profundizaremos en ellos, aunque las explicaremos si aparecen en el desarrollo de este.
\textbf{¿Qué hemos de hacer si queremos añadir nuevos hosts virtuales?}
Cada host virtual que queramos añadir quedará determinado en el archivo de configuración 000-default.conf de la carpeta sites-enabled, que especifica las webs que estaremos utilizando. Por normal general, cada nuevo host que añadamos tendrá su configuración entre las líneas <VirtualHost IP:Port>\ y </VirtualHost>. Dicha configuración dependerá del tipo de hosting virtual que queramos (IP-based o Name-based), por lo que distinguiremos entre ambos casos y los analizaremos con detalle.
\underline{Importante:} Siempre será necesario conocer nuestra IP para configurar los hosts virtuales en base a ella.
\subsubsection{Name-based}
Vamos a ver la configuración necesaria para poder servir distintos sitios web usando una política basada en nombre\footnote{Referencia principal: \url{http://httpd.apache.org/docs/2.4/en/vhosts/name-based.html}}. En primer lugar, necesitaremos definir los hosts virtuales mediante el uso de la directiva NameVirtualHost, indicándole la IP que vamos a utilizar. Por ejemplo, si nuestra IP es 200.200.200.200, al principio del archivo de configuración tendremos que incluir la línea:
NameVirtualHost 200.200.200.200:80\footnote{El puerto 80 es un ejemplo del puerto a usar. Podemos configurar cualquier otro o permitirlos todos con *}
A partir de aquí, usaremos la directiva <VirtualHost>\ para declarar todos los hosts virtuales asociados a la IP. La IP que incluyamos en la declaración debe conicidir con la que hayamos definido en NameVirtualHost. En nuestro caso deberíamos usar:
<VirtualHost 200.200.200.200:80>
Dentro de la directiva VirtualHost declararemos todo lo que sea necesario, aunque obligatoriamente tendremos que declarar el nombre del servidor, con ServerName, y el sitio en el que se encuentran alojados los archivos, con DocumentRoot. Adicionalmente podemos declarar alias para referirnos a más de un nombre, con la directiva ServerAlias. Yo he creado dos páginas de ejemplo, www.example1.com y www.example2.com, para las que he creado un archivo de configuración a partir de 000-default.conf. En él he usado todo lo explicado anteriormente para servir las dos páginas en una única IP, en este caso la 200.200.200.200:80. Podemos ver las líneas relevantes del archivo de configuración en la siguiente figura:
% Imagen aquí.
\begin{figure}[htpb]
\centering
\includegraphics[height=5cm]{../../nb}
\caption{Configuración para host basado en nombres.}
\end{figure}
Podemos ver que los archivos estarán alojados en la carpeta /var/www/html/example1 o /example2, que cada host tiene un nombre de dominio asociado y que además tiene un alias. El tratamiento de los errores es el que tiene por defecto el host que viene en el archivo 000-default.conf.
Si tuvieramos una solicitud al servidor que no coincidiera con ningún host virtual especificado, iría a parar al que se encuentre en primer lugar dentro del archivo de configuración. En nuestro ejemplo, se correspondería con www.example1.com.
Para hacer que las IP's que demos a nuestras web realmente funcionen (por ejemplo, para probarlas localmente), tenemos que asignarlas como direcciones de nuestra máquina. La forma más sencilla de hacer esto es irnos al archivo /etc/hosts y añadirlas manualmente\footnote{Esto será necesario sea cual sea el tipo de almacenamiento compartido que elijamos.}. Relativo a este ejemplo, he tenido que añadir las dos siguientes líneas en la zona para IPv4:
200.200.200.200 www.example1.com\\
200.200.200.200 www.example2.com
Que quedan junto a las direcciones del loopback y el localhost, que ya se encontraban en el archivo.
\underline{Importante:} Al añadir hosts virtuales no estamos añadiendo entradas al servidor DNS. Esta acción debe realizarse por separado dentro del servidor DNS, para que los nombres se vinculen a la IP del sistema. Como esto no abarca el tema del trabajo, no lo trataremos aquí, pero es conveniente saber que esto debe hacerse, pues en otro caso no se servirían nuestras webs al no estar referidas por el servidor DNS, ya que el usuario nunca podría llegar a ellas.
\subsubsection{IP-based}
Pasamos ahora a la configuración necesaria para el alojamiento compartido basado en IP. En este caso, la combinación IP-Puerto de cada host virtual debe ser diferente. Como se comenta en la documentación de Apache\footnote{\url{http://httpd.apache.org/docs/2.4/en/vhosts/ip-based.html}\\También es la referencia principal de la sección.}, \textit{'en terminología del servidor HTTP Apache, usar una única IP con múltiples puertos TCP está considerado hosting virtual basado en IP.'} Esto puede entrar en conflicto con lo anteriormente dicho sobre IP-based y port-based, considerando la versión basada en puertos como parte de la versión basada en IP. Esto se queda a la interpretación de las compañías, que pueden considerarlo de una forma u otra. No obstante, la base teórica no cambia.
Debido a la necesidad de distintas IP's, tendremos que especificarlas en el archivo /etc/hosts mencionado anteriormente, de la misma forma. Yo he añadido dos nuevas IP's para dos nuevas páginas, con las líneas:
100.100.100.100 www.example3.com \\
100.100.100.101 www.example4.com
A la hora de crear un archivo de configuración para tener un almacenamiento basado en IP, se crea una sección para cada host virtual con la directiva <VirtualHost>. Cada una de ellas llevará en su cabecera la combinación IP:Puerto correspondiente al host virtual que referencie, a la que además Apache debe escuchar, por lo que utilizaremos la directiva Listen IP:Puerto antes de declarar el host virtual. Dentro de la directiva para el host virtual declararemos todo lo que sea oportuno, como el directorio raíz y el nombre del servidor. Podemos ver un ejemplo a continuación\footnote{Al ser parecido al anterior, no he considerado necesario hacer un comentario de las directivas incluidas.}:
% Imagen
\begin{figure}[htpb]
\centering
\includegraphics[height=5cm]{../../ip}
\caption{Configuración para host basado en IP.}
\end{figure}
En caso de llegar una petición que no corresponda a ninguna de las IP's especificadas, tenemos distintas opciones. La primera es que todas estas solicitudes vayan a parar al host virtual especificado en el cuerpo del archivo de configuración de Apache. Esta página puede ser una página de bienvenida o de error, aunque se recomienda ofrecer información útil al usuario, dándole por ejemplo una lista de los enlaces simbólicos de las páginas almacenadas en el servidor. Esto queda ya a gusto del administrador.
La segunda opción es crear un host virtual que recoja todas las peticiones por defecto. Esto lo haremos con la palabra reservada \_default\_, usandola en la declaración del host virtual como sigue:
<VirtualHost \_default\_:80>
Aunque no es necesario, se recomienda utilizar un puerto en esta declaración. Este uso es la forma más común de configurar y activar un protocolo SSL, utilizando el puerto 443 combinado con algunas opciones.
\subsubsection{IP-based y Name-based combinados}
Si queremos combinar las dos técnicas, debemos proporcionar un nombre a cada host virtual, como hacíamos para Name-based (usando la directiva NameVirtualHost y la IP correspondiente), y una vez hecho esto declarar todos los nombres que queremos dentro de una IP. Como ya hemos visto un ejemplo para cada caso, me abstengo de incluir otro pues sería redundante. No obstante, podemos ver uno en la página de Apache, en este enlace \url{http://httpd.apache.org/docs/2.4/vhosts/examples.html}.
En todos los casos mencionados anteriormente hemos de habilitar el host virtual para poder visualizarlo. Esto podemos hacerlo con la orden a2ensite, que nos muestra los archivos de configuración disponibles, dándonos a elegir cual queremos habilitar. La orden compañera a2dissite nos permite deshabilitar hosts activados.\footnote{Página de manual de a2ensite y a2dissite: \url{http://manpages.ubuntu.com/manpages/precise/man8/a2ensite.8.html}}
Toda la información relativa a la parte de configuración ha sido consultada en las página web de Apache\footnote{\url{http://httpd.apache.org/docs/2.4/en/vhosts/}} y en los libros [4] y [5] indicados en la bibliografía.
\subsection{Conexiones seguras - SSL}
Para establecer una conexión segura utilizaremos el protocolo SSL [6], que se basa en el uso de certificados para la creación de una clave de encriptación. Normalmente nuestro servidor Apache soportará SSL, aunque tendremos que configurarlo propiamente para que las peticiones que permitan conexión segura la obtengan. Anteriormente mencionamos que el uso de la palabra \_default\_ podía ayudarnos a establecer esta configuración por defecto, pero puede que no queramos que esto sea siempre así, y permitir solo a algunos hosts o a una parte de estos el uso de conexión segura. Para ello deberemos usar distintas directivas, como pueden ser las siguientes:
\begin{itemize}
\item LoadModule ssl\_module - Para cargar el módulo SSL.
\item SSLEngine on - Para activar el uso de SSL (en la declaración de un host virtual).
\item SSLCertificateFile y SSLCertificateKeyFile para los archivos de certificados (dentro de la declaración del host virtual).
\item Y un largo etcétera, para configurar distintos aspectos (p. ej. timeouts o semillas).
\end{itemize}
Sin embargo, nos encontramos con un problema fundamental, relativo al hosting basado en nombres. Nos gustaría poder tener distintos hosts SSL en una única IP, cosa que no es posible debido a cómo trabaja SSL, ya que únicamente permite un host seguro por cada combinación IP:Puerto. En otro caso, el acceso a una de estas IP's derivaría en mensajes de error dados por el navegador, pues estaría recibiendo un certificado erróneo si este no coincidiera con el de la página a la que intentamos acceder (que es lo que normalmente sucede). Esto ocurre debido a que cuando el navegador hace una petición SSL, lo primero en enviarse desde el servidor al navegador es el certificado, para iniciar la encriptación SSL. Como esto ocurre antes de que el servidor sepa la URL a la que se está intentando acceder (el nombre del host), es imposible elegir un host virtual particular y mandar su certificado. Por lo tanto no se puede asociar más de un certificado a cada pareja IP:Puerto.
\textbf{Posibles soluciones}
La solución más sencilla sería simplemente ignorar el problema; aunque haya un error de certificado, en realidad no está habiendo ningún fallo en la conexión, que podría continuar sin problemas si así se lo especificásemos al navegador. Al ocurrir esto, el navegador nos daría un mensaje parecido a este: \\
\textit{'Ha intentado establecer una conexión con www.ejemplo1.com. Sin embargo, el certificado de seguridad presentado pertenece a www.ejemplo2.com. Es posible, aunque improbable, que alguien esté intentando interceptar su comunicación con esta página web. Si sospecha que el certificado mostrado no pertenece a www.ejemplo1.com, por favor, cancele la conexión y notifíqueselo al administrador del sitio.}\footnote{Traducción del inglés}
Si bien ignorar el problema puede ser útil en fases iniciales o de desarrollo, pues el flujo de peticiones se limitará a peticiones locales y muy pocas externas, es bastante poco útil en caso de que nuestra web tenga un cierto número de visitas, ya que no ofrece seguridad al usuario, el cual, al ver el mensaje que le presenta el navegador, probablemente cancele la conexión.
Otra opción es usar más de una IP o distintos puertos, pero esto entra en conflicto con la técnica utilizada; es lógico pensar que si hemos utilizado un almacenamiento basado en nombres, no disponemos de las suficientes direcciónes IP's para poder asignar una a cada web, aunque podría darse la posibilidad. En el caso de los puertos, dar un puerto distinto a cada web resultaría laborioso, pues al no ser un puerto por defecto para la conexión, el usuario tendría que especificarlo a la hora de acceder a la página. Sin embargo, esta opción es una buena alternativa si los accesos a la web van a realizarse mediante enlaces simbólicos desde otros lugares, evitando que el usuario tenga que especificar la dirección y puerto de nuestra web.
Tenemos otra opción, que es la de los certificados comodín (wildcard), que nos permite tener un único certificado para múltiples sitios, evitando los problemas anteriormente mencionados. Es posible generar estos certificados, pero al no estar directamente relacionado con la materia no lo trataremos aquí. Considero que la generación de certificados en general es un tema de gran interés, pero no corresponde hablar de él en este trabajo, que está enfocado en otra dirección.
Por último, la mejor opción que tenemos es el uso de Server Name Indication (SNI), una extensión del protocolo TLS\footnote{Propuesto en 2003 en el RFC 3546, actualmente obsoleto \url{http://tools.ietf.org/html/rfc3546}} que indica, en el proceso de \textit{handshaking}, el nombre del host al que el cliente está tratando de acceder. De esta forma permitimos que cada sitio tenga un certificado propio y no uno común para todos los que compartan IP, pues el servidor es capaz de elegir correctamente el que debe servir, solucionando el problema que se nos presentaba. Si bien SNI podía dar problemas si el navegador no lo soportaba y el servidor lo tenía configurado, en la actualidad prácticamente todos los navegadores lo incorporan. Apache soporta SNI desde su versión 2.2.12, con el módulo de SSL. \\
Para ver más sobre SNI, consultar el último RFC de TLS [7].
\textbf{Implementación en apache}
Para usar SSL en un virtual host tendremos una configuración parecida a la siguiente:
<VirtualHost \_default\_:443>\\
SSLEngine On\\
SSLCertificateFile \dots\\
SSLCertificateKeyFile \dots\\
\dots\\
</VirtualHost>
La directiva Redirect puede sernos útil para redirigir conexiones seguras.
También podemos requerir conexión SSL para el acceso a ciertos lugares, con la directiva Directory (normalmente la ubicaremos dentro de la directiva VirtualHost). Podemos hacerlo como sigue:
<Directory /www/secure>\\
SSLRequireSSL\\
\dots\\
</Directory>
Esto prohibe peticiones que no sean SSL al directorio indicado.
\pagebreak
\section{Bibliografía. Sitios de interés.}
[1] Centros de datos de Google - \url{http://www.google.com/about/datacenters/}
[2] Evolución del almacenamiento web - \url{http://www.hansoninc.com/the-evolution-of-web-hosting/}
[3] - Uso de servidores web - \url{http://news.netcraft.com/archives/2015/04/20/april-2015-web-server-survey.html\#more-18965}
[4] - Ken Coar, Rich Bowen - Apache. Ed. Anaya.
[5] - Mohammed J. Kabir - Apache Server Bible. Ed. Anaya.
[6] - RFC 6101 - SSL \url{https://tools.ietf.org/html/rfc6101}
[7] - RFC 6066 - TLS \url{https://tools.ietf.org/html/rfc6066}
%{Aparte. Ideas para la presentación. Preguntas.}
%
%\item Almacenamientos a lo largo de la historia.
%\item Tipos de hosting virtual. Tanto para presentación como para preguntas.
%\item Combinación de tipos de hosting virtual.
%\item Archivos de configuración de Apache.
\end{document}