ZeroTier: Construye una red privada y soluciona el problema «No se puede hacer ping»

Qué es realmente ZeroTier (y qué no es)

ZeroTier es una red de superposición: crea una interfaz virtual similar a Ethernet en cada nodo y usa transporte cifrado punto a punto
cuando es posible. Cuando el peer-to-peer es imposible (NAT estricta, UDP bloqueado, etc.), puede usar relays.
Piénsalo como “LAN definida por software sobre Internet”, aunque se comporta más como un híbrido:
a veces parecido a L2, a menudo a L3, y siempre dependiente de las condiciones reales de la red.

La implicación práctica: cuando no puedes hacer ping, rara vez es “ZeroTier está caído”.
Normalmente es una de cinco cosas:
autorización, direccionamiento, política de firewall del SO, enrutamiento/solapamiento, o MTU/fragmentación.
El resto de este artículo explica cómo demostrar cuál es, de forma rápida.

Qué no es ZeroTier: no es un bypass mágico para la política de salida corporativa, ni un sustituto de entender rutas.
Tampoco hará que un host Windows responda a ICMP si el Firewall de Windows dice “no”.
Si estás leyendo esto porque “dice ONLINE pero no puedo hacer ping”, bienvenido al club.

Hechos y contexto que facilitan la resolución

Un poco de historia y mecánica importan porque explican modos de fallo. Aquí hay nueve puntos concretos que vale la pena conocer.

1. ZeroTier usa UDP por defecto (comúnmente el puerto 9993). Si la salida UDP está bloqueada, puedes obtener relays o nada en absoluto.
2. Los nodos tienen una identidad de 10 dígitos derivada de claves criptográficas. Esa identidad persiste; cambiar la IP no cambia la identidad del nodo.
3. Las redes se identifican por un ID de 16 dígitos. Unirse a la red equivocada es un error clásico de “todo parece bien”.
4. “ONLINE” no significa “alcanzable”. A menudo significa “el controlador conoce este nodo”, no “ICMP funcionará de extremo a extremo”.
5. El peer-to-peer directo es oportunista. La traversía de NAT tiene éxito o falla según el comportamiento real del NAT, soporte de hairpin y mapeo de puertos.
6. Los relays son normales. Cuando ves “RELAY”, la latencia sube y el rendimiento baja. Eso puede romper aplicaciones sensibles al RTT o al MTU.
7. Las rutas gestionadas son política del plano de control. Si esperas conectividad sitio-a-sitio sin anunciar rutas, te decepcionarás repetidamente.
8. El bridging es potente y arriesgado. El bridging puede convertir una superposición limpia en una fiesta de broadcast. Excelente para algunos casos legacy, terrible para “¿por qué va lento?”
9. Los solapamientos de subredes son veneno. Si tu red ZeroTier usa 192.168.1.0/24 y el router doméstico de alguien también, los paquetes tomarán la ruta más tonta posible.

Construye una red privada que se comporte

Elige un plan de direcciones que no choque con la realidad

No elijas 192.168.0.0/24 o 10.0.0.0/24 a menos que tu hobby sea depurar enrutamiento split‑brain.
Usa algo aburrido y poco probable: un segmento dedicado de 10/8 (pero no los sospechosos habituales), o si tu entorno lo soporta,
usa IPv6 dentro de ZeroTier.

Una elección simple y de baja colisión: 10.147.0.0/16 para la superposición y luego dividir en /24s si más tarde haces bridging entre sitios.
El rango exacto no importa; lo que importa es la ausencia de solapamiento.

Decide: enrutamiento o bridging (no hagas las dos cosas a medias)

El enrutamiento es casi siempre la respuesta correcta para conectividad sitio-a-sitio. El bridging es para cuando realmente necesitas adyacencia L2
(algún protocolo antiguo de descubrimiento, asunciones de aplicaciones no enrutables, o un appliance de un proveedor que cree que los routers son conspiración).

El bridging aumenta el radio de impacto. Broadcast y multicast pueden derramarse en la superposición, y así es como aparecen picos de latencia extraños.
Si tu objetivo es “SSH a servidores y alcanzar un par de subredes”, enrútalo.

Plano de control vs plano de datos: la autorización no es opcional

Una red privada requiere autorización de miembros. Si olvidas autorizar, el nodo puede aparecer pero no pasará tráfico.
Esto no es un tema sutil; es un tema de “lo juro, está conectado”.

Establece una línea base: ping no es la primera prueba

ICMP es útil, pero también comúnmente bloqueado. Tu primera línea base debería ser:
(1) ¿pueden los nodos verse como peers?, y (2) ¿puedes pasar TCP a un puerto conocido abierto (SSH, HTTPS, o un listener temporal con netcat)?

Broma #1: El ping es como un detector de humo—cuando está en silencio o estás a salvo, o la batería se murió hace meses y nadie te avisó.

Guion de diagnóstico rápido (compruébalo en este orden)

Cuando estás de guardia, no te dan puntos por creatividad. Te dan puntos por velocidad y certeza.
Aquí está el orden que encuentra el cuello de botella con menos idas y venidas.

1) Confirma membresía y autorización

• ¿El nodo está unido al ID de red correcto?
• ¿Está autorizado en el controlador?
• ¿Tiene una IP asignada por ZeroTier?

2) Confirma la interfaz local y las rutas

• ¿Existe la interfaz ZeroTier y tiene una IP?
• ¿La tabla de rutas envía tráfico a la interfaz ZeroTier, o al gateway por defecto equivocado debido a un solapamiento?

3) Confirma la calidad del camino a los peers (directo vs relay) y la alcanzabilidad UDP

• ¿Los peers aparecen como “DIRECT” o “RELAY”?
• ¿Está UDP 9993 bloqueado en salida/entrada?
• ¿Estás detrás de un NAT simétrico que mata el P2P?

4) Revisa firewalls del host y la política ICMP

• ¿El firewall del SO permite ICMP y los puertos TCP objetivo?
• ¿La política es distinta para perfiles “Público” vs “Privado” (Windows)?

5) Revisa MTU/fragmentación cuando paquetes pequeños funcionan y los grandes no

• ¿Puedes hacer ping con carga pequeña pero no con grande?
• ¿Ves PMTUD fallando por ICMP fragmentation-needed bloqueado?

6) Solo entonces: ponte creativo

• Bucles de bridging, configuración errónea de rutas gestionadas, enrutamiento basado en políticas, peculiaridades de namespaces de contenedores, moons, etc.

Tareas prácticas: comandos, salidas y decisiones

Las siguientes tareas son intencionalmente operativas. Cada una incluye un comando, una salida realista, lo que significa
y la siguiente decisión que debes tomar. Ejecuta estas en ambos extremos (origen y destino) a menos que la tarea sea explícitamente del lado del controlador.

Task 1: Verify ZeroTier service is running (Linux systemd)

cr0x@server:~$ systemctl status zerotier-one --no-pager
● zerotier-one.service - ZeroTier One
     Loaded: loaded (/lib/systemd/system/zerotier-one.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2025-12-27 09:11:42 UTC; 2h 13min ago
   Main PID: 1178 (zerotier-one)
      Tasks: 24 (limit: 19070)
     Memory: 38.6M
        CPU: 1min 22.413s
     CGroup: /system.slice/zerotier-one.service
             └─1178 /usr/sbin/zerotier-one

Significado: El demonio está vivo. Si está inactive/failed, nada más importa.

Decisión: Si no se está ejecutando, inícialo y revisa los logs antes de tocar rutas/firewalls.

Task 2: Confirm you joined the intended network ID

cr0x@server:~$ sudo zerotier-cli listnetworks
200 listnetworks <nwid> <name> <mac> <status> <type> <dev> <ZT assigned ips>
200 listnetworks a84ac5c10a1b2c3d corp-overlay 5e:33:aa:9d:01:10 OK PRIVATE zt7nn3p3kq 10.147.10.23/16

Significado: Estás unido, el estado es OK y tienes una IP de superposición asignada.

Decisión: Si el estado es ACCESS_DENIED o no hay IP asignada, arregla la autorización o la asignación de IP primero.

Task 3: Check node identity (useful for controller authorization)

cr0x@server:~$ sudo zerotier-cli info
200 info 9f3c1a2b3c 1.14.2 ONLINE

Significado: La ID del nodo es 9f3c1a2b3c. La usarás en el controlador para autorizar y para emparejar membresía.

Decisión: Si no está ONLINE, puedes tener problemas de alcanzabilidad UDP, DNS o desajuste de hora que causan problemas de confianza.

Task 4: List peers and see DIRECT vs RELAY

cr0x@server:~$ sudo zerotier-cli listpeers
200 listpeers <ztaddr> <path> <latency> <version> <role>
200 listpeers 62f865ae71 203.0.113.19/9993;2684 34 1.14.2 LEAF
200 listpeers 9d219039f7 198.51.100.8/9993;58421 41 1.14.2 LEAF
200 listpeers 35c192ce9b - 0 1.14.2 PLANET

Significado: Tienes rutas directas a peers (IP pública/puerto mostrados). Si ves RELAY o un guion para el path, espera problemas.

Decisión: Si hay relays y el rendimiento es crítico, depura NAT/UDP o añade una moon en un lugar alcanzable.

Task 5: Confirm the ZeroTier interface and IP address

cr0x@server:~$ ip -brief addr show | grep -E 'zt|zerotier'
zt7nn3p3kq         UP             10.147.10.23/16 fe80::5c33:aaff:fe9d:110/64

Significado: La interfaz existe, está activa y tiene la IP de superposición esperada.

Decisión: Si falta la interfaz/está abajo, el join probablemente falló o el servicio no se está ejecutando.

Task 6: Check routing table for overlap or wrong next hop

cr0x@server:~$ ip route show
default via 192.168.50.1 dev eth0
10.147.0.0/16 dev zt7nn3p3kq proto kernel scope link src 10.147.10.23
192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.20

Significado: La subred de la superposición se enruta a la interfaz ZeroTier. Bien.

Decisión: Si la subred de superposición se solapa con una local, verás rutas en conflicto. Arregla cambiando el rango de la superposición o usando rutas gestionadas con cuidado.

Task 7: Try TCP connectivity instead of ping (netcat)

cr0x@server:~$ nc -vz 10.147.10.50 22
Connection to 10.147.10.50 22 port [tcp/ssh] succeeded!

Significado: Incluso si el ping falla, TCP funciona. Esto suele indicar que ICMP está bloqueado, no que ZeroTier esté roto.

Decisión: Deja de perder tiempo con el ping. Arregla la política de firewall si realmente necesitas ICMP; de lo contrario, sigue con tu aplicación.

Task 8: Confirm ICMP is blocked locally (Linux firewall: nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    iifname "zt7nn3p3kq" tcp dport { 22, 443 } accept
  }
}

Significado: Política por defecto drop en input, y solo TCP 22/443 están permitidos en la interfaz ZeroTier. ICMP no está permitido.

Decisión: Añade una regla explícita para aceptar ICMP en la interfaz ZeroTier si el ping es necesario, o documenta “ping no funcionará” y sigue adelante.

Task 9: Check Windows Firewall profile mismatch (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetConnectionProfile | Format-Table Name,InterfaceAlias,NetworkCategory"
Name              InterfaceAlias           NetworkCategory
corp-wifi          Wi-Fi                    Public
ZeroTier One [a84ac5c10a1b2c3d]  ZeroTier One Virtual Port Private

Significado: La interfaz ZeroTier es “Private”, pero otras interfaces pueden ser “Public”. Las reglas pueden no aplicarse donde crees.

Decisión: Asegura que las reglas entrantes estén vinculadas a la interfaz ZeroTier o al perfil correcto; no asumas que “Private” significa “permitido”.

Task 10: Test MTU quickly (Linux ping with DF)

cr0x@server:~$ ping -c 2 -M do -s 1472 10.147.10.50
PING 10.147.10.50 (10.147.10.50) 1472(1500) bytes of data.
ping: local error: message too long, mtu=280
ping: local error: message too long, mtu=280

--- 10.147.10.50 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1015ms

Significado: La MTU del camino es mucho menor que 1500. Algo está encapsulando dentro de otra cosa (a menudo VPN sobre VPN, PPPoE, o PMTUD roto).

Decisión: Reduce el MTU de ZeroTier (o arregla el path subyacente) y vuelve a probar con tamaños menores hasta que funcione.

Task 11: Inspect ZeroTier local config and networks directory

cr0x@server:~$ sudo ls -al /var/lib/zerotier-one
total 64
drwxr-xr-x  5 root root  4096 Dec 27 09:11 .
drwxr-xr-x 38 root root  4096 Dec 27 09:11 ..
-rw-r--r--  1 root root    64 Dec 27 09:11 identity.public
-rw-------  1 root root   256 Dec 27 09:11 identity.secret
drwxr-xr-x  2 root root  4096 Dec 27 09:11 networks.d
-rw-r--r--  1 root root  1254 Dec 27 09:11 zerotier-one.port

Significado: La identidad existe; las configuraciones de membresía viven en networks.d.

Decisión: Si faltan archivos de identidad o permisos incorrectos, la identidad del nodo cambia o el demonio falla de formas extrañas. Arregla el sistema de archivos/permisos antes de la red.

Task 12: Validate that UDP 9993 is reachable from the host’s network

cr0x@server:~$ sudo ss -uapn | grep 9993
UNCONN 0      0          0.0.0.0:9993      0.0.0.0:*    users:(("zerotier-one",pid=1178,fd=25))
UNCONN 0      0             [::]:9993         [::]:*    users:(("zerotier-one",pid=1178,fd=26))

Significado: ZeroTier está escuchando en UDP 9993. Eso es necesario pero no suficiente.

Decisión: Si no está escuchando, revisa la configuración o que el demonio esté ligado correctamente. Si lo está y aún así los peers reléan, sospecha del firewall/NAT ascendente.

Task 13: Quick packet capture on the ZeroTier interface

cr0x@server:~$ sudo tcpdump -ni zt7nn3p3kq icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on zt7nn3p3kq, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:45:11.203812 IP 10.147.10.23 > 10.147.10.50: ICMP echo request, id 1789, seq 1, length 64
10:45:12.210914 IP 10.147.10.23 > 10.147.10.50: ICMP echo request, id 1789, seq 2, length 64

Significado: Las requests salen. Si no ves respuestas, el problema está aguas abajo: firewall del host destino, ruta de retorno o pérdida de paquetes.

Decisión: Ejecuta tcpdump también en el destino. Si el destino nunca ve las requests, tienes un problema de enrutamiento/camino ZeroTier. Si las ve y no responde, es política del host.

Task 14: Check reverse path and policy routing traps

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.zt7nn3p3kq.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.zt7nn3p3kq.rp_filter = 1

Significado: El filtrado de ruta inversa estricto está habilitado. En hosts multihomed, puede descartar tráfico válido si Linux piensa que la ruta de retorno es “incorrecta”.

Decisión: Si enrutas entre interfaces o usas policy routing, considera poner rp_filter en loose (2) en las interfaces relevantes.

Task 15: Verify IP forwarding if this node is meant to route traffic

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Significado: Este host no enruta paquetes entre interfaces.

Decisión: Si esta máquina es tu gateway ZeroTier para una ruta sitio-a-sitio, habilita el forwarding y añade reglas de firewall para forwarding/NAT según sea necesario.

Task 16: Check for subnet overlap that steals traffic (classic “can’t ping”)

cr0x@server:~$ ip route get 10.147.10.50
10.147.10.50 dev zt7nn3p3kq src 10.147.10.23 uid 1000
    cache

Significado: El kernel enviará tráfico por la interfaz ZeroTier. Si en su lugar eligiera eth0, tienes solapamiento o una ruta más específica.

Decisión: Arregla el plan de direcciones o la prioridad de enrutamiento. No “soluciones” el solapamiento con parches si no disfrutas incidentes recurrentes.

Profundización en el problema “no se puede hacer ping”: dónde mueren los paquetes

Zona de fallo 1: Realmente no estás autorizado (o te uniste a la red equivocada)

El controlador es el portero. Si no te sellaron, no entras.
Un nodo puede aparecer en la lista de miembros pero permanecer no autorizado. Dependiendo de la UI/política del controlador, aún podrías ver indicadores de “conectado”
que te llevan a una falsa confianza.

Regla operativa: trata “tiene una IP ZeroTier y puede intercambiar paquetes” como la definición real de membresía, no “lo veo en la UI web”.

Zona de fallo 2: ICMP está bloqueado y persigues el problema equivocado

El ping es ICMP echo. Muchos entornos bloquean ICMP entrante por defecto, especialmente hosts Windows y servidores Linux endurecidos.
Si SSH funciona y ping no, eso no es “ZeroTier no puede hacer ping”. Eso es “ICMP está bloqueado”.

Si tu monitorización usa ping, o bien permítelo explícitamente en la interfaz ZeroTier o cambia la monitorización a comprobaciones TCP.
Las comprobaciones TCP suelen estar más cerca de lo que te importa: la aplicación.

Zona de fallo 3: Asimetría de rutas y “el tráfico de retorno va a otro sitio”

Las redes de superposición siguen dependiendo de decisiones de enrutamiento. Si el host A envía paquetes al host B por ZeroTier,
el host B debe enviar respuestas de vuelta por ZeroTier (o al menos de vuelta a A de forma coherente).
Si el host B cree que A está en otra interfaz debido a solapamiento o policy routing, las respuestas se pierden.

Esto aparece como: en A tcpdump muestra solicitudes saliendo, en B tcpdump las muestra llegando,
pero B nunca responde (o responde por la interfaz equivocada). El filtrado de ruta inversa también puede descartar esas respuestas.

Zona de fallo 4: Solapamiento de subredes con redes domésticas/oficina

El solapamiento es un asesino silencioso porque es intermitente. Tu oficina puede usar 10.0.0.0/8 ampliamente,
tu superposición usa 10.0.0.0/24 porque “es privada”, y la red local de un usuario remoto resulta coincidir.
Algunas máquinas funcionan, otras no, y empiezas a culpar a ZeroTier como si estuviera embrujado.

Arregla el solapamiento eligiendo un rango dedicado y manteniéndolo. Si ya desplegaste con solapamiento,
migra deliberadamente y en una dirección. Las rutas superpuestas “temporales” son la forma en que acabas con un caos permanente.

Zona de fallo 5: Traversía de NAT vs relays (DIRECT importa)

Cuando la traversía de NAT tiene éxito, los peers hablan directamente. Cuando falla, pueden relatar a través de infraestructura.
Los relays van bien para tráfico de administración; pueden ser brutales para transferencias a granel, bases de datos y cualquier cosa con timeouts estrictos.
A veces el ping funciona pero tu app agota por latency/jitter del relay.

A menudo puedes mejorar la conectividad directa permitiendo UDP saliente, asegurando que no haya middleboxes que manipulen UDP,
o colocando una moon en una ubicación que ambos lados puedan alcanzar.

Zona de fallo 6: MTU y agujeros negros de PMTUD

Verás esto cuando “las cosas pequeñas funcionan, las grandes fallan”. Tal vez el ping funcione con tamaño por defecto pero falle con cargas grandes,
o SSH se conecta pero las transferencias de archivos se quedan colgadas, o los handshakes TLS se paran misteriosamente.

La encapsulación de la superposición añade overhead. Si el camino subyacente tiene una MTU reducida (PPPoE, redes móviles, túneles anidados),
puedes excederla. PMTUD adecuado requiere mensajes ICMP “fragmentation needed”; muchas redes los bloquean, creando un agujero negro.

Zona de fallo 7: Bridging y tormentas de broadcast (o simplemente redes ruidosas)

El bridging puede hacer que “no se puede hacer ping” parezca “a veces ping, a veces no” porque has introducido ruido L2.
Broadcast y multicast pueden saturar el tráfico útil, especialmente en enlaces limitados.
La solución suele ser dejar de hacer bridging y enrutar en su lugar.

Una cita sobre fiabilidad, porque encaja

“La esperanza no es una estrategia.” — General Gordon R. Sullivan

En términos operativos: deja de esperar que el ping empiece a funcionar y comienza a recopilar evidencia por capas.

Broma #2: El NAT es el gerente intermedio corporativo de las redes: añade reuniones, pierde mensajes y aún así se adjudica el mérito cuando las cosas funcionan.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó ZeroTier para conectar un puñado de estaciones administrativas a un conjunto de servidores de prueba en un laboratorio.
Un desarrollador dijo: “Cuando dice ONLINE, podemos hacer ping a todo.” Esa suposición pasó directo al runbook.
La monitorización se basó en ping, porque era fácil y parecía que hacía networking.

El primer fin de semana, un jump host Windows se parcheó y reinició. Volvió a aparecer ONLINE en el controlador.
Las comprobaciones de ping fallaron. Saltaron las alertas. El on-call pasó una hora persiguiendo peers ZeroTier y la traversía NAT.
Finalmente alguien probó nc al puerto 3389 y funcionó. RDP funcionó. Solo fallaba el ping.

Causa raíz: el Firewall de Windows había vuelto a una política de ICMP entrante más estricta en el adaptador ZeroTier después de un cambio de perfil.
El sistema de monitorización interpretó “no ICMP” como “host caído”, y el informe de incidente culpó a la superposición.
La overlay era inocente; la suposición era culpable.

La solución fue aburrida y efectiva: cambiar la monitorización a comprobaciones TCP para el servicio real (RDP/SSH/HTTPS),
y permitir explícitamente ICMP solo donde importaba. El runbook se actualizó con “ONLINE no es alcanzabilidad”.
Esa sola frase salvó varios sábados futuros.

Mini-historia 2: La optimización que salió mal

Otra organización quería “mejor rendimiento” a través de ZeroTier, así que decidieron puentear dos LANs de oficina
dentro de la superposición. La razón sonaba bien: “Si es una gran LAN, los protocolos de descubrimiento funcionarán y las apps no necesitarán cambios.”
Habilitaron bridging en un par de gateways Linux y declararon victoria tras unos pocos pings exitosos.

El lunes por la tarde llegaron las quejas: las videollamadas tartamudeaban, los compartidos de archivos se pausaban y dispositivos aleatorios en un sitio
empezaron a mostrar advertencias de IP duplicadas. Soporte culpó al ISP. El equipo de red culpó al Wi‑Fi.
El SRE en guardia hizo lo poco elegante: capturó tráfico en la interfaz ZeroTier y contó tramas broadcast.

Resultó que habían extendido efectivamente dominios de broadcast sobre una superposición de internet con latencia y jitter variables,
y estaban transportando mucho tráfico L2 ruidoso (incluyendo cosas que nunca debían salir del edificio). Algunos dispositivos no toleraron la nueva topología “LAN”.
El comportamiento ARP se volvió extraño. Los broadcasts DHCP se convirtieron en una pesadilla.

El rollback fue inmediato. Reemplazaron el bridging por enrutamiento, añadieron un par de rutas gestionadas para subredes necesarias,
y usaron configuración a nivel de aplicación para descubrimiento cuando fue posible.
El rendimiento mejoró, porque dejaron de intentar que Internet se comporte como un switch.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa regulada ejecutaba ZeroTier para una pequeña flota interna de agentes de compilación repartidos entre varios proveedores.
Trataron la superposición como red de producción: plan de direcciones consistente, rutas gestionadas documentadas,
y una línea base de firewall en host que permitía explícitamente los puertos requeridos en la interfaz ZeroTier.
Sin heroicidades, sin “lo recordaremos después”.

Un día, un proveedor cloud cambió algo en su camino de red y un subconjunto de nodos empezó a relatar.
La latencia aumentó; algunos jobs de build comenzaron a agotarse al subir artefactos. Nadie entró en pánico.
El on-call usó la misma lista de verificación cada vez: peers (DIRECT vs RELAY), tablas de rutas, luego pruebas MTU.

Encontraron problemas de PMTUD en la ruta de un proveedor. Porque su baseline incluía una prueba de validación MTU y una perilla documentada
para reducir MTU en nodos afectados, desplegaron temporalmente una MTU menor para los nodos de ese proveedor mientras escalaban con el proveedor.
Las builds se estabilizaron en una hora. No fue necesaria una llamada de incidente.

La lección: valores por defecto aburridos y comprobaciones repetibles son una característica de rendimiento. Reducen el tiempo para llegar a la verdad.
En producción, eso es lo que realmente quieres.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “El nodo está ONLINE pero no tiene IP ZeroTier”

Causa raíz: Miembro no autorizado, auto-asignación de IP deshabilitada, o el nodo se unió al ID de red equivocado.

Solución: Autoriza al miembro y asegúrate de que la red tenga un pool de asignación IPv4/IPv6. Revisa zerotier-cli listnetworks.

2) Síntoma: “Ping falla, SSH funciona”

Causa raíz: ICMP bloqueado por el firewall del host o política del SO.

Solución: Permite ICMP en la interfaz/perfil ZeroTier, o deja de usar ping como comprobación primaria de alcanzabilidad.

3) Síntoma: “Puedo hacer ping por IP ZeroTier, pero no puedo alcanzar la subred LAN remota”

Causa raíz: Falta ruta gestionada, falta IP forwarding, o faltan reglas de NAT/forward en el gateway.

Solución: Añade rutas gestionadas en el controlador; habilita net.ipv4.ip_forward=1; añade reglas de forward (y NAT si es necesario).

4) Síntoma: “Algunos usuarios pueden hacer ping, otros no (especialmente desde casa)”

Causa raíz: Solapamiento de subred con routers domésticos, o DNS dividido que envía tráfico por la ruta equivocada.

Solución: Cambia la subred de la superposición a un rango de baja colisión; evita rangos RFC1918 comunes; verifica con ip route get.

5) Síntoma: “Pérdida intermitente de paquetes, rendimiento con jitter, peers ‘RELAY’”

Causa raíz: Falla en la traversía NAT o UDP bloqueado; el tráfico se relaya.

Solución: Permite UDP saliente; evita redes de salida restrictivas; considera una moon en un entorno alcanzable; revisa listpeers.

6) Síntoma: “Peticiones pequeñas funcionan; transferencias grandes se cuelgan”

Causa raíz: MTU/PMTUD agujero negro; ICMP fragmentation-needed bloqueado en algún punto.

Solución: Baja la MTU en la interfaz de superposición y/o arregla el manejo de ICMP ascendente; valida con ping -M do.

7) Síntoma: “Después de habilitar bridging, todo se puso raro y lento”

Causa raíz: Amplificación de broadcast/multicast a través de la superposición; extensión L2 accidental.

Solución: Deja de hacer bridging; enruta en su lugar; restringe tráfico y subredes permitidas; confirma que realmente necesitas L2.

8) Síntoma: “Funciona hasta que ejecutamos contenedores”

Causa raíz: Namespaces de red de contenedores y reglas de firewall no incluyen la interfaz ZeroTier; enrutamiento asimétrico vía docker0.

Solución: Decide si los contenedores deben vincularse a la IP ZeroTier del host, o ejecuta un conjunto de reglas de enrutamiento/NAT dedicado para las subredes de contenedores.

Listas de verificación / plan paso a paso

Checklist A: Despliegue de nueva red ZeroTier (organización pequeña)

1. Elige una subred de superposición que no se solape con rangos de oficina/casa (evita 192.168.0.0/16 y 10.0.0.0/24 comunes).
2. Decide enrutamiento vs bridging. Por defecto, enruta.
3. Une 2–3 nodos piloto y autorízalos.
4. Verifica que zerotier-cli listnetworks muestre OK y IPs asignadas.
5. Verifica que zerotier-cli listpeers muestre rutas directas cuando sea posible.
6. Define política de firewall en host: permite solo los puertos necesarios en la interfaz ZeroTier.
7. Elige una prueba de conectividad real: TCP al puerto del servicio, y ping solo si permites ICMP explícitamente.
8. Documenta rutas gestionadas y responsables (quién añade rutas, quién aprueba).
9. Ejecuta validación MTU y registra el tamaño de payload que funciona como línea base.

Checklist B: Conectividad sitio-a-sitio (enrutar subred remota dentro de ZeroTier)

1. Elige un nodo gateway en el sitio remoto con uptime estable y propiedad conocida del firewall.
2. Habilita IP forwarding en el gateway (net.ipv4.ip_forward=1).
3. Añade una ruta gestionada para la subred remota apuntando a la IP ZeroTier del gateway.
4. Asegura que la subred remota tenga una ruta de retorno a la superposición (ya sea vía el gateway o NAT).
5. Valida con un enfoque tipo traceroute: host → IP ZeroTier del gateway → IP LAN remota.
6. Cierra las reglas de forwarding para que la superposición solo alcance lo que debe.

Checklist C: Respuesta a incidente “No se puede hacer ping”

1. Confirma join de red + autorización (Task 2).
2. Confirma interfaz arriba + IP de superposición (Task 5).
3. Revisa selección de rutas (Task 6 y Task 16).
4. Revisa path de peers (Task 4).
5. Intenta TCP a un puerto conocido (Task 7).
6. Revisa reglas de firewall del host (Task 8 / comprobaciones de perfiles en Windows).
7. Captura en ambos extremos (Task 13) para ver si las requests llegan y las respuestas salen.
8. Si los síntomas lo sugieren: prueba MTU (Task 10).
9. Sólo entonces escala a moons/bridging/cambios de policy routing.

Preguntas frecuentes (FAQ)

1) ¿Por qué ZeroTier muestra “ONLINE” pero no puedo hacer ping?

“ONLINE” no garantiza la alcanzabilidad por ICMP. Causas comunes: miembro no autorizado, ICMP bloqueado por firewall del host,
solapamiento de subredes, o enrutamiento asimétrico. Usa pruebas TCP y captura de paquetes para demostrar dónde se detienen los paquetes.

2) ¿Es necesario el ping para probar que ZeroTier funciona?

No. Ping prueba ICMP echo; muchos sistemas lo bloquean. Una mejor prueba de “funciona” es TCP a un puerto abierto conocido,
o una comprobación a nivel de aplicación. Permite ICMP solo si tienes una necesidad operativa explícita.

3) ¿Qué significa DIRECT vs RELAY en listpeers?

DIRECT significa que los peers encontraron un camino peer-to-peer (normalmente mejor latencia y rendimiento). RELAY significa que el tráfico pasa por un relay
debido a fallo en la traversía NAT o UDP bloqueado. RELAY es aceptable para acceso administrativo, menos para tráfico pesado.

4) ¿Qué subred debo usar para mi red ZeroTier?

Usa una subred que no se solape con redes reales en las que estarán tus usuarios. Evita rangos domésticos/SMB comunes.
Elige algo poco común dentro de 10/8, o usa IPv6. La consistencia vence a la creatividad.

5) ¿Cómo funcionan las rutas gestionadas?

Las rutas gestionadas indican a los miembros ZeroTier: “para alcanzar esta subred, envía tráfico a ese miembro como gateway.”
No habilitan el forwarding mágicamente; tu gateway debe tener IP forwarding activado y reglas de firewall para reenviar tráfico.

6) ¿Necesito una moon?

No siempre. Una moon puede ayudar cuando muchos nodos están detrás de NAT restrictivo o cuando quieres una alcanzabilidad más predecible.
Si la mayoría de peers están en RELAY y el rendimiento importa, una moon en un entorno alcanzable vale la pena considerar.

7) ¿Por qué SSH conecta pero la transferencia de archivos se cuelga?

Ese patrón suele indicar MTU/PMTUD. SSH puede establecer sesión con paquetes pequeños, luego colgar cuando paquetes mayores o
distintos segmentos TCP encuentran el agujero negro MTU. Prueba con ping -M do y reduce MTU si es necesario.

8) ¿Puedo puentear mi LAN dentro de ZeroTier?

Puedes, pero probablemente no deberías. El bridging extiende dominios de broadcast y puede causar tráfico ruidoso,
comportamiento ARP/DHCP extraño y problemas de rendimiento. Enruta salvo que tengas un requisito L2 que puedas defender en un postmortem.

9) ¿Por qué no puedo alcanzar un dispositivo en la LAN remota desde un cliente ZeroTier?

Usualmente falta la ruta de retorno. Añadiste una ruta gestionada, pero el dispositivo de la LAN remota no sabe cómo responder a la subred de la superposición.
Arregla con una ruta de retorno en el router LAN, o NAT en el gateway (con los ojos abiertos sobre auditabilidad y depuración).

10) ¿Es siempre necesario UDP 9993?

El comportamiento habitual de ZeroTier depende de UDP. Si UDP está bloqueado, puedes ver conectividad degradada o ninguna conectividad.
A veces puedes funcionar a duras penas vía relays, pero si estás en una red que bloquea UDP en salida ampliamente, espera problemas.

Siguientes pasos que puedes hacer hoy

1. Deja de tratar al ping como oráculo. Decide qué significa “arriba” para tu servicio y pruébalo.
2. Estandariza tu plan de direcciones de superposición. Si ya te solapaste, programa una migración antes de que ella te la programe a ti.
3. Registra la salud de los peers. Anota cuántos peers están DIRECT vs RELAY en operación normal.
4. Escribe tu orden de “Diagnóstico rápido”. Ponla en el runbook de guardia, no en la cabeza de alguien.
5. Haz explícita la política de firewall. Permite lo que necesitas en la interfaz ZeroTier; niega el resto; documenta la intención.
6. Añade una prueba MTU a tu caja de herramientas. La mayoría de equipos descubre problemas MTU solo después de perder un día. Sé mejor que eso.

Si haces esas seis cosas, “no se puede hacer ping” pasa a ser un problema de clasificación de dos minutos en lugar de una espiral de culpas de tres horas.
Esa es la diferencia entre una red de superposición ordenada y un hobby caro.