Desbloqueando un switch TP-Link T1500G-8T – Parte 1: El final agrio

Aprendamos de las peripecias de desbloquear un switch de capa 3 junto a una linda historia que involucra un ISP sureño, un poco de plata y mucho, mucho dolor.

Estamos ya en el 2023 y la pandemia pareciera ya no causar más estragos de los que ya dejó. Desde que escribí el último artículo aquí han pasado muchas cosas y en una serie de artículos que tengo preparados (y que quizás nunca publique porque soy una persona horrible) quiero empezar con este que es una historia de dulce y agraz, pero de más que sirve para algo interesante.

La historia

Un amigo encontró unos aparatos que estaban clasificados como «repartidores de internet» a CLP 10000 (unos USD 12,5 a la fecha de redacción) por pieza. Grata fue mi sorpresa cuando me di cuenta que resultaban ser unos switches de capa 3 de TP-Link, modelo T1500G-8T. Compré los que le quedaban al vendedor y al poco rato ya los tenía conmigo. La primera prueba resultó medianamente exitosa, los equipos encendían y parecían tener actividad de red al menos en lo que acusaban los LED frontales.

weqwe
TP-Link T1500G-8T.

El asunto parecía tan simple como aplicar un reset de fábrica y seguir las instrucciones que aparecían en la etiqueta de debajo. Grande fue mi sorpresa cuando al intentar verificar conectividad con el switch mi consola se veía algo así:

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.100 icmp_seq=1 Destination Host Unreachable
From 192.168.0.100 icmp_seq=2 Destination Host Unreachable
From 192.168.0.100 icmp_seq=3 Destination Host Unreachable
From 192.168.0.100 icmp_seq=4 Destination Host Unreachable
From 192.168.0.100 icmp_seq=5 Destination Host Unreachable
From 192.168.0.100 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.0.1 ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6031ms

Evidentemente algo estaba pasando y cómo iba a ser que me quedara con las ganas. Pero antes creo deber una pequeña explicación.

Switches de capa 3

En palabras muy sencillas es un switch que puede hacer ciertas funciones de un router. Aunque es mucho más que eso. Un switch de capa 3 es un dispositivo que además de poder ejercer todas las funciones de un switch (de capa 2) tradicional, también es capaz de entender parte de la información inherente a la conecitividad IP y tomar decisiones de reenvío de paquetes en base a estos datos, algo que resulta particularmente interesante cuando se empieza a trabajar con inter-VLAN, o cuando se está manejando una red muy grande, del orden de miles de hosts.

¿Necesito yo un switch de capa 3?

En el 99% de los casos, no. Aun siendo usuario avanzado debería bastar con un switch de capa 2 administrable, en caso de que se tenga la red segmentada por VLAN. Ya si se requiriera hacer routing entre estas VLAN, es ncesario contar con un switch de capa 3.

Mi caso de uso

Hace algunos meses mi servidor fue víctima del ransomware 0XXX (más info aquí). Es un malware que ataca directamente carpetas compartidas en Internet. En mi caso, tenía un servicio FTP de Windows Server (IIS) para unos amigos, donde se compartía principalmente abandonware. El problema fue cuando decidí compartir una carpeta con más gente y donde perdí básicamente el control respecto a quién utilizaba el servidor. Fue entonces cuando vi que esa carpeta compartida y una más con abandonware habían sido infectadas. Curiosamente, ninguna de las otras carpetas ni los demás discos duros fueron afectados. De todas formas rehice el sistema en un ambiente Linux y hasta el momento no he tenido inconvenientes, claro que no he hecho comparticiones públicas desde entonces.

Entonces, como tengo equipos viejos que quisiera conectar a Internet necesitaba una forma de poder crear una red segmentada para esos equipos, donde pudieran lograr acceso a Internet pero que no pudiesen ver ni interactuar con la red «moderna». Y estos switches son la solución perfecta. O lo serían si no estuvieran bloqueados.

Comienza la aventura

Si de algo estaba seguro es que los equipos funcionaban. Si podían hacer switching entre ellos, es que algo estaban haciendo y al menos la parte de software funcionaban. Como cualquier equipo de telecomunicaciones, lo usual es que cuando no existe un puerto de consola serie disponible, se puede obtener desde el interior del equipo en un pin-header usualmente de cuatro conectores. Esta vez no era la excepción.

Con el único problema que el puerto estaba completamente mudo. No había actividad de datos salvo la energía y la conexión a tierra. Incluso estropeé uno de mis adaptadores serie a USB intentando reconocer si la conexión estaba bien. Luego leí en un foro (ver aquí) que la verdadera conexión serie se saca directamente del integrado principal del equipo. Con unas fotos muy detalladas logré ubicar dos puntos de soldadura que eran relativamente más fáciles de soldar que directamente en el integrado.

También el foro indicaba que la conexión debía hacerse a 38400 bits por segundo, con lo que una conexión y un adaptador nuevo después ya estábamos dentro del equipo.

Afortunadamente la conexión a la consola era sin necesidad de login y con acceso completo. Con ello pude aplicar la siguiente combinación de información, que básicamente era cambiar la contraseña de la cuenta de administración, crear una nueva por si acaso y asignar una dirección IP estática a la VLAN que estaba configurada como de administración, que era la 10:

T1500G-8T>ena
T1500G-8T#conf
T1500G-8T(config)#interface vlan 10
T1500G-8T(config-if)#ip address 192.168.10.1 255.255.255.0
T1500G-8T(config-if)#exit
T1500G-8T(config)#user name admin privilege admin secret admin
T1500G-8T(config)#user name admin2 privilege admin secret adminadmin
T1500G-8T(config)#exit
T1500G-8T#copy running-config startup-config

Luego, con un PC con Linux creé una conexión con dicha VLAN y con ello ya teníamos ping y acceso a la interfaz web, no sin su cuota de sopresa:

Los equipos eran de GTD Telsur, y con una configuración específica de ellos respecto a las VLAN. Aparentemente según otro post (ver aquí) la configuración viene ofuscada y con justa razón, pero con la clave de administración cambiada ya se podía actualizar el firmware a algo más neutro.

La forma fácil de hacerlo

Si de algo sirvió todo este martirio es para revisar brevemente cómo podría hacerse todo este procedimiento sin todo este martirio: Al parecer según la configuración original, el equipo tomará IP de algún servidor DHCP que le entregue a través de la VLAN 10, en cualquiera de sus puertos. Si mi teoría es correcta, bastará colocar un servidor que le entregue dirección por la VLAN 10 para obtener administración del equipo. No obstante, todavía falta saber la contraseña original de la cuenta de administración, la cual no se puede cambiar sin el acceso al puerto serie.

Configuración del equipo

Este es el extracto del comando «show running-config» del switch Cisco TP-Link:

T1500G-8T(config)#sh run

!T1500G-8T
#
vlan 10
 name "Management"
#
vlan 3850
 name "IPTV_Service"
#
ip management-vlan 10
#
system-time ntp UTC-04:00 172.19.12.14 192.168.20.69 12
no system-time dst
#                                  
user name admin privilege admin secret 5 $1$@<D/H;I7B5@3B0O8E=O=K1J6L0O6F>F1{!]-*
#
snmp-server
snmp-server community "9df8322k67" read-write "viewDefault"
#
interface vlan 10
  ip address 192.168.0.1 255.255.255.0
#
interface gigabitEthernet 1/0/1
  switchport general allowed vlan 10,3850 tagged
#
interface gigabitEthernet 1/0/2
  switchport general allowed vlan 10 tagged
#
interface gigabitEthernet 1/0/3
  switchport general allowed vlan 10 tagged
#
interface gigabitEthernet 1/0/4
  switchport general allowed vlan 10 tagged
#
interface gigabitEthernet 1/0/5
  switchport general allowed vlan 3850 untagged
  switchport general allowed vlan 10 tagged
  no switchport general allowed vlan 1
  switchport pvid 3850
#
interface gigabitEthernet 1/0/6
  switchport general allowed vlan 3850 untagged
  switchport general allowed vlan 10 tagged
  no switchport general allowed vlan 1
  switchport pvid 3850
#
interface gigabitEthernet 1/0/7
  switchport general allowed vlan 3850 untagged
  switchport general allowed vlan 10 tagged
  no switchport general allowed vlan 1                                   
  switchport pvid 3850
#
interface gigabitEthernet 1/0/8
  switchport general allowed vlan 3850 untagged
  switchport general allowed vlan 10 tagged
  no switchport general allowed vlan 1
  switchport pvid 3850
#
end

Final agrio y conclusiones

Realicé con éxito el procedimiento en los cuatro equipos y al otro día tres de ellos dejaron de funcionar. Quiero pensar que algo ocurrió mientras hacía la conexión serie, de otra forma no me lo explico. Lo bueno, es que sirvió para publicar este artículo.

De todas formas, no me desharé de los equipos todavía. Aun hay uno que enciende y según pruebas que pude hacer antes de que me pusiera a escribir este artículo al parecer quedó un problema en la consola serie, que hace que el inicio del software se detenga en un menú de pre-arranque. Como en realidad no tenía pensado utilizarlos en lo inmediato, los guardaré hasta que se justifique seguir intruseándolos o si aparece una probable solución para esos problemas.

Si quiere ver cómo continúa este asunto, pase por acá.

Links de cosas que usé para este artículo
  • https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/71?page=4
  • https://www.capa9.net/temas/administraci%C3%B3n-de-tp-link-t1500g-8t.1137379/
  • https://www.capa9.net/temas/gtd-fth-entrega-bridge-o-no.1126809/page-7
  • https://community.tp-link.com/en/business/forum/topic/262186