Esta es de «aviso a navegantes».

Contrato un servidor dedicado a estos sinvergüenzas. Y claro, 1and1 no puede evitar darme un regalo de cumpleaños que «merezca la pena».

Configurando ya el Apache de uno de los dominios que tengo hospedado en el servidor dedicado de 1and1, se me cae la conexión.

Entro por consola serie remota, y veo algo como esto en arranque:

[ 1.706310] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
[ 1.732654] forcedeth 0000:00:14.0: PCI INT A -> Link[LNKL] -> GSI 23 (level, high) -> IRQ 23
[ 1.749683] forcedeth 0000:00:14.0: setting latency timer to 64
[ 2.273729] forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:19:99:27:83:8d
[ 2.290238] forcedeth 0000:00:14.0: highdma pwrctl timirq gbit lnktim desc-v3

(...)

[ 12.139235] eth0: no link during initialization.
[ 12.148893] ADDRCONF(NETDEV_UP): eth0: link is not ready
Listening on LPF/eth0/00:19:99:27:83:8d
Sending on LPF/eth0/00:19:99:27:83:8d
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
done.


además:


s15310050:/# cat /sys/class/net/eth0/uevent
PHYSDEVPATH=/devices/pci0000:00/0000:00:14.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=forcedeth
INTERFACE=eth0
IFINDEX=2

s15310050:/# cat /sys/class/net/eth0/carrier
0

Para los no informáticos, y administradores de sistemas de 1and1; significa «he reconocido una tarjeta de red, pero como no tiene enlace -porque el cable o el switch fallan- no puedo obtener la IP por DHCP». Esto es un problema de la red de 1and1, y es el tipo de problemas que todos los proveedores de hospedaje, todos, solucionan cuanto antes. Porque si es mi cable, es mi problema. Pero si es mi switch que ha muerto, es además el problema de todos los servidores conectados a dicho switch. 24 o 48 servidores que están fuera de red, perdiendo pasta, y que a 1and1 le da lo mismo. Cobran funcione o no la salida a red.

Otras cosas. Sí, la IP es fija: la 213.165.84.97. La dan por DHCP, pero es fija. De esto te enteras luego. Vamos a dejarlo ahí. No quiero que me hierva la sangre, se supone que hoy es mi cumpleaños.

Mando el correo; teniendo en cuenta el tipo de problema que es, espero respuesta rápida. Pasa un dia. Nadie contesta. Sigo entrando por consola. Sigue sin ver enlace. Hago pruebas estúpidas, a ver si algo funciona. (Como ponerle a mano la IP). Pero es estúpido, ya que como no hay enlace, no sirve para nada.

Después hago lo que hace toda persona desesperada: llamo al amigo que me recomendó 1and1. Tiene varios dominios y máquinas contratadas allí. Un buen cliente. Le comento el caso, y me dice que porqué no he tomado un ticket, en lugar de un correo electrónico. Que los tickets los deberían atender al momento. Se me queda cara de tonto, y siento alivio. Vale, estaba haciendo las cosas mal, los partes se dan por tickets. Pasamos la próxima hora, el en su ordenador en su casa, y yo en la mía, en el panel de control buscando en enlace a los tickets. Sorpresa: 1and1 ha eliminado la posibilidad de tickets de soporte de su web: manda un correo, y ya te contestarán.

Mal rollo cuando una empresa de este tipo elimina el sistema de tickets: o su sistema es perfecto y no tiene sentido los tickets, o simplemente da tantos fallos que pasan de tener un mecanismo de trazabilidad de los problemas, porque objetivamente no los van a resolver. Entonces viene el momento que temo: cuando abro el cajón, y leo el contrato otra vez. Como decía un jefe del que aprendí mucho, los contratos están para comprobar que todos estamos hablando de lo mismo, y después guardarlos en el cajón. Y cuando necesitas abrir el cajón, es muy mala señal. Leo la letra pequeña, y veo dos cosas: la primera, que pueden cortarte el enlace si no les gusta el uso que haces de su máquina, o ven que te han entrado. Pero te tienen que avisar con un correo. Ese correo no me ha llegado, y además el único servicio activo era el ssh, y la única persona que había entrado era yo. Lo segundo, que no te garantizan servicio, ni disponibilidad, ni que nada funcione. Lo de los nueves está en la publicidad, pero no en el contrato. Cuando lo leí por primera vez no le di tanta importancia y lo achaqué a una cláusula defensiva de cara a reclamaciones judiciales ante problemas graves -todos los que hemos administrado sistemas a principios de siglo conocemos a nuestro amigo «el tio de la pala excavadora»-. Pero el problema es que lo de no asegurarte el servicio los sinvergüenzas de 1and1 lo llevan muy en serio.

Evidentemente, no se puede llegar ni al servidor ftp para hacer backup que te pone 1and1. Le doy a «restaurar imagen servidor», lo que básicamente te instala una debian nueva, desde cero. Lo pierdes todo. Pierdes un día de trabajo completo, que es lo que tengo desde el último backup. Pero el servidor tiene que andar; tienes clientes que no puedes dejar tirados. Aquí se abren tres alternativas -teniendo en cuenta que las IPs las sirven por dhcp-. La primera, que tengan un pool de máquinas con distros preinstaladas, en cuyo caso al formatear cambias de máquina física. La segunda, que esto haga que un operador humano se levante y mueva el culo, porque el proceso no esté automatizado. Y la tercera, que el proceso esté automatizado; y que, como no funciona la red porque no hay enlace, la máquina no sea capaz de restaurar la imagen.

¿Sabéis que ha pasado?

Pues que la máquina se ha arrancado, no ha conseguido acceder por dhcp a la reinstalación, y ha entrado como si nada. Es decir, que no puedo hacer nada más que aguantarme. Al menos me dará pie para que el lunes pueda montarle el numerito a los de 1and1. Lo que probablemente no sirva absolutamente para nada; ya que no es técnicamente un problema de mala atención, sino de ignorar a un cliente con un problema a nivel de enlace. Un problema físico. Desde luego, si ni restaurar el sistema a un debian limpio desde el interfaz web de 1and1 funciona, está claro que el problema no es de software

Esto supone dos escenarios, a cada cual más desasosegador:

El primero, que 1and1 tiene el servicio desatendido. Si arde su datacenter, se enterarán el lunes a las nueve de la mañana.

El segundo, que 1and1 tiene administradores que, o no atienden las peticiones de soporte, o no saben como atenderlas. Un día de downtime, y aumentando. O, dicho de otra forma, que salvo que arda el datacenter, el que tienen ahí estará jugando al buscaminas. Y si arde el datacenter, como saltarán los extintores de Xenón, dejará de jugar al buscaminas.

(El tercero, actualización) Xen, Qemu o cualquier aplicación de virtualización en un servidor dedicado 1and1 se interpreta como una interpretación de seguridad.

(El cuarto, actualización) Diga lo que diga el contrato, 1and1 te puede cortar el servicio cuando quiera, el tiempo que quiera, sin preaviso, y dejarte sin servicio una navidad o una semana santa completa. Basta emplear como escusa la «seguridad».

No se cual de los dos me da más grima, pero los dos me dan grima. Así que la cosa está clara: a llevarme los dominios a otro proveedor que no sea 1and1. Lo que me duele es que les he pagado un año de permanencia, y es un servidor que no me va a servir para nada. 480 euracos tirados. Pero al menos, aviso a los que leáis esto. Estáis avisados de como funciona 1and1.

Actualización a 6/7/2009: Finalmente me lo han arreglado, después de 60 horas de downtime. No han contestado el correo, ni han dado señal de vida. Simplemente, han vuelto a conectar el p[r-z]t? enlace:

s15310050:~# cat /sys/class/net/eth0/uevent
PHYSDEVPATH=/devices/pci0000:00/0000:00:14.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=forcedeth
INTERFACE=eth0
IFINDEX=2
s15310050:~# cat /sys/class/net/eth0/carrier
1

He llamado para darme de baja al servicio, al 902 882 11; la primera vez la centralita estaba saturada. La segunda, me han puesto con una señorita que me ha informado de que:

No puedo darme de baja hasta dentro de un año. (esto me lo suponía… tenía dudas de que fuera como telefonía, en la que si firmas permanencia y te das luego de baja, basta conque pagues la «multa», y puedes hacerlo. Mea culpa, por contratar el pack de un año como un imbecil, por ahorrar pasta. Al final la broma son 12*40 euros de algo que no me sirve para nada)

La baja es por fax, al 902023296; y hay que mandar fotocopia del dni por dos caras, id cliente, nombre, dni, listado exaustivo de todos los productos contratados para que no te cobren por una ip suelta aunque hubieras dado de baja el servidor -palabras textuales de la que me atendió-, fecha y firma.

Actualización 2 a 6/7/2009:

Un par de horas después de hablar por teléfono con la chica de la baja, recibo el correo adjunto:

Lamentamos su malestar con respecto a esta situación. Su servidor
dedicado, con ID de contrato XYZ, fue bloqueado temporalmente en
nuestros switchs por motivos de seguridad, dado que se detectó un envío
de paquetes no registrados originado en su servidor. Debe tener en
cuenta que este tipo de acciones tienen la consideración de MAC
spoofing, una práctica no permitida en los servidores alojados en
nuestro centro de datos, a fin de proteger a los clientes bajo nuestra
infraestructura.

Como información de su interés le proporcionamos el log del sistema a
este respecto:

Jul 4 00:45:07 sw-prtr-XX-c.lan.XX.XXXX.XXX 8144: Jul 3 22:45:06.296
UTC: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred,
caused by MAC address 0016.3e49.6873 on port FastEthernet0/5.

En estos momentos su servidor dedicado responde correctamente a las
conexiones a través del protocolo SSH, así como a las peticiones ping.
Le recordamos que el horario de nuestro servicio de atención al cliente
y soporte técnico es de lunes a viernes de 9 a 21 horas.

En caso de que desee configurar una IP en su servidor, le recomendamos
que use la configuración DHCP para ello, teniendo en cuenta que puede
comprobar la configuración de su Ip actual en /etc.resolve.

La «violación de seguridad» es que se dan cuenta que estoy empleando Xen. Lo pintoresco es que, según contrato, me deberían haber mandado un correo antes del corte, explicando la situación. Yo habría explicado que no es un ataque, que mire la MAC, que es una MAC del rango de Xen. Y no habría habido problemas. Pero es más sencillo tirar del cable, y que el próximo día laborable el cliente haga penitencia para conseguir recuperar su sistema. Lo siento, pero ya estoy muy mallorcito para ponerme de rodillas a decirle el Mater Ecclesiae, ora pro nobis a alguien con pocas luces y menos conocimiento.

Mi contestación, por correo:

Lo que usted denomina «MAC spoofing» es una máquina virtual Xen con un dominio contratado a ustedes, en un servidor dedicado contratado a ustedes, empleando una IP contratada a ustedes. Mis limitadísimos conocimientos sobre el tema no permiten percibir donde está el problema de seguridad en esto; especialmente cuando para hacer MAC spoofing hay que suplantar la identidad de otra MAC ya existente en la red; y, hasta donde llegan mis limitados conocimientos, las MACs del rango 00:16:3e:xx:xx:xx están reservadas para máquinas virtuales Xen. El administrador que le llega un paquete de respuesta a petición ARP con MAC 00:16:3e:xx:xx:xx no lo tiene muy complicado para sospechar que si sale por un puerto físico un paquete con una MAC de Xen, es una máquina virtual de Xen.

Que me conste, el uso de Xen o de cualquier solución de virtualización o de emulación para separar los dominios contratados y así reforzar la seguridad del servidor final ni está prohibido por contrato, ni es un abuso de sus recursos por mi parte. Lo he hecho numerosísimas veces en entornos de producción. De hecho, este domingo finalmente contraté servidor dedicado en otro proveedor, he hecho la instalación, y funciona sin ningún problema. Me ha costado ir a dormir a las tres de la mañana, y que el fin de semana de mi cumpleaños me quede currando como un burro, pero el problema está resuelto -en otro proveedor.

> En estos momentos su servidor dedicado responde correctamente a las
> conexiones a través del protocolo SSH, así como a las peticiones ping.
> Le recordamos que el horario de nuestro servicio de atención al cliente
> y soporte técnico es de lunes a viernes de 9 a 21 horas.

Les recuerdo que según sus condiciones de servicio, mandan un correo al cliente antes de cortarle la conexión si consideran que hay un problema de seguridad.

Si me cortan arbitrariamente el servicio fuera de horario de oficina, espero que el mismo especialista que lo ha cortado lo notifique, y que no me deje colgado hasta que haya alguien localizable. Más que nada, por si me hacen esto antes de semana santa o navidad y el corte no es de 60 horas, sino de 150.

La parte positiva es que he aprendido antes de poner algo crítico que ustedes pueden cortarme el servicio en cualquier momento, sin previo aviso, aunque eso suponga un incumplimiento por parte de ustedes de sus propias condiciones contractuales. También que por «problema de seguridad» basta cualquier cosa que la persona que esté a cargo no entienda. Esto me muestra que ustedes pueden ser útiles para poner unas paginas web estáticas no críticas, pero no para que ningún profesional serio ponga ahí nada que le genere dinero o que sea importante.

La parte negativa es que esta mañana he ido a darme de baja, y me han comunicado que tendré que aguantarles durante un año completo, ya que cometí el error en confiar y contratar un año de permanencia.

Ustedes están en su derecho de hacerme cumplir el contrato, aunque no cumplieron su parte (vale, aceptamos Xen como peligrosa vulneración de la seguridad, pero deberían haber mandado el correo preavisando del corte). Yo estoy en el mío de, en mis limitadísimos medios, de contar como me ha ido la historia con ustedes.

Conclusión: Con cualquier cosa que esté por encima del «umbral de dolor de seguridad» de 1and1 te cortan la conexión sin previo aviso. Para que entendamos donde está el umbral de dolor de los señores de 1and1, una MAC de Xen se considera «MAC Spoofing» y una terrible violación de las normas de seguridad.

En caso de que haya cualquier incidente de seguridad, entendiendo como tal que a alguien de 1and1 se le pase por la cabeza de que algo de lo que utilizas no le gusta, o que el patrón de uso de la red no le mola, te cortan el servicio sin preaviso. Y ya lo recuperarás, rogando, el próximo dia laborable.

1and1 no tiene servicio de tiquets ni personal técnico fuera de horario de oficina para atender incidentes de nivel 1: problemas de hardware o de red achacables a 1and1. Independientemente de la excusa de que fue un problema de «seguridad» -llamaré a McAffee, finalmente ha salido un virus funcional para Linux, se llama Xen-, he «disfrutado» todo el mecanismo de atención a cliente de 1and1 en caso de problemas atribuibles a nivel 1: no son notificables fuera de correos que se atenderán en horario de oficina.

¿Recomendarías 1and1? No. Especialmente después de que OVH me provéa un servidor con Mandriva un domingo, en media hora, y haya sido capaz de hacer lo que en 1and1 me ha llevado días, 60 horas de cortes de servicio, y no haya sido capaz finalmente de hacerlo.

¿Recomendarías salir escopeteado de 1and1? Si tienes páginas web estáticas, o código cuyo tráfico jamás pueda ser interpretado como malicioso -lo sea o no-, y te da lo mismo que en fines de semana, noches, y fiestas de guardar el servicio pueda no funcionar, y no te estresarás, pues… cada uno donde le pique. Pero a cualquier persona que necesite que el servicio funcione, y si casca la red o el servidor alguien intente solucionarlo, 1and1 es para huir.

Actualización a 7/7/2009: Finalmente estube hablando con la persona que me mandó el correo anterior. Xen no se puede utilizar; y, como el servidor no ha llegado a estar realmente en funcionamiento y lleva contratado tres días, con dos de downtime, me permiten cancelar el contrato y no pagar todo un año, sino sólamente un mes.

Tags:1and1