Kademlia e I2P. Redes sin servidor Central

Hoy vamos a intentar explicar qué aporta Kademlia al mapa de Internet.

La primera analogía sencilla es imaginar una clase de estudiantes, hay una diferencia entre una lista que pueda tener un única personsa (como el delegado de clase) y un trabajo en equipo donde todos guardan un pedazo de información.

Para ponerlo en contexto, hay que pensar en la diferencia entre el modelo tradicional cliente-servidor y el modelo descentralizado que permite Kademlia.

1. Redes Descentralizadas: Eliminar al "jefe de fila"

• La analogía: En el modelo tradicional (como YouTube o Google), hay un servidor gigante que es el "profesor" con la lista de datos. Si el servidor se cae o apaga la luz, nadie aprende nada.
• Qué aporta Kademlia: Kademlia organiza a miles de ordenadores (nodos) para que colaboren entre sí sin necesidad de un servidor central. Cada ordenador guarda solo una pequeña parte del "índice" de contenidos. Si diez ordenadores se desconectan para cenar, la red sigue funcionando exactamente igual porque la información está duplicada en otros nodos cercanos.

2. Resistencia a la Censura: Imposible de apagar de un plumazo

• La analogía: Si un gobierno o una empresa quiere bloquear una página web tradicional, solo tiene que ir a la puerta del servidor central y ponerle un candado.
• Qué aporta Kademlia: Al no haber un servidor central ni una "lista maestra" en un solo sitio, no hay una puerta que cerrar. Para tumbar un contenido en Kademlia habría que apagar uno a uno los miles de ordenadores repartidos por todo el mundo que están compartiendo ese índice. Por eso redes como BitTorrent o IPFS usan Kademlia para que nadie pueda borrar información unilateralmente.

3. Privacidad: Nadie tiene la foto completa de lo que haces

• La analogía: Si le pides un libro al bibliotecario del instituto, él sabe perfectamente quién eres y qué has leído. Pero si le preguntas a un compañero, este le pregunta a otro, y este a otro... al final la petición se diluye.
• Qué aporta Kademlia: En lugar de enviar tus búsquedas a una empresa que guarda tu historial con tu nombre y apellidos, en Kademlia pides información mediante pequeños "saltos" entre ordenadores anónimos. Ningún nodo intermedio sabe con certeza si tú eres el que realmente quiere ver ese archivo o si simplemente estás ayudando a reenviar la pregunta de otra persona.

4. Anonimato: Un buen escudo, pero no mágico

• La analogía: Usar un seudónimo para enviar "notitas" evita que el profesor sepa de quién es a simple vista, pero la caligrafía o el papel pueden dar pistas si alguien investiga a fondo.
• Qué aporta Kademlia: Dentro de la red no te identificas con tu nombre ni con tu correo, sino con un número gigante de 160 bits (tu Node ID). Esto da un nivel alto de pseudonimato.
• La nota del profe (¡ojo en el examen!): Kademlia por sí solo no es 100% anónimo. Como dos ordenadores necesitan saber sus direcciones IP reales para enviarse datos, un observador con bastantes recursos podría rastrearte. Por eso, proyectos que buscan anonimato absoluto (como la red I2P) cogen la idea de Kademlia y le añaden capas extra de cifrado pesado por encima.

Un resumen de Conceptos

La red I2P adapta Kademlia con cifrado "garlic" para lograr anonimato real

Cifrado Garlic ó ajo y cifrado Onion ó cebolla... ¿En serio?

El cifrado Garlic (o enrutamiento de ajo) es unatécnica de seguridad y anonimato en redes informáticas que agrupa varios mensajes cifrados individuales dentro de un solo paquete de datos grande, emulando la estructura de una cabeza de ajo donde cada mensaje es un "diente" (clove).
Es una evolución directa del enrutamiento cebolla (Onion Routing) utilizado por la red Tor, y es el pilar fundamental de la red I2P (Invisible Internet Project).

¿Cómo funciona?

1. Agrupación en "Dientes": En lugar de enviar un único mensaje en cada circuito (como hace Tor), el remitente toma varios mensajes, cada uno con sus propias instrucciones de entrega finales.
2. Cifrado por Capas: Cada uno de estos mensajes ("dientes") se cifra de forma independiente utilizando la clave pública del nodo de destino final.
3. El "Bulbo" de Ajo: Todos los mensajes cifrados se empaquetan juntos dentro de un contenedor global, el cual se vuelve a cifrar en su totalidad.
4. Desmantelamiento en Ruta: A medida que este paquete viaja por la red a través de túneles unidireccionales, los nodos intermediarios solo pueden descifrar la capa necesaria para saber a dónde enviar el paquete a continuación, pero no pueden ver cuántos mensajes hay dentro, qué dicen ni hacia dónde van sus componentes individuales. Al llegar al punto final, el "ajo" se abre y cada diente sale hacia su destino real.

Diferencias principales: Garlic vs. Onion

¿Por qué ofrece mayor seguridad?
Este cifrado está diseñado específicamente para combatir el análisis de tráfico.
Si un espía observa la red de Tor, podría adivinar quién habla con quién midiendo los tiempos en que entran y salen los paquetes de datos individuales.
En el cifrado Garlic, al ir muchos mensajes juntos y mezclados con instrucciones de confirmación o datos de relleno, resulta prácticamente imposible para un observador externo correlacionar qué ráfaga de datos pertenece a qué usuario.

La REd I2P

La red I2P (Invisible Internet Project) coge la estructura eficiente de Kademlia y la transforma por completo para garantizar anonimato bidireccional estricto.

Mientras que Kademlia tradicional mapea claves directamente a direcciones IP reales, I2P rediseña la DHT para que ningún nodo de la red sepa jamás quién habla con quién ni qué IP física hay detrás de una solicitud.

1. La adaptación de Kademlia: La Base de Datos de Red (netDb)

En I2P, la tabla DHT basada en Kademlia se denomina netDb (Network Database). A diferencia del Kademlia básico, en I2P la DHT nunca guarda direcciones IP personales de los clientes. En su lugar, almacena dos tipos de referencias criptográficas:

• RouterInfo: Las claves públicas y métodos de contacto de los nodos intermedios de enrutamiento (los "reles" de la red).
• LeaseSet: Los "puntos de entrada" a un servicio o usuario anónimo. Un LeaseSet le dice a la red: "Si quieres enviar un mensaje al destino X, entregáselo a estos túneles de entrada", sin revelar dónde está la máquina física.

Los datos dentro de esta DHT adaptada solo se consultan a través de nodos especiales con alta capacidad llamados Floodfill router, que ejecutan una variante distribuida y protegida de Kademlia.

2. Cifrado de Ajo (Garlic Routing): El paquete contenedor

Mientras que el cifrado de cebolla (usado en Tor) envuelve un solo mensaje en capas de cifrado para un único camino, el cifrado de ajo (Garlic Routing) lleva la idea más lejos:

• Contenedor con varios "dientes" (cloves): Un mensaje de ajo empaqueta dentro de una sola estructura criptográfica múltiples mensajes o instrucciones independientes.
• Contenido combinado: Un único paquete enviado a través de la red puede contener:
  1. La solicitud real de datos (por ejemplo, cargar una web .i2p).
  2. Las instrucciones cifradas sobre cómo y por qué túnel devolver la respuesta (LeaseSet del emisor).
  3. Una confirmación de entrega (Delivery Status).

Cada nodo intermedio que reenvía el "ajo" solo puede desencriptar la capa exterior necesaria para saber a qué siguiente salto debe pasarlo, pero desconoce el contenido interno o cuántos "dientes" hay dentro.

3. Túneles unidireccionales: Rompiendo la correlación de tráfico

Para evitar que un observador detecte el origen analizando la ida y vuelta de los paquetes, I2P utiliza túneles estrictamente unidireccionales:

1. Túnel de salida (Outbound Tunnel): Tu cliente construye una cadena de 2 o 3 nodos para enviar tráfico.
2. Túnel de entrada (Inbound Tunnel): El destinatario construye su propia cadena independiente para recibir tráfico.

[Tú de salida] ──> (Ajo con solicitud + datos de retorno) ──> [Su túnel de entrada]
                                                                        │
[Tu túnel de entrada] <── (Respuesta cifrada) <── [Su túnel de salida] ─┘

Cuando consultas la DHT de Kademlia en I2P:

• La consulta viaja por tu túnel de salida. El nodo de Kademlia que responde solo ve la IP del final de ese túnel, no la tuya.
• La respuesta vuelve por tu túnel de entrada, garantizando que ni el nodo consultado ni los intermediarios sepan quién inició la petición.

Comparativa: Kademlia Estándar vs. Kademlia en I2P

¿Qué tipos de Proyectos o Aplicaciones se benefician de I2P y Kamdelia?

Tanto Kademlia (como protocolo base) como I2P (como red anónima completa) encajan de forma natural en entornos Linux (Servidores, Debian, Ubuntu, Arch, sistemas embebidos, etc.), donde la gestión de red, demonios en segundo plano y sockets P2P son nativos y altamente eficientes.

1. Proyectos ideales para Kademlia puro (Enfocados en Descentralización y Rendimiento)

Kademlia por sí solo se aplica cuando necesitas localizar y sincronizar información rápido sin depender de un servidor central, pero el anonimato absoluto de la IP no es crítico.

• Sistemas de archivos distribuidos y copias de seguridad P2P:
  • Caso de uso: Crear un clúster de almacenamiento distribuido entre varios servidores o equipos Linux sin una base de datos central.
  • Herramientas/Proyectos reales: IPFS (Kubo en Linux) o plataformas de sincronización tipo Syncthing / Resilio.
• Redes de distribución de contenido (P2P CDN):
  • Caso de uso: Compartir actualizaciones de software, imágenes ISO o vídeos pesados (por ejemplo, transmisiones en vivo vía PeerTube) distribuyendo la carga de ancho de banda entre los propios nodos.
  • Herramientas/Proyectos reales: Clientes de BitTorrent sin servidor tracker (usando Mainline DHT como rtorrent, transmission-daemon o aria2 en scripts de Linux).
• Descubrimiento de nodos en redes Blockchain:
  • Caso de uso: Crear una red descentralizada donde los nodos deban descubrir a sus pares automáticamente al arrancar.
  • Herramientas/Proyectos reales: Clientes de Ethereum (Geth) ejecutados en servidores Linux, los cuales usan Kademlia (devp2p) para encontrarse entre sí.

2. Proyectos ideales para I2P (Enfocados en Anonimato y Anti-Censura)

I2P se integra en Linux como un demonio (i2pd escrito en C++ o i2p en Java) que expone un proxy SOCKS/HTTP local (127.0.0.1:4444 o 127.0.0.1:9050).
Es ideal cuando necesitas comunicación privada punto a punto.

• Servicios web ocultos e-eepsites (Eepsites) insensibles a la censura:
  • Caso de uso: Alojar un blog, un foro de libre expresión o una plataforma de periodismo de investigación en un servidor sin revelar la ubicación ni la IP del servidor.
  • Cómo se aplica: Un servidor web ligero (NGINX o Lighttpd) escuchando solo en localhost, vinculado a un túnel de servidor I2P a través de i2pd.
• Sistemas de mensajería privada y chat descentralizado:
  • Caso de uso: Comunicaciones seguras para equipos periodísticos, activistas o redes internas críticas sin intermediarios que puedan auditar el tráfico.
  • Herramientas/Proyectos reales: Bots de IRC sobre I2P, clientes de mensajería Bote (I2P-Bote) o integración de protocolos como Matrix/XMPP haciendo que los servidores se conecten entre sí exclusivamente a través de la red I2P.
• Descargas P2P 100% anónimas:
  • Caso de uso: Compartir archivos mediante torrents sin exponer la dirección IP pública en el swarm del torrent.
  • Herramientas/Proyectos reales: Clientes nativos como I2P-Snark o clientes torrent de Linux configurados con proxy SOCKS5 apuntando a I2P.

Servicio web anónimo con NGINX e i2pd en Debian

Configurar un servicio web anónimo (un eepsite) en Debian Linux combinando NGINX e i2pd (la implementación ligera en C++ de I2P) es un proceso muy eficiente.

NGINX servirá la web únicamente en local, mientras que i2pd gestionará los túneles anónimos para exponerla a la red I2P sin revelar tu dirección IP pública.

1.1. Instalar NGINX e i2pd:

Primero actualiza la lista de paquetes e instala tanto el servidor NGINX como el demonio de I2P (i2pd se encuentra en las ramas oficiales de Debian):

sudo apt update
sudo apt -y install nginx i2pd

2.2. Configurar NGINX para el sitio anónimo: Garantizar la privacidad local.

Crea un bloque de servidor para tu sitio.
Es crítico que NGINX solo escuche en 127.0.0.1 (localhost) para evitar exponer la página a la red Internet convencional.

Crea el archivo de configuración:

sudo vi /etc/nginx/sites-available/eepsite

Añade el siguiente contenido:

server {
    listen 127.0.0.1:8080;
    server_name localhost;

    root /var/www/eepsite;
    index index.html;

    # Evitar revelar la versión de NGINX en las cabeceras por privacidad
    server_tokens off;

    location / {
        try_files $uri $uri/ =404;
    }
}

A continuación, crea el directorio de la web, añade una página de prueba y habilita el sitio:

sudo mkdir -p /var/www/eepsite
echo "Mi servicio web anónimo en I2P" | sudo tee /var/www/eepsite/index.html
sudo chown -R www-data:www-data /var/www/eepsite

sudo ln -s /etc/nginx/sites-available/eepsite /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

3.3. Configurar el túnel de entrada en i2pd: Crear el túnel de servidor.

Edita el archivo de configuración de túneles de i2pd para reenviar las peticiones que entren desde la red I2P hacia el puerto 8080 de tu NGINX:

sudo vi /etc/i2pd/tunnels.conf

Añade el siguiente bloque al final del archivo:

[MI-EEPSITE]
type = http
host = 127.0.0.1
port = 8080
keys = eepsite-keys.dat

Reinicia el servicio de i2pd para que cree el túnel y genere las claves criptográficas:

sudo systemctl restart i2pd

4.4. Consultar tu dominio anónimo: Obtener tu dirección .b32.i2p

Al arrancar el túnel, i2pd genera la clave pública y la dirección única del servicio.
Puedes consultar la dirección completa .b32.i2p ejecutando:

sudo i2pdcmd tunnels | grep -A 5 "MI-EEPSITE"

O revisando directamente las claves en el directorio de trabajo de i2pd:

sudo grep -i "b32" /var/log/i2pd/i2pd.log

Verás una dirección larga terminada en .b32.i2p (por ejemplo, abcd...1234.b32.i2p).
Esa es la URL con la que cualquier usuario de la red I2P podrá acceder a tu sitio web.

Buenas prácticas de seguridad (Hardening)

1. Cortafuegos (UFW / nftables):
   Asegúrate de que el puerto 8080 no sea accesible desde fuera. Solo el puerto HTTP/HTTPS convencional o el puerto que use i2pd para comunicarse con sus pares debe estar expuesto si fuera necesario.
2. Sanitización de contenidos:
   No incluyas en la web recursos externos (fuentes de Google, scripts CDN, imágenes alojadas en la red clara/clearnet), ya que el navegador del usuario intentaría cargarlos revelando su IP real.
3. Copias de seguridad de la clave:
   El archivo /var/lib/i2pd/eepsite-keys.dat contiene la identidad criptográfica de tu web.
   Guárdalo bien; si lo pierdes, la dirección .b32.i2p cambiará para siempre.

Como Navegar por direcciones b32.i2p

Para navegar por direcciones .b32.i2p no necesitas un navegador completamente distinto desarrollado desde cero, pero tampoco puedes ponerla en un navegador convencional sin configurar nada, ya que las extensiones de dominio .i2p no existen en los servidores DNS públicos de Internet.

Tienes dos opciones principales para acceder a esas webs desde un ordenador con Linux u otro sistema operativo:

Opción 1: Tu navegador habitual (Firefox) + Proxy de I2P (Recomendada)

Es el método más utilizado. Configuras tu navegador para que redirija las peticiones de dominios .i2p a través del servicio local de I2P que se ejecuta en tu máquina.

1.1. Tener i2pd o I2P ejecutándose en tu ordenador: Instalación local.

Para acceder a la red I2P, tu propio equipo necesita tener instalado el demonio de I2P (como el paquete i2pd que configuramos antes).
Este servicio abre un proxy HTTP local en tu máquina, normalmente en:

• Dirección: 127.0.0.1
• Puerto: 4444

2.2. Configurar el Proxy en el navegador: Enrutamiento de red.

En Mozilla Firefox:

1. Abre Ajustes -> General -> Configuración de red.
2. Selecciona Configuración manual del proxy.
3. En Proxy HTTP, introduce 127.0.0.1 y en Puerto 4444.
4. Marca la casilla "Usar este proxy también para SOCKS" o deja el campo SOCKS en 127.0.0.1 con puerto 4447 (si usas SOCKS5).
5. Muy importante: Asegúrate de activar la opción "DNS remoto" (o "Proxy DNS al usar SOCKS v5"), para que las búsquedas de nombres .i2p no se filtren a tu proveedor de internet convencional.

3.3. Abrir la dirección .b32.i2p: Navegación anónima.

Con el proxy activado, simplemente pegas la dirección (por ejemplo abcd...1234.b32.i2p) en la barra de direcciones de Firefox.

El navegador enviará la petición a tu i2pd local, este buscará el objetivo en la DHT de Kademlia/netDb, construirá los túneles anónimos y cargará la página web.

Opción 2: Usar un navegador preconfigurado (I2P-Easy-Install / Firefox Profile)

Si no quieres cambiar manualmente la configuración de red de tu Firefox habitual (lo cual afectaría a tu navegación normal si apagas i2pd), existen alternativas empaquetadas:

• I2P-Browser / Profile: El proyecto oficial ofrece un script de instalación que crea un perfil aislado de Firefox preconfigurado exclusivamente para navegar por la red I2P, aislando las cookies y la memoria caché de tu navegación normal.
• LibreWolf / Tor Browser modificados: Algunos usuarios crean un perfil secundario en navegadores centrados en la privacidad para abrir únicamente sitios de redes oscuras (darknets).

¿Qué es exactamente una dirección .b32.i2p?

Para entender por qué funciona así, piensa en la dirección .b32.i2p como una clave criptográfica pública comprimida:

• En la web normal, la URL ejemplo.com se traduce mediante un servidor DNS a una IP como 192.0.2.1.
• En I2P no hay servidores DNS. La dirección .b32.i2p es la representación en texto (Base32) del hash de la clave pública del servicio.
• Cuando la pones en el navegador, tu cliente I2P usa Kademlia (netDb) para preguntar:
  "¿Qué túneles de entrada corresponden a esta clave criptográfica?".
  La red le responde con los túneles activos sin revelar jamás la IP real del servidor.