La gestión de redes en la nube demuestra algunos aspectos bipolares — este es uno de los principales elementos que favorecen la computación en nube y también uno de los peligros para los usuarios de la computación en nube.

La degradación del desempeño de red y la inestabilidad pueden afectar considerablemente el consumo de recursos de nube; por lo tanto, las aplicaciones que estén relativamente aisladas o diseñadas especialmente para solucionar perturbaciones de red tienen una ventaja al ejecutarse en la nube.

Desde una perspectiva diferente, los recursos de red pueden virtualizarse y utilizarse en la computación en nube tal como se hace con otros recursos.

Las diferentes capas del sistema de red serán responsabilidad o bien del proveedor de la nube, o bien del consumidor de la nube, dependiendo del tipo de nube. La siguiente tabla resume algunos escenarios típicos:

La tabla es la simplificación de los diversos modelos que existen en la práctica. No obstante, a partir de la tabla es obvio que una IaaS proporciona a los consumidores de la nube una flexibilidad considerablemente mayor en topología de red y servicios que las nubes PaaS y SaaS, posiblemente con el costo adicional de la administración de las herramientas que proporcionan tal flexibilidad.

Examinemos los pros y los contras de algunas herramientas de red, bajo la lente de diferentes escenarios de negocios y de sus diferentes requerimientos.

Volver arriba

Cómo las herramientas de red son facilitadoras en diversos escenarios

La Figura 1 describe una topología de red típica para una aplicación da web compuesta. Esta contiene configuraciones de firewall, configuración de VLAN, configuración de IP pública/privada para balanceo de carga y acceso a la Intranet de asociados de negocios.

Observemos cómo se pueden utilizar las herramientas de red en diferentes escenarios de organización de nube de negocios.

En un sistema de producción (que utiliza firewalls):

• También se puede usar un proxy, pero normalmente para balanceo de carga y no para propósitos de seguridad.
• Un administrador puede acceder a servidores backend vía túnel SSH o un proxy SOCKS.
• Se necesitan reglas de firewall para permitir que los servidores que están dentro del firewall puedan acceder a Internet para actualizaciones de seguridad, activación de licencias y otras tareas, sin hacer que los intervalos sean visibles para Internet.

Para escenarios de desarrollo (que involucran el uso de VPNs):

• Puede llegar a ser necesario el acceso revertido a la empresa.
• Se requiere una configuración ligera porque tal vez no haya un experto de red disponible para soporte.
• Se puede utilizar un servidor VPN en un computador portátil con DHCP para permitir el acceso desde la nube.

A nivel corporativo:

• Puede necesitarse una VPN de sitio-a-sitio para acceso general a la empresa.

Nota del editor: La sección Recursos contiene otros recursos que cubren la gestión de redes y las herramientas para la nube de nivel corporativo, incluyendo Entregarle al usuario el control de la red en nube: Vea cómo usar una red virtual puede dar al usuario el control de gestión de redes en la nube.

Volver arriba

Herramientas y las tareas que cumplen

A continuación hay una lista de herramientas útiles para administrar la entrega de los servicios de nube sobre una red.

• Conectándose a la VM (direcciones IP)
• Administrando redes virtualizadas
• Administrando múltiples direcciones IP individuales
• Utilizando un firewall para proteger múltiples máquinas virtuales
• Autenticando usuarios y servidores vía SSH o PuTTY
  • Transferencia de puertos
  • Creando y usando el túnel SSH
  • Uso de túnel con línea de comandos con OpenSSH
  • Uso de túnel con PuTTY
• Usando redes virtuales privadas
• Configurando OpenVPN
• Configurando un servidor proxy

Volver arriba

Conectándose a la VM vía direcciones IP

Una de las primeras tareas que usted enfrenta en la computación en nube es cómo conectarse con su máquina virtual. Existen diferentes opciones cuando se crea una máquina virtual: generada por sistema, reservada y red virtual de área local (VLAN).

La generada por sistema es análoga a las direcciones asignadas por protocolo de control de host dinámico (DHCP). Estas son en realidad direcciones IP estáticas pero asignadas por la nube IaaS. Esta es la opción más fácil si todo lo que ha necesidad es una máquina virtual en la cual poder iniciar sesión para utilizarla.

Las direcciones IP reservadas son direcciones que pueden ser suministradas y administradas de forma independiente respecto a una máquina virtual. Las direcciones IP reservadas son útiles si usted desea asignar múltiples direcciones IP a una máquina virtual.

Trataremos la VLAN más adelante en este artículo.

Volver arriba

Administrando redes virtualizadas

Cuando se trabaja con sistemas de máquinas virtuales y se considera la seguridad de red, es necesario administrar redes. Los recursos de red pueden virtualizarse tal como otros recursos de la nube. Para hacer esto una nube utiliza conmutadores virtuales para separar una red física en particiones lógicas. Este concepto se ilustra en la Figura 2.

Las redes virtuales de área local (VLANs) pueden utilizarse como una extensión de la red privada de su empresa. Las VLAN en nubes usan direcciones IP privadas para restringir la visibilidad de red de las máquinas virtuales conectadas a ellas. La Internet Assigned Numbers Authority (IANA) reserva los siguientes tres bloques del espacio de la dirección IP para redes privadas:

• 10.0.0.0 - 10.255.255.255 (prefijo 10/8)
• 172.16.0.0 - 172.31.255.255 (prefijo 172.16/12)
• 192.168.0.0 - 192.168.255.255 (prefijo 192.168/16)

Es posible conectarse a una VLAN mediante una red privada virtual (VPN) cifrada o por enrutamiento a través de una máquina virtual con doble encauzamiento conectada a otra red, incluyendo Internet.

Un hypervisor puede compartir una interfaz de red física individual con múltiples máquinas virtuales. Cada máquina virtual cuenta con una o más interfaces de red virtual. Existen tres formas en las que el hypervisor puede hacer esto:

• Puentes
• Enrutamiento
• Traducción de dirección de red (NAT)

Los puentes normalmente son el método predeterminado. En este modo el hypervisor trabaja en la capa de enlace de datos (Capa OSI 2; Tabla 1) y hace que la interfaz de red virtual sea visible externamente a nivel de Ethernet.

En el modo de enrutamiento el hypervisor funciona al nivel de la capa de red (#3) y hace que la interfaz de red virtual sea visible externamente a nivel de IP.

En la traducción de dirección de red, la interfaz de red virtual no es visible externamente. En lugar de ello, permite a la máquina virtual enviar datos de red hacia Internet, pero la máquina virtual no es visible en Internet.

La traducción de dirección de red se utiliza normalmente para ocultar interfaces de red de virtualización con direcciones IP privadas, tras una dirección IP pública usada por un host o enrutador. El software para traducción de direcciones de red cambia la información de la dirección IP en los paquetes de red basada en la información en una tabla de enrutamiento. Los valores de verificación del paquete también deben cambiarse.

La traducción de dirección de red puede utilizarse para poner en la red más servidores que el número de máquinas virtuales que usted tenga. Esto lo puede hacer mediante traducción de puertos. Esta es una de las razones por la cuales la IPv6 todavía no es usada ampliamente — incluso cuando el número de computadores excede el número de direcciones IP. Existen ciertas cosas que es posible hacer para compartirlas.

Por ejemplo, suponga que usted tiene un enrutador y tres servidores manejando HTTP, FTP y correo respectivamente. Es posible asignar una dirección IP pública al enrutador y direcciones IP privadas a los servidores HTTP, FTP y de correo, y direccionar el tráfico entrante como se muestra en la Tabla 2.

Volver arriba

Trabajando con múltiples direcciones IP

IBM SmartCloud Enterprise le permite administrar direcciones IP de forma independiente y asignarlas a máquinas virtuales, incluyendo la posibilidad de asignar múltiples direcciones IP a una sola máquina virtual.

¿Por qué querría usted hacer eso? Usted podría querer mayor disponibilidad o conectarse a diferentes zonas de red con un firewall o una VPN. Esos pasos se describen en el consejo developerWorks Extensión de redes de área local virtual.

Volver arriba

Utilizando un firewall para proteger múltiples máquinas virtuales

Un firewall individual es un firewall que está instalado en el mismo servido que el recurso que está protegiendo. Esta es una herramienta esencial en la computación en nube. La mayoría de sistemas operativos modernos, incluyendo todas las imágenes del IBM SmartCloud Enterprise, incluyen un firewall individual. En máquinas virtuales Linux® es iptables; en Windows® es una solución Microsoft® .

En IBM SmartCloud Enterprise, también hay un firewall entre el hypervisor y las máquinas virtuales que este administra.

Una regla de firewall especifica un conjunto de criterios para un paquete de red y un objetivo. Cuando llega un paquete de red, cada regla es verificada. Si el paquete no satisface los criterios de la regla, entonces se verifica la siguiente regla.

En máquinas SUSE es posible usar la herramienta de administración YAST para añadir reglas de firewall. Por ejemplo , para permitir el acceso al puerto 50030 desde cualquier dirección externa:

1. Inicie YAST desde la línea de comandos escribiendo yast como raíz y navegue hacia Security and Users > Firewall usando la tecla Tab y presione Enter. Se abrirá una pantalla similar a la de la Figura 3.
   
   Figura 3. Herramienta YAST para administración de firewall
   
   
   
2. Navegue hacia Custom Rules y haga clic en Enter.
3. Navegue hacia Add y haga clic en Enter.
4. Ingrese 0/0 en Source Network, la cual indica la computadora fuente y 50030 en el puerto, que es el puerto en el que usted está interesado(a). Vea la Figura 4.
   
   Figura 4. Regla de firewall personalizada en YAST
   
   
   
5. Haga clic en Add, Next y Finish. No hay necesidad de reiniciar manualmente. YAST se encarga de ello.

En imágenes Red Hat es posible usar el comando iptables para administrar reglas de firewall. La forma básica de un comando iptables es:

# iptables [-t table] -[AD] chain rule-specification [options]

Las acciones asociadas con una regla de firewall incluyen ACCEPT, DROP, QUEUE y RETURN. Si usted no desea aceptar un paquete de red entonces deberá especificar una acción DROP . En el comando iptables , A adjunta una regla y D elimina una.

Hay tres tablas de firewall. La tabla predeterminada tiene por nombre filter. Esta tabla contiene tres cadenas: input, forward y output. La cadena input es para los paquetes que ingresan a los socket locales, la cadena forward es para los paquetes que son enrutados y la cadena output es para los paquetes generados localmente.

Como ejemplo, para permitir paquetes de red provenientes de cualquier fuente en el puerto 80, el puerto HTTP predeterminado, use el comando # /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT.

Esto añade una regla a la cadena input de la tabla filter para paquetes TCP en el puerto 80, con una acción ACCEPT . El parámetro -p especifica el protocolo, tcp en este caso. La opción --dport 80 es el puerto de destino, 80 en este caso. La opción -j (jump) es el objetivo, ACCEPT en este caso.

Puede ser una buena práctica dejar reglas de firewall vigentes solo durante el tiempo que las necesite. La forma en línea de comandos es ideal para hacer esto. No obstante, con frecuencia usted querrá mantener reglas permanentemente, incluso después de la próxima vez que usted reinicie la instancia. Para hacerlo, edite el archivo /etc/sysconfig/iptables. Un archivo iptables típico se parecerá a lo siguiente:

*filter
:INPUT DROP [67:14849]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [346:34696]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
COMMIT

Este especifica las reglas de la tabla filter . Todos los paquetes entrantes de los puertos 67 a 14849 se detendrán. No se permite redireccionamiento, todos los paquetes salientes en los puertos 346 a 34696 están permitidos, y los paquetes entrantes en el puerto 22 (SSH) están permitidos. Después de que usted haya editado y guardado el archivo, inicie o reinicie el servicio iptables con el comando # /sbin/service iptables restart.

Si usted ha realizado cambios con el comando iptables , guárdelos con el comando # /sbin/service iptables save.

Compruebe el estado del firewall con el comando:

# /sbin/service iptables status

Es posible lograr algunas ventajas en rendimiento al utilizar las reglas de firewall de hypervisor. Sin embargo, no es posible manejarlas tan dinámicamente como las reglas del firewall local y solo puede hacerlo para sus imágenes de visibilidad de nivel personal o comunitario.

Es posible establecer las reglas de firewall de hypervisor en el momento de creación de la instancia, usando el archivo parameters.xml en IBM SmartCloud Enterprise. Este archivo XML se halla en la entrada de catálogo de activos de su imagen.

Los firewall Linux también pueden utilizarse para proteger servidores diferentes al servidor en el cual reside el firewall. En realidad, esta es la configuración preferida pues proporciona un nivel adicional de aislamiento.

Para proteger servidores, usted primero necesita aislar los servidores que está protegiendo de Internet, ubicándolos en una VLAN. Añada dos direcciones IP en la máquina virtual del firewall. Finalmente, configure reglas para reenvío entre Internet y la VLAN en iptables. Vea la Figura 5.

En la Figura 5, la máquina virtual VM1 está conectada directamente a Internet. La VM2 de firewall tiene direcciones IP:

• Una permite acceso vía Internet
• La otra está en la VLAN privada

La máquina virtual VM3 tiene una dirección IP individual a la cual solo se puede acceder vía VLAN. Una regla de firewall que permita acceso de entrada desde Internet y que correlaciones la IP del firewall con la IP de la VM3 para un puerto determinado, permite acceso de entrada desde Internet para ese puerto únicamente.

Por ejemplo, si este era un servidor web y un usuario intentó acceder a la dirección IP del firewall en el puerto 80, entonces esa solicitud sería reenviada a un servidor web en VM3. Ningún otro puerto en VM3 está abierto.

Otra regla de firewall permite acceso de salida para VM4. Esto se puede hacer usando puertos dinámicamente para una conexión TCP individual. Por ejemplo, si VM4 intenta abrir una conexión TCP hacia Internet, entonces el firewall puede encontrar un puerto disponible y cambiar el paquete TCP para que contenga este puerto y la dirección IP propia del firewall. Cuando este recibe un paquete de retorno de Internet en respuesta a la solicitud de VM4, entonces hace correlacionamiento revertido. De esta forma, la máquina virtual VM4 puede abrir conexiones hacia Internet sin ser visible en Internet.

Volver arriba

Autenticando servidores y usuarios con SSH o PuTTY

Como se vio en secciones previas, SSH es una herramienta fundamental para la computación en nube; puede valer la pena aprenderla para resolver numerosos problemas prácticos de la computación en nube. SSH se diseñó como un reemplazo seguro de telnet, pero ahora se usa común y programáticamente para muchas aplicaciones.

Las dos versiones principales de SSH son SSH-1 y SSH-2. La versión original, SSH-1, fue reemplazada por SSH-2. SSH-2 se desarrolló como un estándar por la Internet Engineering Task Force y se publicó en el 2006. La implementación más popular de SSH es el proyecto de fuente abierta OpenSSH. En Windows, PuTTY es el cliente más popular. Consulte la sección Recursos para información sobre el uso básico de PuTTY.

SSH utiliza criptografía de clave pública para autenticar la computadora remota y el usuario, si se necesita. Además del inicio de sesión remoto, SSH también puede utilizarse para el uso de túneles, redireccionamiento, conexiones X11 y transferencia de archivos. Los archivos se pueden copiar con el protocolo SCP (Copia Segura) y con SFTP, los cuales usan SSH.

Considere este escenario común: Usted crea dos instancias en la nube, server1 y server2, y desea abrir una sesión SSH desde server1 hacia server2. Usted ya debe tener su clave privada en su PC local, por lo que necesitará copiarla en server1. Es posible hace r esto con WinSCP. Server2 ya estará configurado para aceptar esta clave porque esta se creó con la clave pública en la lista de claves autorizadas. Use estos comandos:

> chmod 0700 mykey
> ssh -i mykey server2

Donde mykey es el nombre de su clave privada. Usted debe crear su clave privada de manera que no sea visible para otros usuarios. El comando chmod hace eso. Si usted no lo hace, ssh reclamará y puede ignorar la clave. La opción -i utiliza la clave que usted acaba de copiar en la sesión SSH. El valor predeterminado es~/.ssh/id_rsa. El argumento server2 es el nombre host o dirección IP del server2. Asegúrese de contar con los permisos adecuados en el directorio .ssh. Si algunos de los archivos son propiedad de la raíz, entonces cámbielos a idcuser con el comando chown .

Para generar una nueva clave SSH, use el comando ssh-keygen . Por ejemplo,> ssh-keygen -t rsa -P 'My Passphrase' -f ~/.ssh/mykey.

Eso genera un tipo RSA (distintivo -t ) con la frase de acceso 'My Passphrase' (-P distintivo), ponga la clave privada en el archivo ~/.ssh/mykey (distintivo -f ) y ponga la clave pública en el archivo ~/.ssh/mykey.pub. Si no utiliza una opción -f entonces la clave privada será escrita en ~/.ssh/identity. Las c laves autorizadas están contenidas en el archivo ~/.ssh/authorized_keys. Para añadir una nueva clave pública al archivo de claves autorizadas, añádalas con el comando:

> cat mykey.pub >> ~/.ssh/authorized_keys

Las claves SSH generadas por IBM SmartCloud Enterprise están en un formato compatible con OpenSSH. También es posible convertirlas a formato PuTTY usando PuTTYgen. PuTTYgen también puede convertir de regreso a formato OpenSSH, en caso de que pierda la clave original. ara hacer esto, vaya al menú Conversions > Export OpenSSH Key y guarde el archivo.

PuTTYgen también puede generar claves. Cargue en SmartCloud Enterprise la clave SSH pública generada, si prefiere no utilizar las claves generadas por la nube.

El archivo de configuración para SSH en los sistemas Linux en IBM SmartCloud Enterprise está en /etc/ssh/ssh_config y /etc/ssh/sshd_config. El parámetro AllowedUsers es un parámetro que usted tal vez desee cambiar. El valor de este parámetro es una lista de patrones de nombres de usuario separados por espacios. Por ejemplo,AllowUsers idcuser webadmin.

Para iniciar el servidor SSH (sshd), use el comando # /etc/init.d/sshd start; para reiniciarlo, use el comando # /etc/init.d/sshd restart.

Es posible que usted desee incluir el nombre de usuario en el comando SSH en algunos casos, especialmente de los scripts. Para hacerlo, use la forma $ ssh -i .ssh/key-file idcuser@host:

• El síbmolo @ define el nombre de usuario a partir del nombre de host o la dirección IP.
• La opción -v (verboso) imprime información adicional y puede ser útil en la depuración de problemas.

Para la mayoría de imágenes en IBM SmartCloud Enterprise, de manera predeterminada el servidor SSH envía mensajes de información y de errores al archivo /var/log/secure.

Es una buena práctica añadir una frase de acceso a sus claves SSH para protegerlas. El problema con esa práctica es que los scripts y los programas que necesitan acceso a las claves no tienen la frase de acceso. La herramienta ssh-agent, que es una parte de la distribución OpenSSH, está diseñada para resolver este problema. Esta puede automatizar el ingreso de la frase de acceso de forma similar a como un archivo oculto (stash) puede permitir al servidorweb abrir el certificado X.509.

Numerosas herramientas hacen uso de túnel sobre SSH. Por ejemplo, la tecnología de escritorio remoto NX utiliza túnel sobre SSH. Varias herramientas para transferencia de archivos también utilizan túnel sobre SSH.

Secure Copy, también conocida como SCP, es un protocolo y un programa para transferir archivos de forma segura. Está basado en el comando BSD remote copy (RCP) que utiliza túnel sobre SSH. Como con SSH, este se ejecuta de forma predeterminada en el puerto 22. Para usar SCP en Linux, use este comando:

# scp -i identity_file host:sourcefile destinationfile

Este comando utiliza el archivo de clave privada identity_file para copiar el archivo sourcefile desde la máquina host hacia el archivo destinationfile de la máquina local.

El programa Windows WinSCP en realidad funciona en SFTP (FTP seguro) de manera predeterminada, pero también puede usar SCP.

Transferencia de puertos con SSH

La transferencia de puertos con SSH es un proceso donde:

1. La dirección y el puerto de un paquete son transferidos hacia un nuevo destino.
2. El paquete es llevado sobre una conexión SSH donde se accede al destino.

Esto permite al usuario usar otro protocolo mediante túnel sobre una conexión SSH. Con OpenSSH, esto se lleva a cabo con sshd. Esto puede ser útil si el protocolo al que se está aplicando el túnel no es seguro o si la combinación de dirección de destino y puerto no es visible desde el origen.

El cliente que utiliza el protocolo con túnel debe estar en capacidad de especificar un puerto no estándar para que esto funcione. El concepto es que usted establece una sesión SSH para su servidor y luego especifica desde cuál puerto de la máquina del cliente transferir las conexiones.

SSH también puede transferir hacia otros servidores. La transferencia de puertos puede ser importante para resolver problemas de conectividad entre la nube, su estación de trabajo y los recursos de TI dentro de su compañía. Esto es especialmente importante cuando es necesario acceso flexible pero seguro para tareas administrativas de bajo volumen, como mover archivos hacia ubicaciones seguras.

Conocer bien las herramientas puede evitarle tener que escribir y mantener código personalizado para estas tareas administrativas. En esta sección se presenta un ejemplo con VNC.

En aplicaciones nube con frecuencia es necesario conectarse con equipos Linux remotos de escritorio. Como las máquinas remotas están en Internet, usted debe evitar enviarles tráfico de red no asegurado y también debe evitar abrir servicios inseguros, como VNC, en Internet.

La Figura 6 muestra una representación esquemática de las conexiones de red involucradas.

Un servidor VNC ejecutándose en la máquina virtual en el puerto 5901 se conecta a un monitor X11, que a su vez soporta un equipo de escritorio de Linux. El Pc portátil o la estación de trabajo utiliza un cliente SSH para crear una conexión con un túnel hacia el servidor SSH que se ejecuta en la máquina virtual. Un firewall que se ejecuta en la máquina virtual evita que cualquier tráfico diferente al tráfico SSH que se ejecuta en el puerto 22, acceda a la máquina virtual. El túnel permite que un cliente VNC que se esté ejecutando en el portátil se conecte al servidor VNC, pasando a través del firewall del puerto 22.

Creando y usando el túnel SSH

1. Cambie la raíz y vaya al directorio /etc/ssh y edite el archivo sshd_config:

   AllowTcpForwarding yes

   
   
2. Reinicie el servidor ssh como raíz:

   # /etc/init.d/sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ]

   
   
3. Si todavía no está ejecutándose, inicie el VNC como idcuser:

   $ /usr/bin/vncserver ... New 'vhost0270:1 (idcuser)' desktop is vhost0270:1 Creating default startup script /home/idcuser/.vnc/xstartup Starting applications specified in /home/idcuser/.vnc/xstartup Log file is /home/idcuser/.vnc/vhost0270:1.log

   
   
4. Ingrese la contraseña cuando se le solicite y responda no a la contraseña solo visible. El comando imprime la información mostrada, la cual incluye el nombre del archivo log.
5. La primera vez que usted ejecuta vncserver, este crea el archivo de configuración ~idcuser/.vnc/xstartup. Es necesario cambiar dos configuraciones en ese archivo para poder iniciar sesión con un equipo normal de escritorio. Retire los comentarios de estas dos líneas del archivo ~idcuser/.vnc/xstartup:

   unset SESSION_MANAGER exec /etc/X11/xinit/xinitrc

   
   
6. Es posible que no encuentre estas dos líneas en xstartup si utiliza SUSE. Detenga e inicie la sesión VNC:

   $ /usr/bin/vncserver -kill :1 $ /usr/bin/vncserver

   
   

   En este ejemplo, la visualización :1 del primer comando debe coincidir con la visualización creada cuando usted inicializó previamente vncserver.

7. Revise el registro VNC para saber el puerto en el que se está ejecutando. Usted deberá ver algo como lo que sigue:

   tail -f /home/idcuser/.vnc/vhost0270:1.log Copyright (C) 2002-2005 RealVNC Ltd. See http://www.realvnc.com for information on VNC. Underlying X server release 70101000, The X.Org Foundation Sun Oct 16 03:54:31 2011 vncext: VNC extension running! vncext: Listening for VNC connections on port 5901 vncext: Listening for HTTP connections on port 5801 vncext: created VNC server for screen 0

   
   

   En este ejemplo usted ve que VNC está escuchando conexiones en el puerto 5901.

Use un cliente SSH para conectarse con la máquina virtual. La siguiente sección describe 2 clientes: OpenSSH y PuTTY.

Utilizando túneles con el comando OpenSSH

Es posible usar OpenSSH en Linux o Windows mediante una línea de comandos Cygwin. Con Cygwin, instale primero el paquete cygwin openssh si su sistema aún no lo tiene.

Inicie un túnel desde su cliente SSH hacia la máquina virtual del puerto 5901:

$ ssh -i ~/.ssh/key_name -L 5901:localhost:5901 idcuser@${SCE_VM}

La opción -i especifica la clave a usar y la opción -L especifica el túnel. El puerto usado (5901) debe coincidir con el puerto usado por el servidor VNC que se ejecuta en la máquina virtual.

Uso de túnel con PuTTY

Para crear un túnel equivalente con PuTTY:

1. Haga clic en Connection > SSH > Tunnels para abrir la ventana de configuración de PuTTY mostrada en la Figura 7.
   
   Figura 7. Configurando un túnel con PuTTY
   
   
   
2. Ingrese el puerto de destino 5901 en el puerto fuente y el puerto de destino de la forma ip:port en el campo Destination.
3. Haga clic en Add.
4. Haga clic en Open.
5. Ingrese idcuser en el protocol de inicio de sesión. El túnel se crea y le inicia sesión dentro de un shell interactivo.
6. Inicie el cliente VNC. Ingrese la dirección localhost:5901 como se muestra en la Figura 8.
   
   Figura 8. Cliente VNC
   
   
   
7. Haga clic en OK. Usted deberá ver el escritorio de Linux.

Volver arriba

Usando redes virtuales privadas

Las Redes Virtuales Privadas (VPNs) se basan en el cifrado para crear una extensión de una red privada sobre Internet. Las VPN permiten diversos escenarios de red que son valiosos para las empresas.

Un uso tradicional de las VPN es conectar redes de área local de diferentes oficinas de una empresa, formando una red de área más amplia. Este tipo de conexiones son de sitio-a-sitio. Cuando las VPN se introdujeron con este propósito, reemplazaron el uso de líneas arrendadas, reduciendo en gran medida los costos para las empresas.

Otro uso tradicional de una VPN es permitir a los empleados acceder a las redes privadas de las empresas de forma remota, por ejemplo, para trabajar desde casa. En este escenario, la empresa proporciona una puerta de enlace de VPN al que se puede acceder desde Internet y el empleado instala un cliente VPN en su portátil para acceder a aplicaciones, como email. A esto se le asignó el término de red virtual privada móvil, porque uno de los puntos finales (donde el empleado está ubicado) no tiene una dirección IP fija.

Cuando un cliente envía un paquete a través de una puerta de enlace de VPN se añade un encabezado de autenticación, los datos son cifrados y los datos se ponen en una Encapsulating Security Payload. El servidor VPN receptor descifra los datos y enruta el paquete hacia destino, según la información del encabezado.

El cifrado proporcionado por los VPN está a un nivel muy bajo, de manera que todas las comunicaciones hacia la empresa son cifradas. Esto puede suceder en la Capa OSI 2 (capa de enlace de datos) o en la Capa 3 (capa de red) y puede incluir cualquiera de estos métodos:

• IPsec
• SSL /TLS
• Datagram Transport Layer Security (Cisco)
• Cifrado Microsoft Point-to-Point
• Uso de túneles SSH

Las VPN pueden usar puentes para crear un área Ethernet LAN virtual ampliada. Esto tiene algunas ventajas frente al uso de enrutamiento, dado que puede funcionar con cualquier protocolo que funcione sobre Ethernet. El uso de puentes es necesario si usted está usando protocolos que no sean IP o intercambio de archivos Windows. No obstante, configurar una VPN con enrutamiento puede ser más fácil y permitir un control más fino sobre el acceso a hosts y puertos específicos.

Muchas empresas pueden querer usar la computación en nube para extender la capacidad de sus infraestructuras de TI. Para soportar este escenario, la VPN es configurada a través de una puerta de enlace en la red corporativa, hacia una VLAN privada en la nube. Esto se conoce como una conexión de sitio-a-sitio. Las máquinas virtuales en la red privada en la nube no son visibles desde Internet, pero solo se puede tener acceso a ellas vía la VPN o mediante otra máquina virtual en la VLAN. Esto se ilustra en la Figura 9.

En este escenario la nube actúa como una extensión de la red corporativa. La extensión de la nube es aislada de Internet y de máquinas virtuales en la nube, por fuera de la VLAN. IBM SmartCloud Enterprise soporta este escenario como un ofrecimiento fundamental. A diferencia del escenario de trabajo desde casa, el empleado no necesita realizar ninguna instalación especial de cliente VPN.

También es posible soportar un escenario de red que utilice la nube para soportar una VPN sin necesidad de que una empresa tenga la propiedad de una puerta de enlace VPN dentro de las instalaciones. Por ejemplo, las imágenes CohesiveFT VPN-Cubed del catálogo IBM SmartCloud Enterprise pueden proporcionar una puerta de enlace VPN. Esto puede apoyar a empleados que trabajen desde casa con un cliente VPN, como el cliente OpenVPN. Ver Figura 10.

OpenVPN es una solución de fuente abierta para cliente y servidor VPN, que puede manejar conexiones de punto-a-punto y de sitio-a-sito. Esta utiliza la biblioteca de cifrado OpenSSL. La imagen para instalación OpenVPN puede descargarse del sitio web de OpenVPN. Esta incluye software tanto de cliente como de servidor y debe instalarse tanto en ambas máquinas, cliente y servidor. Es posible hacer la instalación usando el paquete RPM en máquinas RHEL y usando el comando apt-get en SUSE u otros sistemas basados en Debian. Es posible hacer la instalación en otros sistemas Linux desde el tarball usando make. Existe un instalador que se extrae automáticamente para Windows y también imágenes de instalación solo para el cliente hacia donde es posible dirigir a los usuarios finales.

La solución VPN-Cubed es un paquete de software comercial de Cohesive FT que está disponible en IBM SmartCloud Enterprise. Este puede soportar muchas configuraciones de red que son útiles para crear configuraciones de red virtual más complejas dentro de una nube, y conectar recursos computacionales sobre múltiples nubes con una VPN. VPN-Cubed puede actuar como un enrutador virtual, un puente virtual, un concentrador de VPN y un firewall.

Volver arriba

Configurando OpenVPN

Configurar una VPN con OpenVPN incluye configurar una infraestructura de clave pública, incluyendo un certificado con una clave pública y una clave privada para cada servidor y cliente, y un certificado de autoridad de certificación (CA) para firmar cada uno de estos certificados. De manera predeterminada, la VPN realiza autenticación mutua tanto de servidor como de cliente, usando estos certificados. Sin embargo, es posible configurar métodos de autenticación alternativos. También es posible configurar un servidor Open VPN en una dirección IP dinámica.

Instale y configure el servidor OpenVPN en RHEL5

1. Instale el servidor OpenVPN usando yum:
   1. El paquete OpenVPN para RHEL5 no está en los repositorios estándar. Como raíz, descargue las descripciones para los repositorios Fedora EPEL (Extra Packages for Enterprise Linux) antes de escribir yum install openvpn.

      # rpm -ivh http://download.fedora.redhat.com/pub/epel/5/x86_64/ epel-release-5-4.noarch.rpm

      
      

      Output:

      Retrieving http://download.fedora.redhat.com/pub/epel/5/x86_64/ epel-release-5-4.noarch.rpm warning: /var/tmp/rpm-xfer.wmJlYz: Header V3 DSA signature: NOKEY, key ID 217521 f6 Preparing... ########################################### [100%] 1:epel-release ########################################### [100%] [root@vhost0508 ~]#

      
      
   2. Instale el paquete OpenVPN con el comando # yum install openvpn.

      Output:

      Loaded plugins: security Repository rhel-server is listed more than once in the configuration Setting up Install Process Resolving Dependencies --> Running transaction check ...

      
      

   Usted deberá poder ver en el resultado que los repositorios EPEL proporcionaron el Release Candidate 9 de OpenVPN (Version 2.1) actual (aunque oficialmente todavía inestable) como instalación exitosa. Yum también instala las bibliotecas LZO dependientes.

2. Configure el servidor OpenVPN. Ejecute los siguientes comandos como raíz.

   # mkdir -p /etc/openvpn # cp -R /usr/share/openvpn/easy-rsa/ /etc/openvpn/ # cd /etc/openvpn/easy-rsa/2.0/

   
   

   Aparecerá una lista de scripts que le ayudarán a configurar la VPN. Los scripts principales se resumen como sigue:

   • vars: Crea variables de entorno y establece las variables de script necesarias
   • build-ca: Crea certificado CA (interactivo)
   • build-dh: Crea archivos Diffie-Hellman
   • build-key-server: Crea claves privadas de servidor
   • build-key: Crea claves privadas de cliente
3. Genere un certificado CA/clave maestro(a), un certificado/clave de servidor y certificados/claves para los clientes.
   1. Edite el script vars de acuerdo a su entorno. Este es un ejemplo:

      export KEY_COUNTRY="CN" export KEY_PROVINCE="Shanghai" export KEY_CITY="Shanghai" export KEY_ORG="IBM" export KEY_EMAIL="a.user@example.com"

      
      
   2. Genere un certificado CA:

      # ./clean-all # source ./vars # ./build-ca

      
      

      Output:

      Generating a 1024 bit RSA private key .........................++++++ ...................++++++ writing new private key to 'ca.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [CN]: State or Province Name (full name) [Shanghai]: Locality Name (eg, city) [Shanghai]: Organization Name (eg, company) [IBM]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) [IBM CA]: Name []: Email Address [a.user@example.com]: #

      
      
   3. Genere la clave privada de servidor:

      # ./build-key-server server

      
      

      Output:

      Generating a 1024 bit RSA private key .................................++++++ ....++++++ writing new private key to 'server.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. ... Certificate is to be certified until Sep 23 13:15:05 2021 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

      
      
   4. Genere la clave privada de cliente:

      # ./build-key client1

      
      

      Output:

      Generating a 1024 bit RSA private key ....................++++++ .............++++++ writing new private key to 'client1.key' ----- ... Certificate is to be certified until Sep 23 13:16:57 2021 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

      
      
   5. Genere los parámetros Diffie-Hellman:

      # ./build-dh

      
      

      Output:

      Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time .........+........................................................+.........

      
      
   6. Copie el certificado de servidor en /etc/openvpn:

      # cd keys # cp server.crt server.csr server.key ca.crt ca.key dh1024.pem /etc/openvpn/

      
      
   7. Comprima el certificado del cliente:

      tar zcvf client1.vpn.key.tar ca.crt ca.key client1.crt client1.csr client1.key

      
      
   8. Configure el servidor. Es preferible referir archivos openvpn de configuración de muestra y no crear archivos de configuración openvpn. El siguiente es un ejemplo:

      # cp /usr/share/doc/openvpn-2.1.4/sample-config-files/server.conf /etc/openvpn/ # cd /etc/openvpn/ # vi server.conf

      
      

      Output:

      local 129.35.209.162 # Which local IP address should OpenVPN listen on port 1194 # proto udp dev tun ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh1024.pem server 10.8.0.0 255.255.255.0 client-to-client keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status.log log openvpn.log log-append openvpn.log verb 3 push "dhcp-option DNS 10.8.0.1" push "dhcp-option DNS 170.225.111.10" # see h) to get name server, push "dhcp-option DNS 170.225.111.10" # see h) to get name server push "dhcp-option DNS 170.224.55.203" # see h) to get name server

      
      
   9. Verifique que la resolución de nombre DNS se haya efectuado adecuadamente:

      # vi /etc/resolv.conf

      
      

      Output:

      domain site2.compute.ihost.com nameserver 170.225.111.10 nameserver 170.225.111.11 nameserver 170.224.55.203

      
      
   10. Asegúrese de que el puerto 1194 esté abierto. Compruebe que el firewall permita tráfico en el puerto 1194 o utilice los siguientes comandos para abrirlo:

       /sbin/iptables -A INPUT -i eth0 -p udp --dport 1194 -j ACCEPT /sbin/iptables -A OUTPUT -o eth0 -p udp --dport 1194 -j ACCEPT /sbin/service iptables save /sbin/service iptables restart

       
       
   11. Inicie/detenga/reinicie el servicio openvpn.

       Inicie el servicio openvpn:

       # service openvpn start

       
       

       Output:

       Starting openvpn: [ OK ]

       
       

       Detenga el servicio openvpn:

       # service openvpn stop

       
       

       Output:

       Shutting down openvpn: [ OK ]

       
       

       Reinicie el servicio openvpn:

       # service openvpn restart

       
       

       Output:

       Shutting down openvpn: [ OK ] Starting openvpn: [ OK ]

       
       

En este punto, el servidor OpenVPN ha quedado instalado, configurado y ejecutándose. Ahora es necesario configurar un cliente para que se comunique con él.

Instale y configure el cliente OpenVPN en RHEL5

1. Instale el paquete openvpn. Repita los pasos 1 y 2 de las instrucciones anteriores.
2. Copie client1.key, client1.crt y ca.crt del servidor a la máquina client1:

   #cp /usr/share/doc/openvpn-2.1.4/sample-config-files/client.conf /etc/openvpn

   
   
3. Encuentre sample-config-files/client.conf y edítelo. Edite la directiva "remote" para que apunte al nombre de host/dirección IP y número de puerto del servidor OpenVPN.

   Output:

   remote 129.35.209.162 1194 ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt cert /etc/openvpn/easy-rsa/2.0/keys/client1.crt key /etc/openvpn/easy-rsa/2.0/keys/client1.key

   
   
4. Inicie openvpn desde el directorio fuente:

   ./openvpn sample-config-files/client.conf

   
   

Hacia el final de la inicialización debe aparecer "Initialization Sequence Completed."

Instale y configure la GUI del cliente OpenVPN en Windows

1. Descargue OpenVPN GUI del sitio web OpenVPN . Nota: Las versiones de OpenVPN GUI y del servidor OpenVPN deben ser las mismas.
2. Instale OpenVPN GUI. Siga las instrucciones cuando descargue el archivo.
3. Configure OpenVPN:
   1. Cope los certificados del cliente desde el servidor:

      ca.crt ca.key client1.crt client1.csr client1.key

      
      
   2. Copie sample-config-files/client.conf en el directorio de configuración bajo el directorio de instalación, edítelo y cámbiele el nombre por client.ovpn (C:\Program Files\OpenVPN\config):

      129.35.209.162 1194 ca ca.crt cert client1.crt key client1.key

      
      
4. Reinicie OpenVPN usando la GUI

Volver arriba

Configurando un servidor proxy

Para configurar un servidor proxy en Red Hat:

1. Suministre una instancia Red Hat 5.6 en RTP Data Center. La instancia tiene tanto una IP pública como una privada; de forma predeterminada, la IP privada queda inactiva después del aprovisionamiento.
   
   Figura 11. Configurando un servidor proxy
   
   
   
2. Ejecute el siguiente comando para verificar la información de puerta de enlace actual; la puerta de enlace actual es 170.224.160.1.

   # /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 170.224.160.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 170.224.160.1 0.0.0.0 UG 0 0 0 eth0

   
   
3. Para activar la dirección IP privada:

   # /sbin/ifup eth1

   
   
4. Ejecute el siguiente comando de nuevo para verificar la información de puerta de enlace actual. La puerta de enlace actual es ahora 10.216.1.1.

   # /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.216.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 170.224.160.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 0.0.0.0 10.216.1.1 0.0.0.0 UG 0 0 0 eth1

   
   
5. Verifique de nuevo para ver que la IP privada ahora está "Active".
   
   Figura 12. La IP privada ahora está activa
   
   
   
6. Si usted activa la IP privada, la puerta de enlace predeterminada cambia y ya no podrá acceder a Internet. Para corregir este inconveniente, establezca la puerta de enlace de IP pública como la primera prioridad a ser alcanzada por Internet:

   [root@vhost0513 ~]# /sbin/route del default [root@vhost0513 ~]# /sbin/route add default gw 170.224.160.1 [root@vhost0513 ~]# /sbin/route add default gw 10.216.1.1 metric 1

   
   

Ahora, es posible ejecutar ping para la IP de Internet exitosamente.

Los siguientes pasos le ayudarán a configurar la IP privada como servidor proxy para acceder a instancias dentro de IP privadas dentro de la misma subred.

1. Ejecuteyum para instalar el servidor proxy squid. Para SUSE, ejecute zypper install squid.

   [root@vhost0513 ~]# yum install squid Loaded plugins: security Setting up Install Process Resolving Dependencies ... Complete!

   
   
2. Configure squid en /etc/squid/squid.conf para añadir las líneas en negrita:

   http_access allow localhost acl lan_users src 10.216.1.0/24 http_access allow lan_users http_access deny all

   
   
3. Inicie squid como se muestra:

   # /sbin/service squid start

   
   

   Ahora es posible usar openssh para acceder a otra instancia con una IP privada, desde la instancia previa.

4. El último paso es exportar el proxy como se muestra:

   # export http_proxy=http://10.216.1.144:3128

   
   

Usted ha completado la configuración del proxy.

Volver arriba

En conclusión

En este artículo resumimos la administración de capas de red en diferentes escenarios de nube y le mostramos cómo las herramientas para administración de red en la nube pueden beneficiar diferentes escenarios de negocios. También mostramos en detalle las siguientes herramientas que le serán útiles para administrar la entrega de servicios en nube sobre una red:

• Conectándose a la VM (direcciones IP)
• Administrando redes virtualizadas
• Administrando múltiples direcciones IP individuales
• Utilizando un firewall para proteger múltiples máquinas virtuales
• Autenticando usuarios y servidores vía SSH o PuTTY
  • Transferencia de puertos
  • Creando y usando el túnel SSH
  • Uso de túnel con línea de comandos con OpenSSH
  • Uso de túnel con PuTTY
• Usando redes virtuales privadas
• Configurando OpenVPN
• Configurando un servidor proxy

Recursos

Aprender

• Más recursos sobre los temas mencionados en este artículo:
  • Entregarle al usuario el control de la red en nube
  • Extend your corporate network with the IBM Cloud
  • documentación sobre OpenSSH
  • Tunneling with SSH
  • SSH Port Forwarding
  • documentación sobre OpenVPN
  • Consejo de IBM SmartCloud Enterprise: Abarcar redes de área local virtuales
  • Developing and Hosting Applications on the Cloud by Alex Amies, Harm Sluiman, Qiang Guo Tong, and Guo Ning Liu. Publicado por IBM Press.
  
  
• Para saber más sobre cómo realizar tareas en el IBM Cloud, visite estos recursos:
  • Up and download files from a Windows instance.
  • Install IIS web server on Windows 2008 R2.
  • Create an IBM Cloud instance with the Linux command line.
  • Create an IBM Cloud instance with the Windows command line.
  • Extend your corporate network with the IBM Cloud.
  • High availability apps in the IBM Cloud.
  • Parameterize cloud images for custom instances on the fly.
  • Windows-targeted approaches to IBM Cloud provisioning.
  • Deploy products using rapid deployment service.
  • Integrate your authentication policy using a proxy.
  • Configure the Linux Logical Volume Manager.
  • Deploy a complex topology using a deployment utility tool.
  • Provision and configure an instance that spans a public and private VLAN.
  • Secure IBM Cloud access for Android devices.
  • Recover data in IBM SmartCloud Enterprise.
  • Secure virtual machine instances in the cloud.
  
  
• En los recursos para desarrollador de nube de developerWorks, descubra y comparta conocimiento y experiencia de desarrolladores de aplicaciones y servicios que están creando sus proyectos para implementación en la nube.
  
  
• Conozca cómoaccesar a IBM SmartCloud Enterprise.
  
  

Obtener los productos y tecnologías

• Consulte las imágenes de producto disponibles para IBM SmartCloud Enterprise.
  
  

Comentar

• Únase al grupo de computación en nube de developerWorks.
  
  
• Lea todos los excelentes blogs sobre la nube en developerWorks.
  
  
• Únase al comunidad developerWorks, una red profesional y un conjunto unificado de herramientas comunitarias para conectarse, compartir y colaborar.
  
  

Sobre los autores

Alex Amies es ingeniero sénior de software en el Laboratorio de desarrollo de China de IBM GTS Development Lab.Actualmente es un arquitecto que participa en el desarrollo de IBM SmartCloud Enterprise.Anteriormente se desempeñó como arquitecto y desarrollador de seguridad y productos en nube junto a otros grupos de IBM.

Chun Feng Wu es Consultor y Arquitecto de Soluciones Certificadas IBM para la computación en nube. Trabajó en la nube pública IBM, en SmartCloud Enterprise y ahora trabaja para la nube administrada IBM, SmartCloud Enterprise Plus.

Guang Cai Wang es Advisory Software Engineer en IBM y trabaja como uno de los desarrolladores líderes del equipo IBM SmartCloud Enterprise.

Mihai Criveti es Arquitecto de TI; se concentra principalmente en la computación en nube y la virtualización. Dentro de sus intereses están la computación en nube, la virtualización, la arquitectura corporativa, la SOA, el middleware, lo forense-digital y los sistemas UNIX.

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Cómo las herramientas de red son facilitadoras en diversos escenarios
• Herramientas y las tareas que cumplen
• Conectándose a la VM vía direcciones IP
• Administrando redes virtualizadas
• Trabajando con múltiples direcciones IP
• Utilizando un firewall para proteger múltiples máquinas virtuales
• Autenticando servidores y usuarios con SSH o PuTTY
• Usando redes virtuales privadas
• Configurando OpenVPN
• Configurando un servidor proxy
• En conclusión
• Recursos
• Sobre los autores
• Comentarios