2026-05-16 13:36:03 +03:00
1
2026-05-14 23:30:34 +03:00
1
2026-05-14 23:30:34 +03:00
1
2026-05-14 23:30:34 +03:00
1
2026-05-14 23:30:34 +03:00
1
2026-05-14 23:30:34 +03:00
2026-04-28 22:29:50 +03:00
2026-05-16 13:35:11 +03:00
1
2026-05-14 23:30:34 +03:00
1
2026-05-14 23:30:34 +03:00
2026-04-28 22:29:50 +03:00
2026-05-12 21:02:29 +03:00
2026-05-12 21:02:29 +03:00
2026-05-12 21:02:29 +03:00
1
2026-05-14 23:30:34 +03:00
2026-04-28 22:29:50 +03:00
2026-05-12 21:02:29 +03:00

Remote Access Platform

Production-oriented Secure Access Fabric platform.

The project started as an RDP proxy, but the target architecture is broader:

  • multi-tenant control plane
  • direct realtime data plane
  • service adapters for RDP now and VNC/SSH/VPN/file/video later
  • native Access Clients
  • future secure mesh / node-agent / updater / connector model
  • shared Fabric Service Channel runtime for working service data so VPN, Remote Workspace, video, file, and future services request a common channel instead of reimplementing transport, routing, and failover

RDP is the first proven service baseline. RDP work is currently paused by product decision while the project moves to the Secure Access Fabric platform-core foundation: clusters, node enrollment, node-agent identity, role assignments, and platform administration.

Current Baseline

  • Backend: Go control plane with PostgreSQL as source of truth and Redis for live coordination/routing only.
  • Worker: active C++ RDP Adapter worker based on FreeRDP.
  • Windows client: C# / WPF native Access Client.
  • Data plane: direct worker WSS for realtime RDP when available, backend WebSocket gateway retained as fallback/debug.
  • Current test Docker host: docker-test / 192.168.200.61.
  • Current test Docker deployment for Stage 5.2 proof: rap-backend-smoke:stage5-2-download and rap-rdp-worker:stage5-2-download.

See the current audit and baseline matrix before starting new work:

  • docs/audits/PROJECT_AUDIT_2026-04-26.md
  • docs/audits/CURRENT_BASELINE_MATRIX.md

Proven RDP Capabilities

  • real RDP connect through worker
  • active/detach/reattach/takeover/terminate lifecycle
  • takeover without remote session recreation
  • worker-death/orphan-active-session recovery
  • direct worker WSS data plane
  • binary direct render frames
  • backend gateway JSON/base64 fallback
  • Windows client rendering and input
  • text clipboard with policy enforcement
  • client-to-server file upload into controlled worker storage
  • restricted transfer-drive visibility through RAP_Transfers, runtime-proven
  • server-to-client file download implementation through RAP_Transfers\ToClient; core direct/fallback data path is runtime-proven, lifecycle blocking is runtime-proven, and manual desktop UI acceptance remains pending

Repository Structure

  • backend/ - Go control plane
  • workers/rdp-worker/ - active C++ RDP Adapter worker
  • workers/rdp-service-csharp/ - inactive research scaffold, not current runtime
  • clients/windows/ - Windows native Access Client
  • clients/android/ - Android VPN client
  • docs/architecture/ - target and staged architecture documents
  • docs/codex/ - current Codex status and next-step prompts
  • docs/audits/ - current audits and baseline matrices
  • scripts/ - smoke and helper scripts
  • deploy/ - deployment assets
  • web-admin/ - future/admin UI area

Быстрый локальный билд Android APK после апдейта

pwsh -ExecutionPolicy Bypass -File scripts\prepare-local-build-workstation.ps1 -SetEnvironment
pwsh -ExecutionPolicy Bypass -File scripts\android\prepare-android-build-environment.ps1 -SetEnvironment
pwsh -ExecutionPolicy Bypass -File scripts\android\rebuild-and-publish-android-apk.ps1

Для быстрого release (сборка + публикация + опциональная проверка манифеста):

pwsh -ExecutionPolicy Bypass -File scripts\android\release-android-apk.ps1 `
  -InstallMissing `
  -PublishToTestDockerDownloads

Для одного шага «всё-в-одном»:

pwsh -ExecutionPolicy Bypass -File scripts\android\fast-release-android-apk.ps1

Или через .cmd (Windows, двойной клик/ссылкой):

scripts\android\fast-release-android-apk.cmd

После обновления Android-клиента выполните на машине сборки:

pwsh -ExecutionPolicy Bypass -File scripts\android\rebuild-and-publish-android-apk.ps1 -InstallMissing -BuildType release

Скрипт сам проверит окружение, при необходимости поставит недостающие компоненты SDK (флаг -InstallMissing) и соберет APK. После этого артефакт сразу окажется в web-admin/deploy/html/downloads для скачивания из панели.

Важно по процессу релиза: каждый новый номер версии должен проходить полный цикл сборка → публикация → проверка manifest и всегда попадать в latest-release + releases/<version> на стороне дистрибутива, чтобы узлы и пользователи всегда обновлялись с актуального билда.

Read Order

  1. CODEX_CONTEXT.md
  2. docs/audits/PROJECT_AUDIT_2026-04-26.md
  3. docs/audits/CURRENT_BASELINE_MATRIX.md
  4. docs/codex/CURRENT_STATUS.md
  5. docs/codex/ARCHITECTURE_GUARDRAILS.md
  6. docs/architecture/RDP_ADAPTER_RUNTIME.md
  7. docs/architecture/DATA_PLANE_V1.md
  8. docs/architecture/FABRIC_SERVICE_CHANNEL_RUNTIME.md
  9. docs/architecture/CLUSTER_NODE_ADMIN_FOUNDATION.md
  10. docs/codex/NEXT_STEP_PROMPT.md

Do not use docs/_legacy_v1 for implementation decisions. Legacy files are historical reference only.

Current Next Step

RDP work is paused. Platform-core stages C1-C9 are implemented and verified: cluster/node model foundation, node enrollment hardening, native rap-node-agent MVP, Platform Admin Console MVP, service workload supervision contract, mesh control-plane preparation, Mesh MVP skeleton, multi-cluster hardening, and organization admin foundation.

Planning baseline:

  • docs/architecture/CLUSTER_NODE_ADMIN_FOUNDATION.md
  • artifacts/c1-cluster-node-foundation-report.md
  • artifacts/c2-node-enrollment-hardening-report.md
  • artifacts/c3-rap-node-agent-mvp-report.md
  • artifacts/c4-platform-admin-console-report.md
  • artifacts/c5-service-workload-supervision-contract-report.md
  • artifacts/c6-mesh-control-plane-preparation-report.md
  • artifacts/c7-mesh-mvp-skeleton-report.md
  • artifacts/c8-multi-cluster-hardening-report.md
  • artifacts/c9-organization-admin-foundation-report.md

Stage C1 implemented the backend foundation for:

  • explicit clusters
  • cluster memberships
  • node join tokens with hashed tokens only
  • node join requests
  • node identity/certificate metadata
  • node role assignments
  • node heartbeat/latest health
  • cluster audit events
  • safe migration/backfill of existing node data into a default cluster

Recommended next step is a decision between platform auth hardening for web-admin, node PKI hardening, node-agent runtime hardening, mesh runtime DP-0, or returning to paused RDP work.

Do not start all continuation paths at once.

S
Description
No description provided
Readme 574 MiB
Languages
Go 46.8%
PowerShell 36%
TypeScript 6.8%
C++ 4%
Java 2.8%
Other 3.4%