# Servidor Devkron con V12 en red local y acceso remoto por túnel inverso --- ## 1. Qué muestra el diagrama El diagrama describe la topología estándar de una instalación de V12 sobre Devkron en el sitio del cliente: un solo servidor en la red local atiende a todos los dispositivos del negocio, y un túnel inverso publica ese servidor en internet sin modificar la infraestructura de red del cliente. Son dos planos que conviene leer por separado: - **Plano local (abajo).** Es donde ocurre la operación diaria. Tablets, PCs e impresoras dependen del servidor y de nada más. - **Plano remoto (arriba).** Es acceso adicional. Se apoya en internet, pero la operación no depende de él. --- ## 2. El servidor Devkron como punto único de verdad El servidor ejecuta el runtime de Devkron, y sobre él corre V12 con la lógica de negocio escrita en DKL. Concentra tres responsabilidades: | Responsabilidad | Qué implica | |---|---| | **Base de datos** | Todas las transacciones se escriben en un solo lugar. No hay réplicas por dispositivo ni sincronización que reconciliar. | | **Lógica de negocio** | Precios, descuentos, folios, inventario y reglas fiscales se resuelven en el servidor, no en el cliente. | | **Servicio de aplicación** | Las terminales consumen la interfaz publicada por el servidor. | La consecuencia práctica: los dispositivos no hablan entre sí. Una tablet no consulta a otra tablet para saber si una mesa está ocupada, ni una PC coordina con otra el folio siguiente. Todo pasa por el servidor. Esto elimina de raíz las condiciones de carrera y los conflictos de sincronización que aparecen en arquitecturas peer-to-peer o con bases locales por terminal. --- ## 3. Los dispositivos de la red local **Tablets.** Terminales móviles para captura en piso: toma de pedidos, levantamiento de inventario, atención en mesa. Se conectan por Wi-Fi al mismo segmento de red del servidor. **PCs.** Estaciones fijas de punto de venta, caja y administración. Cobro, cierres de turno, consultas y configuración. **Impresoras.** Tickets, comandas de cocina y formatos administrativos. Este punto merece énfasis: **la impresión tiene que resolverse en la red local**. Una impresora térmica en cocina no es alcanzable desde internet ni conviene que lo sea. El servidor Devkron actúa como intermediario, recibe la instrucción de impresión desde cualquier terminal y la despacha al dispositivo físico correspondiente dentro de la LAN. --- ## 4. El problema que resuelve el túnel inverso Publicar un servidor que vive dentro de la red de un cliente es, tradicionalmente, un problema de infraestructura de red. Las salidas habituales tienen costo o fricción: - **IP fija:** implica contratar un servicio adicional con el proveedor de internet. - **Port forwarding:** requiere entrar al router del cliente, abrir un puerto y exponer el servidor a escaneos desde internet. - **DNS dinámico:** frágil ante cambios de IP y sigue exigiendo apertura de puertos. - **CGNAT:** en muchos enlaces residenciales y móviles, el port forwarding simplemente no es posible porque el cliente no tiene una IP pública propia. Cualquiera de estas rutas convierte cada instalación en un proyecto de red, dependiente de la buena voluntad del proveedor de internet del cliente y del acceso al router. --- ## 5. Cómo funciona el túnel inverso Devkron Bridge invierte la dirección del establecimiento de la conexión. En lugar de que internet toque la puerta del negocio, el negocio abre la puerta desde adentro. 1. Un agente corre junto al servidor Devkron dentro de la red local. 2. El agente **inicia una conexión saliente** hacia el relay de Devkron Bridge. 3. El relay asigna al servidor un subdominio bajo `*.http.induxsoft.net`. 4. Cuando un usuario remoto solicita ese subdominio, el relay enruta la petición por el canal ya establecido, y el servidor responde por la misma vía. Por eso la flecha del túnel en el diagrama es de doble punta: **el establecimiento es unidireccional (de adentro hacia afuera), pero el tráfico es bidireccional**. Lo que esto significa en la instalación: - No se abre ningún puerto entrante en el router del cliente. - No se requiere IP fija ni DNS dinámico. - Funciona detrás de CGNAT. - El firewall del negocio solo observa tráfico saliente, que es lo que ya permite por defecto. - El servidor no queda expuesto a escaneo directo desde internet: no tiene superficie pública propia. --- ## 6. Comportamiento ante caída de internet Este es el argumento comercial más fuerte de la topología y conviene decirlo explícitamente al cliente: | Escenario | Operación local | Acceso remoto | |---|---|---| | Todo funcionando | Normal | Disponible | | Se cae el internet del negocio | **Normal** | No disponible | | Se cae el servidor local | Detenida | No disponible | Si el enlace de internet falla, las tablets siguen tomando pedidos, las PCs siguen cobrando y las comandas siguen imprimiendo, porque todo eso ocurre dentro de la LAN. Lo único que se pierde es la capacidad de consultar el sistema desde afuera. El agente reintenta la conexión y el túnel se restablece cuando vuelve el enlace. Es la diferencia frente a un SaaS puro: ahí, sin internet, no hay operación. --- ## 7. Casos de uso del acceso remoto - **Dueño o gerente fuera del local.** Consulta de ventas del día, cortes y reportes desde el celular. - **Soporte técnico.** El equipo puede diagnosticar sin desplazarse al sitio. - **Multisucursal.** Cada sucursal mantiene su servidor y su autonomía operativa; la dirección consolida desde afuera. - **Integraciones entrantes.** Webhooks y servicios externos pueden alcanzar el servidor local a través del subdominio asignado. --- ## 8. Notas para la conversación comercial Al presentar este diagrama, tres ideas suelen ser las que aterrizan: 1. **"No tocamos su router."** Elimina la objeción de involucrar al proveedor de internet o al área de sistemas del cliente. 2. **"Si se cae el internet, usted sigue vendiendo."** Diferenciador directo frente a soluciones 100% en la nube. 3. **"Su servidor no queda expuesto en internet."** Responde a la preocupación de seguridad antes de que se formule.