In most split-tunnel VPN/ZTNA deployments, installing an internal route authorizes the entire device, not a specific application, to use it. An unprivileged malicious process can therefore reach internal services by reusing routes intended for corporate applications. We present ProcRoute, a system that restricts internal-route access to explicitly authorized applications. ProcRoute models route access as an access-control problem: application identities are principals, destination prefixes with port and protocol constraints are resources, and a total, default-deny decision function mediates every connect() and UDP sendmsg() to an internal destination. Processes without a grant retain external access but are denied internal routes under our threat model. We describe ProcRoute's formal model, a Linux prototype built on cgroup v2 and eBPF socket-address hooks, and two complementary evaluations. In a two-machine WireGuard deployment, ProcRoute matches the WireGuard baseline and 13% faster than an nftables cgroup-matching configuration, with a p50 connect latency of 93 $μ$s (+3.6 $μ$s over baseline), flat policy scaling to 5,000 prefixes, and sub-millisecond revocation. Single-machine loopback microbenchmarks confirm low hook overhead: 2.7 $μ$s on the internal-allow path, 82/82 unauthorized pivot attempts blocked, and zero transient allows across 1.2 million connection attempts during policy reload.

翻译：在大多数分割隧道VPN/ZTNA部署中，安装内部路由会授权整个设备（而非特定应用）使用该路由。因此，未授权的恶意进程可通过复用为企业应用设计的路由访问内部服务。我们提出ProcRoute系统，该系统将内部路由访问限制为仅限显式授权的应用程序。ProcRoute将路由访问建模为访问控制问题：应用身份为主体，含端口和协议约束的目标前缀为资源，通过全量默认拒绝决策函数中介所有对内部目标的connect()和UDP sendmsg()调用。根据我们的威胁模型，未获授权的进程仍可保留外部访问权限，但被拒绝使用内部路由。本文阐述了ProcRoute的形式化模型、基于cgroup v2与eBPF套接字地址钩子构建的Linux原型，以及两项互补性评估。在双机WireGuard部署中，ProcRoute性能与WireGuard基准持平，比nftables cgroup匹配配置快13%，其中p50连接延迟为93微秒（较基准增加3.6微秒），策略可平滑扩展至5,000条前缀，撤销操作在亚毫秒级完成。单机回环微基准测试证实钩子开销较低：内部允许路径延迟2.7微秒，阻止82次/82次未授权枢轴攻击尝试，在策略重载期间1,200,000次连接尝试中实现零瞬态允许。