Patent ID: 12199944

DETAILED DESCRIPTION

Disclosed are various embodiments for providing split-tunneled network connectivity on a per-application basis in a transparent manner. Network connectivity is often termed as split-tunneled if network traffic can be directed to take different routes based on one or more criteria (e.g., network destination or traffic type). For instance, VPN clients often offer split-tunnel connectivity. As an example, network traffic with a destination to the LAN may be routed through a VPN, while network traffic with a destination to the WAN may be routed through another network interface.

Unfortunately, many operating systems do not permit split-tunneled network connectivity on a per-application basis. VPN settings are often per device—all applications are subject to the same VPN settings. If the VPN connection does not permit a split-tunnel, then no applications are able to bypass the VPN. If the VPN connection is a split-tunnel, the same routing rules are applied to all applications installed and executing on the client device. And even if the operating system allows for the VPN to configured on a per-application basis (e.g., VPN access is granted on a per-application basis), the same VPN routing rules are often still applied to those applications that are granted VPN access.

This can be a problem in some instances because different applications may have different requirements for VPN access. For example, a web-browser may need a split-tunnel VPN so that certain types of traffic are routed through the VPN while other types of traffic are routed directly across the network, bypassing the VPN. These traffic rules could be based on traffic type or destination. Meanwhile, an email client may need all traffic routed across the VPN in order to establish a secure connection with a company's internal email servers.

To address these issues, various approaches to providing a split-tunneled network connection on a per-application basis are provided. The split-tunneled network connection is further performed in a transparent manner, such that applications are unaware that their network traffic is being routed or proxied. Each application installed on a computing device can have traffic routed in a split-tunnel fashion using application specific rules. For example, a web browser could have multiple rules specified for routing traffic across a network tunnel or bypassing the network tunnel based on criteria such as the destination hostname or destination internet protocol (IP) address, while an email client could have a rule specifying that all traffic be routed across the network tunnel. In the following discussion, a general description of the system and its components is provided, followed by a discussion of the operation of the same.

With reference toFIG.1, shown is a network environment100according to various embodiments. The network environment100includes a client device103, a tunnel server106, an internal remote host109, an internal domain name service (DNS) server113, an external remote host116, and an external DNS server119, which are in data communication with each other via a network123. The network123can include the Internet, intranets, extranets, wide area networks (WANs), local area networks (LANs), wired networks, wireless networks, or other suitable networks, etc., or any combination of two or more such networks123. For example, such networks123can comprise satellite networks, cable networks, Ethernet networks, and other types of networks.

The client device103is representative of any one or more client devices103that can be coupled to the network123, such as a desktop computer, a laptop computer, personal digital assistants, cellular telephones, smartphones, set-top boxes, music players, web pads, tablet computer systems, game consoles, electronic book readers, or other devices with like capability. The client device103can include a display, such as liquid crystal display (LCD) displays, gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electrophoretic ink (E-ink) displays, LCD projectors, or other types of display devices, etc. The client device103can be configured to execute various applications such as a one or more client applications126, a network driver129, a tunnel client133, and a DNS resolver136.

The client application126can access network content or resources made available by the internal remote host109or the external remote host116. Illustrative examples of a client application126include a web browser, email client, instant messenger, or a network file storage client.

The network driver129can capture network traffic from client applications126and route that traffic to the tunnel client133. For example, the network driver129can modify the destination address to the localhost address and the destination port to a port that the relay service139of the tunnel client133is bound. The network driver129can be configure to intercept or capture the network traffic of all client applications126installed on the client device103or just from those client applications126that have been previously selected or specified to have their network traffic capture and routed by the network driver129.

In some implementations, the network driver129can be installed and operate separately from the networking drivers provided by the operating system of the client device103. In these instances, the network driver129would only accept connections from client applications126explicitly configured to use the network driver129for network connectivity. Other client applications126would be unaware of the existence of the network driver129and use the generic networking functionality provided by the operating system of the client device103.

The tunnel client133can establish a network tunnel with the tunnel server106. A network tunnel is a point-to-point network connection between two endpoints (e.g., the tunnel client133and the tunnel server106) that allows for network traffic to be encapsulated and sent or routed between the two endpoints. A network tunnel can be established using a variety of approaches, such as virtual private networks (VPNs) or proxy services. A network tunnel may or may not be encrypted, depending on whether encryption is supported by the tunnel protocol or service used. Examples of VPNs include interne protocol security (IPSEC) VPNs, secure sockets layer (SSL) VPNs, and secure shell (SSH) VPNs. Examples of proxy services or connections include SOCKS proxies and application proxies (e.g., HTTP or HTTPS proxies, FTP proxies, SMTP proxies, etc.).

The relay service139is executed to accept connections at the transport layer of the OSI model (e.g., TCP, UDP, SCTP, or DCCP connections) and relay those connection across a network tunnel or tunneled connection. For example, the relay service139can have an open socket listening on a predefined or prespecified port to accept transmission control protocol (TCP), universal datagram protocol (UDP), stream control transmission protocol (SCTP), or datagram congestion control protocol (DCCP) connections. When a connection is made to the relay service139, it can route or send the connection across the network tunnel to the tunnel server106, from which the connection continues to its destination.

The local DNS server143is an application that provides response to queries for an IP address. Generally, the queries can contain a hostname, uniform resource locator (URL), or other human readable network address. The local DNS server143can then search for an IP address that has been previously associated with the hostname in the DNS query. If the IP address has not been previously cached (e.g., in response to a prior query for the same hostname), the local DNS server143can recursively search for IP address. For example, the local DNS server143can query either the internal DNS server113, the external DNS server119, or both, in order to determine the IP address for a hostname.

The DNS resolver136can send a DNS query to a DNS server to determine the IP address associated with a hostname included in the DNS query. The DNS resolver136can send DNS queries on behalf of client applications126executed by the client device103. The DNS resolver136can be configured to use a specific DNS server, such as the local DNS server143provided by the tunnel client133, or another DNS server, such as the internal DNS server113or the external DNS server119. For example, the DNS resolver136could be configured to use the local DNS server143in response to the tunnel client133beginning execution and establishing a tunneled connection with the tunnel server106. Once the DNS resolver136receives the requested IP address, it can cache or otherwise store the response and provide the requested IP address to the requested client application126.

Also, various data is stored in a data store146stored on the client device103. Examples of data stores146include relational databases, non-relational databases, object-oriented databases, hierarchical databases or data structures, key-value stores, as well as any area in the memory of the client device allocated to store information related to the implementation of one or more components executed by the client device103. The data stored in the data store146is associated with the operation of the various applications executed by the client device103, including the client applications126, network driver129, tunnel client133, and DNS resolver136. The data stored in the data store146includes routing policies149, a hostname lookup table153, an address translation table156, a list of managed applications159, and potentially other data.

Routing policies149are used to decide how to route traffic originating from a client application126based on various criteria. Examples of the criteria used to determine how to route the traffic include the type of client application126(e.g., web browser, email client, VoIP application, instant messenger, etc.), the identity of the client application126(e.g., CHROME®, FIREFOX®, INTERNET EXPLORER®, etc.), the type of network traffic (e.g., TCP or UDP, HTTP, FTP, SSMTP, POP3, IMAP, SSL/TLS encrypted, etc.), or the destination of the network traffic (e.g., the IP address or destination hostname). A routing policy149can also specify the type of action to be taken based on the matching criteria. Examples of the actions that may be taken can include blocking the network traffic, routing the network traffic through a network tunnel between the tunnel client133and the tunnel server106, or allowing the client application126to directly send network traffic to the destination through a bypassed connection.

Multiple routing policies149may also apply to the same client application126. As an illustrative example, a web browser could be subject to multiple routing policies149. Some routing policies149could direct network traffic to particular hostnames or domains through a tunneled connection, while other routing policies149could block network traffic to other hostnames or domains. Meanwhile, a default routing policy149for the web browser could specify that all other network traffic be routed through a bypassed connection.

The hostname lookup table153can be used to maintain a mapping of hostnames163with respective external IP addresses166and internal IP addresses169. In some instances, however, the hostname lookup table153may only maintain a mapping of external IP addresses166and internal IP addresses169. An entry in a hostname lookup table153could be formatted accordingly:

HostnameExternal IPInternal IPExampleMachine11.1.1.1192.168.1.1ExampleMachine21.1.1.1192.168.1.2
Of note is that it is possible for multiple machine names to be assigned different internal IP addresses169, but share the same external IP address166. As the world approaches IPv4 address exhaustion, it is common for multiple services or machines to share the same publicly accessible external IP address166. For example, the web server www.example.com and the email server mail.example.com could resolve to the same external IP address166, even if they are hosted on different machines. Similarly, the hostnames www.exampleA.com and www.exampleB.com could resolve to the same external IP address166. Generally, when multiple hostnames resolve to the same external IP address, the connections are appropriately routed and processed using various virtual hosting or reverse proxy solutions.

For reference, a hostname163is a humanly meaningful, and often text-based, identifier of a computing device. Examples of hostnames163include fully qualified domain names (FQDNs), machine names, or similar identifiers.

An external IP address166is a publicly reachable or routable IP address. Accordingly, the external IP address166for a hostname163can represent an IP address for an external remote host116that be reached through either a tunneled connection or a bypassed connection.

An internal IP address166for hostname163can represent an IP address for an internal remote host109that is only reachable through a tunneled connection or an IP address for an external remote host109when the connection to the external remote host116is made through a tunneled connection instead of a bypassed connection. Examples of internal IP addresses166include private IPv4 address ranges specified by RFC 1918 (e.g., 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) or IPv6 address ranges specified by RFC 4193 (e.g., fd00::/8). However, IP addresses outside of these address ranges that are not publicly routable or accessible could also be used as internal IP addresses166.

The address translation table156can be used to store a mapping of IP addresses for correctly relaying datagram or other stateless or connectionless network traffic, such as UDP network traffic. Because stateless connections, such as UDP, do not track whether a datagram that is received is related to a previous datagram, client applications126often implement their own state tracking mechanisms. For example, if a client application126receives a UDP datagram, the client application126can evaluate the UDP datagram to determine whether the UDP datagram is a response to a previously sent UDP datagram or is an unsolicited UDP datagram. Accordingly, changes to a UDP datagram that are made to tunnel or otherwise route a UDP datagram through a tunneled connection can break the evaluation performed by the client application126to determine whether a UDP datagram it receives is a response to a previously sent UDP datagram or is an unsolicited UDP datagram. Accordingly, for each UDP datagram that is sent by a client application126, the source port173for the UDP datagram is recorded as well as the respective destination IP address176for the UDP datagram. If the UDP datagram is routed through a tunneled connection to the tunnel server106, the source IP address179used for the UDP datagram can also be recorded. Although described in further detail later, when a response UDP datagram is received from the source IP address179, the response UDP datagram can be modified to reflect as its source IP address the destination IP address176of the original UDP datagram. As a result, the client application126is able to continue to determine whether a UDP datagram it receives is a response to a previously sent UDP datagram or is an unsolicited UDP datagram while the tunnel client133is able to intercept and reroute UDP traffic transparently on behalf of the client application126.

The list of managed applications159is a list of client applications126for which the network driver129is to intercept or capture network traffic for routing in compliance with the routing policies149. Client applications126may be identified by name, by a unique identifier application identifier, or other mechanism.

Next, a general description of the operation of the various components of the network environment100is provided. The following description is only intended to introduce the interactions between the various components of the network environment100. More detailed descriptions of the various components are provided when discussing the subsequent figures, including alternative implementations of various features, where appropriate.

To begin, a client application126makes an attempt to access network content, such as when a web browser attempts to access a web page, a VoIP client attempts to connect to a VoIP service, or an email client attempts to access an email server. The access generally involves the client application126making two requests. First, the client application126makes a DNS request for an IP address that maps to the hostname163(e.g., fully qualified domain name) where the network content is located. Upon receiving the IP address, the client application126then makes a connection attempt to access the network content using the IP address.

To process the DNS request, the client application126sends the DNS request to the DNS resolver136provided by the operating system of the client device103. The DNS resolver136then sends the DNS query to the local DNS server143, which has been previously configured as the default or primary DNS server for use by the DNS resolver136. If the local DNS server143has previously cached a response for the hostname163, then the local DNS server143can provide the internal IP address169or external IP address166for the hostname163from the hostname lookup table153, if available. Whether the local DNS server143provides the internal IP address169or external IP address166can depend on what is specified by a routing policy149.

If no record for the hostname163is provided in the hostname lookup table153, then the local DNS server143can make recursive queries in parallel to the internal DNS server113and the external DNS server119. The internal IP address169provided by the internal DNS server113and the external IP address166provided by the external DNS server119can then be stored together with the hostname163in the hostname lookup table153. Again, whether the local DNS server143provides the internal IP address169or external IP address166can depend on what is specified by a routing policy149.

In some implementations, the local DNS server143can provide a resolved IP address according to a predefined priority order. For example, the local DNS server143can be configured to always provide the internal IP address169for a hostname163, if available. If an internal IP address169is unavailable, then the external IP address166for the hostname163can be provided. Additional routing decisions can be made by the network driver129or the tunnel client133in compliance with one or more routing policies149, as discussed later.

In other implementations, the local DNS server143can provide a resolved IP address in compliance with a routing policy149. In this implementation, the local DNS server143can search for a routing policy149that matches the hostname163to be resolved. If the routing policy149specifies that the network traffic is to be routed through a tunneled connection by the tunnel client133, then the internal IP address169can be provided by the local DNS server143to the DNS resolver136. Likewise, if the routing policy149specifies that the network traffic is not to be routed through the tunneled connection, but instead through a bypassed connection across the network123, then the external IP address169can be provided by the local DNS server143to the DNS resolve136. However, if the routing policy149specifies that the network traffic for the client application126should be blocked (e.g., because the hostname163is for a website that is prohibited by policy or the external IP address falls within a range of prohibited or “blacklisted” IP addresses), the local DNS serve143could respond with a non-routable IP address or simply fail to respond.

In any of these scenarios, once the DNS resolver136receives an IP address from the local DNS server143, the DNS resolver136provides the resolved IP address for the hostname163to the requesting client application126. Upon receiving the IP address (e.g., internal IP address169or external IP address166), the client application129attempts to make a connection to the remote host. To do so, the client application126can provide the network driver with the resolved IP address (e.g., internal IP address169or external IP address166) to the network driver129. The network driver129can then follow one of several potential implementations in order to decide whether and how to establish a network connection on behalf of the client application126. In the first implementation, the routing decision can be performed by the tunnel client133, while in the second implementation, the routing decision can be performed by the network driver129.

In the first implementation, the network driver129can make a connection request with the tunnel client133on behalf of the client application126. The tunnel client133can then make a routing determination for the connection and provide a response to the network driver129. The response can include an instruction, signal, or message for the network driver129regarding how to handle the connection request from the client application126. For example, the connection response can instruct the network driver129to redirect the network connection to the relay service139provided by the tunnel client133, which can route the connection to the tunnel server106over a tunneled connection. As another example, the connection response can instruct the network driver129to bypass the relay service139and route the connection directly to a remote host (e.g., an external remote host116) over a bypassed connection. As a third example, the connection response can instruct the network driver129to close the connection, thereby blocking access to the remote host by the client application126.

To make the routing determination for the connection, the tunnel client133can evaluate one or more routing policies149. As a simple example, if the connection request from the network driver129on behalf of the client application126includes an internal IP address169, the routing policy149can specify that the connection be redirected to the relay service139for routing over a tunneled connection. However, there are more complicated examples of routing polices149.

For instance, many services are hosted using the same external IP address166. Accordingly, multiple different websites reachable through different hostnames163can be hosted using the same external IP address166(e.g., through the use of virtual hosting or a reverse proxy). To provide routing policies149on a per-hostname163basis, the internal DNS server113can provide a separate internal IP address169for each hostname163that is reachable at the same external remote host116using the same external IP address166. When the tunnel client133receives an internal IP address169, it can search for a routing policy149applicable to the internal IP address169. The applicable routing policy149could specify that the connection should be blocked (e.g., when access to certain hostnames163is to be blocked). In this case, the tunnel client133could respond to the network driver129with a command to close the connection. As another example, the applicable routing policy149could specify that the connection is permitted using a tunneled connection provided by the tunnel client133and tunnel server106. In this example, the tunnel client133could respond to the network driver129with a command to redirect the connection to the relay service139. As a third example, the applicable routing policy149could specify that the connection is permitted, but should be made using a bypassed connection directly with the external remote host116using the external IP address166for the external remote host116. Accordingly, the tunnel client133could retrieve the external IP address166from the hostname lookup table153and provide it to the network driver129with a command to connect directly to the external remote host116using the provided external IP address166.

However, the tunnel client133may not evaluate a routing policy149in every instance. For example, the connection request could include an external IP address166. As discussed previously, the external IP address166could map to any number of hostnames163or internal IP addresses169. Therefore, the tunnel client133may opt not to search for or evaluate a routing policy149, but instead send a response to the network driver129to establish a connection to the external remote host116directly (e.g., over a bypassed connection).

In the second, alternative implementation, the network driver129can evaluate the request from the client application126to initiate the network connection instead of the tunnel client133. Accordingly, the network driver129could use the IP address provided in the network connection request from the client application126to search for an applicable routing policy149. If the routing policy149specified that the network connection were to be blocked, the network driver129could close the connection. If the routing policy149specified that the connection were to be routed through a tunneled connection to its final destination (e.g., the internal remote host109or the external remote host116), then the network driver129could establish a connection with the relay service139provided by the tunnel client133to establish the tunneled connection. Likewise, if the routing policy149specified that the network connection were to use a bypassed connection to connect to an external remote host116directly, the network driver could establish the bypassed connection with the external remote host116.

Referring next toFIG.2, shown is a flowchart that provides one example of the operation of the local DNS server143to resolve DNS queries. As an alternative, the flowchart ofFIG.2can be viewed as depicting an example of elements of a method implemented in the network environment100.

Beginning at step203, the local DNS server143receives a DNS query from the DNS resolver136. The DNS query can include a hostname163, such as a hostname163identifying an internal remote host109or an external remote host116.

Next at step206, the local DNS server143sends or relays the DNS query to an external DNS server119. The request can be sent through a tunneled connection established by the tunnel client133and tunnel server106or through a bypassed connection that passes over the network123directly to the external DNS server119. The external DNS server119may have been previously specified when the local DNS server143was originally configured or when the client device103first connected to the network123. For instance, the external DNS server119may have been specified using the dynamic host configuration protocol (DHCP) when the client device103first connected to the network123.

Then at step209, the local DNS server143receives a response from the external DNS server119. The response can include an external IP address166to which the hostname163maps. In instances where the external DNS server119implements various security protocols (e.g., DNSSEC), the local DNS server143can validate the response received from the external DNS server119as specified by the security protocol(s).

In parallel at steps213and216, the local DNS server143similarly sends or relays the DNS query to an internal DNS server113. The request can be sent through a tunneled connection established by the tunnel client133and tunnel server109. The internal DNS server113may have been identified or previously specified to the client device103when the tunnel client133first established a tunneled connection with the tunnel server106.

Subsequently at step219, the local DNS server143saves the responses to the hostname lookup table153. If the hostname163has not been previously resolved by the local DNS server143, the local DNS server143can create a new entry in the hostname lookup table153to create a mapping between the hostname163, external IP address166received from the external DNS server119at step209, and the internal IP address169received from the internal DNS server113at step216. If the hostname163has already been previously resolved by the local DNS server143, then the local DNS server143can instead update an existing mapping to reflect any new information, such as a new external IP address166or internal IP address169associated with the hostname163.

Finally at step223, the local DNS server143provides an IP address to the DNS resolver136. This can be either the internal IP address169or the external IP address166, depending on the particular implementation deployed. For example, the local DNS server143could provide the internal IP address169by default, and the external IP address166if an internal IP address169was not returned at step216. As another example, the local DNS server143could provide either the internal IP address169or the external IP address166based on a routing policy149. In this example, the local DNS server143could search for a routing policy149applicable to the hostname163and then return the IP address type specified by the routing policy149.

FIG.3provides an architectural diagram illustrating the interactions between the local DNS server143provided by the tunnel client133and the various other components of the network environment100. As illustrated, client applications126are in communication with the DNS resolver136. If the DNS resolver136is unable to response with an appropriate IP address for the hostname163specified in the DNS query (e.g., from a cache or from the hostname lookup table153), then the DNS query can be recursively resolved. To recursively resolve the DNS query, the DNS resolver136communicates the DNS query to the local DNS server143. If the local DNS server143is unable to respond with an appropriate IP address (e.g., an internal IP address169or external IP address166previously cached in the hostname lookup table153), then the local DNS server143can forward the DNS request containing the hostname163to the external DNS server119and the internal DNS server113. The external DNS server113and internal DNS server119can both respond to the DNS query from the local DNS server143, which stores the results and forwards one of the resolved IP addresses (e.g., the external IP address166or internal IP address169) to the DNS resolver136. The DNS resolver126can then forward the IP address to the requesting client application126.

Referring next toFIG.4A, shown is a flowchart that provides one example of the operation of the tunnel client133to route TCP connections on behalf of a client application126within the network environment100ofFIG.1. As an alternative, the flowchart ofFIG.4Acan be viewed as depicting an example of elements of a method implemented in the network environment100.

Beginning with step401a, the tunnel client133receives a request from the network driver129to create a TCP connection. Because the connection is a TCP connection, it will include an IP address representing the endpoint of the TCP connection, but lack a hostname163.

Proceeding to step403a, the tunnel client133can parse the TCP connection request to determine the endpoint IP address. For reference, the endpoint IP address is the IP address (e.g., internal IP address169or external IP address166) of a remote host (e.g., internal remote host109or external remote host116) to which the network driver129is attempting to establish a connection.

Next at step406a, the tunnel client133can query the hostname lookup table153to determine a hostname163that is mapped to the endpoint IP address of the TCP connection. For example, if the TCP connection request includes an internal IP address169, the tunnel client133could search the hostname lookup table153for a hostname163mapped to the internal IP address169specified as the endpoint of the TCP connection. Similarly, if the TCP connection request includes an external IP address166, the tunnel client133could search the hostname lookup table153for a hostname163mapped to the external IP address166specified as the endpoint of the TCP connection.

Then at step409a, can identify a routing policy149based on the hostname163previously identified at step406a. For example, the routing policy149can specify a particular type of action to be taken in response to a TCP connection specifying an endpoint IP address that maps to the hostname163. Examples of such actions include blocking the connection, redirecting the connection to the relay service139in order to utilize a tunneled connection across the network123, or directly connecting to the endpoint IP address using a bypassed connection across the network123.

Subsequently at step413a, the tunnel client133then routes or causes the TCP connection to be routed based on the routing policy149identified at step409a. For example, if the routing policy149specifies that the connection is to be blocked, the tunnel client133could return a connection denied or connection closed status to the network driver129. In some implementations, the tunnel client133could alternatively allow the TCP connection to time out. As another example, if the routing policy149specifies that the connection is to be routed across a tunneled connection, the tunnel client133could provide a TCP response to the network driver129redirecting the connection to the relay service139. Once the network driver129connects to the relay service139, the connection can be through the tunnel server106before reaching the final endpoint. In a similar example, if the routing policy149specifies that the connection is to be made directly with the endpoint IP address, the tunnel client133can return a response to the network driver129redirecting the TCP connection to the endpoint IP address directly. This allows for the network driver129to connect to a remote host (e.g., external remote host116) using a bypassed connection.

In some instances, the routing of a TCP connection can require that the endpoint IP address be rewritten. For example, if the network driver129is attempting to initiate a TCP connection with an external remote host116and specifies an external IP address166as the endpoint IP address for the TCP connection, the network driver129will need the internal IP address169if the routing policy149specifies that the connection must be completed using a tunneled connection between the relay service139of the tunnel client133and the tunnel server106. In such examples, the tunnel client133could provide the internal IP address169to the network driver129, thereby allowing the network driver129to modify the TCP connection request in order to connect in a manner that complies with the routing policy149. As a similar example, the tunnel client133could provide to the network driver129the external IP address166if the network driver129is attempting to access a remote host using a tunneled connection, but a routing policy149specifies that the connection should be made using a bypassed connection.

Referring next toFIG.4B, shown is a flowchart that provides an alternative example of the operation of the tunnel client133to route TCP connections on behalf of a client application126within the network environment100ofFIG.1. As an alternative, the flowchart ofFIG.4Bcan be viewed as depicting an example of elements of a method implemented in the network environment100.

Beginning with step403b, the tunnel client133receives a request from the network driver129to create a TCP connection. Because the connection is a TCP connection, it will include an IP address representing the destination of the TCP connection, but lack a hostname163.

Next at step406b, the tunnel client133can parse the TCP connection request to determine the endpoint IP address. For reference, the endpoint IP address is the IP address (e.g., internal IP address169or external IP address166) of a remote host (e.g., internal remote host109or external remote host116) to which the network driver129is attempting to establish a connection.

Unlike the method depicted inFIG.4A, the tunnel client133can, at step409b, identify an applicable routing policy149based on the endpoint IP address identified previously at step406b. In certain implementations, the configuration of the hostname lookup table153and the setup of the routing policies149may allow for the tunnel client133to identify a routing policy149without identifying a hostname163associated with the endpoint IP address in the TCP connection request. For example, if there is a one-to-one mapping between internal IP addresses169and hostnames163, then any routing policy149that is applicable to a particular internal IP address169is applicable to a specific hostname163. Likewise, if there is a default routing policy149for endpoint IP addresses (e.g., all TCP connections with an external IP address166are to be routed across a bypassed connection), then identifying a routing policy149by IP address is equivalent to identifying a routing policy149by hostname163.

Subsequently at step413b, the tunnel client133then routes or causes the TCP connection to be routed based on the routing policy149identified at step409b. For example, if the routing policy149specifies that the connection is to be blocked, the tunnel client133could return a connection denied or connection closed status to the network driver129. In some implementations, the tunnel client133could alternatively allow the TCP connection to time out. As another example, if the routing policy149specifies that the connection is to be routed across a tunneled connection, the tunnel client133could provide a TCP response to the network driver129redirecting the connection to the relay service139. Once the network driver129connects to the relay service139, the connection can be through the tunnel server106before reaching the final endpoint. In a similar example, if the routing policy149specifies that the connection is to be made directly with the endpoint IP address, the tunnel client133can return a response to the network driver129redirecting the TCP connection to the endpoint IP address directly. This allows for the network driver129to connect to a remote host (e.g., external remote host116) using a bypassed connection.

In some instances, the routing of a TCP connection can require that the endpoint IP address be rewritten. For example, if the network driver129is attempting to initiate a TCP connection with an external remote host116and specifies an external IP address166as the endpoint IP address for the TCP connection, the network driver129will need the internal IP address169if the routing policy149specifies that the connection must be completed using a tunneled connection between the relay service139of the tunnel client133and the tunnel server106. In such examples, the tunnel client133could provide the internal IP address169to the network driver129, thereby allowing the network driver129to modify the TCP connection request in order to connect in a manner that complies with the routing policy149. As a similar example, the tunnel client133could provide to the network driver129the external IP address166if the network driver129is attempting to access a remote host using a tunneled connection, but a routing policy149specifies that the connection should be made using a bypassed connection.

Referring next toFIG.5A, shown is a flowchart that provides one example of the operation of the tunnel client133to route UDP connections on behalf of a client application126within the network environment100ofFIG.1. As an alternative, the flowchart ofFIG.5Acan be viewed as depicting an example of elements of a method implemented in the network environment100.

Beginning with step503a, the tunnel client133can receive a request from the network driver129to relay a UDP datagram. Because the connection is a UDP connection, it will include a destination IP address176representing the destination or endpoint of the UDP datagram, but lack a hostname163. Upon receipt, the tunnel client133can also process the request. For example, the tunnel client133can create an entry in the address translation table156for the UDP datagram. The entry can include the destination IP address176of the UDP datagram and the port that the UDP datagram is attempting to connect to. The port could be stored as a source port173for subsequent state tracking and address translation.

Proceeding to step506a, the tunnel client133can parse the UDP relay request to determine the endpoint IP address for the UDP datagram. For reference, the endpoint IP address is the IP address (e.g., internal IP address169or external IP address166) of a remote host (e.g., internal remote host109or external remote host116) to which the network driver129is attempting to establish a UDP connection on behalf of a client application126.

Then at step509a, the tunnel client133can query the hostname lookup table153to determine a hostname163that is mapped to the endpoint IP address of the UDP connection. For example, if the UDP connection request includes an internal IP address169, the tunnel client133could search the hostname lookup table153for a hostname163mapped to the internal IP address169specified as the endpoint of the UDP connection. Similarly, if the UDP connection request includes an external IP address166, the tunnel client133could search the hostname lookup table153for a hostname163mapped to the external IP address166specified as the endpoint of the UDP connection.

Next at step513a, can identify a routing policy149based on the hostname163previously identified at step509a. For example, the routing policy149could specify a particular type of action to be taken in response to a UDP connection specifying an endpoint IP address that maps to the hostname163. Examples of such actions include blocking the connection, redirecting the connection to the relay service139in order to utilize a tunneled connection across the network123, or directly connecting to the endpoint IP address using a bypassed connection across the network123.

Moving on to step516a, the tunnel client133then routes or causes the UDP connection to be routed based on the routing policy149identified at step513a. For example, if the routing policy149specifies that the connection is to be blocked, the tunnel client133could return a connection denied or connection closed status to the network driver129. In some implementations, the tunnel client133could drop the UDP datagram, simulating a network timeout or error. As another example, if the routing policy149specifies that the connection is to be routed across a tunneled connection, the tunnel client133could provide a UDP response to the network driver129redirecting the connection to the relay service139. Once the network driver129connects to the relay service139, the connection can be through the tunnel server106before reaching the final endpoint. In a similar example, if the routing policy149specifies that the connection is to be made directly with the endpoint IP address, the tunnel client133can return a response to the network driver129redirecting the UDP connection to the endpoint IP address directly. This allows for the network driver129to connect to a remote host (e.g., external remote host116) using a bypassed connection.

In some instances, the routing of a UDP connection can require that the endpoint IP address be rewritten. For example, if the network driver129is attempting to initiate a UDP connection with an external remote host116and specifies an external IP address166as the endpoint IP address for the UDP connection, the network driver129will need the internal IP address169if the routing policy149specifies that the connection must be completed using a tunneled connection between the relay service139of the tunnel client133and the tunnel server106. In such examples, the tunnel client133could provide the internal IP address169to the network driver129, thereby allowing the network driver129to modify the UDP connection request in order to connect in a manner that complies with the routing policy149. As a similar example, the tunnel client133could provide to the network driver129the external IP address166if the network driver129is attempting to access a remote host using a tunneled connection, but a routing policy149specifies that the connection should be made using a bypassed connection.

Then at step519a, the tunnel client133can determine whether or not the UDP datagram or connection was relayed or routed through a tunneled connection using the relay service139. If the UDP connection was not routed through a tunneled connection, then the process ends. However, if the UDP connection was routed through a tunneled connection, then the process proceeds to step523a.

Next at step523a, the tunnel client133(e.g., the relay service139) can receive a response to the UDP datagram that was previously routed or transmitted through the tunneled network connection. Because of the stateless or connectionless nature of UDP, client applications126often verify the source IP address179and port of UDP responses to confirm that the UDP response is a response to a previously sent request. However, a datagram being received from the tunnel server106can have a source IP address179that fails to match the destination IP address176of the original UDP request. Accordingly, the tunnel client133can rewrite the source IP address179of the UDP response to match the original destination IP address176of the original UDP request in order to allow the client application126to correctly verify the UDP response. This may be conceptually viewed as a “man-in-the-middle” being performed on the UDP connection.

Proceeding to step526a, the tunnel client133can relay or provide the UDP response to the network driver129, which can in turn forward the UDP response to the client application126. The process can then subsequently end.

Referring next toFIG.5B, shown is a flowchart that provides one example of the operation of the tunnel client133to route UDP connections on behalf of a client application126within the network environment100ofFIG.1. As an alternative, the flowchart ofFIG.5Bcan be viewed as depicting an example of elements of a method implemented in the network environment100.

Beginning with step503b, the tunnel client133can receive a request from the network driver129to relay a UDP datagram. Because the connection is a UDP connection, it will include a destination IP address176representing the destination or endpoint of the UDP datagram, but lack a hostname163. Upon receipt, the tunnel client133can also process the request. For example, the tunnel client133can create an entry in the address translation table156for the UDP datagram. The entry can include the destination IP address176of the UDP datagram and the port that the UDP datagram is attempting to connect to. The port can be stored as a source port173for subsequent state tracking and address translation.

Proceeding to step506b, the tunnel client133can parse the UDP relay request to determine the endpoint IP address for the UDP datagram. For reference, the endpoint IP address is the IP address (e.g., internal IP address169or external IP address166) of a remote host (e.g., internal remote host109or external remote host116) to which the network driver129is attempting to establish a UDP connection on behalf of a client application126.

Next at step513b, can identify a routing policy149based on the hostname163previously identified at step509b. For example, the routing policy149could specify a particular type of action to be taken in response to a UDP connection specifying an endpoint IP address that maps to the hostname163. Examples of such actions include blocking the connection, redirecting the connection to the relay service139in order to utilize a tunneled connection across the network123, or directly connecting to the endpoint IP address using a bypassed connection across the network123.

Unlike the method depicted inFIG.5A, the tunnel client133can, at step513b, identify an applicable routing policy149based on the endpoint IP address identified previously at step506b. In certain implementations, the configuration of the hostname lookup table153and the setup of the routing policies149may allow for the tunnel client133to identify a routing policy149without identifying a hostname163associated with the endpoint IP address in the UDP connection request. For example, if there is a one-to-one mapping between internal IP addresses169and hostnames163, then any routing policy149that is applicable to a particular internal IP address169is applicable to a specific hostname163. Likewise, if there is a default routing policy149for endpoint IP addresses (e.g., all UDP connections with an external IP address166are to be routed across a bypassed connection), then identifying a routing policy149by IP address is equivalent to identifying a routing policy149by hostname163.

Moving on to step516b, the tunnel client133then routes or causes the UDP connection to be routed based on the routing policy149identified at step513a. For example, if the routing policy149specifies that the connection is to be blocked, the tunnel client133could return a connection denied or connection closed status to the network driver129. In some implementations, the tunnel client133could drop the UDP datagram, simulating a network timeout or error. As another example, if the routing policy149specifies that the connection is to be routed across a tunneled connection, the tunnel client133could provide a UDP response to the network driver129redirecting the connection to the relay service139. Once the network driver129connects to the relay service139, the connection can be through the tunnel server106before reaching the final endpoint. In a similar example, if the routing policy149specifies that the connection is to be made directly with the endpoint IP address, the tunnel client133can return a response to the network driver129redirecting the UDP connection to the endpoint IP address directly. This allows for the network driver129to connect to a remote host (e.g., external remote host116) using a bypassed connection.

In some instances, the routing of a UDP connection can require that the endpoint IP address be rewritten. For example, if the network driver129is attempting to initiate a UDP connection with an external remote host116and specifies an external IP address166as the endpoint IP address for the UDP connection, the network driver129will need the internal IP address169if the routing policy149specifies that the connection must be completed using a tunneled connection between the relay service139of the tunnel client133and the tunnel server106. In such examples, the tunnel client133could provide the internal IP address169to the network driver129, thereby allowing the network driver129to modify the UDP connection request in order to connect in a manner that complies with the routing policy149. As a similar example, the tunnel client133could provide to the network driver129the external IP address166if the network driver129is attempting to access a remote host using a tunneled connection, but a routing policy149specifies that the connection should be made using a bypassed connection.

Then at step519b, the tunnel client133can determine whether or not the UDP datagram or connection was relayed or routed through a tunneled connection using the relay service139. If the UDP connection was not routed through a tunneled connection, then the process ends. However, if the UDP connection was routed through a tunneled connection, then the process proceeds to step523b.

Next at step523b, the tunnel client133(e.g., the relay service139) can receive a response to the UDP datagram that was previously routed or transmitted through the tunneled network connection. Because of the stateless or connectionless nature of UDP, client applications126often verify the source IP address179and port of UDP responses to confirm that the UDP response is a response to a previously sent request. However, a datagram being received from the tunnel server106may have a source IP address179that fails to match the destination IP address176of the original UDP request. Accordingly, the tunnel client133can rewrite the source IP address179of the UDP response to match the original destination IP address176of the original UDP request in order to allow the client application126to correctly verify the UDP response. This may be conceptually viewed as a “man-in-the-middle” being performed on the UDP connection.

Proceeding to step526b, the tunnel client133can relay or provide the UDP response to the network driver129, which can in turn forward the UDP response to the client application126. The process can then subsequently end.

Referring next toFIG.6, shown is a flowchart that provides one example of the operation of the network driver129to establish network connections on behalf of a client application126within the network environment100ofFIG.1. As an alternative, the flowchart ofFIG.6can be viewed as depicting an example of elements of a method implemented in the network environment100.

Beginning at step603, the network driver129can obtain network traffic from a client application126. This can be performed in a number of ways. For example, the client application126may be specifically configured use the network driver129instead of another driver or interface provided by the operating system of the client device103. As another example, the network driver129can replace or impersonate a driver or interface provided by the operating system of the client device103. In this example, all client applications126attempting to access the network123would utilize the network driver129, allowing the network driver129to intercept or capture any traffic originating from any client application126installed on the client device103.

Next at step606, the network driver129can determine whether the client application126that originated the network traffic obtained at step603is a managed application. For example, the network driver129can determine an identifier for the client application126(e.g., a process name) and see if the identifier is present in the list of managed applications159. However, in those embodiments where a client application126must be specifically configure to utilize the network driver129, the network driver129may presume or otherwise assume that any client application126that uses the network driver129to access the network123is a managed application. If the network driver129determines that the client application126is a managed application, then the process continues to step609. However, if the network driver129determines that the client application126is not a managed application, then the process instead continues to step619.

If the process proceeds to step609, the network driver129can make a connection with the tunnel client133. As part of the connection process, the network driver129makes a connection request (e.g., a TCP connection request or forwards a copy of a UDP datagram).

Subsequently at step613, the network driver129can receives a connection response from the tunnel client133that provides routing information. The routing information may be based on one or more routing policies149evaluated by the tunnel client. For example, the routing information may specify that the connection be closed, that the connection be forwarded through the relay service139provided by the tunnel client133, or that the connection be made directly with the remote host.

Moving on to step616, the network driver129forwards the network traffic from the client application as instructed by the tunnel client133. If the connection is to be blocked, the network driver129can close the connection and report it as closed, terminated, or rejected to the client application126. Likewise, if the connection is to be routed through a tunneled connection, the network driver129may connect with the relay service139and forward the traffic from the client application126through the tunneled connection. Similarly, if the connection is to be made directly with the remote host, the network driver129can create a bypassed connection across the network123to directly connect with the remote host. After establishing the connection or forwarding the network traffic, the process ends.

However, if the process instead proceeded from step606to step619, then the network driver129can create a network connection in the manner requested by the client application126. For example, if the network connection specifies an external IP address166, the network driver129can create a bypassed connection with the external remote host116. Similarly, if the network connection specifies an internal IP address169, the network driver129can create a tunneled connection to the appropriate internal remote host109or external remote host116.

FIG.7provides an architectural diagram illustrating the interactions between the client application126, the network driver129, the tunnel client133, the tunnel server106, and an external remote host119or internal remote host109within the network environment100. As illustrated, a client application126can call the network driver129to establish a network connection. The network driver129can then establish either a bypassed connection directly with a remote host (e.g., the external remote host119) or a tunnel connection utilizing a network tunnel established between the tunnel client133and the tunnel server106. Whether the network driver129establishes a bypassed connection or a tunneled connection is determined using the previously described processes ofFIGS.2-6. If the network driver129utilizes a tunneled connection, the network traffic can be sent to either an internal remote host109or an external remote host119. Likewise, if the network driver129utilizes a bypassed connection, the network traffic can be sent to the external remote host119directly.

A number of software components are stored in the memory of a computing device and are executable by a processor. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor. Examples of executable programs can be a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory and run by the processor, source code that can be expressed in proper format such as object code that is capable of being loaded into a random access portion of the memory and executed by the processor, or source code that can be interpreted by another executable program to generate instructions in a random access portion of the memory to be executed by the processor. An executable program can be stored in any portion or component of the memory including random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

The memory can include both volatile and nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power. Thus, the memory can comprise random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, and/or other memory components, or a combination of any two or more of these memory components. In addition, the RAM can comprise static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM) and other such devices. The ROM can comprise a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other like memory device. Also, the processor can represent multiple processors and/or multiple processor cores and the memory can represent multiple memories that operate in parallel processing circuits, respectively.

The computer-readable medium can represent any one of many physical media such as magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium would include, but are not limited to, magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Also, the computer-readable medium can be a random access memory (RAM) including static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). In addition, the computer-readable medium can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other type of memory device.

Although the applications or services described herein can be embodied in software or code executed by general purpose hardware as discussed above, as an alternative the same can also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies can include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field-programmable gate arrays (FPGAs), or other components. Such technologies are generally well known by those skilled in the art and, consequently, are not described in detail herein.

Although the flowcharts show a specific order of execution, it is understood that the order of execution can differ from that which is depicted. For example, the order of execution of two or more blocks can be scrambled relative to the order shown. Also, two or more blocks shown in succession in the flowcharts can be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks shown in the flowcharts can be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids, etc. It is understood that all such variations are within the scope of the present disclosure.

Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the disclosure. Many variations and modifications can be made to the above-described embodiment(s) without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.