Atención al cliente

El soporte ofrecido y la atención al cliente son dos de los valores más grandes de una empresa; más todavía hoy en día con las posibilidades infinitas que brindan las nuevas tecnologías y los nuevos servicios. Os cuento esto porque me ha sorprendido mucho el buen uso de Twitter que hace una gran empresa de hosting como Liquid Web. Enchufa2 se encuentra en sus servidores, allá al otro lado del charco, y sin embargo no soy su cliente. En realidad, Liquid Web es el proveedor de la empresa de hosting a la que he contratado los servicios: Minerva Hosting —de la cual, tras casi 3 años, no tengo más que palabras positivas, por cierto—.

El caso es que ayer llegué a casa de la universidad y Enchufa2 no cargaba. El dominio se resolvía sin problemas, pero no había respuesta a las peticiones a su IP. Supuse que habría sufrido una caída y así lo manifesté en Twitter a las 20:33 h:

Liquid Web está caído. Y por consiguiente, Enchufa2 también… :-(

Poco más tarde, desapareció el problema y Enchufa2 volvía a ser accesible. Efectivamente, esta misma mañana recibía un email de Minerva Hosting que me informaba de que había existido esa incidencia el día anterior y que no era culpa de los servidores, sino de una red intermedia entre la península y el emplazamiento de los mismos en Estados Unidos. Otra muestra más del soporte impecable que me ha brindado siempre esta empresa.

Pero es que 10 horas antes del email de mi proveedor de hosting, recibía dos mensajes de Liquid Web a través de Twitter:

@Enchufa2 I am sorry you were seeing problems earlier. It should be fixed now. The problem was with an internet service provider in Spain and Portugal. Novis was able to get it repaired, though. Let me know if I can help with anything. ^bc

Es decir: se molestan en buscar los mensajes que hablan de Liquid Web (fijaos en que no pongo la @ en mi mensaje y no aparece como una mención), encontraron el mío y se disculparon ofreciéndome una explicación; y ni siquiera soy su cliente. Me quito el sombrero.

Cómo conectarnos con seguridad a una red WiFi abierta

En ocasiones, podemos querer conectarnos a una red WiFi abierta; existen dos escenarios, a saber: (1) estamos en la universidad/cafetería/… de turno o (2) somos muy majos y queremos dejar nuestra red abierta para el disfrute de los demás. Obviamente, hacerlo sin seguridad es un suicidio porque cualquiera puede estar monitorizando nuestro tráfico y, quién sabe, intentando robar contraseñas, etc. Por ello, a continuación voy a pasar a explicar cómo añadir nosotros mismos una capa de seguridad para utilizar redes WiFi abiertas con tranquilidad (aunque este método tampoco es 100 % seguro, digamos que sí en un 99 %, a no ser que nos encontremos en una DEFCON o similar…).

Ambos escenarios descritos requieren un servidor SSH que puede estar disponible en nuestro router WiFi, o bien podemos poner nosotros mismos una máquina vieja con Linux en nuestra red (existen excelentes tutoriales para todo tipo de servidores). En el escenario (2) no se necesita nada más porque el servidor se encontrará en la misma red desde la que nos conectamos (la de casa). En el (1) accederemos a ese servidor a través de Internet, así que se hace difícil de localizar debido a que los ISP proporcionan direcciones IP dinámicas; luego necesitaremos un servicio como DynDNS (que puede configurarse en la mayoría de los routers, por no decir en todos) para disponer de un nombre de host fijo con el que «llamar a casa».

El método que utilizaremos se denomina Dynamic Port Forwarding y nos sirve para enviar todas nuestras conexiones a través de un túnel SSH cifrado que actúa como proxy SOCKS local. Esto, que probablemente sonará a chino, es algo así:

Las conexiones que antes se realizaban en claro y que podían ser interceptadas durante su periplo aéreo, ahora viajan a través de un túnel cifrado hasta un servidor SSH desde el que se redirigen a su destino final. Este esquema es para el escenario (1); en el escenario (2), el router y el servidor SSH son el mismo equipo. Ahora bien, ¿qué aplicaciones y configuraciones necesitamos?

En Windows

Existen aplicaciones que ya implementan la posibilidad de utilizar un proxy SOCKS, como Firefox o Skype. Otras en cambio no: Tweetdeck, etc. En cualquier caso, aunque todas las aplicaciones lo soportasen, habría que ir una por una configurándolas a tal efecto. En su lugar, vamos a ver cómo utilizar una herramienta llamada proxyficador que se encarga de monitorizar las actividades de red de todos los programas y redirigir ese tráfico a un servidor proxy. En concreto, el software necesario es el siguiente:

  • PuTTY: necesario para abrir el túnel SSH.
  • Proxyfier: la misma palabra lo dice. No es freeware, pero no he encontrado nada mejor. En otros programas, como FreeCap, es necesario hacer un perfil para cada aplicación. Proxyfier, en cambio, redirige automáticamente todo el tráfico de cualquier aplicación si así se lo indicamos.

El primer paso consiste en abrir la conexión SSH indicando que se desea reenviar a través de dicha conexión todo el tráfico destinado a un puerto (para nuestros ejemplos utilizaremos el puerto 8080). Para ello, abrimos PuTTY y ponemos la ruta al servidor SSH en el campo Host Name (ejemplos: servidorssh.dyndns-home.com desde fuera de la red, 192.168.1.1 desde dentro de la red).

A continuación, en la columna de la izquierda desplegamos Connection > SSH y pinchamos en Tunnels. Una vez allí, (1) indicamos el puerto, (2) marcamos la opción Dynamic, (3) añadimos la opción y (4) abrimos la conexión. Se nos pedirá que aceptemos el certificado (¡hay que revisar bien que es el auténtico!) junto con el nombre de usuario y la contraseña (previamente configuradas en el servidor SSH).

El siguiente paso es instalar y configurar Proxyfier. En primer lugar configuramos las reglas de proxyficación.

En el cuadro de diálogo que se abre, marcamos Process All except the following + manually proxyfied, lo que significa que proxyficará todo el tráfico salvo la lista de exclusiones siguiente. Aquí tenemos que añadir, aparte del loopback que ya viene por defecto, la propia aplicación PuTTY para no crear un bucle sin sentido, así que presionamos Add.

En el siguiente diálogo, (1) ponemos un nombre representativo, (2) añadimos el ejecutable de PuTTY y (3) presionamos OK.

Ahora le toca el turno a las opciones del proxy.

Para añadir el proxy que vemos en la siguiente imagen, presionamos Add.

En el diálogo emergente, (1) indicamos la dirección local como dirección del proxy, (2) el puerto, (3) el protocolo y (4) OK.

Para lograr mayor privacidad, si queremos que las peticiones DNS también viajen por el túnel y que nadie sea capaz de ver qué sitios visitamos, acudiremos a la pestaña de resolución de nombres.

Allí tenemos que marcar la opción Remotely para lograr lo descrito antes.

¡Y listo! Al cerrar el programa se minimiza a la barra de tareas y hace su trabajo en silencio. Ya podemos navegar tranquilamente.

En Linux

Para establecer la conexión SSH, basta con abrir una terminal y escribir el siguiente comando:

[code light=»true»]ssh -D 8080 <nombre_de_usuario>@<servidor_SSH>[/code]

No he encontrado ningún programa de Linux que redirija el tráfico de cualquier programa automáticamente hacia el proxy SOCKS. Lo más parecido a Proxyfier es el proyecto Kernel Socks Bouncer, pero es un módulo del kernel y no lo he probado. Sin embargo, tenemos otras soluciones menos versátiles pero fáciles de utilizar como ProxyChains y tsocks. Para utilizarlos, hay que editar el archivo de configuración correspondiente (/etc/proxychains.conf y /etc/tsocks.conf respectivamente) e incluir el servidor (127.0.0.1) y el puerto (8080). Después, para que una aplicación utilice el túnel cifrado basta con llamarla por línea de comandos de la siguiente manera:

[code light=»true»]tsocks <aplicación> [argumentos][/code]