OpenVPN y tablas de enrutamiento

Hoy configuré mi máquina con un servidor OpenVPN y otra máquina a la que tengo acceso con un cliente. Pero no se hablaban.

El servidor me decía que

Dec  5 19:51:29 host ovpn-server[16743]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

Pero la cosa es que no tenía ningún problema de NAT: los paquetes llegaban:

Dec  5 19:51:29 host ovpn-server[16743]: xx.xx.xx.xx:22122 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:22122, sid=12345678 90abcdef

Por otro lado el cliente era un poco más explícito:

Dec  5 21:33:47 client ovpn-client[5128]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Dec  5 21:33:47 client ovpn-client[5128]: Re-using SSL/TLS context
Dec  5 21:33:47 client ovpn-client[5128]: UDPv4 link local: [undef]
Dec  5 21:33:47 client ovpn-client[5128]: UDPv4 link remote: [AF_INET]yy.yy.yy.yy:1194
Dec  5 21:34:47 client ovpn-client[5128]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  5 21:34:47 client ovpn-client[5128]: TLS Error: TLS handshake failed
Dec  5 21:34:47 client ovpn-client[5128]: SIGUSR1[soft,tls-error] received, process restarting

Un caso difícil. Tuve que ponerme a hacer otras cosas durante un rato para entender el problema: El paquete inicial llega, pero la negociación TLS falla. Y no podía deberse a que los certificados estuvieran mal: acababa de revisarlos.

Luego recordé que mi sistema tiene dos direcciones IP distintas, ya que tengo dos conexiones a Internet en casa. De repente estuve seguro de que el problema estaba ahí.

Me senté y desactivé la tarjeta de red a la que llega la IP dinámica. Todo empezó a funcionar. Pero no detectaba la causa del problema. Súbitamente caí en la cuenta: OpenVPN utiliza UDP, y UDP es un protocolo sin estado. Es decir: OpenVPN no envía un paquete de respuesta al saludo TLS, como haría a través de TCP, sino que envía un paquete independiente conteniendo la respuesta al saludo TLS. Y esta diferencia es crucial.

Los paquetes de respuesta a las solicitudes normales a mi máquina salen siempre por la tarjeta de red a la que llega la IP estática, gracias a unas reglas de enrutamiento:

ip route add table 1 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.25 
ip route add table 1 default via 192.168.1.1 dev eth1
ip rule add from 192.168.1.25 lookup 1

Pero esas reglas no se aplicaban a los paquetes salientes de OpenVPN porque no son paquetes de respuesta: en UDP no existen los paquetes de respuesta.

Rápidamente la documentación oficial de OpenVPN me dio la solución:

#Dirección y máscara de red que utilizaremos
server 10.9.0.0 255.255.255.0
local 192.168.1.25

La orden local le dice al servidor OpenVPN que utilice la IP especificada.

Y listo. Todo funcionando. Ya tengo un túnel permanente para entrar a la máquina remota con IP dinámica.

Actualizaciones

Hacía tiempo que no actualizaba mi ordenador de casa. Ese en el que corro un servidor web, otro DNS, otro de correo entrante, saliente y buzones... y ya no recordaba por qué.

Estaba seguro de que la base era no actualizar KDE. No uso KDE, pero sí me gustan (o no puedo prescindir de) sus aplicaciones, como Kmail (tengo muchas reglas y accedo a buzones Maildir, aparte de una cuenta IMAP y uso de GPG). No me gusta, prefería el Kmail de KDE 3.5, pero sigue funcionando para mí.

Más o menos, quiero decir. Cada actualización anterior fue una dolorosa experiencia entre cosas que no funcionaban y capacidades desaparecidas.

No era consciente de que actualizarme implicaba meter mi mundo en las fauces de Akonadi.

Pero sin embargo, no era esa la causa de no actualizar hace mucho, sino Gnome. No quería pasar de mi útil (que no querido) Gnome 2 al nuevo Gnome 3.

Pero empecé a actualizar, y me vi forzado a actualizar todo el KDE y todo el Gnome. Y ahora tengo un sistema Akojo... perdón, Akonadizado en un Gnome Shell que consume medio Giga (residente) de memoria (que en virtual es más, Giga y medio).

En fin... bonito, al menos, sí es.

Velocidades casi decentes

ONO recientemente ofertaba doblar la velocidad por el mismo precio, por lo visto debido a que han puesto algo de fibra óptica en algún sitio.

El viernes vino un instalador de ONO a casa, mediante una cita concertada anteriormente, a ponérmelo. El nuevo cable-módem es más grande que el anterior, y trae cuatro conexiones LAN y una inalámbrica.

Las pruebas de velocidad me han dado 30 megas redondos de bajada (30Mbps, equivalentes a 3,75MiB/s) y, oh sorpresa, 1 mega redondo de subida (1Mbps, equivalente a unos 122KiB/s). Una bajada en línea con lo que "se lleva" en el primer mundo y una subida casi decente.

Y sin subirme el precio (y aún estoy con la promoción del primer año).

Buenos y malos

Hasta ayer Internet se dividía en dos grupos: con ánimo de lucro (como Twitter) o sin (como identi.ca). La división no es clara, porque servicios como Twitter o Google no cobran a sus usuarios, pero son empresas con ánimo de lucro. Facebook, evidentemente, entre los primeros. Wikipedia entre los segundos. eBay entre los primeros, OpenStreetMap entre los segundos.

Básicamente era una división entre los "puntocom" y los "puntoorg".

Ya no. A partir de hoy Internet se divide entre buenos y malos: los que luchan, como pueden dentro de sus estrategias empresariales o de proyecto, contra SOPA y PIPA (como Google) y los que las apoyan (como Facebook).

Y digo hoy porque hoy los primeros han tenido la decencia de cerrar, en todo o en parte, sus páginas web en protesta.

Quiero que mis servicios me los den los buenos, y sólo en segundo lugar elegiré entre los sin ánimo de lucro.