Elige tu propia IP

Artículo original ↗ Discusión en Hacker News ↗

La nueva función de Tailscale “elige tu propia IP”, que permite a las tailnets usar rangos de direcciones personalizados en lugar de un único pool global, es recibida como una solución práctica para conflictos con el NAT de grado de operador y con redes privadas superpuestas. Los comentaristas comparan la UX y las capacidades de Tailscale (traversal automático de NAT, SSO/ACLs, conectividad mesh) con WireGuard y OpenVPN en bruto, debatiendo cuándo su plano de control gestionado compensa la dependencia frente a alternativas autoalojadas como headscale. El hilo también deja ver tensiones más amplias sobre el agotamiento de IPv4, la adopción lenta y desordenada de IPv6, el impacto del NAT en la conectividad extremo a extremo y si las redes superpuestas comerciales tienen incentivo para mantener el statu quo.

Reacción a “Elige tu propia IP”

  • Muchos celebran la función; resuelve conflictos con CGNAT/rangos privados que se superponen con la LAN local y con servicios que insisten en vincularse a IPs específicas en lugar de interfaces.
  • Algunos están entusiasmados por alinear las IPs de la Tailnet con sus esquemas domésticos (p. ej., 10.3.x → 100.103.x).
  • Se planteó la pregunta de por qué se usa CGNAT (100.64/10) en lugar de 10/8; la respuesta: 10/8 se usa comúnmente en las LAN y colisionaría aún más.

Tailscale vs WireGuard/OpenVPN

  • Tema recurrente: Tailscale = WireGuard + automatización + identidad + políticas + traversal de NAT + mesh.
  • Ventajas citadas:
    • Integración con SSO/OIDC y fácil incorporación.
    • ACL integradas en lugar de iptables por host.
    • Traversal de NAT con fallback a DERP, útil para CGNAT y configuraciones de “road-warrior”.
    • Conectividad estilo mesh frente a la configuración manual hub-and-spoke.
  • Críticas: mayor consumo de batería en iOS frente a WireGuard puro; algunos prefieren el WireGuard “minimalista” autogestionado para casos simples.

Debates sobre NAT, IPv4 e IPv6

  • Bromas y quejas sobre que NAT es a la vez causa y solución de los problemas de red.
  • Fuerte desacuerdo sobre NAT frente a IPv6:
    • Algunos defienden NAT y desconfían de IPv6 (privacidad, exposición, comportamiento del ISP).
    • Otros sostienen que NAT rompe el extremo a extremo, impulsa la centralización, y que IPv6 puede rotar direcciones y evitar el rastreo.
  • Tailscale ya da a cada nodo una dirección IPv6 interna, pero el soporte IPv4 sigue siendo necesario porque muchas apps/SO siguen centrados en IPv4.
  • Frustración porque las soluciones nuevas siguen apoyándose mucho en IPv4 en lugar de impulsar diseños IPv6-first, aunque se cita el pobre despliegue de IPv6 por parte de los ISP como una limitación difícil.

CGNAT, Starlink y uso en el mundo real

  • Varios ejemplos donde Tailscale “simplemente funcionó” en entornos complicados (Starlink, granjas rurales, ISP solo CGNAT), mientras que WireGuard en bruto era difícil de configurar correctamente.
  • Discusión sobre los límites del traversal del firewall; cuando el NAT simétrico rompe UDP, los enlaces hacen fallback a DERP sobre TCP 443, que es más lento. tailscale status puede mostrar si un enlace está usando DERP.

Confianza, autoalojamiento e identidad

  • A algunos les incomoda depender de un plano de control alojado o de identidad de terceros (Google/Microsoft/Apple).
  • Alternativas discutidas:
    • Headscale (servidor de control de código abierto) para autoalojar; elogiado como red de seguridad contra el bloqueo.
    • OIDC personalizado mediante IdP autoalojados (Keycloak, Authelia, Dex, Casdoor).
  • Se expresó el deseo de flujos sencillos de usuario/contraseña o solo passkey, sin identidad de las grandes tecnológicas.

Meta: rol de la empresa e incentivos

  • Gran admiración por la UX, la documentación y el devrel de Tailscale; algunos sienten que HN los sobrevalora por su buen marketing para desarrolladores.
  • Se planteó la preocupación de que las empresas que resuelven funciones “faltantes” de Internet (como la conectividad segura extremo a extremo) pueden estar estructuralmente desincentivadas a impulsar correcciones más amplias a nivel de protocolo que volverían obsoletos sus productos.