Curso de OpenVPN en Bizkaia Enpresa Digitala

Estas en: Solid Rock IT >> Inicio >> Blog >> Curso de OpenVPN en Bizkaia Enpresa Digitala

Curso de OpenVPN en Bizkaia Enpresa Digitala

Escrito por Inigo Kintana el miércoles 3 octubre 2007 a las 09:05 :: Link permanente :: rss

El próximo 16 de octubre de 2007 Solid Rock IT impartirá un curso sobre OpenVPN en las instalaciones de Bizkaia Enpresa Digitala.

"OpenVPN"
Este curso fue anteriormente impartido en Miramón Enpresa Digitala con satisfactorios resultados.

Comentarios

1. Escrito por Ángel Lafuente Echeazarra el miércoles 31 octubre 2007 a las 17:09

El curso logró los objetivos fijados en el programa.

El organizador, Bizkaia Enpresa Digitala, nos ha proporcionado el resumen de las encuestas de satisfacción de los asistentes. Los resultados son, como en la anterior vez que impartimos el curso, muy buenos.

Gracias a todos.

2. Escrito por Ángel Lafuente Echeazarra el miércoles 31 octubre 2007 a las 17:42

Durante el curso se plantearon algunas dudas a las que, dado lo intenso del programa, no di una respuesta totalmente satisfactoria.

Pasados unos días, les hice llegar a los alumnos un e-mail con esas dudas tratadas con mayor profundidad.

RESPUESTAS A CUESTIONES PLANTEADAS EN EL CURSO

1- INTEGRACIÓN CON PKI

La integración con una PKI externa es posible. La principal diferencia con el procedimiento que seguimos ayer está en que es la CA externa la que firma los certificados.

Si os fijáis en la tabla de la página 29 del manual, el archivo ca.key sólo tiene que estar en el sistema que firma los certificados.

Por lo tanto puedo usar una PKI externa que me firme los certificados que genero para OpenVPN. El procedimiento sería el siguiente:

- Me descargo el certificado raíz de la CA.

- Genero certificados pendientes de validación del servidor de OpenVPN y de los clientes. En este momento también se crearán las claves correspondientes a dichos certificados.

- Mandamos los certificados a la CA para que los valide y los firme.

Con el certificado de la CA, los certificados del servidor, los de los cliente y los correspondientes ficheros de claves, puedo configurar OpenVPN.

La PKI puede estar implementada dentro de la organización o ser un servicio externo, que cobra por cada certificado firmado.

Una alternativa gratuita es:

http://www.cacert.org

Para ciertos entornos puede ser perfectamente válida.

De hecho, en su documentación:

http://wiki.cacert.org/wiki/openVPN

2- Protocolo UDP

Atención a lo que indica el manual de Openvpn:

--proto p
    Use protocol p for communicating with remote host. p can be udp, tcp-client, or tcp-server.

    The default protocol is udp when --proto is not specified.

    For UDP operation, --proto udp should be specified on both peers.

    For TCP operation, one peer must use --proto tcp-server and the other must use --proto tcp-client. A peer started with
tcp-server will wait indefinitely for an incoming connection. A peer started with tcp-client will attempt to connect, and if
that fails, will sleep for 5 seconds (adjustable via the --connect-retry option) and try again. Both TCP client and server
will simulate a SIGUSR1 restart signal if either side resets the connection.

    OpenVPN is designed to operate optimally over UDP, but TCP capability is provided for situations where UDP cannot be
used. In comparison with UDP, TCP will usually be somewhat less efficient and less robust when used over unreliable or
congested networks.

    This article outlines some of problems with tunneling IP over TCP:

    http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

    There are certain cases, however, where using TCP may be advantageous from a security and robustness perspective, such as
tunneling non-IP or application-level UDP protocols, or tunneling protocols which don't possess a built-in reliability layer.

Nunca me había planteado que por ser UDP un protocolo no orientado a la conexión, se pudiese perder información. No sé que porcentaje de paquetes UDP se perderán. Supongo que no me lo había planteado porque OpenVPN da sensación de robustez cuando lo usas (si el acceso a Internet es decente).

También hay que tener en cuenta que el protocolo UDP es más rápido en su procesamiento ya que se evita el control de paquete a nivel de transporte.

En cuanto a la idea de "esnifar" el tráfico de OpenVPN en una conexión entre cliente y servidor, no serviría de mucho, ya que el paquete TCP/IP encapsulado va cifrado. Es el tráfico TCP encapsulado (y otros protocolos por encima de él) el que se encarga de asegurar la fiabilidad de la conexión.

He revisado "Computer Networks, third edition", de Andrew Tanenbaum, y acerca de UDP reproduzco lo siguiente:

"UDP provides a way for applications to send encapsulated raw IP datagrams and send them without to establish a connection.
Many client-server applications that have one request and one response use USP rather go to the trouble of establishing and
later releasing a connection."

Relacionado con anterior, está la opción "tcp-queue-limit".

3- Problemas de rendimiento

Ante un problema de rendimiento de OpenVPN y antes de empezar a configurar OpenVPN con parámetros avanzados, conviene plantearse si el problema es de OpenVPN.

El problema suele ser planteado por el usuario de la VPN del siguiente modo: el acceso remoto va lento.

Como en cualquier conexión, tenemos:

- Origen: programa o aplicación que se desea usar remotamente.
- Cliente OpenVPN.
- Internet.
- Servidor OpenVPN
- Destino: servicio al se desea acceder.

Antes de cambiar los parámetros de nuestra VPN hay que estar COMPLETAMENTE SEGURO de que la contención sólo es achacable a OpenVPN.

Muchas veces, los problemas vienen dados por un diseño incorrecto de la arquitectura del servicio que se pretende dar a
través de la OpenVPN. En el ejemplo que me planteasteis ayer, en el que se trabajaba abriendo ficheros en un servidor SAMBA remoto a través de OpenVPN, el problema no creo que esté en la VPN. Habría que utilizar la VPN de otro modo: habilitando conexiones a un Terminal Server en el que se ejecuten las aplicaciones, o configurando algún método de sincronización de ficheros, o simplemente enseñando a los usuarios que para trabajar con esos ficheros deben bajárselos al portátil, modificarlos y luego subirlos al servidor.

La cuestión es tratar de localizar el cuello de botella. Por ejemplo, si el servidor de OpenvPN también proporciona otros
servicios, estos pueden afectar al rendimiento de OpenVPN y el problema no está en OpenVPN. Esto también suele pasar con usuarios que tienen un PC excesivamente saturado y dejan escasos recursos de CPU al cliente de OpenvPN.

Hoy en día, el problema con las líneas de ADSL viene dado por la A de "asymmetric". El ancho de bando de subida es crítico y hay que conocer las limitaciones de trabajar con los aproximadamente 200 kbps de una línea estándar por la que también circulan los e-mails enviados.

Si la VPN es un recurso crítico para la empresa, habría que plantearse agregar líneas de ADSL o contratar una línea DSL
simétrica con ancho de banda garantizado (a partir de 200 € /mes).

Otro aspecto a tener en cuenta es cuántos usuarios concurrentes utilizan la VPN.

A nivel de OpenVPN se pueden cambiar estos parámetros para ver SI ES POSIBLE MEJORAR EL RENDIMIENTO:

- Si estamos muy seguros de que nos va a beneficiar, cambiar el MTU de los paquetes. ALTAMENTE DESACONSEJADO, incluso en el
manual.

"--link-mtu n
    Sets an upper bound on the size of UDP packets which are sent between OpenVPN peers. It's best not to set this parameter
unless you know what you're doing."

- Cambiar el tamaño de los "buffers" con "sndbuf" y "rcvbuf". De todos modos, habría que ver qué relación hay entre el tamaño
del "buffer" y rendimiento, que no es necesariamente lineal. En cualquier software, un "buffer" muy grande puede penalizar el
rendimiento.

- Activar la opción "fast-io". EXPERIMENTAL. SÓLO EN LINUX.

Nunca he utilizado estos parámetros en producción.

4- PRÁCTICA Y ENRUTAMIENTO HACIA LA RED INTERNA

La práctica con VMware trataba de emular el escenario que planteábamos al principio para una PYME. Se trataba de reflejar la realidad en el aula con VMware. Para conseguir recrear un escenario en el que el tráfico de la VPN sea enrutado a la red ¡local, habría que crear otra VM que contuviese los servicios de XAMPP y SAMBA. Tanto la máquina virtual de OpenVPN como la de XAMPP/SAMBA irían conectadas a la red NAT de VMware, que permite hacer PAT de puertos.

Si no planteo la práctica así, es porque el PAT no funciona bien en el VMware (al menos en los productos de generación 5) y nunca sé qué clase de VMware me voy a encontrar en el aula (Workstation, server o player).

5- OTROS

Para ajustar mejor los parámetros de los certificados generados con los "scripts" del directorio "easy-rsa", echad un vistazo
al fichero "openssl.cnf" que hay en dicho directorio.

Este artículo explica cómo utilizar de OpenSSL directamente para generar los certificados para OpenVPN:

http://www.oreillynet.com/pub/a/security/2004/10/21/vpns_and_pki.html?page=1

Y para organizaciones grandes, cómo organizar la alta disponibilidad y la distribución de carga:

http://www.imped.net/oss/misc/openvpn-2.0-howto-edit.html#loadbalance

Nadie me preguntó en qué zona de su red hay que ubicar el servidor de OpenVPN. El servidor de OpenVPN hay que colocarlo en una DMZ o en una pseudo-dmz.

3. Escrito por Ángel Lafuente Echeazarra el viernes 4 enero 2008 a las 13:44

El mismo curso también se impartió en Araba Enpresa Digitala el 20 de noviembre de 2007 con una aceptación muy similar a las ocasiones anteriores.

Las valoraciones medias de los asistentes fueron las siguientes:

Valoración del curso: 8.09

Actuación del formador: 8.09

Documentación recibida: 8.27

Expectativas satisfechas: 8.09

CALIDAD GLOBAL: 7.91

Creemos que la principal causa del éxito del curso en todas sus ediciones ha sido el esfuerzo de síntesis realizado para que puede impartirse en una única jornada.

Añadir un comentario

Trackbacks

No hay trackback.

Para hacer un trackback a este post: http://www.solid-rock-it.com/web-solid-rock/blog/tb.php?id=31