InforSupports

Categoría: Homelab

  • Abrir puertos detrás de NAT cuando el ISP bloquea UPnP y NAT-PMP

    Un problema común en homelabs: quieres exponer un servicio P2P (un nodo, un servidor de juego, un servicio de mensajería descentralizada) a internet, pero el router del ISP tiene bloqueados los protocolos estándar de apertura automática de puertos. Este es el diagnóstico y las alternativas cuando eso pasa.

    Diagnóstico del problema

    Se intentó forzar al router del ISP a abrir el puerto de forma automática desde la terminal de la máquina local, pero ambos protocolos estándar fallaron porque el ISP los tiene bloqueados o desactivados:

    • UPnP: falló con el error No valid UPNP Internet Gateway Device found.
    • NAT-PMP: falló con el error Connection refused (errno=111), lo que confirma que el router rechaza las peticiones de reenvío de puertos.

    Comandos utilizados para el diagnóstico

    Instalación de herramientas de mapeo automático:

    sudo apt install miniupnpc natpmpc

    Intento de apertura con UPnP:

    upnpc -a $(hostname -I | cut -d' ' -f1) 18080 18080 TCP

    Intento de apertura con NAT-PMP:

    natpmpc -a 18080 18080 tcp

    Verificación local de que el servicio está escuchando en el puerto:

    sudo ss -tulpn | grep :18080

    Alternativas sin acceso al router

    Al no tener las credenciales del router ni soporte de apertura automática, estas son las alternativas para saltarse el NAT del ISP de forma gratuita, de menor a mayor esfuerzo:

    A. Usar el servicio en modo «privado» (la opción sin cambios)

    No es necesario hacer nada. El servicio funcionará haciendo conexiones salientes (outbound) sin problema — se puede sincronizar, consultar y usar localmente. El único inconveniente es que otros nodos externos no podrán iniciar conexiones hacia el equipo (inbound).

    B. Redes mesh (para conectar tus propios dispositivos)

    Si el objetivo es conectar un celular o laptop propio al servicio de casa estando fuera, sin necesitar acceso público real, la solución más simple es usar Tailscale o ZeroTier. Ambas evitan el router usando UDP hole punching, sin necesidad de configurar nada en él.

    Instalar ZeroTier:

    curl -s https://install.zerotier.com | sudo bash
sudo zerotier-cli join [ID_DE_TU_RED]

    C. Túnel SSH inverso (para exponer el servicio 100% público y gratis)

    Se puede crear una cuenta en Oracle Cloud (Always Free Tier) para obtener un VPS gratuito con IP pública, y redirigir el tráfico desde ahí hacia el equipo local sin gastar dinero:

    ssh -N -R 18080:localhost:18080 usuario@ip_vps_gratis

    Con esto, cualquier conexión que llegue al puerto 18080 del VPS se reenvía automáticamente al puerto 18080 de la máquina local, sin que el router del ISP intervenga en absoluto.

    D. Exposición temporal (pruebas rápidas)

    Si solo se necesita exponer el puerto temporalmente, para una prueba puntual desde afuera:

    sudo snap install ngrok
ngrok tcp 18080

    Cuál elegir según el caso

    • Modo privado — suficiente si el servicio solo se necesita para uso propio, sin depender de conexiones entrantes de terceros.
    • Red mesh (Tailscale/ZeroTier) — ideal para acceso personal remoto (celular, laptop) sin exponer nada realmente a internet público.
    • Túnel SSH inverso — la opción más robusta y permanente si se necesita exposición pública real y gratuita, aprovechando un VPS con IP fija.
    • ngrok — el más rápido de levantar, pero pensado para pruebas puntuales, no para uso permanente (la URL/puerto cambia en el plan gratuito).

  • Recuperar datos de un backup .vma dividido en partes (Proxmox 8/9)

    Se tiene un respaldo de una máquina virtual de Proxmox dividido en 14 partes de exactamente 20 GB cada una (a excepción de la última, que pesa poco más de 11 GB). El peso total combinado es de aproximadamente 291.8 GB.

    Limitaciones identificadas

    • No se puede montar como un ISO: los respaldos de Proxmox usan un formato empaquetado propietario llamado .vma que Linux no entiende nativamente con el comando mount. Además, la imagen contiene una tabla de particiones interna completa, no un sistema de archivos plano.
    • Espacio en disco: para procesarlo de forma manual en una PC externa, se requiere al menos el doble de espacio (~292 GB extra para la unión, y otros ~292 GB si se extrae el disco virtual completo).

    ¿Qué es realmente un archivo .vma?

    .vma (Virtual Machine Archive) es el formato de contenedor que usa vzdump, la herramienta de respaldo nativa de Proxmox, para empaquetar en un solo archivo: la configuración de la VM (qemu-server.conf), y el contenido crudo de cada disco virtual asociado. No es un sistema de archivos por sí mismo — es un contenedor que hay que extraer primero con la herramienta vma para llegar al disco virtual real (típicamente un .raw), que ya sí contiene una tabla de particiones montable.

    Paso 1: unir las partes secuenciales

    Como los archivos terminan en sufijos alfabéticos ordenados (.part-aa hasta .part-an), se utiliza el comodín de Bash para unirlos en el orden correcto dentro de un solo contenedor comprimido:

    cat vzdump109.part-* > vzdump109.vma.zst

    Paso 2: extraer y montar el contenido

    Escenario A — Si estás en un Linux externo (sin Proxmox)

    Para este método necesitas instalar herramientas de descompresión y utilidades para interactuar con sistemas de archivos virtuales (guestfs-tools):

    # 1. Descomprimir el contenedor VMA de Proxmox
unzstd vzdump109.vma.zst

# 2. Extraer el disco virtual interno a una carpeta de destino
vma extract vzdump109.vma ./carpeta_destino

# 3. Montar de forma segura (solo lectura) la partición interna del disco virtual
mkdir /mnt/disco_vm
guestmount -a ./carpeta_destino/disk-drive-scsi0.raw -m /dev/sda1 --ro /mnt/disco_vm

    Una vez hecho esto, los archivos de la VM quedan accesibles directamente en la ruta /mnt/disco_vm.

    Escenario B — Si tienes acceso a un servidor Proxmox funcional (método rápido)

    Si dispones de un nodo Proxmox funcional, la vía óptima evita el duplicado de almacenamiento en comandos manuales:

    1. Mueve el archivo final vzdump109.vma.zst al directorio de dumps del servidor (usualmente /var/lib/vz/dump/).
    2. Desde la interfaz web de Proxmox, restaura la VM asignándole un ID genérico que no esté en uso (ej. 999). No enciendas la máquina virtual.
    3. Accede por la terminal SSH de Proxmox y monta directamente el volumen lógico o archivo de disco asignado a esa VM para extraer la información de manera local, sin necesidad de ocupar espacio extra extrayendo archivos .raw.

    También se puede hacer el mismo proceso por línea de comandos, sin pasar por la interfaz web, usando qmrestore directamente:

    qmrestore /var/lib/vz/dump/vzdump109.vma.zst 999

    ¿Esto aplica igual en Proxmox 9?

    Sí — Proxmox VE 9 mantiene el mismo formato .vma y las mismas herramientas (vma, qmrestore, guestmount) sin cambios en el procedimiento descrito arriba. La documentación oficial de vzdump y qmrestore para la versión actual sigue usando exactamente esta sintaxis.

    Hay un caso puntual a tener en cuenta si el respaldo fue creado en un host Proxmox 8.x y se intenta restaurar directamente en un host 9.x: hay reportes en el foro oficial de un error wrong vma extent header checksum durante la restauración cruzada entre versiones. El workaround confirmado es hacer el proceso en dos etapas:

    1. Descomprimir el archivo .vma.gz o .vma.zst a un .vma plano en el host 8.x (donde la restauración funciona sin problema):
    gunzip -c /path/to/backup/vzdump-qemu-VMID-DATE.vma.gz > /mnt/pve/NFS/temp_restore/vzdump-qemu-VMID-DATE.vma
    1. Mover ese .vma ya descomprimido al host 9.x y restaurarlo desde ahí con qmrestore, evitando que el 9.x tenga que descomprimir el archivo original.

    Si el respaldo y la restauración se hacen ambos dentro de la misma versión (8.x con 8.x, o 9.x con 9.x), no hay ningún problema de compatibilidad — el procedimiento de este artículo aplica sin modificaciones.

    Notas finales

    • El Escenario B (con un Proxmox funcional disponible) siempre es preferible: evita duplicar 292+ GB de espacio en disco de forma innecesaria.
    • Nunca enciendas la VM restaurada con un ID temporal si el único objetivo es extraer archivos — así evitas conflictos de red (IP/MAC duplicada) con la VM original si esta sigue existiendo en otro lugar.
    • guestmount siempre debe usarse con --ro (solo lectura) al inspeccionar un disco extraído manualmente, para no arriesgar corromper el sistema de archivos interno por error.