Skip to content
CV ↗P.
05Caso de estudio2026

Okiyumi VPN

Caso de estudio tecnológico: VPN con smart routing para Windows

Sistemas · redes

APPVPNDIRECTBLOCKDNSAPP → VPN · DIRECT · BLOCK

El estudio de un sistema de red ambicioso: enrutamiento por aplicación y por dominio en lugar del «todo o nada».

Contexto

Okiyumi VPN es una plataforma para Windows en beta cerrada. La estudio como caso tecnológico: cómo está construido el sistema, qué problemas resuelve y qué compromisos de ingeniería ha elegido.

Problema

Una VPN típica es una herramienta tosca: o todo el tráfico pasa por el túnel o nada. El objetivo es un enrutamiento por reglas — una app por la VPN, un dominio directo, algo bloqueado — sobreviviendo a reinicios y caídas sin dejar la máquina en un estado de red roto.

Cómo funciona el sistema

  • 01

    Smart Routing: Application → VPN / Direct / Block y Domain → VPN / Direct / Block, con reglas TTL para dominios y seguimiento de propiedad de rutas.

  • 02

    Separación de privilegios: la interfaz React + Tauri se comunica con un servicio Windows dedicado mediante named pipes: la interfaz nunca necesita derechos de administrador.

  • 03

    Cambios de red transaccionales, conexión VPN en dos fases y validación real del handshake WireGuard: el sistema se recupera solo de caídas y reinicios.

Arquitectura

Interfaz React

interfaz

Tauri

shell nativa

Capa Rust

named pipes · DPAPI

OkiyumiEngine

servicio de Windows

Network Safety Layer

Smart Routing · WireGuard · WFP · DNS

Red de Windows

FLOW

  1. 01Aplicación / dominio
    regla
    → Smart Routing
  2. 02Smart Routing
    → VPN / Direct / Block

Cifras

todas las métricas son del proyecto, no logros personales

353

pruebas del núcleo Rust del proyecto

métrica del proyecto

49

pruebas del servidor de provisioning del proyecto

métrica del proyecto

Por qué importa

  • Para mí es el estudio de un sistema complejo: cómo una idea de producto («una VPN que no hay que estar activando y desactivando») se convierte en una arquitectura de servicios, límites de drivers y recuperación de fallos.

Qué aprendí

  • Cómo un requisito de producto dicta un límite de ingeniería: si la interfaz no debe pedir derechos de administrador, se necesita un servicio separado y un canal hacia él.

Stack

  • TypeScript
  • React 18
  • Vite
  • Zustand
  • Tailwind CSS
  • Tauri 2
  • Rust
  • WireGuard
  • WFP
  • Named Pipes
  • DPAPI
  • Debian
  • systemd

Habilidades

  • Alfabetización técnica
  • Análisis de sistemas

Resultado

  • Un stack de red completo en Windows: WFP, APIs de enrutamiento, un resolvedor DNS y un límite propio del routing driver: no un envoltorio del cliente de otra persona.
  • La estabilidad del proyecto está verificada por pruebas: 353 pruebas del núcleo y suites separadas para frontend, servidor y despliegue.