Base de conocimiento: rDNS, tickets, DDoS, SSH, facturas cripto

El escritorio de operaciones en una guía: rDNS, correo de abuso, primer acceso SSH, facturas cripto y la ruta de un slice VPS a metal con IPMI. Desde $4.80/mes.

Un servicio de solo root convierte el soporte en listas de verificación

No hay ninguna capa gestionada en ningún nivel, y la forma honesta de decirlo es que el root es el producto. El parcheado, las copias de seguridad, la seguridad de la aplicación y todo lo que ocurre dentro del SO pertenecen al operador; el trabajo de la plataforma es el slice, la red, la factura y el hardware que hay debajo. La consecuencia para el soporte es estructural: las acciones del panel son de autoservicio, y la cola humana solo existe para lo que el panel no puede hacer.

La capa de autoservicio cubre la mayor parte de las operaciones diarias: Reboot, Reinstall y rDNS se ejecutan desde el panel de cliente sin ticket, a cualquier hora, en segundos. La cola humana existe para el residuo: una factura pagada de menos, una migración atascada, una pregunta que las listas de verificación no responden. Los tickets requieren saldo positivo, un asunto que nombre el objeto y el código de factura o la IP en el cuerpo; ese es todo el esquema.

Las cifras enmarcan la división: un reinicio desde el panel se mide en segundos, una reinstalación en minutos y una respuesta de ticket en horas laborables — por eso todo lo que el panel puede hacer le pertenece al panel. Escribir en inglés consigue las respuestas más rápidas en la cola, y la interfaz del panel sigue tu configuración regional; ambas son comodidades, no niveles de servicio, y ninguna te parchea el servidor a las 2 de la madrugada.

Esta página es el escritorio completo en un desplazamiento: rDNS y PTR, primer acceso SSH, correo de abuso y DDoS, facturas cripto, ampliaciones desde un slice de 2 vCPU hasta hardware con IPMI, además de snapshots y el panorama de privacidad. Cada sección nombra el fallo que previene, porque una base de conocimiento demuestra su valor a las 2 de la madrugada, cuando estás a un error del downtime, no con calma y con un café.

El error típico es importar supuestos del hosting gestionado: esperar parcheado proactivo, esperar a que una persona reinicie el servidor, o abrir un ticket para preguntar algo que el panel ya hace en un clic. El modo solo-root corta en ambos sentidos: nadie parchea tu servidor por ti, pero tampoco nadie se interpone entre tú y él. Empieza por la lista de verificación del primer acceso de abajo, porque todas las demás secciones asumen que el servidor es alcanzable y tuyo.

rDNS: el registro que la gente configura en la dirección equivocada

La mayoría de operadores configura SPF y DKIM con cuidado, y luego deja el registro PTR apuntando a lo que sea que el host puso por defecto — y se pregunta por qué el correo de un VPS limpio acaba en spam. El DNS inverso es el único registro que el servidor del destinatario comprueba primero, porque hace la pregunta que importa: ¿la historia de propiedad de esta IP se sostiene en ambas direcciones, o solo en la que tú escribiste?

El mecanismo es el forward-confirmed reverse DNS. El servidor de correo receptor resuelve tu IP a un nombre (203.0.113.10 → mail.example.com), luego resuelve ese nombre de vuelta y compara. Coincidencia más SPF publicado más firma DKIM es el mínimo que cualquier receptor serio espera; una discrepancia o un hostname genérico de centro de datos es una puntuación de spam antes incluso de leer el contenido. Los registros de puntero subyacentes están definidos en la RFC 1035, y la dirección de la comprobación nunca cambia entre receptores.

La latencia de la confianza es asimétrica: un PTR correcto con su registro A coincidente puede levantar una marca de reputación en días, mientras que uno discrepante socava todas las demás señales que publiques. Las guías de entregabilidad discrepan sobre los pesos y nunca sobre la dirección: el forward y el reverse deben contar una sola historia, y la historia debe incluir registros SPF, DKIM y DMARC que nombren el mismo origen. Una IP, un nombre, una sola narrativa.

En esta flota el cambio es de autoservicio: el campo rDNS del panel toma el hostname, lo aplica a tu IP, y la respuesta autoritativa se actualiza en minutos. Primero apunta el registro A de ese hostname a la IP, y luego ajusta el PTR para que coincida con el A — la dirección importa, porque la resolución directa debe existir antes de que la declaración inversa sea creíble. Los resolvers guardan en caché la respuesta antigua durante el tiempo de vida del registro, así que calcula una hora de impaciencia, no un ticket de soporte.

Dónde se rompe: configurar PTR en una IP que sirve muchos dominios. Una IP lleva un PTR; si cinco sitios comparten la dirección, el PTR debería nombrar el origen de correo principal o nada útil. Esa restricción — un nombre por IP — es también la razón silenciosa por la que la gente acaba pidiendo una IP adicional o moviendo el correo a una máquina aparte; el panel gestiona ambas cosas, y el buzón es la prueba que te dice si algo de esto funcionó.

Primer acceso SSH antes de que nada más toque el servidor

El servidor llega con root y una contraseña que fijaste en el pago, y la primera hora decide si eso sigue siendo verdad. Los escáneres de internet encuentran puertos SSH nuevos en minutos — el ruido de los logs por sí solo lo demuestra — así que el primer acceso existe para reemplazar el acceso por contraseña con claves antes de instalar cualquier otra cosa. Quince minutos de orden ahora eliminan toda una clase de compromiso después, y el orden importa más que las herramientas.

La secuencia, en orden: crea un usuario con adduser deploy, genera un par de claves en tu estación de trabajo con ssh-keygen -t ed25519 e instala la mitad pública con ssh-copy-id deploy@your-server. Prueba el acceso con clave desde una segunda terminal antes de tocar la configuración del servidor — una clave sin probar es un rumor, no una credencial. El manual de ssh-keygen cubre los tipos de clave y las opciones que realmente usarás.

Las claves escalan mejor que las contraseñas en otro sentido que importa a las 2 de la madrugada: perder un portátil significa borrar una línea de authorized_keys, no rotar una contraseña en cada servidor y servicio que la compartía. Una clave por dispositivo, un authorized_keys por usuario, y el radio de impacto de cualquier compromiso único se reduce a una máquina que puedes nombrar — que es la diferencia entre un incidente y un martes.

Solo después de un acceso con clave demostrado editas /etc/ssh/sshd_config: pon PasswordAuthentication no y PermitRootLogin prohibit-password, y luego recarga el demonio con systemctl reload sshd — recarga, no reinicio, para que una sesión existente sobreviva a un error tipográfico en la configuración. El manual de sshd_config documenta cada directiva; cambia dos líneas, no veinte, y ten a mano la página de ssh para las opciones del lado del cliente.

Dónde se rompe: desactivar la autenticación por contraseña antes de demostrar que la clave funciona, en un servidor donde la consola del panel es el único camino de vuelta. El botón de reinstalación lo arregla en minutos, pero borra el disco — un profesor caro. Demuestra, luego restringe, luego parchea (apt update && apt upgrade o el equivalente de tu distribución), y el servidor queda listo para todo lo demás de este escritorio, empezando por la historia del rDNS de arriba.

Correo de abuso y DDoS: qué llega y qué significa

Un correo de abuso parece una acusación y funciona como una página de estado. Un informe llega a la dirección de abuso cuando un tercero — una lista antispam, un proyecto de escaneo, un titular de derechos — observó algo procedente de tu IP, y el host lo reenvía porque la ley de la ubicación de la instalación y la política de uso aceptable convierten el informe en un proceso, no en una opinión. El proceso tiene una forma, y esa forma favorece a los operadores que responden con correcciones.

El filtrado también tiene una forma que conviene conocer: el scrubbing DDoS funciona aguas arriba del puerto, está incluido en todos los niveles en lugar de facturarse por ataque, y nunca lee tus payloads — pesa el tráfico, no el contenido. Un puerto sin límite de tráfico de 1 Gbps en Forge y de 10 Gbps en Summit y superiores es el techo contra el que planificas; el trabajo del filtro es que las inundaciones nunca lleguen a ser tu problema, y por eso la mayoría de ataques pasan sin que los notes.

Lo que prohíbe la AUP es corto e innegociable: CSAM, phishing, spam y atacar a otros. Todo lo demás es administración. La observabilidad es cosa tuya: comprueba qué está escuchando con ss -tlnp, lee lo que vio tu servicio con journalctl -u app, y mantén el correo de contacto del panel en uno que realmente leas. Del lado del servidor, los metadatos de conexión se conservan ≤24 h y el payload no se registra, así que la historia de la corrección tiene que salir de tus logs, no de los del host.

La respuesta correcta a un aviso de abuso real es aburrida: identifica el servicio comprometido o mal configurado, arréglalo y responde con qué cambió. Un open relay, un resolver expuesto, una aplicación web secuestrada que envía phishing — cada uno tiene una corrección de una línea y una explicación de un párrafo. Los informes respondidos con correcciones se cierran; los informes discutidos escalan, porque la ley de la instalación, y no el humor del operador, decide el final del proceso.

Dónde se rompe: ejecutar algo que no sabías que estaba escuchando. Todo administrador acaba encontrando un servicio ligado a 0.0.0.0 que creía local — el hábito que previene el correo de abuso es un inventario: lista los puertos en escucha después de cada instalación, cierra lo que no tiene audiencia, y mantén el correo de contacto registrado al día, porque ese buzón es donde el proceso te alcanza, estés o no preparado.

Facturas cripto: el watcher, el bloqueo y el caso del pago insuficiente

Las facturas se fijan en USD, se convierten a un tipo de cambio en vivo al crearse, y se acreditan cuando un watcher del lado del servidor coincide con el importe exacto en la cadena — diecinueve monedas, un solo motor, direcciones de un solo uso, sin formularios de hash de transacción que rellenar. La pantalla de la factura imprime la moneda, la cifra bloqueada y la profundidad de confirmación; el panel de cliente muestra el mismo trío en la sección de facturación, así que la pregunta de dónde fue a parar un pago tiene respuesta de autoservicio antes de tener ticket.

El término anual de −20% se aplica antes de la conversión: Core con precio de lista de $6 queda en $4.80 con el cálculo anual, y solo entonces la conversión a moneda fija el importe. Ese orden importa al comparar facturas — dos compradores con monedas distintas pagan cifras distintas de moneda por el mismo total en USD, y ambas coinciden correctamente. El bloqueo ocurre una vez, en la creación, y ni movimientos posteriores del tipo de cambio ni recargas posteriores de la página cambian lo que el watcher espera ver.

Monedas, para el registro: XMR y BTC encabezan la lista, ETH, SOL, LTC, BNB y TRX siguen, luego XRP, DOGE, DASH y ADA, GRAM (TON), y USDT en siete redes — TRC-20, ERC-20, BEP-20, SPL, Polygon, Arbitrum, Optimism. Diecinueve formas de pagar, ninguna con tarjeta, todas en la página de factura que ya tienes abierta, y todas sujetas a la misma regla de importe exacto en una dirección de un solo uso.

Las transferencias con pago insuficiente o en la cadena equivocada son material de ticket, no motivo para un segundo envío. Una dirección de un solo uso que recibe un importe inferior a la cifra impresa tiene un problema de tamaño humano: el watcher no coincidió con nada, y disparar otra transferencia a ciegas a la dirección retirada suele apilar un segundo desajuste sobre el primero. Abre un ticket con el código de factura y los detalles de la transferencia, y deja que el soporte concilie una sola vez, limpiamente, con ambos lados de la aritmética a la vista.

El error recurrente es tratar la cifra de la factura como una cotización en lugar de un contrato: los tipos bloqueados en la creación no siguen el mercado después, y una factura pagada una hora tarde a otro precio sigue debiendo el número impreso. Lee la vista de factura del panel antes de dar por atascado un pago — el abono es automático cuando la coincidencia aterriza, y las FAQ cripto cubren a fondo los bloqueos de tipo de cambio y el procedimiento de pago insuficiente.

Cuando un slice se gradúa a metal

Las ampliaciones tienen dos ejes, y el selector de planes del panel solo muestra uno. RAM y vCPU escalan dentro de la escalera VPS; los núcleos exclusivos, la memoria ECC y el acceso a consola fuera de banda no — eso vive en el lado dedicado, y la carga de trabajo anuncia el movimiento mucho antes que los paneles, en el steal time y los contadores de swap antes que en elegantes gráficos resumen.

Las señales son concretas: %steal subiendo durante la carga de los vecinos, columnas si/so activas en vmstat, latencia p99 creciendo mientras la utilización de CPU parece plana — firmas clásicas de vecinos ruidosos que ningún nivel VPS puede arreglar porque son estructurales a compartir un host. Cuando un slice Core o Titan pasa sus días escondiéndose de los vecinos, el siguiente peldaño de la escalera es el metal, no un slice más grande con la misma física.

Los hechos de hardware trazan la línea con precisión: los planes VPS ejecutan KVM sobre ECC y NVMe local — Titan lleva 32 GB de DDR5 ECC — mientras que la escalera dedicada añade núcleos exclusivos e IPMI en todos los niveles. Si la carga de trabajo nunca sale de los recursos del slice, quédate en el slice; si necesita todo el die, un hipervisor es la capa equivocada bajo la que alquilar, y ninguna cantidad de redimensionado vertical cambia eso.

Mueve la carga de trabajo a VPSbit Forge con precio de lista de $49 — $39.20 de efecto anual — cuando los inquilinos empiezan a aparecer en el steal time: dieciséis hilos Ryzen 9 9950X de tiempo exclusivo, 32 GB DDR5, dos unidades NVMe de 1 TB e IPMI en el puerto. El mismo checkout sin KYC lo tarifica en las mismas diecinueve monedas, y el montaje en rack añade 2–4 horas a la ventana de migración, lo cual es un dato de planificación más que un inconveniente.

La escala de terabytes es el otro eje: Monolith combina 4 × 2 TB de NVMe con 128 GB ECC para archivos y bases de datos que superaron con creces los slices. El error es escalar el eje equivocado — comprar slices de RAM contra un problema de steal ligado a CPU, o metal contra un problema de espacio en disco que un Prime de 160 GB habría resuelto. Nombra primero el cuello de botella; la guía de slice contra metal recorre el árbol de decisión de principio a fin.

Tickets que consiguen respuesta

Un ticket de soporte es una consulta con un esquema, y el esquema está impreso en el formulario: saldo positivo, asunto que nombre el objeto, código de factura o IP en el cuerpo. Los tickets a los que les falta cualquiera de los tres esperan más de lo debido, no porque nadie castigue a nadie, sino porque el primer paso de la cola es la identificación, y un ticket sin identificar ni siquiera puede empezar a moverse hacia una respuesta.

Expectativas de respuesta, dichas sin rodeos: las acciones de autoservicio del panel aterrizan en segundos, los tickets en horas laborables, y el correo del proceso de abuso al ritmo del carril legal. El requisito de saldo positivo suena raro hasta que ves el inverso: las cuentas prepagadas generan la fracción más pequeña de tickets basura, porque el mismo crédito que mantiene el servidor también respalda la pregunta. La identificación no es burocracia; es enrutamiento.

Un buen asunto hace la mayor parte del trabajo: Invoice A8F3 — underpaid transfer se enruta solo; server problem!! espera a que una persona adivine. El cuerpo lleva el objeto — IP, código de factura, nombre del servicio en el panel — más qué hiciste y qué viste, con marcas de tiempo. El inglés consigue las respuestas más rápidas, aunque la interfaz del panel sigue tu configuración regional: escribe el ticket en inglés, lee la interfaz en lo que te guste, y adjunta las evidencias en lugar de describirlas.

Lo que no va en un ticket: contraseñas (nadie debería pedirlas jamás), volcados completos de disco, ni una queja de un tercero contra tu experiencia con un proveedor — los informes de abuso se dirigen a la dirección de abuso, donde reciben el proceso legal y no la cola de operaciones. Las disputas de facturación viajan con el código de factura; las preguntas de red viajan con trazas que adjuntas, no que describes: la salida de mtr -rw example.com pegada como texto le gana a una captura de pantalla de un sentimiento todas las veces.

El patrón de fallo es la escalada por impaciencia: tres tickets en una hora, cada uno con menos contexto que el anterior, cada uno reiniciando la posición en la cola. Un ticket completo respondido en horas vale más que tres fragmentos respondidos en días — y para todo lo que hace el panel (reinicio, reinstalaciones, rDNS), no debería existir ningún ticket. La forma del escritorio, repasada: autoservicio primero, tickets con esquema completo después, correo de abuso para el carril legal.

Privacidad, enunciada con los límites incluidos

Sin KYC significa que el registro nunca pide un pasaporte — no hace que la cuenta sea invisible. El correo existe, la factura existe, y tu invitado conserva los registros que tu invitado conserve. La parte del ledger que toca al pago es estrecha por diseño: facturación y acciones del panel retenidas, metadatos de conexión conservados ≤24 horas, sin registros de payload ni de tráfico de invitados. Estrecho no es cero, y una planificación honesta de la privacidad empieza en esa frase y no en una de marketing.

En el servidor, la privacidad es administración: claves OpenSSH en lugar de una contraseña reutilizada, cifrado de disco completo donde la carga de trabajo lo permita, y WireGuard si el endpoint debe responder solo a ti — un túnel que deja el puerto 22 invisible para los escáneres cuesta un archivo de configuración en /etc/wireguard/wg0.conf. La plataforma ve metadatos de conexión por la necesidad de operar una red; no necesita ver dentro del túnel, y con tu propio endpoint WG, no lo ve.

La higiene de registros es tuya, por partida doble: los registros propios del invitado — auth, access, aplicación — son el relato más rico de la vida del servidor, y rotarlos o minimizarlos es una decisión del operador. Una línea base útil: conserva los logs de auth, reduce los de access a nivel de errores, y nunca registres payloads que no entregarías, porque la respuesta honesta a la pregunta de qué registros existen debería empezar por los que elegiste, no por los que olvidaste.

Fondéa la cuenta una vez y deja el rastro de papel en la moneda que elegiste: pon un slice Core en el término anual — $6/mes de lista, $4.80 de efecto anual, una factura, sin cargos automáticos — y renueva deliberadamente en lugar de dejar atrás un hábito con forma de tarjeta. La parte de la cuenta de ese panorama se declara en el registro — token o correo, una contraseña de 12 caracteres, nada más se recoge — y los límites están impresos en cada factura en lugar de prometidos en una política aparte.

Dónde se rompe: reclamar invisibilidad desde una factura sin KYC mientras la propia aplicación envía restablecimientos de contraseña a una dirección personal, o mientras el DNS del dominio descansa en una cuenta de registrador con tu nombre legal encima. La privacidad es una cadena de custodia a través del registrador, el DNS, el correo y los registros, y el eslabón más débil marca el nivel; la guía de dominios anónimos cubre la mitad del registrador de esa cadena.

Snapshots, copias de seguridad y el rollback que olvidaste comprar

Las copias de seguridad son lo más común que la gente planea añadir más tarde y lo único que convierte un incidente en una molestia. En esta plataforma los snapshots son un complemento de rollback en el panel, y los discos en espejo protegen las unidades del host — y ninguna de las dos cosas te protege de ti mismo, porque rm -rf se ejecuta con alegría sobre almacenamiento en espejo y borra todas las copias a la vez.

Los costes mantienen el hábito honesto: el almacenamiento de snapshots se factura un poco por gigabyte, las copias fuera del servidor se facturan a la tarifa del segundo servidor, y el control de versiones es gratis — que es exactamente el orden correcto de gasto para el valor que devuelve cada capa. Un slice Core de 80 GB se snapshottea en minutos; los 8 TB de NVMe en bruto de un Monolith quieren un plan de copias real, no una casilla marcada, porque a esa escala el tiempo de restauración es el incidente.

Diseña las tres capas deliberadamente. Los snapshots del panel capturan el slice para rollback antes de cambios arriesgados — toma uno antes de cada actualización, nómbralo con la fecha, borra los viejos para que no facturen para siempre. Las copias de la aplicación van fuera del servidor: rsync -a --delete a un segundo servidor, o restic a almacenamiento de objetos, con una programación que funcione sin ti. La configuración vive en control de versiones desde el primer día, así que una reinstalación es un checkout, no arqueología.

Prueba las restauraciones cada trimestre, porque una copia sin probar es una esperanza, no una copia de seguridad. El simulacro es corto: lanza el snapshot o la ruta de restauración, confirma que el servicio responde, y anota cuánto tardó. Una base de datos que restaura en 40 minutos cambia tu aritmética de incidentes para bien; una que nunca ha restaurado no cambia nada, estadísticamente, salvo tu confianza el día que la necesites.

Dónde se rompe: snapshots en el mismo servidor que los datos que protegen. Una cuenta de panel comprometida o un borrado con el dedo gordo se lleva ambas capas a la vez — la copia fuera del servidor es la que sobrevive, y por eso la programación importa más que la herramienta. Con las capas montadas, la mitad que queda del escritorio es humana: tickets y escalada, cubiertos en la sección anterior.

El escritorio de operaciones, en el orden de ejecución

Orden de operaciones, primera hora: entra, crea tu usuario, instala la clave con ssh-copy-id, demuestra el acceso con clave desde una segunda terminal, y luego pon PasswordAuthentication no en /etc/ssh/sshd_config y recarga. Parchea el servidor, lista los puertos en escucha con ss -tlnp, y cierra lo que no tiene audiencia — el servidor ya es más difícil de tomar que la mayoría de máquinas de internet, y te llevó quince minutos.

Segunda pasada, identidad y nomenclatura: apunta el registro A del hostname con el que piensas responder, luego ajusta el rDNS en el panel para que coincida, y dale una hora de propagación antes de probar con dig -x. Publica SPF, DKIM y DMARC si el correo entra en el alcance, y confirma que la historia se lee igual en ambas direcciones — forward, reverse, y los registros que nombran el origen.

Tercera pasada, el túnel y la programación: levanta WireGuard si el endpoint debe ser privado, toma un snapshot del panel como línea base conocida-buena, y programa copias fuera del servidor hacia un segundo servidor o almacenamiento de objetos. Apunta la factura en el calendario — los términos anuales se renuevan en una fecha que tú elegiste, no una que un procesador de tarjetas eligió por ti, y una wallet fondeada con una semana de antelación es la diferencia entre renovar y reaprovisionar.

Ritmo permanente, semanal y trimestral: revisa el steal time si estás en un slice compartido, rota claves en los dispositivos perdidos, prueba una restauración por trimestre, y lee el buzón de abuso que registraste. Cuando la firma de la carga de trabajo — steal, swap, p99 — dice que el slice llegó a su fin, el panel tarifica la escalera dedicada en la misma página, en las mismas monedas, bajo los mismos términos sin KYC que el slice que reemplaza.

Ese es el escritorio: root, claves, registros, copias, tickets — en ese orden, porque cada paso asume los anteriores. Las listas de verificación siguen siendo válidas en las doce ubicaciones y en todos los niveles, desde el slice más pequeño hasta el metal con IPMI; los hechos cambian, el orden no. Guarda esta página en los marcadores del panel, porque las 2 de la madrugada no son momento de reconstruirla de memoria.