Bastion Host Tunneling for Secure Resource Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing VPN connections are limited in that they require pre-connection to access internal network resources, leading to failures such as DNS name resolution issues and lack of granularity in security configurations, often requiring direct user intervention and additional administrative setups.
Innovation Solution
A computer-implemented method that allows access to protected resources by transmitting requests over a second network, using an authentication server to identify a bastion host, port, and connection method, establishing a tunnel connection to access the resource, and providing resource records with reachability information to client devices.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a single tunnel endpoint per client device is used in traditional VPN connections, then the configuration is simple, but the security granularity is limited and cannot provide application-level access control
Solution Approach 1:
The patent segments the network access control into multiple levels: network-level tunnel endpoints and application-level service identifiers. This allows different applications on the same client device to access different internal resources through the same VPN tunnel, providing fine-grained security control without requiring separate tunnels for each application.
Solution Approach 2:
The patent adds a new dimension to VPN connectivity by introducing service identifiers that operate at the application layer, complementing the traditional network-layer tunnel endpoints. This dimensional addition enables application-specific routing and access control within the established tunnel, resolving the contradiction between simplicity and granularity.
2Reliability
If DNS name resolution is used before VPN connection is established, then the DNS query can be resolved, but the resource may be unreachable resulting in NXDOMAIN errors
Solution Approach 1:
The patent implements preliminary action by pre-resolving DNS names to internal IP addresses and caching these mappings before the VPN tunnel is established. When the tunnel is created, the client device already has the necessary routing information to immediately access internal resources without experiencing NXDOMAIN errors or delays.
Solution Approach 2:
The system incorporates feedback mechanisms where DNS resolution results are cached and reused, and where the system learns from connection attempts to improve future resource accessibility. This feedback loop ensures that once a resource is successfully accessed, the routing information is retained for faster subsequent access.
3Adaptability or versatility
If additional VLAN configurations are implemented to achieve application-level security, then security granularity is improved, but the configuration complexity and administrative overhead increase significantly
Solution Approach 1:
The patent introduces service identifiers as an intermediary layer between the VPN tunnel and internal resources. These service identifiers act as a mediator that enables application-level routing and access control without requiring complex VLAN configurations. The service identifier framework provides the necessary granularity while keeping the network infrastructure simple.
Solution Approach 2:
The service identifier mechanism serves multiple functions simultaneously: it provides application-level routing, enables fine-grained access control, and works with the existing VPN tunnel infrastructure. This multi-functionality eliminates the need for separate VLAN configurations for each application, reducing administrative overhead while maintaining security granularity.
4Reliability
If direct user intervention is required to resolve connection failures, then the system can handle edge cases, but the ease of operation is reduced and user experience is degraded
Solution Approach 1:
The patent implements self-service mechanisms where the system automatically detects connection failures, retrieves updated DNS information, and re-establishes tunnels without user intervention. The client device autonomously manages tunnel lifecycle, resource discovery, and connection recovery, eliminating the need for users to manually troubleshoot or reconfigure VPN connections.
Solution Approach 2:
The system employs periodic actions by automatically refreshing DNS caches, re-evaluating resource availability, and attempting automatic reconnection when failures occur. These periodic checks and automated recovery attempts ensure reliable connection handling while keeping the system easy to operate, as users don't need to manually intervene in the connection lifecycle.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Aspects of the present disclosure relate to providing secure access to resources R-1, R-2, R-3, R-4 of a private net-iwork 160. For example, a client device 110, 130, 140 may transmit a request 310 identifying the protected resource R-1, R-2, R-3, R¬4 to an authentication server 120. The authentication server 120 queries a network address lookup table to identify a network address of the protected resource R-1, R-2, R-3, R-4 based on the identifying information of the request 310. If the network address denotes a network location that is not generally accessible, the authentication server 120 generates a resource record that identifies a bastion host 170, 180, 190, a port, and a connection method for accessing the protected resource R-1, R-2, R-3, R-4. The resource record and the network address may then be transmitted to the client device 110, 130, 140. In response, the client device 110, 130, 140 may use the information in the resource record to establish a tunnel connection 510 with the bastion host 170, 180, 190, and the client device 110, 130, 140 uses the tunnel connection 510 to access the protected resource R-1, R-2, R-3, R-4 via the bastion host 170, 180, 190.