Mi primera experiencia arreglando una red de ordenadores como freelance con 21 o 22 años

Durante mis años mozos, cuando aún comenzaba a trabar en el mundo de la informática y hacía un poco de todo, me pasó una historia que marcaría el futuro de mi trabajo en el mundo de la consultoría Troubleshooting. Ese tipo de trabajos en los que te llaman porque hay un problema que no han sabido solucionar y te toca descifrar a ti. 

Figura 1: Mi primera experiencia arreglando una red
de ordenadores como freelance con 21 o 22 años

Tengo muchas historias curiosas de mis consultorías tecnológicas, y reconozco que son súper interesantes, porque aprendes mucho, y descubres cómo cuantos más conocimientos tengas de todo, más fácil, y más rápido se encuentra el problema. Al final, es como resolver un puzzle y es divertido. 

Los que han trabajado en soporte resolviendo casos saben bien a lo que me refiero, porque es como descifrar un misterio en cada uno de los expedientes que además aportan dos cosas a tu vida. La primera es que te dejan la satisfacción de resolver un misterio y la segunda es que siempre te enseñan algo. Se nota mucho las personas que han tenido que hacer este tipo de trabajo y la que siempre ha estado en el lado del Power Point o el púlpito de los blogs y las RRSS. 

El caso que os voy a contar no es extremadamente complejo para nada, pero sí que es significativo por lo joven que era yo, lo que aprendí de aquella noche, y lo que le enseñó al dueño de la empresa que me llamó sobre lo que es la tecnología. Desde entonces, cuando he ido a resolver un problema gordo – y he tenido algunos muy jodidos con servidores de correo electrónicos de Exchange que no echaban e-mails a los buzones o una infraestructura de VPNs con servidores CISCO en cluster que daban conectividad a un FireWall-ONE que había que migrar y que dejaron de levantarse paralizando una multinacional -, siempre he aplicado lo que aprendí esa noche. 

Después de esta larga introducción – recuerda que estás leyendo un blog y la lírica, la estética y la narrativa son importantes – os pongo en situación. Yo tendría 21 o 22 años, y comenzaba a trabajar haciendo pequeñas cosas con los ordenadores. Sería el año 1996-1997, y me llamaron para ir un domingo a las 22:00 de la noche a una dirección de una empresa en la ciudad de Fuenlabrada, porque tenían un problema con la red. 

En aquellos momentos las redes de las PyMes podían ser redes en MS/DOS con servidores Novell Netware, redes con Windows NT 3.51 o 4 y puestos de trabajo de todo tipo de Windows, o incluso redes de trabajo en grupo con Windows 3.11 o 95. Y los cableados podían ser coaxial o RJ45 con algún HUB o Switch. Y luego algún router de conexión a Internet, o un modem con la conexión compartida por medio de algún Proxy (Web y Socks), y luego un poco NetBEUI con su sistema de nombres NetBIOS, TCP/IP o IPX. Y todo lo que yo tenía es… .que la red no funcionaba. 

Cuando iba hacia el sitio me sentía como yendo al matadero. No os tengo que explicar que no llevaba mucho tiempo trabajando, así que no tenía mucha experiencia. Estaba seguro que aquel error, fuera el que fuera, iba a encontrármelo por primera vez en mi vida. Seguro. Así que iba con más miedo que vergüenza. 

Cuando llegué allí me esperaba en una especie de casa-chalet reconvertida a oficina el dueño de la empresa muy nervioso. Estaba atacado, porque según él tenía que trabajar el lunes y la red no funcionaba, y los equipos no podían acceder al servidor Novell Netware (horror), para ver los documentos, así que yo era su última esperanza. 

Acojonado estaba. 

Me dijo que los técnicos habían montado la red, habían dejado todo funcionando, que apagaron los ordenadores, y que cuando los encendieron nada estaba bien y no se podía acceder a ningún documento. Y me dejó la red a mí para que la arreglara: “¿Por dónde quieres empezar?” 

Ni puta idea de qué coño podía haber pasado. ¿Tenía que repasar todo paso por paso? Pues sí. Con la información que tenía no había mucho más, y aquello prometía ser una noche larga para aprender a configurar un servidor Novell Netware en detalle. Así que me dieron ganas de empezar a llorar y salir de allí corriendo… pero… ¿Y si no era tan complicado? 

Según el dueño de la empresa lo habían dejado todo funcionando, así que era alguna cosa que había desconfigurado la red. Solo había que averigüar qué. Además, hacía no mucho tiempo el tener paciencia y aprender cómo funcionaban las cosas logró que me dieran el voluntariado en mi instituto por arreglar el sistema de notas y conseguir que las actas se entregaran a tiempo con solo seguir los pasos de un .BAT. Había que intentarlo. 

Encendió el servidor de Novell Netware… y todo arrancó bien. Encendió uno de los equipos, abrió el Word Perfect para abrir uno de los documentos y… el documento no estaba disponible. ¿Qué podría estar pasando? ¿Sería un problema de seguridad con permisos sobre los documentos? ¿Sería un problema de red? ¿Y si es de red sería de configuración o de conexión? 

Como os podéis imaginar, mi primera reacción fue toquetear todos los protocolos de red para ver cuáles eran los que se estaban utilizando en esa red y cómo estaban configurados. En esos entornos se daban casos muy divertidos donde se conectaba a Novell Netware por IPX, pero entre los equipos de la misma red se utilizaba NetBEUI, pero si salían a Internet por un Proxy se hacía por TCP/IP. 

Así que entré a ver la configuración de la pila de protocolos en el cliente para tomar datos de cómo estaba montado, pero no toqué nada. Esto es algo que aprendí ese día porque si lo hubiera hecho la abría liado gorda, y que desde entonces he aplicado. Como los médicos, se opera solo cuando se sabe qué hay que operar, mientras tanto solo se hacen pruebas y se toman datos del paciente. 

Figura 2: Libro de Ataques en redes de datos IPv4 & IPv6 3ª Edición

Yo sabía entonces de redes bastante, pero aún estaba lejos de saber que un día iba a acabar escribiendo el libro de Ataques en redes de datos IPv4&IPv6 con todos los ataques de IPv6, y los ataques con servidores Proxy, etcétera. Aún me quedaba para empezar a tomarme en serio la Seguridad Informática y el Hacking,  pero me había puesto mucho las pilas después de la entrevista de trabajo que me habían hecho un tiempo atrás en la que fui incapaz de contestar una respuesta coherente de redes.

Los protocolos parecían bien, pero no había red, así que el problema debía ser físico. Por supuesto, mis conocimientos de redes me decían que estaban las cosas bien configuradas, y entendía para que se usaba el protocolo IPX, para qué TCP/IP, por qué había un Proxy configurado en TCP/IP y por qué había un protocolo llamado NetBEUI hay funcionando en el stack, así que decidí buscar el error en otro sitio. Me fui al equipo que hacía de servidor Proxy para conectarse a Internet y navegué a una página desde él, el modem y la conexión a Internet funcionaba. Así que ahora podía probar los mensajes de error de TCP/IP conectándome al Proxy desde el equipo con Word Perfect. El error era “Network Error”.

Al final, el cliente con Word Perfect se quería conectar al servidor de ficheros Novell Netware y lo haría por IPX, pero quería saber si el medio físico estaba funcionando, y para eso el mejor protocolo era TCP/IP que los mensajes de error de NetBEUI, si has trabajado con él, eran confusos.

Pues nada, a ver qué cable tenía mala conexión en la red, que estaba en BUS con cable coaxial. No había HUB, RJ-45 o Swich. Un BUS en coaxial como medio físico. Pues nada a revisar cables, T’s y ver cuál estaba mal. De nuevo, organicé unas pruebas muy sencillas.

Saqué un tapón terminador de mi mochila - por supuesto, siempre llevaba varios porque daba clases en aulas en red y eran propensos a "desaparecer" - y acorté la red al servidor Proxy y al siguiente equipo del BUS. Para ello solo había que sacar el cable que llevaba al equipo 3 y puse el tapón. Reinicié el equipo, y mágicamente navegó por Internet.

Ale, resuelto el misterio. Ahora… ¿cuál era el cable, la tarjeta o la T que fallaba? Podría haber tardado una horita o dos buscando el punto de ruptura, pero en ese momento el empresario me dio una pista al preguntarme:

- “¿Para qué es ese tapón?”

Hoy en día, cualquier pregunta así hecha en un entorno de troubleshooting es una pista que no debes dejar escapar.

- “Pues es donde rebota la señal y es necesario que haya uno al final de cada extremo. ¿Me enseñas donde está el otro extremo de la red?”

Tras hablar un poco, y entender lo que yo quería, me llevó al último equipo y allí estaba el misterio. Había un cable que no tenía T y que se conectaba directamente a la salida coaxial de la tarjeta de red. Lo miré, y le dije:

- “Si esto ha estado así es imposible que esta red haya funcionado cuando se fueron los técnicos”.

Entonces el hombre dudó, sudó un poco, y me dijo:

- “Es que este equipo estaba en otro sitio y tuvimos que hacer un cable más largo, y llamé a un vecino que era electricista y me hizo este cable que es más largo y lo conecté yo. Pensé que la T era como un ladrón de enchufes, y pensé que, como no iba a enchufar más equipos… pues mejor que sin T”.

Lo miré y le dije:

- “… y tapón. La T es solo importante porque hay que poner el tapón.”

Resolví el misterio. El hombre se pudo muy contento y me pago – poquísimo, porque me pagó solo por el tiempo -, pero aprendí mucho. Primero cogí confianza en lo que sabía. Me di cuenta de que las cosas que había aprendido se podían aplicar. Saber configurar los drivers en un sistema operativo, conocer los protocolos de red, el hardware y el software, te eran útiles en esos momentos.

También aprendí que no debía tocar nada hasta tener toda la información, y que en este caso, el hombre del problema no estaba dando todos los datos porque él no los consideraba importantes. Pero el único que en ese momento tenía criterio para saber si eran útiles o no era yo. A pesar de ser un joven veinteañero.

Desde entonces aprendí que en un proceso de troubleshooting necesitas muchos datos antes de tocar nada, así que aprendí a preguntar mucho, anotar la pregunta y las respuestas, y probar una a una todas las hipótesis para descartar cosas, una a una. Encontrar el tornillo que hay que apretar exige haber hecho mucho trabajo antes.

Figura 3: El libro de "Wardog y el mundo", nuestro querido BOFH
(Bastard Operator From Hell) escrito por el propio Wardog

Para mí fue una buena experiencia de aprendizaje y creo que para todos los que hacemos tecnología, entender en detalle cómo funcionan cosas a bajo nivel es crucial. Y la gente que ha pasado por soporte en las empresas o ha hecho consultoría de Troubleshooting… tiene mi mayor respeto, por eso creo que me gusta tanto, tanto, tanto el libro de Wardog y El Mundo. Los Bastard Operators from Hell han tocado mucho troubleshooting lidiando con falta de información de los usuarios.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)