Process Level Routing
Routing is the process of directing network communications to the intended destination. This is normally thought of in the context of the Internet where a packet moves between routers until it eventually reaches its destination. However, the routing of that packet starts before it leaves your system.
Every computer has its own internal route table that guides how packets move within, and ultimately out of, the computer. This route table does not provide a lot of flexibility especially when multiple routes may exist. Generally, the system will use a metric to determine which route is the best to take however, that may not always be the route you desire.
For example, suppose you have two VPN connections running on your computer along with your normal Internet connection. The first VPN is for your work while the second VPN is for your privacy. It's entirely possible that packets intended for your work VPN may leak onto the other connections and vice-versa. This is because of how routing works within the system itself. Some packets, while intended for a specific destination, may end up going another route because it was calculated to be better. And unless the process allows you to specifically set which network to use, you have little control.
Route Shield does away with the internal route tables based on metrics. Instead,
Route Shield allows you to configure
applications to use the exact network resources that are required.
It is important to understand how
Route Shield makes its routing decisions. There is an order of precedence that it follows based on
configured settings and other available information. In some situations,
Route Shield will fall back to default settings while in
others it may simply fail the connection.
First, we have to look at all the ways that
Route Shield can route packets.
Route Shield monitors for outbound DNS requests and proxies them to the
service. The service will determine the calling process and extract the domain. Those two pieces of information are then used to determine the
appropriate route and options.
Route Shield will first check if the domain should be sinkholed. If so, the request is just dropped. Next, if DNS caching is enabled
Route Shield looks to see if a valid response based on the time to live (TTL) value is available. If so, it will simply return
the result. The next step is to check if the domain has a mapping available. If a provider is mapped, then that is what will be used for the request.
If no domain mapping is found, then
Route Shield checks if the process has a configured DNS route. If so, then that will be the provider
that will be used. If not, it will finally check if the system-wide settings are enabled. If no system-wide settings are configured then the
packet will be resent without any modification.
Route Shield has the DNS provider, it will then check if any bindings are set. First it checks if the process has a configured
DNS binding. If not, it will check if the system-wide DNS binding is set. If no binding is set, then the system default will apply.
The DNS request is now ready to be routed to the appropriate DOH or DOT server. If it succeeds then the response is parsed and the IP addresses are extracted. These are checked against the sinkhole list and if any one matches, the entire packet is dropped. If none match and if caching is enabled, then the result is added to the cache list.
This process can be seen in this simple flow-chart.
1) Domain sinkhole check 1a) Drop if match 2) Cached responses 2a) Return cached response 3) Domain mapping 3a) Goto binding check (6) 4) Process mapping 4a) Goto binding check (6) 5) System-wide settings 6) Binding: 6a) Process binding 6a1) Goto lookup (7) 6b) System-wide binding 7) Perform lookup 8) IP sinkhole check 8a) Drop if match 9) Add response to cache 10) Provide response to original process
Note that there are numerous error points within this workflow. Everything from malformed requests and responses to network errors may cause this
workflow to fail. If that does occur,
Route Shield will simply try to resend the original packet without any modifications.
Route Shield has a built-in proxy server designed to route connections to the appropriate destination. For proxying to work,
Route Shield driver will first re-route all new outbound HTTP and HTTPS connections to the
Route Shield service.
Only HTTP (port 80) and HTTPS (port 443) can be proxied by
Route Shield. Process details and information about the request
are extracted and is then used to make the routing decision.
Route Shield will first check if the domain has a proxy mapping. If VPN mapping is also enabled, the VPN mapping will also be
checked here as well.
Route Shield will next check if the process has a defined route. If a process route is set and if no
proxy or VPN mapping exists then
Route Shield will use the process route details. If either the proxy or VPN process details is
not set, then
Route Shield will use the system-wide settings for both settings.
If no proxy is set then the connection will continue on as originally intended. And if no VPN is set, then the system default bind point will be used.
VPN routing works very similar to proxy routing and as discussed, is intertwined with both DNS and proxying.
First, if proxying is enabled, then VPN binding occurs within
Route Shield's proxy server and is described above. However,
if proxying is not enabled, then VPN routing occurs in the kernel and is based solely on configured process and system settings. There is
no domain mapping available in the kernel.
When a process starts, the
Route Shield driver checks if a route is configured. If it is, it marks the process so it knows to
use the VPN settings when a new binding occurs. When it detects a new binding, it determines the process and will use the saved settings
if they were set. If no settings were set, then it will check if the system-wide settings have been set. If no system-wide settings were
set, then the binding continues without any modification.