Per-Application VPN Routing with Linux BPF Flow Identification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing operating systems, such as LINUX and Unix variants, do not provide native support for per-application VPN access, resulting in all applications being subject to the same VPN settings, which can lead to inefficient VPN usage as different applications have varying VPN requirements.
Innovation Solution
Implementing a flow identification solution using the proc filesystem and Berkeley Packet Filter (BPF) to identify which application is requesting network access, allowing for split-tunneled network connectivity on a per-application basis by applying application-specific routing rules.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If all applications are subject to the same VPN settings, then system simplicity is maintained, but VPN efficiency and security are reduced due to inability to apply application-specific routing rules
Solution Approach 1:
The patent segments the network traffic routing by creating separate virtual network interfaces (tun0 for tunneled traffic, eth0 for direct traffic) and assigning different routing rules to different applications based on their requirements. This allows efficient VPN usage for specific applications while maintaining system manageability through structured segmentation.
Solution Approach 2:
The patent applies local quality by configuring different routing policies for different applications - some applications receive split-tunneled VPN access while others receive full VPN access or no VPN access, depending on their specific security and performance requirements. This targeted approach optimizes VPN efficiency without uniformly complicating the entire system.
2Adaptability or versatility
If per-application VPN support is implemented, then VPN efficiency and security are improved, but operating system limitations prevent native support
Solution Approach 1:
The patent introduces an intermediary component - a background service or proxy application - that intercepts network requests from applications, identifies the requesting application, and routes traffic through appropriate virtual network interfaces based on pre-configured policies. This intermediary enables per-application VPN support without requiring core operating system modifications.
Solution Approach 2:
The patent adds another dimension to network routing by creating virtual network interfaces that operate alongside the physical network interface. This dimensional addition allows traffic to be routed through different paths (tunneled vs. direct) based on application requirements, achieving adaptability without fundamentally altering the operating system architecture.
3Speed
If split-tunneling is applied to all applications, then network performance is improved, but security requirements for certain applications are not met
Solution Approach 1:
The patent applies local quality by configuring different routing policies for different applications - some applications receive split-tunneled VPN access while others receive full VPN access or no VPN access, depending on their specific security and performance requirements. This targeted approach optimizes VPN efficiency without uniformly complicating the entire system.
Solution Approach 2:
The patent changes the routing parameter (tunneled vs. direct) dynamically based on the application identity and its security requirements. By modifying the routing parameter according to application-specific needs, the system achieves both improved network performance for appropriate applications and security compliance for applications requiring full VPN tunneling.
Data Source
AI summary
Disclosed are approaches for providing per-application tunnel access, such as virtual private network (VPN) access, in LINUX based systems. In response to an application requesting a network connection, a process identifier of the application and an inode identifier representing a socket for the network connection are obtained. Then, a kernel space map is updated to include the process identifier of the application and the inode identifier. In response to the application making a network connection request, the inode identifier of the application is obtained based at least in part on a source network address, a source port number, a destination network address, and a destination port number. Then, the kernel space map is queried to obtain the process identifier of the application, wherein the inode identifier is a query parameter. Then, a routing policy is identified based at least in part on the process identifier.