Perforar NAT en la práctica: la coreografía, el porcentaje y el plan B

Hay una asimetría en el corazón de internet que ninguna biblioteca puede derogar: casi cualquier máquina puede iniciar una conexión hacia una máquina pública, y casi ninguna máquina pública puede iniciar una conexión hacia una máquina doméstica. La documentación de libp2p lo formula dividiendo los nodos en públicos y no públicos, y observando que la mayoría de los nodos de casa, de oficina y todos los móviles caen del lado no público. Perforar es el conjunto de trucos que convierte esa asimetría en una simetría temporal, y funciona por una razón sorprendentemente frágil: el router de cada lado guarda una entrada en su tabla de estado cuando sale un paquete, y si el paquete del otro extremo llega mientras esa entrada sigue viva, lo deja pasar creyendo que es una respuesta. Todo lo demás —sondeos, reservas, sincronización de relojes— existe para conseguir que esos dos paquetes salgan al mismo tiempo. Y todo lo demás falla lo bastante a menudo como para que el plan de reserva no sea una nota al pie.

El router dice que no, y tiene sus razones

Un router doméstico funciona como una puerta de un solo sentido: lo de dentro sale, lo de fuera no entra salvo que parezca respuesta a algo que salió. La documentación de libp2p describe el mecanismo con precisión: cuando un paquete atraviesa el router, este añade una quíntupla a su tabla de estado —dirección de origen, puerto de origen, dirección de destino, puerto de destino y protocolo de transporte—. Cualquier paquete entrante que coincida con una quíntupla registrada se entrega al equipo interno. Cualquier otro se descarta sin ceremonia.

Las soluciones clásicas atacan el problema desde fuera de la aplicación y las dos envejecen mal. El protocolo de configuración automática entre equipos y router permite pedir la apertura de un puerto, pero la propia documentación advierte de que en muchos escenarios está desactivado por el router o el cortafuegos, y de que puede no funcionar según el firmware. Abrir un puerto a mano funciona siempre y exige conocimientos técnicos que ningún producto de consumo puede presuponer, además de no llevar consigo ninguna autenticación ni autorización.

Queda entonces el retransmisor puro: el nodo A mantiene una conexión permanente con un nodo relevo R, y cuando B quiere hablar con A se conecta a R, que reenvía todos los paquetes de la conversación. Funciona siempre y por eso es la red de seguridad, pero la documentación es franca sobre su precio: añade latencia y consume recursos, porque R tiene que manejar todo el tráfico de todos. La pregunta que da origen a la perforación está escrita casi con esas palabras en el manual: ¿y si usáramos R para facilitar una conexión directa entre A y B en lugar de para transportarla?

La coreografía completa: sondear, reservar, sincronizar

libp2p se inspira declaradamente en el protocolo de establecimiento interactivo de conectividad, pero con una diferencia que define su carácter: perfora sin servidores centrales de coordinación, sin la infraestructura clásica de sondeo y retransmisión. El procedimiento se divide en dos fases, y la primera ocurre mucho antes de que exista intención de hablar con nadie en concreto.

En la fase de preparación, el nodo empieza por averiguar si acaso necesita perforar. El protocolo de autodiagnóstico de alcanzabilidad —equivalente funcional del sondeo clásico— consiste en que el nodo pide a otros pares que intenten marcarle en las direcciones que sospecha que son suyas, direcciones que ha aprendido sobre todo mediante identify, y esos pares le informan del resultado. Con esos informes el nodo se hace una idea de si es marcable desde fuera. Si no lo es, descubre relevos de forma dinámica; en la red de ficheros distribuidos que le dio origen, esto se hace consultando en la tabla de Kademlia los relevos públicos más cercanos a su propio identificador. Con cada relevo descubierto negocia una reserva: le pide que escuche conexiones en su nombre, y si el relevo acepta, el nodo puede anunciarse como alcanzable a través de él.

La fase de perforación empieza cuando A quiere hablar con B y solo dispone de la dirección anunciada a través del relevo. A conecta directamente con el relevo, le pide un canal hacia B, el relevo reenvía la petición, B la acepta, y ambos extremos quedan unidos por un canal bidireccional que acto seguido se protege con TLS. Sobre ese canal ya seguro corre el protocolo de promoción a conexión directa, que es donde ocurre la sincronización fina.

sequenceDiagram
participant A
participant R as relevo
participant B
A->>R: conectar y pedir canal hacia B
R->>B: reenviar la solicitud de canal
B->>R: aceptar
R->>A: canal establecido y protegido con TLS
A->>B: mensaje de conexion con mis direcciones directas
B->>A: mensaje de conexion con sus direcciones directas
Note over A: mide el tiempo de ida y vuelta a traves del relevo
A->>B: mensaje de sincronizacion
Note over A: espera la mitad del tiempo medido
A->>B: marcado directo
B->>A: marcado directo al recibir la sincronizacion
Note over A,B: los dos paquetes se cruzan y perforan a la vez

Ese cálculo de la mitad del tiempo de ida y vuelta es la pieza más bonita del protocolo y la más fácil de pasar por alto. A no puede decirle a B marca ahora, porque el mensaje tarda en llegar. Lo que hace es medir cuánto tarda un viaje completo a través del relevo, enviar la señal de sincronización y esperar exactamente la mitad de ese tiempo antes de marcar. B marca en cuanto recibe la señal. Si la medida fue buena, los dos marcados salen prácticamente a la vez y cada paquete encuentra al llegar la quíntupla que el otro acaba de crear. Toda la perforación se juega en esa estimación.

Por qué falla, y a quién le falla

Conviene dar cifras y darlas con su origen, porque el género abunda en optimismo. En libp2p, la tasa de éxito de la perforación ronda el setenta por ciento en condiciones reales. La documentación de iroh, para su propia implementación sobre QUIC, sitúa la cifra más arriba: en torno a nueve de cada diez configuraciones de red permiten establecer una conexión directa. Ambas cifras dicen lo mismo con distinta severidad: la perforación funciona en la mayoría de los casos y falla en una minoría que no es despreciable en absoluto.

La documentación de iroh añade dos observaciones que valen más que la cifra. La primera es dónde falla: en algunos cortafuegos corporativos y en redes de telefonía móvil. La segunda es una propiedad del comportamiento que cambia por completo cómo se depura esto: su implementación es determinista, de modo que si la perforación funciona una vez entre dos dispositivos, seguirá funcionando mientras su configuración de red no cambie. Es decir, el fallo no es aleatorio; es estructural, y por tanto reproducible.

// Los dos comportamientos que hacen falta viven juntos y no se pueden separar
#[derive(NetworkBehaviour)]
struct Conectividad {
    identify: identify::Behaviour,   // aprender que direcciones tengo
    autonat: autonat::Behaviour,     // averiguar si soy marcable
    relay: relay::client::Behaviour, // reservar plaza en un relevo
    dcutr: dcutr::Behaviour,         // promocionar a conexion directa
}

Merece la pena entender por qué se resiste ese diez o treinta por ciento restante. La perforación asume que el router asigna a una misma conexión saliente un puerto externo predecible. Cuando la traducción de direcciones asigna un puerto distinto por cada destino, la dirección que el relevo observó no sirve para que el otro extremo entre, porque el router creará una quíntupla diferente. A eso se suman las traducciones a nivel de operador, donde miles de abonados comparten dirección pública y el equipo del operador aplica políticas que el usuario no controla, y los cortafuegos corporativos que sencillamente descartan el tráfico no solicitado por política.

El plan de reserva forma parte del diseño

De todo lo anterior se deduce una regla que conviene escribir en el documento de arquitectura antes que ninguna otra: el relevo no es el modo degradado, es un modo de operación normal para una fracción conocida de tus usuarios. Si la perforación acierta en el setenta por ciento de los casos, tres de cada diez conversaciones de tu producto irán por relevo de forma permanente, no transitoria. Diseñar como si eso fuera una excepción produce sistemas que funcionan de maravilla en la mesa del equipo y son inservibles en una oficina con cortafuegos.